In an environment where it is very difficult to get downtime for maintenance/software upgrades.
Today on 6500 Sup2 performing an OS upgrade means a switch reset. Realise we would need to move to new platform/supervisor to get full benefits of ISSU.
Eager to understand from members here how successful ISSU is on either the 45xx or 65xx platform and does it really mean zero impact?
From how I read it with the 45xx, as long as the images are compatible (which may not be that often), you can load new IOS on standby supervisor and perform a sub-second failover. Only impact is <150ms while secondary sup is taking over.
With a 6500 running modular IOS it seems that one can do software updates on different modules without the need for any downtime. Not sure if this applies across all modules and whether one truly can perform software updates with zero downtime. Also, not sure if you necessarily need to have dual supervisors for this to work.
Any practical experience from those in the know would be appreciated. Typically we would only do upgrades between major releases so what is best non-impacting s/w upgrade solution that members have come across.
We actually test it a couple of weeks ago. The only difference is that we are running VSS. By using eFSU, we ware able to upgrade our VSS boxes without any downtime. The only thing you loose is capacity of 50% for about 10 minutes until the other switch comes on line. Now, as you mentioned, it has to be form one major release to another, if not it does not work.
Again, our envirement is VSS and I have not done it on stand alone switches
Modular IOS has a concept of patches and maintenance packs. If you take a look on CCO to date there has only been one patch released for SXF7. There have been only two maintenance packs released. One again for SXF7 and one for SXH4. I do not know if things have changed, but patching originally was going to be restricted to PSIRT fixes.
A patch does not need dual supervisors to work. This is not a real example, but say a patch was released for CDP. The idea is you could patch only the CDP process and relaunch that individual process. This would leave the rest of the system intact and not require IOS to reboot.
Patching requires you to install the Modular IOS image. Most customers that I have seen running Modular IOS have not taken this step.
Regarding ISSU, you need SXI or later if I recall correctly for the 6500. As you already mentioned, with a Sup2 you will never see this functionality because SXF is the last stop for your hardware.
I'm sure there is a lot of things that happen behind the scenes to make ISSU possible, but at a very high level the primary way ISSU reduces downtime is the redundant supervisors can run SSO when the IOS versions are not identical. Normally someone upgrading would load the new IOS on the standby sup and force the standby to reload. When the standby boots, it will become the standby in RPR mode due to the code difference. When following the ISSU procedure, instead the two sups will continue to operate in SSO which allows the failover times to be significantly reduced.
I personally have only helped customers with ISSU on the 7600. ISSU aims to reduce the downtime of your network and it is not perfect. It is possible to see sub second failover times, but I wouldn't tell someone there is "zero impact".
ISSU on the 4500 works as advertised with pretty much zero impact.
ISSU on the 6500 (or eFSU as Cisco calls it) will take your line cards down. eFSU on SXI does allow ISSU type functionality between the redundant Sup720 supervisors, but will force a line card reload unless they have 512Mb or greater memory available for IOS preload. The 6700 series cards I have only have 256Mb and reload during the sup switchover, but are upgradable to 512Mb. WISMs have 256Mb but don't appear to be upgradable and reload during the ISSU switchover.
I have also tested ISSU with VSS, and it works (subsecond upgrade, although not completely 'hitless'). Within one chassis, i also heard that ISSU is more interruptive as it -might- reload the linecards (if the upgrade fixes linecard code bugs, it must load new firmware into the linecards), same as dvr has said above.
The advantage of ISSU with VSS is of course that you don't care if the line cards are reloaded, you have another chassis continueing...
- 4500 ISSU with SSO allows for sub-second supervisor failover during IOS upgrade. No reset of linecards.
- 6500 eSSU on a standalone (non-VSS) dual supervisor chassis allows the new image to be pre-loaded on secondary but still requires a reset of line cards on supervisor failover.
- 6500 ISSU with a VSS dual chassis (single supervisor in each) running SXI code allows for non-impacting upgrades (albeit at 50% reduced switching capacity for a time). There are card resets but because dual homed nature of VSS will not cause impact to connected systems.
- 6500 modular IOS allows for in service patching of certain elements on a single supervisor (no downtime needed and no supervisor failover involved). However this is only for patches within an IOS release train and are mainly aimed at security alerts (PSIRT's). To upgrade to a new version of modular IOS one still needs to reboot (dual supervisor reduces impact with eSSU but still requires line card reset). I wonder how prevalent the use of modular IOS is out there and whether there is a huge driver given the limitation in the amount of patches that are released to security alerts? (on the flip side why would one not go with modular over standard native IOS if it does indeed allow for patching of critical security vulnerabilities without impact?)
âWith Cisco IOS Software Modularity, patches are delivered as maintenance packs containing one or more patches. Maintenance packs will provide patches to address publicly announced security vulnerabilities (PSIRTs). Maintenance packs for non-PSIRT issues are not supported at this time. Availability is being evaluated based on customer input and demandâ
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...