Connecting the world…

3560

XMODEM recovery speed

Configuring switches and routers is regular work for me. But if I would like to configure a switch or a router, I have to be able to boot the specific device…. Today I had to configure some new Cisco Catalyst 3650(E) en 3750 switches. In total I had 16 switches to configure, but three of them didn’t have any IOS image in flash and weren’t able to boot.

I have never seen this before. The switches aren’t refurbished, at least that is what the customer told me. At first I didn’t see any problem, because I wanted to upload an image from rommon through TFTP. After accessing rommon, I noticed that the Catalyst 3560 en 3750 don’t support TFTP upload in rommon. This leaves an XMODEM transfer as the only available option.

The image I wanted to upload was approximately 10 MB and upload with XMODEM at a baud rate of 9600 bps isn’t really fast. I had only one laptop to use, so it would take a whole day to upload the correct image into the three switches. Because I had only one COM port, I wasn’t able to configure anything.

I wanted to speed up my XMODEM transfer to buy some time and I found a way. At the switch prompt I set the baud rate to 115200:

switch: set BAUD 115200

Next I reconfigured my terminal (TeraTerm) to use the new baud rate of 115200. I started the XMODEM recovery procedure:

switch: copy xmodem: flash:c3560-ipbasek9-mz.122-50.SE.bin

I was satisfied while looking at the transfer rate. I had some time to invite myself to a cappuccino and  chat a little with the customer. The image was transferred in approximately 30 minutes. The last step in the recovery was setting back the baud rate to 9600, reconfigure my terminal and boot the image:

switch: set BAUD 9600

switch: boot flash:c3560-ipbasek9-mz.122-50.SE.bin

It only took two hours upload the correct IOS image to the three switches. Now I am set to start the configuration.

Policy-Based Routing Catalyst 3560

Today I visited a customer where the power a Cisco Catalyst 3548XL blew up. The switch had a manufacture date of December 2000. It is an old one, but still I haven’t seen a power supply being blown up from a Cisco switch from that age.

But oké, the switch needed to be replaced. The customer ordered some 3560 switches, so all the 3548 switches could be replaced. The customer was also using a Cisco 2650XL router for routing between the different VLAN’s. Because they purchased some layer 3 switches, I also wanted to remove the Cisco 2650XL router.

The configuration of the router wasn’t that spectacular, there was only some policy-based routing (PBR) configured. The switches had IP base images, so I had to upgrade one switch with IP services firmware. After upgrading the switch, I configured the ACL and route-map as listed below.

ip access-list extended ACL-PBR
permit ip 10.10.10.0 0.0.0.255 any

!

route-map RM-PBR permit 10
match ip address ACL-PBR
set ip default next-hop 10.10.10.253

Next I wanted to apply the route-map to the correct interface, but that resultant in the following syslog message.

%PLATFORM_PBR-4-SDM_MISMATCH: PBR requires sdm template routing

Looking at the internet for a PBR example on a Cisco Catalyst 3560, I found that I had to change the SDM (Switch Database Management) template. The SDM manages the layer 2 and layer 3 switching information that is maintained in the Ternary Content Addressable Memory (TCAM). The TCAM is used for forwarding lookups.

Looking at the default configuration the switch had the following SDM configuration.

SW01-L3(config)#do sh sdm prefer
The current template is “desktop default” template.
The selected template optimizes the resources in
the switch to support this level of features for
8 routed interfaces and 1024 VLANs.

number of unicast mac addresses:                  6K
number of IPv4 IGMP groups + multicast routes:    1K
number of IPv4 unicast routes:                    8K
number of directly-connected IPv4 hosts:        6K
number of indirect IPv4 routes:                 2K
number of IPv4 policy based routing aces:         0
number of IPv4/MAC qos aces:                      0.75K
number of IPv4/MAC security aces:                 1K

Looking at the output, there is no memory configured for IPv4 policy based routing aces. This means that I have to change the SDM template to routing. This is achieved be entering the global configuration command:

sdm prefer routing

The execution of the command requires a switch reboot. After the reboot I checked the SDM configuration and noticed that memory is allocated for PBR, like displayed below:

SW01-L3(config)#do sh sdm prefer
The current template is “desktop routing” template.
The selected template optimizes the resources in
the switch to support this level of features for
8 routed interfaces and 1024 VLANs.

number of unicast mac addresses:                  3K
number of IPv4 IGMP groups + multicast routes:    1K
number of IPv4 unicast routes:                    11K
number of directly-connected IPv4 hosts:        3K
number of indirect IPv4 routes:                 8K
number of IPv4 policy based routing aces:         0.5K
number of IPv4/MAC qos aces:                      0.75K
number of IPv4/MAC security aces:                 1K

So I try to apply the route-map to the specific interface, but this resulted in another syslog message.

%PLATFORM_PBR-3-UNSUPPORTED_RMAP: Route-map RM-PBR not supported for Policy-Based Routing

Seems that the PBR configuration is not supported on the switch. At least some commands are not supported. Checking the internet again, I found a document with Unsupported Route Map Commands for a Catalyst 3550.

I had to change the next-hop configuration. I replaced the route-map with the following commands.

route-map RM-PBR permit 10
match ip address ACL-PBR
set ip next-hop 10.10.10.253

Finally, after changing the route-map it could be applied to the interface. After replacing the components I tested the route-map and it is working without any problems.