Networking

Upgrading the Cisco 4006 switch

If you're thinking of upgrading your Cisco 4006 switch, Robert McIntire shows you exactly what NOT to do.


When upgrading the OS in a Cisco switch, there are several different methods and options. It is beneficial to know what the options are so that you can choose the most appropriate path for your situation. Depending upon your scenario, there are certain things you should and should not do.

The first thing to look at is version compatibility. The version of OS that you are installing should be compatible with the supervisor engine installed in the Cisco 4000. Likewise, you’ll want to check for minimum RAM requirements. You can visit the Cisco site and, with the proper account access, you can download the desired version.

What not to do
Just for kicks, let’s look at an upgrade process that I witnessed recently. I was working under contract assisting another network engineer with a network build-out. He was installing an access layer switch that was not yet connected to the network. The goal was to update the configuration, as well as the OS version. Since all switches were going to be configured similarly, he had taken a config file from another switch that was already in production and modified it to reflect the specifics for this new switch (name, address, etc.). He did have the new OS software and the config file loaded on his laptop and was running the Cisco TFTP server software. I gathered that his plan was to copy the new config to flash first and then upgrade the OS. The switch management interface, Sc0, had already been configured via the console port with an IP address on the same network as the laptop’s NIC. He then intended to perform the rest of the operation via one of the switch’s fast Ethernet ports. Because of the size of the OS file, it was understandable that this type of port was chosen over the console.

This is actually when I came into the picture. I watched as a telnet session was set up from the laptop to the switch. Then began the slow and painful descent into an abyss of confusion. As he performed the TFTP transfer from the laptop to the switch, the telnet session errored out and froze. Keep in mind that the CatOS series of switches is different from the IOS-based switches, in that there is no discrimination between running and startup config. For instance, when copying the config from a TFTP server to the switch config on a 4000 series, the statements from the source config file actually execute in real time on the switch. Unfortunately, one of these commands caused the telnet session to drop, but which one?

Since we couldn’t reinitiate a telnet session on the Ethernet port, the sensible choice at this point was to reconnect to the switch via the console port. After discussing the previous failure, the network engineer agreed to focus just on the OS upgrade for the moment. We simply cleared the config and set up the management interface again. At this point, we were able to reconnect to a switch port using a telnet session. We then determined that there was enough free space on the file system to upload the new OS version. Unfortunately, he decided to delete the old OS before uploading the new. This may not have been so bad if he hadn’t also restarted the switch. Now we hit bottom. The switch came back up in rommon mode because there was no OS in the flash. What to do?

What went wrong
First of all, the main problem here was that we were trying to do too much at one time. The two tasks of updating the config file and upgrading the CatOS should have been divided into two discrete operations. Secondly, the sequence of the operations with respect to the connection method used was not well thought out. Specifically, let’s see if we can determine what caused the first problem (telnet session disconnect).

As you may remember, he was uploading a prepared config via a telnet session. After the fact, he mentioned that he had previously performed this operation in approximately the same manner on two other switches on the network. However, it turns out that these switches had been connected to the network at the time. In going through the config afterwards, the first thing I noticed was that the management interface address was changed and moved from the default VLAN, 1. Either one of these things could have caused the session to be disconnected. The probable reason he was successful with the first two switch upgrades may have been because they were connected to the existing network and routing mechanisms were in place.

So what have we learned from all this? Be careful when uploading a config file to your switch via a network connection. Any number of changes in that config can disrupt your session. Seriously consider performing this type of operation from the console port. The worst downside factor here is that you may not be able to access the config in the flash file system even after reconnecting via the console. The switch may still see that file as open by a TFTP session. If so, you can try to disconnect the TFTP session, but if that doesn’t work, you may need to restart the switch.

Chances are that you’ll have an incomplete and somewhat jumbled config file at this point. A solid option is to copy and paste commands selectively into the switch session while connected via Telnet. At least this way you’re not blindly uploading and changing the entire config.

The other problem was with the process of uploading the OS file. This is a no-brainer. If you’ve got enough memory, don’t delete the old OS until after you’ve got the new OS successfully functioning. There could be any number of minor problems with the new OS file that could cause you to want to revert to the old, well-known OS version. As a matter of fact, why not let the old version cohabitate with the new and add a second boot statement to boot the old OS secondarily, in case the new OS file experiences some problem?

Conclusion
What should have been an easy, straightforward task became a long-drawn-out nightmare. But now that we know where the wheels came off the wagon, we should be better prepared to try again. In the next part of this series, I’ll explore legitimate options for upgrading a Cisco 4006 switch. These options will guarantee success with a minimum of hassle. We’ll also consider contingency issues that should ensure smooth sailing during the process.

Editor's Picks

Free Newsletters, In your Inbox