Apr 29

Don’t forget to change the Registry before upgrading your Cisco 4500-E with a SUP-8E!!!

I recently acquired a brand new Cisco 4506-E with the Supervisor 8-E. The Supervisor came with the latest K9 version software. This was very odd for me, I almost always have to upgrade my new network equipment when I get it. After configuring the switch I relocated it to the wiring closet where it is going to spend the rest of it’s life.

Two days before the scheduled installation, I turned it on to make a couple changes that needed to be made. Once it was booted up, I issued the “show ip int brief” command and the only interfaces that showed up were the tengigabit interfaces on the Supervisor. I did some more digging and found the following error in the log %C4K_CHASSIS-3-BACKPLANESEEPROMREADFAILED. Cisco’s Error Message Decoder stated that the chassis was bad and to return the chassis.

After replacing the chassis, I still had the same error and none of the line cards works. Cisco then sent me a replacement Supervisor 8-E. I installed the replacement Supervisor 8-E, configured it enough to get on the network, then did a TFTP to get the configuration file on it. Knowing it took 5-7 minutes to boot up, I stepped away and when I came back I was able to validate the config loaded (From the console port).


After the chassis was booted up and the configuration was validated I attempted to configure the SSH version and generate the crypto key. The commands where not there. I thought this was very odd because there was only one software version for this platform and the original Supervisor came with the correct version. After checking, this version did not have the SSH feature so I needed to upgrade the switch to Crypto image cat4500es8-universalk9.SPA.03.03.00.XO.151-1.XO.bin. The only difference in the file name is the K9.

I copied the file to the bootflash and changed the boot statement to “boot system flash bootflash:/cat4500es8-universalk9.SPA.03.03.00.XO.151-1.XO.bin”, saved the configuration and reloaded. The switch ignored the boot statement and used the first file in the bootflash. I thought that I had the boot statement wrong, so I tried it without the /, same thing.

After reading the configuration guide I found that the registry needed to be changed to 0X0102. This registry entry tells the switch to read the boot statement. So I entered the following command config-register 0x0102, saved the configuration and reloaded. The switch now booted up with the new image and I was able to configure SSH on the switch.

Like so many other Cisco products, I thought I could simply change the boot statement, save and reload. My assumption failed me on this upgrade. Because of this, I always recommend reading the configuration guides or release notes. Sometimes I get in a hurry and don’t read them. When I do that, I usually get reminded that I need to read the documentation.

Have you found other networking devices that you have to change the config-register to tell it to read the boot statement? If so, please share your experience

Feb 25

QOS on the 4500-E with IOS XE is different from the older 4500s.

For years I have configured QOS on Cisco switches. The 4500’s and 6500’s always caused me the most frustration. Depending on the line card, you may have 2 or 4 hardware queues with the Priority queue different on each platform. The 4500’s and 6500’s are different then the other Cisco platforms.

I recently had the privilege to setup a new 4506-E running IOS-XE 3.3.0X0(15.1(1)XO). For the most part, this switch was very similar to the older 4500’s. Most of my configuration from the other 4500’s easily pasted into the switch. I was doing well until I got to the QOS portion of the config. I found that with the exception of the Marking policy, nothing else worked.

What did not work?
1. Trust DSCP commands on the uplink ports
2. Egress queueing, mapping COS value to the hardware queue
3. COS To DSCP mapping
4. Selecting the priority queue, what queue was the priority queue?

After some more digging I found out that the 4500 trust DSCP and COS values by default. This explains why the commands would not work. This in itself may cause new challenges to you. If you are not careful, an end user or application could put all of their traffic in the EF queue and use up all of your priority bandwidth. To resolve this challenge, I mark all traffic coming in from an edge port. How do you handle this?

Egress queuing, this is done with a policy map just like a router. The switch comes with 8 hardware queues. (I’m very happy to hear that Cisco finally added 8 hardware queues per port on their switches. Other vendors have been doing this for years.) In your policy map you identify what queue you want to be the priority queue, then under each class you can specify the bandwidth you want to give that queue. For more information on how to configure the policy map, please refer to the Cisco IOS XE Documentation You do need to be careful while going through this guide. The IOS XE software works on routers too. You may find documentation that only applies to ASR routers, but does not work on the 4500 platform.

COS to DSCP mappings may not be needed. I mark all of my traffic at the edge port with DSCP values. I mark DSCP so I do not need to worry about the COS value being dropped going over an access port. With IOS XE, the outbound queuing policy is capable of queuing egress traffic by DSCP value. Due to this, I don’t have to worry about the COS to DSCP or DSCP to COS mappings.

Now for the priority queue and mapping QOS markings to a hardware queue. This has been a major frustration for me due to the different capabilities and commands on the variety of Cisco platforms. To me, this has been no different then if every platform was a different vendors equipment. Due to the challenges in the past, I was really getting upset when I wasn’t able to find any documentation on how to perform this mapping. After speaking with my Cisco SE, I found out that IOS XE will automatically place the different classes in your policy map into different hardware queues. The specific queue for the priority traffic is GONE!!! The unique commands of allocating QOS markings to hardware queue is GONE!!!

Even though this new IOS was frustrating at first, I believe the changes in IOS regarding QOS is a drastic improvement. The old method was more difficult then I feel it should be. As long as you understand Cisco’s MQC logic, the change in Trust and automatic queuing methods, I believe you will find this IOS much better to work with. Do you agree?

Other then Marking and queuing, what other changes have you notices in this new version of software?
Are you happy with the newer IOS XE on the 4500?