Modern network designs require fault-tolerance, often in the form of redundant devices, connections, and services. This can be seen in the use of multiple layer 2 switches in access and distribution layers that have multiple redundant cabling paths. As these access and distribution blocks grow in size or number, so does the management and operational complexity of the switched environment.
The topology diagram below shows a traditional access/core/distribution connectivity design. Notice the amount of cross connectivity required to prevent any one device or connection failure from disrupting network access. This level of redundancy using stand-alone switching inevitably leads to increased operational and Spanning Tree forwarding complexity.
One solution to reducing complexity in a tiered network design is the use of virtualized switching. This can be in the form of StackWise switch stacks (Cisco 3750/3850), vPC (Cisco Nexus), or VSS (Cisco 6500/4500). For the purposes of this conversation we will be looking at Virtual Switching System, more commonly referred to as VSS.
All switch virtualization methods are designed to simplify switch operation and configuration by presenting two or more switches as a single unit. By reducing the number of logical network elements down to one, configuration and connectivity options can be greatly simplified.
Virtual Switching System
Virtual Switching System, or VSS, logically combines a pair of Cisco 6500 or 4500 switch chassis into a single logical unit. Deploying VSS allows the use of redundant links across two chassis to be seen as the same device to the remote end. This reduces the number of both layer 2 and layer 3 neighbors in the switched environment and simplifies the logical forwarding topology.
The VSS topology diagram below shows how the access and distribution layers logically connect once VSS is deployed in the distribution switches. Unlike other switch virtualization options, VSS on the Cisco 6500 and 4500 families only support two switches. This is why VSS is designed for distribution or core deployments where it is common to see a pair of large chassis switches.
It is important to understand that while the two VSS switches are still physically separate, the operation and control planes are merged to act as a single device. This unified capability allows the multi-chassis port channel to forward layer 2 traffic loop-free. VSS also simplifies routed environments by decreasing the number of layer 3 neighbors – reducing complexity in both the control and data plane.
Cisco VSS requires specific VSS roles between the interconnected VSS switch pair. Each time the VSS is restarted, the two switches begin a role negotiation procedure – with one becoming the active switch and the other the standby switch.
The active switch controls all functions of the VSS, including layer 2 and 3 control protocols for both member switches. Even though the active switch manages all control traffic and processing, each individual switch still performs packet forwarding for traffic on their local interfaces.
Virtual Switch Link (VSL)
VSS pairs are required to use a special-purpose virtual switch link that connects the two devices together. The virtual switch link, or VSL, is dedicated to carrying control and data traffic between the two VSS switches.
Cisco recommends using an EtherChannel for the VSL, allowing up to eight links in the bundle. This provides additional inter-switch bandwidth and link redundancy. Link load balancing across the VSL uses the global EtherChannel load-balancing algorithm. That can be configured from its defaults in global configuration mode.
Another distinct feature of the VSL is its prioritization of management and control traffic over normal data flows. This ensures that management communication between the switches is never dropped – a situation that would quickly cripple a virtualized switch pair.
1. VSS Domain ID
VSS first requires a virtual switch domain be configured on each switch in the VSS pair. The virtual switch domain is a numeric value between 1-255 that must be configured and match on both switches.
2. VSS Switch Assignment
Once the domain is configured, the switches must be assigned a switch number – either 1 or 2.
3. VSL Configuration
The VSL should be configured as a multilink port channel on each switch. The port channel ID used for the VSL can be a different number on each switch, but must be not be used by any other local port channels. Using a VSL port channel ID that conflicts with an existing port channel can lead to undesirable outcomes after the VSS comes up. Issue the show etherchannel summary command to verify.
In the example below, port channel 10 is created on both switches for the VSL. Interfaces Gigabit 2/45-48 on switch 4500-1 will be connected to interfaces Gigabit 7/45-48 on switch 4500-2.
After the individual interfaces are added to the VSL port channel interface using the channel-group command, the interfaces transition into a “notconnect” state. The interface will be up but the line protocol will show down. The VSL interfaces will remain in the “notconnect” state until the switches are reloaded.
4500-1#4500-1#configure terminal4500-1(config)#4500-1(config)# int port-channel 104500-1(config-if)# switchport4500-1(config-if)# switch virtual link 14500-1(config-if)# no shut4500-1(config-if)# exit4500-2(config)# int port-channel 104500-2(config-if)# switchport4500-2(config-if)# switch virtual link 24500-2(config-if)# no shut4500-2(config-if)# exit
4500-1(config)# int range gig2/45 – 484500-1(config-if-range)# switchport mode trunk4500-1(config-if-range)# channel-group 10 mode onWARNING: Interface GigabitEthernet2/45 placed in restricted config mode. All extraneous configs removed!WARNING: Interface GigabitEthernet2/46 placed in restricted config mode. All extraneous configs removed!WARNING: Interface GigabitEthernet2/47 placed in restricted config mode. All extraneous configs removed!WARNING: Interface GigabitEthernet2/48 placed in restricted config mode. All extraneous configs removed!4500-1(config-if-range)# exit4500-2(config)# int range gig7/45 – 484500-2(config-if-range)# switchport mode trunk4500-2(config-if-range)# channel-group 10 mode onWARNING: Interface GigabitEthernet7/45 placed in restricted config mode. All extraneous configs removed!WARNING: Interface GigabitEthernet7/46 placed in restricted config mode. All extraneous configs removed!WARNING: Interface GigabitEthernet7/47 placed in restricted config mode. All extraneous configs removed!WARNING: Interface GigabitEthernet7/48 placed in restricted config mode. All extraneous configs removed!4500-2(config-if-range)# exit
4. VSS Mode Conversion
The final VSS configuration step is to issue the switch convert mode virtual command on both switches – starting with switch 1. This will finalize the VSS conversion and prompt for confirmation before continuing. Entering “yes” at the prompt kicks off the creation of a converted configuration file that is stored in the system bootflash, used upon the next reboot.
After the VSS conversion procedure is complete on both switches, the running configuration is automatically saved to to the startup configuration and the switches will reboot. After reboot, the switches will be operating in virtual switch mode.
It is important to verify that the VSS is operating on both switches as expected after a new conversion or switch reload. The show switch virtual command will display the VSS domain ID, switch numbers, and individual switch roles within the VSS.
To display status information on the VSL, use the show switch virtual link command. Notice in the output below that the interface numbering changed from 2-digit notation to 3-digit notation (slot/port to VSS-switch-nuber/slot/port). Interfaces on switch 1 will be prepended with 1/; interfaces on switch 2 will be prepended with 2/.
A simple way to verify which switch is in the standby role is to console into each switch. The standby switch will present the message “Standby console disabled”. The active switch will show normal console output.