Using EFSU, I want to upgrade the Cat.6513 switches running in VSS with currently installed IOS -ipservicesk9_wan-mz.122-33.SXI3.bin.
Want to upgrade to lastest available version in SXI which is SXI13
Eager to understand from members here how successful ISSU is on 65xx platform and does it really mean zero downtime impact?
Any practical experience from those who performed upgrade in VSS scenerio using EFSU
When standby chassis get reloaded in ISSU loadversion step then only all the modules (Service modules & line cards) on standby chassis get reloaded or the modules on Active chassis will also get reloaded.
When Active chassis get reloaded during switchover in ISSU runversion then only the modules (Service modules & line cards) on Active chassis get reloaded or the modules on standby chassis will also get reloaded.
I have service modules installed in both the chassis. Does EFSU have any dependency on these service modules.
Mod Ports Card Type Model --- ----- -------------------------------------- ------------------ 3 1 Application Control Engine Module ACE20-MOD-K9 4 6 Firewall Module WS-SVC-FWM-1 5 8 Intrusion Detection System WS-SVC-IDSM-2 6 8 Network Analysis Module WS-SVC-NAM-2-250S 7 5 Supervisor Engine 720 10GE (Active) VS-S720-10G 9 8 CEF720 8 port 10GE with DFC WS-X6708-10GE 10 8 CEF720 8 port 10GE with DFC WS-X6708-10GE 11 48 CEF720 48 port 1000mb SFP WS-X6748-SFP 12 48 CEF720 48 port 10/100/1000mb Ethernet WS-X6748-GE-TX 13 48 CEF720 48 port 10/100/1000mb Ethernet WS-X6748-GE-TX
first you should check the eFSU compatibility matrix. Usually eFSU is only supported if source and target IOS images are within one year of publication. Otherwise this means multiple steps.
I also think that the described IOS Upgrade processes (whatever) for VSS systems are not reflecting impact on service modules, that means you need to make an individual migration plan, which service module to switchover manually during the upgrade process. Otherwise service modules will be rebooted as other line cards. Remember that service modules are "single attached" devices with their own OS, operational state and configuration, even if they are installed within the VSS Chassis.
Although I did not have service-modules in my installation, I decided to go with FSU because of the many interim steps for eFSU. In any case and even with eFSU, I would never commit zero-downtime for a software upgrade of a cluster core device, because there always might happen individual issues.
During SSO supervisor switchover from active to standby SUP, do the linecards and service modules still have to reset? Is that reset occur only on Standby SUP or both on Active & Standby SUP
For Modules support eFSU, will these line cards still reset ?
According to below document only following modules supports eFSU and outage time is 300 sec for Module WS-X6708-10GE (CEF720 8 port 10GE with DFC ) and outage time is 360 for modules (WS-X6748-SFP & WS-X6748-GE-TX)
Preloading new module software into memory on supported modules to avoid a hard reset.
If the new software release contains new module software, eFSU preloads the new module software onto any modules in the switch that support eFSU preload. When the switchover occurs between the active and standby supervisor engines, the modules are restarted with the new software image.
The following modules support eFSU preload: – WS-X67xx modules – SIP-400 and SIP-600 All other modules undergo a hard reset at switchover, and the software image loads after the module restarts.
Outage Time and Support Considerations
During an eFSU upgrade, modules are restarted or reset after the switchover that occurs between the supervisor engines. Because the modules are restarted or reset, any links attached to the modules go up and down and traffic processing is disrupted until protocols and software features are brought back online. The length of time that module processing is disrupted (outage time) depends on whether the eFSU process was able to preload a new software image onto the module. • For modules that support eFSU preload, the outage time for an eFSU module warm reload is faster than an RPR mode module reload. • For modules that do not support eFSU preload, the outage time for module reload is similar to an RPR mode module reload. Once the new software is loaded (issu loadversion), you can use the show issu outage slot all command to display the maximum outage time for installed modules. See the “Displaying the Maximum Outage
Displaying the Maximum Outage Time for Installed Modules (Optional)
Once the new software is downloaded, you can enter the show issu outage slot all command on the switch processor to display the maximum outage time for the installed modules:
What line card and service modules did you have in the chassis during the upgrade.
I just want to know after initiating the command the issu runversion, the current standby chassis takes over the role as the new active chassis and formerly active chassis will reload with all the line cards and service modules installed in that chassis so i want to know during the reload of formerly active chassis, will the line cards and service modules (IDSM,FWSM,ACE etc) reset/reload installed in formerly standby chassis (new active chassis) or not
The ProblemEnter EVCsHow It Works (Ingress)How It Works
(Egress)Step-by-Step ExampleFinal Thoughts The ProblemOn traditional
switches whenever we have a trunk interface we use the VLAN tag to
demultiplex the VLANs. The switch needs to determine which MAC ...
The ProblemEnter EVCsHow It Works (Ingress)How It Works
(Egress)Step-by-Step ExampleFinal Thoughts Introduction: Netdr is a tool
available on a RSP720, Sup720 or Sup32 that allows one to capture
packets on the RP or SP inband. The netdr command can be use...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...