Showing results for 
Search instead for 
Did you mean: 
Join Customer Connection to register!
Bauer Chris

VSS eFSU downtime

I have seen conflicting information regarding downtime for this upgrade process and still have questions after reading In this scenario, we have a VSS with one SUP in each chassis.

Are the chassis or modules rebooted one at a time? For instance, if I issue an "issu loadversion", will this just load the code on the SUP in the standby chassis, or will it load the code on the modules as well? If it does load the code on the modules, then I will have to wait the longest time from the "show issue outage slot all" before issuing a "issu runversion", correct?

Also, what outage times have people seeen on modules that support pre-loading? I have not been able to find any documented information on this other than it is faster, and the link referenced above still shows a 5 minutes outage for a warm reset on one of the modules.

Any information is appreciated




Sorry for adding comments to almost 3-year old thread but I have a same question as OP about downtime during software upgrades in VSS. In our environment we have a single SUP in each chassis and wondering if it is really 200ms of downtime like Cisco doc suggests with eFSU? Some documents suggest that eFSU require dual SUPs per chassis so 4 SUPs for a VSS pair but not entirely sure. All our our lines cards are 67xx, 68xx or 69xx so should support eFSU but can not find accurate answer on dual SUP per chassis requirement for eFSU. Any help is appreciated.


eFSU doesn't require dual sup per chassis. eFSU works fine with sup in each chassis.

BTW, VSS with quad sup is not supported yet. 

As for downtime when upgrading VSS using eFSU, I have seen cases where it takes less then a second and up to 3 seconds.  I also have seen cases where you don't loose any packet at all.

So, basically, you loose what ever packet is already in the wire when that chassis/portchaanel port goes down.


VSS with quad sup is not supported yet.

It is supported only on Sup2T running 15.1(1)SY1.  VSS Quad-Sup SSO (VS4O)

Unless someone from Cisco can chime in, Sup720 will never be supporting VS4O.

I'm not sure how far away is the Sup7E from supporting this feature.  I'm also not sure if Sup8 will immediately support VS4O during launch. 

Thanks Reza. If this is true, we are doing something wrong. We have a lab setup (please see attached pdf) with two brand new 6509-E chassis each with one SUP-2T and 1xWS-6908 plus 1xWS-6824 line cards for lab. Tomorrow I will find out exactly what IOS we are running but we are running 15.x code and have two levels of code staged on flash. We tried to do IOS upgrade/downgrade using eFSU couple of times in the lab environment and we lost connectivity - hard down for good 3-4 minutes each time. We have two PCs connected one behind one of the access switches and one to the router behind pair of Core routers for testing, as I said we lost ping for good 3-4 mintues each time about a minute after issuing "issu runversion" command. I did not do any configuration for this specific lab setup but will be taking over the setup tomorrow and have to look at the config.

Leo Laohoo
VIP Community Legend

Try this.


So we are doing IOS upgrade tests (eFSU) with 15.1(1)SY and 15.0(1)SY4. Basically switching between these two IOS levels and timing the upgrade. I took over the setup and realized that the cross connect links between the pair of Core routers and the full mesh links between VSS pair and the Core routers weren't working correctly - EIGRP wasn't configured correctly after fixing that now we got the upgrade time down to about 20 ping drops, but it is still nowhere near 200ms.

A test PC is connected to cs-4506-access-3 and another to a router on a top with IP address.


The issue in this case might be your routing protocol convergence and not necessarily VSS fail over.  For example, if you have a loopback address on the VSS pair, you can run a continues ping from the PC connected to the 4500 to it and do the upgrade to get better idea of how long it takes for the ping to recover. If that is successful and you see one or 2 ping packets drops, then the next layer to look at is your routing protocol.  I haven't work much with EIGRP, but I know if you are running OSPF in the core, you would need to enable graceful restart (NSF Cisco) under the OSPF process for the routing table to switch over from one device to another gracefully. I am sure, there is a command you can add under the EIGRP process.

Have a look at this doc on how to configure it: