A VSS is network system virtualization technology that pools multiple Cisco Catalyst 6500 Series Switches into one virtual switch, increasing operational efficiency, boosting nonstop communications, and scaling system bandwidth capacity to 1.4 Tbps. At the initial phase, a VSS will allow two physical Cisco Catalyst 6500 Series Switches to operate as a single logical virtual switch called a virtual switching system 1440 (VSS1440).
The main reason for VSS is something that is typically addressed when there are redundant routing platforms on a network. There are actually quite a few solutions that can be used in the presence of redundant devices, such as the popular and Cisco-proprietary Hot Standby Router Protocol (HSRP), or the IETF open standard Virtual Router Redundancy Protocol (VRRP). There are quite a few others, each with their own feature sets (for instance, some offer configurable load-balancing, others do not).
VSS actually removes the need for a next-hop redundancy protocol like HSRP or VRRP. These first-hop redundancy protocols are usually heavily tied to a fast-converging routing protocol like EIGRP, and still require that each device maintain its own control plane. Often, two switches are configured, and one responds to ARP requests while the other does not. This is an active/passive relationship. VSS takes this a step further and actually merges the two switches into one virtual “mega-switch”, rather than wasting a perfectly good switch. There’s still a master/slave relationship, but rather than placing one switch in standby while the other is active, this determines which switch maintains control over the other. The function of the supervisor module, as well as the configuration of both switches, becomes the responsibility of the primary switch.
Observe the following diagram:
In either case, these two switches are configured with a port channel between them. Using HSRP, you can establish redundancy just fine, but keep in mind that since both switches are distinct entities, you must rely on spanning tree to eliminate bridging loops, which means each access layer switch will put one of their uplink connections to the core in a blocking state.
VSS utilizes the port channel between the switches to merge them together into one massive switch. As a result, redundant connections from the Access layer to the Core no longer need to be blocked because since they’re virtually both connected to the same switch, they can be configured in a port-channel, as shown by the diagram to the right.
This configuration also adds a third number to the interface names, which looks like Chassis/Slot/Port. The following interface names came from the same config file after a VSS pair was formed:
Both of those interfaces came from the same config. The first one is the first port on the first card on switch 1, and the second is the first port on the first card on switch 2. Since the switches are merged, so are their configurations. In fact, check out what what happens when you try to enter global configuration mode on the “secondary” switch:
Standby console disabled
So….now that I’ve spoiled the ending, let’s find out how to configure this on a relatively basic level.
Before I get started, something that’s oft-overlooked in online walkthroughs is the fact that you need to configure SSO to be used as the redundancy mode:
6509SW1(config-red)# mode sso
First we have to set up the virtual switch domain. With very few exceptions, these configurations should be applied exactly the same on both switches in order for the VSS pair to form.
6509SW1(config)# switch virtual domain 100
6509SW1(config-vs-domain)# switch 1
6509SW1(config-vs-domain)# switch mode virtual
6509SW1(config-vs-domain)# switch 1 priority 110
6509SW1(config-vs-domain)# switch 2 priority 100
6509SW2(config)# switch virtual domain 100
6509SW2(config-vs-domain)# switch 2
6509SW2(config-vs-domain)# switch mode virtual
6509SW2(config-vs-domain)# switch 1 priority 110
6509SW2(config-vs-domain)# switch 2 priority 100
The priority configuration shown above is optional, and will produce the same results as is the default, since in the event of a priority tie, the smaller numbered switch will be elected the primary, but it is important to remember that the configurations must be identical to form a VSS system.
Next, configure the port-channel and place the relevant interfaces into it:
6590SW1(config)# interface port-channel 1
6509SW1(config-if)# no shut
6509SW1(config-if)# switch virtual link 1
6509SW1(config-if)# interface range TenGigabitEthernet 1/1 – 2
6509SW1(config-if-range)# no shut
6509SW1(config-if-range)# channel-group 1 mode on
6509SW2(config)# interface port-channel 2
6509SW2(config-if)# no shut
6509SW2(config-if)# switch virtual link 2
6509SW2(config-if)# interface range TenGigabitEthernet 1/1 – 2
6509SW2(config-if-range)# no shut
6509SW2(config-if-range)# channel-group 2 mode on
Finally, to execute the conversion, enter the following (on both cases):
6509SW1# switch convert mode virtual
It should ask you to reload, select yes. The switches will come back up as a VSS pair, and the interfaces on the secondary switch will be assimilated into the configuration for the primary switch.
You can view the details of this VSS pair:
6509SW1#show switch virtual
Switch mode : Virtual Switch
Virtual switch domain number : 100
Local switch number : 1
Local switch operational role: Virtual Switch Active
Peer switch number : 2
Peer switch operational role : Virtual Switch Standby
Try some of the additional parameters of this command to view even further levels of detail.
More reference from Cisco.com : Q&A: Virtual Switching System (VSS)
∼ Chandra Kumar Morkonda