When you configure VSL, all existing configurations are removed from the interface except for specific allowed commands.
Redundancy and High Availability
In a VSS, supervisor engine redundancy operates between the VSS active and standby switches, using stateful switchover (SSO) and nonstop forwarding (NSF). The peer switch exchange configuration and state information across the VSL and the VSS standby supervisor engine runs in SSO-HOT mode.
Packet Handling
Both switches perform packet forwarding for ingress traffic on their interfaces. If possible, ingress traffic is forwarded to an outgoing interface on the same switch to minimize data traffic that must traverse the VSL.
The VSS active supervisor engine acts as a single point of control for the VSS. The VSS standby switch runs a subset of system management tasks. For example, the VSS standby switch handles its own power management, linecard bringup, and other local hardware management.
Catalyst 4500 and Catalyst 4500-X VSS require the same supervisor engine type in both chassis. The chassis must contain the same number of slots, even if their linecards differ or their slots are empty.
Switch 1 receives a module number from 1-10 and switch 2 receives a number from 11-20, irrespective the chassis type, supervisor type, or number of slots in a chassis. The show switch virtual slot-map command provides virtual to physical slot mapping.
Configure at least two of the 10 Gigabit Etherent/1 Gigabit Ethernet ports as VSL, selecting ports from different modules.
RPR and SSO Redundancy
A VSS operates with stateful switchover (SSO) redundancy if it meets the following requirements:
• Both supervisor engines must be running the same software version, unless it is in the process of software upgrade.
• VSL-related configuration in the two switches must match.
• SSO and nonstop forwarding (NSF) must be configured on each switch.
If a VSS does not meet the requirements for SSO redundancy, it will be incapable of establishing a relationship with the peer switch. Catalyst 4500/4500-X series switches’ VSS does not support route processor redundancy (RPR) mode like 6500 does.
The failed switch performs recovery action by reloading the supervisor engine. If the VSS standby switch or supervisor engine fails, no switchover is required. The failed switch performs recovery action by reloading the supervisor engine.
The VSL links are unavailable while the failed switch recovers. After the switch reloads, it becomes the new VSS standby switch and the VSS reinitializes the VSL links between the two switches. The switching modules on the failed switch are unavailable during recovery, so the VSS operates only with the MEC links that terminate on the VSS active switch. The bandwidth of the VSS is reduced until the failed switch has completed its recovery and become operational again. Any devices that are connected only to the failed switch experience an outage.
Ports on the VSS standby switch (while it boots) come up tens of seconds before the control plane is fully functional. This behavior causes a port to start working in independent mode and might cause traffic loss until the port is bundled.
If only the VSL has failed and the VSS active switch is still operational, this is a dual-active scenario.
If you enter the reload command from the command console, it performs a reload on the switch where reload is issued.
To reload only the VSS standby switch, use the redundancy reload peer command.
To force a switchover from the VSS active to the standby supervisor engine, use the redundancy force-switchover command.
To reset both the VSS active and standby switch, use the redundancy reload shelf command.
Multichassis EtherChannels
At the VSS, an MEC is an EtherChannel with additional capability: the VSS balances the load across ports in each switch independently. For example, if traffic enters the VSS active switch, the VSS selects an MEC link from the VSS active switch. This MEC capability ensures that data traffic does not unnecessarily traverse the VSL.
PAgP or LACP protocols run only on the VSS active switch. PAgP or LACP control packets destined for an MEC link on the VSS standby switch are sent across VSL.
If all links to the VSS active switch fail, switch, Data traffic terminating on the VSS active switch reaches the MEC by crossing the VSL to the VSS
standby switch. Control protocols continue to run in the VSS active switch. Protocol messages reach the MEC by crossing the VSL.
The VSS active switch runs Spanning Tree Protocol (STP). The VSS standby switch redirects STP BPDUs across the VSL to the VSS active switch.
If possible, to minimize data traffic that must traverse the VSL, ingress traffic is forwarded to an outgoing interface on the same switch. When software forwarding is required, packets are sent to the VSS active supervisor engine for processing.
The same router MAC address, assigned by the VSS active supervisor engine, is used for all Layer 3 interfaces on both VSS member switches. After a switchover, the original router MAC address is still used. The router MAC address is configurable.
Diagnosis
Bootup diagnostics are run independently on both switches. Online diagnostics can be invoked on the basis of virtual slots, which provide accessibility to modules on both switches. Use the show switch virtual slot-map command to display the virtual to physical slot mapping.
Accessing the Remote Console on VSS
Remote console (the console on the standby switch) can be accessed from the Local (active) switch. (Switch# remote login module 11)
When you copy a file to a bootflash on the active switch, it is not automatically copied to the standby bootflash. This means that when you perform an ISSU upgrade or downgrade, both switches must receive the files individually. This behavior matches that on a dual-supervisor standalone system.
Similarly, the removal of a file on one switch does not cause the removal of the same file on the other switch.
Dual-Active Detection
A dual-active scenario can have adverse effects on network stability, because both switches use the same IP addresses, SSH keys, and STP bridge ID.
The VSS supports the method, Enhanced PAgP, for detecting a dual-active scenario. PAgP uses messaging over the MEC links to communicate between the two switches through a neighbor switch. Enhanced PAgP requires a neighbor switch that supports the PAgP enhancements.
Dual-Active Detection Using Enhanced PAgP
In virtual switch mode, PAgP messages include a new type length value (TLV) which contains the ID of the VSS active switch. Only switches in virtual switch mode send the new TLV.
When the VSS standby switch detects VSL failure, it initiates SSO and becomes VSS active. Subsequent PAgP messages to the connected switch from the newly VSS active switch contain the new VSS active ID. The connected switch sends PAgP messages with the new VSS active ID to both VSS switches. If the formerly VSS active switch is still operational, it detects the dual-active scenario because the VSS active ID in the PAgP messages changes. This switch initiates recovery actions.
Recovery Actions
An VSS active switch that detects a dual-active condition shuts down (by err-disabling) all of its non-VSL interfaces to remove itself from the network, and waits in recovery mode until the VSL links have recovered. You might need to intervene directly to fix the VSL failure. When the shut down switch detects that VSL is operational again, the switch reloads and returns to service as the VSS standby switch. Loopback interfaces are also shut down in recovery mode. If the running configuration of the switch in recovery mode has been changed without saving, the switch will not automatically reload.
SSO Dependencies
For the VSS to operate with SSO redundancy, the VSS must meet the following conditions:
• Identical software versions (except during ISSU with compatible versions)
• VSL configuration consistency
During the startup sequence, the VSS standby switch sends virtual switch information from the
startup-config file to the VSS active switch.
The VSS active switch ensures that the following information matches correctly on both switches:
– Switch virtual domain
– Switch virtual node
– Switch priority (optional)
– VSL port channel: switch virtual link identifier
– VSL ports: channel-group number, shutdown, total number of VSL ports
• If the VSS detects a mismatch, it prints out an error message on the VSS active switch console and the VSS standby switch does not bootup.
• SSO and NSF must be configured and enabled on both switches.
VSL Initialization
A VSS is formed when the two switches and the VSL link between them become operational. Because both switches need to be assigned their role (VSS active or VSS standby) before completing initialization, VSL is brought online before the rest of the system is initialized. The initialization
sequence is as follows:
1. The VSS initializes all cards with VSL ports, and then initializes the VSL ports.
2. The two switch communicate over VSL to negotiate their roles (VSS active or VSS standby).
3. The VSS active switch completes the boot sequence, including the consistency check described in the “SSO Dependencies” section on page 5-26.
4. If the consistency check completed successfully, the VSS standby switch comes up in SSO VSS standby mode. If the consistency check failed, the VSS standby switch comes up in RPR mode.
5. The VSS active switch synchronizes configuration and application data to the VSS standby switch. If VSS is either forming for the first time or a mismatch exists between VSL information sent by the standby switch and what is on the active switch, the new configuration is absorbed in the
startup-config. This means that if the active switch was running prior to the standby switch and unsaved configurations existed, they would be written to the startup-config if the standby switch sends mismatched VSL information.
System Initialization
If you boot both switches simultaneously, the switch configured as Switch 1 boots as VSS active and the one with Switch 2 boots as VSS standby. If priority is configured, the higher priority switch becomes active.
If you boot only one switch, the VSL ports remain inactive, and the switch boots as VSS active. When you subsequently boot the other switch, the VSL links become active, and the new switch boots as the VSS standby switch.
Configuring a VSS
When you convert two standalone switches into one VSS, all non-VSL configuration settings on the VSS standby switch reverts to the default configuration.
To convert two standalone switches into a VSS, you perform the following major activities:
• Save the standalone configuration files.
• Configure each switch for required VSS configurations.
• Convert to a VSS.
Step 1 Switch-1(config)# switch virtual domain 100 Configures the virtual switch domain on Switch A.
Step 2 Switch-1(config-vs-domain)# switch 1 Configures Switch A as virtual switch number 1.
Step 3 Switch-1(config-vs-domain)# exit Exits config-vs-domain.
Step 1 Switch-2(config)# switch virtual domain 100 Configures the virtual switch domain on Switch A.
Step 2 Switch-2(config-vs-domain)# switch 2 Configures Switch A as virtual switch number 1.
Step 3 Switch-2(config-vs-domain)# exit Exits config-vs-domain.
The switch number is not stored in the startup or running configuration, because both switches use the same configuration file (but must not have the same switch number).
Configuring VSL Port Channel and Ports
The VSL is configured with a unique port channel on each switch. During the conversion, the VSS configures both port channels on the VSS active switch.
Step 1 Switch-1(config)# interface port-channel 10 Configures port channel 10 on Switch 1.
Step 2 Switch-1(config)# switchport Convert to a Layer 2 port.
Step 3 Switch-1(config-if)# switch virtual link 1 Associates Switch 1 as owner of port channel 10.
Step 4 Switch-1(config-if)# no shutdown Activates the port channel.
Step 5 Switch-1(config-if)# exit Exits interface configuration.
Step 1 Switch-2(config)# interface port-channel 20 Configures port channel 10 on Switch 1.
Step 2 Switch-2(config)# switchport Convert to a Layer 2 port.
Step 3 Switch-2(config-if)# switch virtual link 2 Associates Switch 1 as owner of port channel 10.
Step 4 Switch-2(config-if)# no shutdown Activates the port channel.
Step 5 Switch-2(config-if)# exit Exits interface configuration.
For line redundancy, we recommend configuring at least two ports per switch for the VSL. For module redundancy, the two ports can be on different switching modules in each chassis.
Step 1 Switch-1(config)# interface range tengigabitethernet 3/1-2
Step 2 Switch-1(config-if)# channel-group 10 mode on
Step 1 Switch-2(config)# interface range tengigabitethernet 3/1-2
Step 2 Switch-2(config-if)# channel-group 20 mode on
Converting the Switch to Virtual Switch Mode
Conversion to virtual switch mode requires a restart for both switches. Prior to the restart, the VSS converts the startup configuration to use the switch/module/port convention. A backup copy of the startup configuration file is saved in bootflash.
Switch-1# switch convert mode virtual Converts Switch 1 to virtual switch mode. After you enter the command, you are prompted to
confirm the action. Enter yes. The system creates a converted configuration file, and saves the file to the bootflash.
Switch-2# switch convert mode virtual
When switches are being converted to VSS, you should not set them to ignore startup-config.
Displaying VSS Information
Switch# show switch virtual Displays the virtual switch domain number, and the switch number and role for each of the switches.
Switch# show switch virtual role Displays the role, switch number, and priority for each of the switch in the VSS.
Switch# show switch virtual link Displays the status of the VSL.
Switch# show switch virtual link port-channel Displays information about the VSL port channel.
Switch# show switch virtual link port Displays information about the VSL ports.
Configuring the Router MAC Address
On VSS, all routing protocols are centralized on the active supervisor engine. A common router MAC address is used for Layer 3 interfaces on both active and standby switches. Additionally, to ensure non-stop forwarding, the same router MAC address is used after switchover to the standby switch, so that all layer 3 peers see a consistent router MAC address. There are three ways to configure a router MAC address on VSS:
• HHH—Manually set a router MAC address. Ensure that this MAC address is reserved for this usage.
• chassis—Use the mac-address range reserved for Chassis. This is the Cisco MAC address assigned o the chassis.
• use-virtual—Use the mac-address range reserved for the VSS. This is the reserved Cisco MAC ddress pool, which is derived from a base MAC address +vss domain-id.
By default, the virtual domain based router MAC address is used. Any change of router MAC address configuration requires a reboot of both VSS supervisor engines.
Configuring Dual-Active Detection
Configuring Enhanced PAgP Dual-Active Detection
By default, PAgP dual-active detection is enabled. However, the enhanced messages are only sent on port channels with trust mode enabled. Before changing PAgP dual-active detection configuration, ensure that all port channels with trust mode enabled are in administrative down state. To enable or disable PAgP dual-active detection, perform this task:
Switch(config)# switch virtual domain domain_id Enters virtual switch submode.
Switch(config-vs-domain)# dual-active detection pagp Enables sending of the enhanced PAgP messages.
To configure trust mode on a port channel,
Switch(config)# interface port-channel 20
Switch(config-if)# shutdown
Switch(config-if)# exit
Switch(config)# switch virtual domain 100
Switch(config-vs-domain)# dual-active detection pagp
Switch(config-vs-domain)# dual-active detection pagp trust channel-group 20
Switch(config-vs-domain)# exit
Switch(config)# interface port-channel 20
Switch(config-if)# no shutdown
Switch(config-if)# exit
Switch# show switch virtual dual-active summary Displays information about dual-active detection configuration and status.
Switch# show pagp dual-active
In-Service Software Upgrade (ISSU) on a VSS
Prerequisites to Performing ISSU
The type of the pre- and post-upgrade images must match precisely. Identical. ISSU is not supported from a Universal_lite to a Universal image, or vice versa. ISSU is also not supported from a k9 image to a non-k9 image, or vice versa.
• VSS must be functionally in SSO mode;
• The pre- and post-upgrade Cisco IOS XE software image files must both be available in the local file systems (bootflash, SD card, or USB) of both the active and standby supervisor engines before you begin the ISSU process.
-ISSU in a VSS will result in loss of service on non-MEC links, and peers must be prepared for this. On links connected over MECs, Nonstop Forwarding (NSF) must be configured and working properly.
-Autoboot is turned on and the current booted image matches the one specified in the BOOT environmental variable.
Converting a VSS to Standalone Switch
Save the configuration file from the VSS active switch.
When you convert the VSS active switch to standalone mode, the VSS active switch removes the provisioning and configuration information related to VSL links and the peer chassis modules, saves the configuration file, and performs a reload. The switch comes up in standalone mode with only the configuration data relevant to the standalone system. Not recommended that you convert a VSS to standalone in a live network.
Switch-1# switch convert mode stand-alone
To convert the peer switch to standalone, perform this task on the VSS standby switch
Switch-2# switch convert mode stand-alone
To configure the switch priority, perform this task:
Switch(config)# switch virtual domain 100
Switch(config-vs-domain)# switch [1 | 2] priority [priority_num]
Switch# show switch virtual role
The show switch virtual role command shows the operating and configuThe new priority value only takes effect after you save the configuration and perform a reload of the VSS. You can manually set the VSS standby switch to VSS active using the redundancy force-switchover command.
