In our last Daily Feature regarding the Cisco 4006 switch OS upgrade, we discussed a process gone completely awry. It was definitely a worst-case scenario. The idea was not so much how-to but rather how not to. In this Daily Feature, I’m going to describe a better method that can be employed instead of the previous madness. With this tried-and-true procedure, you can be assured of a successful upgrade.

Pre-upgrade check
First of all, let’s do our homework. It’s a good idea to check the supervisor module information. Keep in mind that you’re really upgrading the CatOS on the supervisor module. The following command will give us the information we need:
Switch>(enable) show module

After we get the output from this command, we can visit the Cisco Web site for OS-specific information regarding our switch engine. Make sure that you have enough memory for the OS version you’re upgrading to and that it is an OS version compatible with your hardware. Assuming you already have a working OS on your switch, I recommend leaving it on the file system at least until you have successfully loaded the new version. You can check the free space on the flash file system as follows:
Switch>(enable) show flash

If you have enough room remaining for the new OS file, then it’s time to get started.

The simple upgrade process
If your switch is already configured and running an OS version, the upgrade process is fairly straightforward. The tools you’ll need to complete the process as easily as possible are a laptop (with a NIC), an RJ-45 network patch cable, a TFTP server, and a console cable. The TFTP server could actually be running somewhere on the network, or you could run it on the laptop. Also, the laptop is not an absolute necessity for this process, but it’s nice to have if something goes wrong and you have to physically visit the switch in a tiny, dark wiring closet. You could actually perform the entire process from a remote network-attached workstation, as long as it has Telnet access to the switch. Let’s assume that we’re using a laptop to directly connect to the switch. To start, you’ll need to connect to the switch via console to handle any preliminaries. Connect the console cable from the serial port on the laptop to the console port of the switch. Adapters may be necessary at either or both ends of the cable. These adapters generally come with the switch. It’s not a bad idea to leave the console cable connected to the switch so that it doesn’t get misplaced. Now, start a terminal program like HyperTerminal on the laptop, and configure it for the serial port that the console cable is connected to. After starting the terminal session and logging into the switch, you need to get the IP address and subnet mask from the management interface, sc0. To do so, execute the following:
Switch>(enable) show interface

Now you can configure the laptop with an IP address in the same subnet as the sc0 management interface on the switch. Depending on your laptop OS, you may need to restart it at this point for the TCP/IP stack to load the new settings. Continuing with another console-based session, we need to determine which VLAN the sc0 interface resides in and find another Ethernet switch port that lies in the same one. If none of the local switch ports are in the management VLAN, we can temporarily assign one for use during our OS upgrade:
Switch>(enable) set vlan 10 2/1

In the previous example, we have determined that the management VLAN is 10, and we have placed the first port on the second module in that VLAN. We could have performed both of the previous steps in one session to save time, but the goal here is to provide an iterative step-by-step process that is easy to follow. The reason we are placing the laptop connection port in the same VLAN as sc0 is to alleviate any potential routing issues during the upgrade process. At this point, we can connect our network patch cable from the laptop NIC to the aforementioned port. We can test that connection by attempting a Telnet session from the laptop to the switch. Once that session is initiated, we have a fat Ethernet pipe to our switch that we can now use to copy the new OS file. Assuming that the TFTP server software is running on the laptop and the new OS file for the switch has been placed in the appropriate directory (on the laptop), we can begin the copy process. First, we’ll back up the existing config and OS files (just in case):
Switch>(enable) copy config tftp
Switch>(enable) copy flash tftp

After issuing the previous commands, we’ll be prompted for file names as well as the address of the TFTP server. Once the backup process is complete, you can copy the new OS file:
Switch>(enable) copy tftp flash

Again, you’ll be prompted for file names. After copying the OS file to the switch’s flash file system, you’ll want to change the boot variable to point to the new OS file when booting. To do so, use the following command:
Switch>(enable) set boot bootflash:cat4000-5.4.1.bin prepend

In this example, we have prepended the name of the new OS file, while leaving the old OS file in place as a secondary boot source, in case the new OS is problematic. To verify the value of the boot variable, use the following command:
Switch>(enable) show boot

And now for the moment of truth: Let’s reboot the switch to verify loading of the new OS version:
Switch>(enable) reset

You can watch for the OS load information as the switch reloads, but if it scrolls by too quickly (before you can initiate a terminal session), you can use the show version command after the reload is complete as described previously.

As I’ve shown here, the upgrade process in an operative switch with a running OS is not difficult. It could be performed from a workstation Telnet session across the network or, as we chose, from a directly connected laptop. The reason for our choice is simple: It’s a more foolproof method. There is nothing like a direct connection to the switch if or when the process goes wrong. However, it’s not always the case that we’re lucky enough to be operating on a running switch. The next topic we’ll deal with in this series pertains to other, more adverse scenarios. Namely, how do we recover a switch with a failed or corrupt OS? What are our options for connectivity? Stay tuned for the next article in this series on the Cisco 4006 switch, when I’ll address these and other pertinent issues.