From the blog.

Managing Digital Racket
The more I tune out, the less I miss it. But that has presented me with some complex choices for a nuanced approach to curb
Complexity – My Friend, My Enemy
Over my years of network engineering, I've learned that the fewer features you can implement while still achieving a business goal, the better. Why? Fewer

OT: Cat6500/Sup720 12.2(33)SXH1 Modular IOS

893 Words. Plan about 6 minute(s) to read this.

I’ve spent much of today working on upgrading a couple of our lab Catalyst 6500s with Sup720s from a pretty old version of IOS – 12.2(18)SXD5 to the shiny new 12.2(33)SXH1 Cisco released last month. Among a number of other new features, 12.2(33)SXH1 supports the VSS1440 platform. We don’t have a VSS in house yet, although it’s a “possibly” for 2009 at this point, if Cisco gets VSS to support dual sups in a chassis. We’re looking at Nexus 7000 too, but Nexus doesn’t seem like a core replacement exactly, more of a 10 gig aggregation point. We don’t push enough packets for Nexus, although it’s mind-numbingly cool.

[Added 2/13/2008: More accurately, I should state that Nexus is not a core switch replacement for the particular network I support. We see VSS as the evolutionary step we can benefit from the most. Nexus supports virtual device contexts and other interesting features like fabric spine cards, but those aren’t features we’re looking for. We want to simplify management of the network. Being able to simplify the spanning tree, eliminate HSRP, and effectively double throughput to our distribution layer will all be big wins for us when we roll out VSS. We don’t (as yet) need the throughput of a Nexus. Nexus doesn’t offer the management simplification offered by VSS.]

The 12.2(33)SXH1 comes in “standard” or “modular” flavors. I opted for the modular version. My understanding is that you can upgrade modular IOS modules via a patching process, and you don’t have to take the chassis offline to do it. It’s not an “all or nothing” IOS upgrade anymore. That makes me happy, since taking a Cat offline to do an upgrade makes people pretty nervous in my world…letting it push packets while we patch an offending module sounds much better to me.

Installing modular IOS has been a little weird compared to what I’m used to. We run native IOS on our Cat 6500s. Native IOS on a Cat6500 is a no-brainer. Download the new IOS, blast it up to your supervisor flash card (or cards if you run dual-sups), fix the boot variable, write mem, and reload the Cat. The Cat comes back up with the new version, you fix whatever the new IOS didn’t like in your old config, double check your redundancy is all good, and that’s about it. Installing modular IOS has not been quite so simple. I’m running dual sups in my Cats, so if you only run a single sup, your process will be a little simpler when you make the jump to modular IOS.

  • Modular 12.2(33)SXH1 Advanced Enterprise for the Cat 6500 with Sup720 is a HUGE image. Cisco requires 512MB of compact flash minimum. The image itself is (only) about 125MB, but you’ll end up needing a lot more flash for reasons you’ll see in a minute.
  • When you get the image onto compact flash, presumably your disk0: and slavedisk0:, you can tweak the boot variable to point to the new image and reload. Now, you won’t be running modular IOS yet after that initial reboot, but you’re getting closer.
  • Once the Cat is booted up on the new IOS bin file, you go through an “install file” process that extracts the modules that are in the bin to a directory you specify. I copied the example from the Doc CD and extracted to disk0:/sys. That installation process takes quite a while, and if you run dual sups, you’ll have to do it twice.
  • With that “install file” process done, and all your IOS modules extracted to the disk0:/sys directory (or wherever you put it), you can tell the Cat to boot from it via a “install bind” statement. “Install bind” will find the bootable image in whatever directory you point it to, and set the boot variable for you. You can add backup boot images with “boot system” if you want after that.
  • After that, you “write mem” again, then you reload your standby sup using “hw-module module x reset”. When that standby sup is done reloading, you do a “redundancy force-switchover” to cut over to it. Then you reload the other sup.
  • When the last sup is done reloading, you can “redundancy force-switchover” back to it if you want.

After all that, you’re finally running modular 12.2(33)SXH1. There’s more reading to be done on modular IOS if it interests you. I just did it on lab Cats – the lab we use at work to model production traffic, not my CCIE rack – so I didn’t pay much attention to preventing traffic interruptions. There were a LOT of traffic interruptions the way I hammered through it, make no mistake.

I don’t know if there’s a way to do a modular IOS upgrade without taking the chassis offline at some point or other, but that’s a process I’ll have to nail down before we move 12.2(33)SXH1 into production. We can tolerate a chassis outage, don’t get me wrong, but that’s not the kind of thing you WANT to do if you can work around it. ;-)

MORE READING:

Release Notes for Cisco IOS Release 12.2(33)SXH and Later Releases

Cisco IOS Software Modularity Installation and Configuration Guide

With these 2 documents come a lot of other links that will take you as deep as you might need to go on this topic. Obviously, I just skimmed the surface.