I am in the progress of doing ISSU upgrades on some nexus 7710 chassis' with dual supervisor modules. I set a ping test that to traverse across the switch shortly before the upgrade and experienced about 15-20 seconds of lost pings. Is this test scenario a good one and does this amount of downtime seem acceptable? Is cisco's marketing on this feature just bs? I see the same behavior for a supervisor switchover as well.
ISSU Nexus Upgrade – How Long Is the Outage?
ciscocisco-nexuscisco-nexus-7kcisco-nx-osnx-os
Related Solutions
You can do a show run | egrep interface.Vlan|ip.address. It does grab a bit more info, but should provide similar output to what you see in IOS. I think grep might work as well, but I used egrep and got the correct output.
Setting up the configuration synchronization mode (conf sync) involves creating a switch profile (switch-profile). Cisco has a lot of documents regarding this, e.g. Chapter: Configuring Switch Profiles:
Prerequisites for Switch Profiles
Switch profiles have the following prerequisites:
- You must enable CFSoIP distribution over mgmt0 on both switches by entering the cfs ipv4 distribute command.
- You must configure a switch profile with the same name on both peer-switches by entering the config sync and switch-profile
commands.- Configure each switch as peer switch by entering the sync-peers destination command
Configuration Guidelines and Limitations
Switch profiles have the following configuration guidelines and limitations:
- You can only enable configuration synchronization using the mgmt0 interface.
- You must configure synchronized peers with the same switch profile name.
- Commands that are qualified for a switch profile configuration are allowed to be configured in the configuration switch profile
(config-sync-sp) mode.- Supported switch profile commands relate to vPC commands. FCoE commands are not supported.
- One switch profile session can be in progress at a time. Attempts to start another session will fail.
- Supported command changes made from the configuration terminal mode are blocked when a switch profile session is in progress. You should
not make unsupported command changes from the configuration terminal
mode when a switch profile session is in progress..- When you enter the commit command and a peer switch is reachable, the configuration is applied to both peer switches or neither switch. If there is a commit failure, the commands remain in the switch profile buffer. You can then make necessary corrections and try the commit again.
- Cisco recommends that you enable pre-provisioning for all Gigabit-Ethernet Modules (GEMs) and Cisco Nexus Fabric Extender
modules whose interface configurations are synchronized using the
configuration synchronization feature. Follow these guidelines in
Cisco Nexus Fabric Extender A/A topologies where the Fabric Extenders might not be online on one switch and its configuration is changed
and synchronized on the other switch. In this scenario, if you do not enable pre-provisioning, a commit fails and the configuration is
rolled back on both switches.Configuring Switch Profiles
You can create and configure a switch profile. Enter the switch-profile name command in the configuration synchronization mode (config-sync).
Before You Begin
You must create the switch profile with the same name on each switch and the switches must configure each other as a peer. When connectivity is established between switches with the same active switch profile, the switch profiles are synchronized.
SUMMARY STEPS
- configuration terminal
- cfs ipv4 distribute
- config sync
- switch-profile name
- sync-peers destination IP-address
- show switch-profile name status
- exit
- copy running-config startup-config
Best Answer
The best tip I can give for anything involving ISSU on 7K's is to read- and re-read- the release notes. There are very specific versions that are supported as origin/destination and there are also some features that are going to work better with ISSU than others. The other caveat to consider is that in some instances there may be requirements for firmware or EPLD upgrades that could create a brief outage (again - usually mentioned in release notes).
In general I can tell you that the ISSU process can be truly hitless but that you need to stick within the limits of what QA has specifically validated.