Cisco 6500 User Manual
CHAPTER
4
Configuring Virtual Switching Systems
This chapter describes how to configure a virtual switching system (VSS) for the Catalyst 6500 series
switch. Cisco IOS Release 12.2(33)SXH1 and later releases support VSS.
Note For complete syntax and usage information for the commands used in this chapter, see these
publications:
• The Cisco IOS Virtual Switch Command Reference at this URL:
http://www.cisco.com/en/US/docs/ios/vswitch/command/reference/vs_book.html
• The Cisco IOS Release 12.2 publications at this URL:
http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_installation_and_configuratio
n_guides_list.html
Tip For additional information about Cisco Catalyst 6500 series switches (including configuration examples
and troubleshooting information), see the documents listed on this page:
http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html
This chapter consists of these sections:
• Understanding Virtual Switching Systems, page 4-1
• VSS Configuration Guidelines and Restrictions, page 4-27
• Configuring a VSS, page 4-29
• Upgrading a VSS, page 4-54
Understanding Virtual Switching Systems
These sections describe a VSS:
• VSS Overview, page 4-2
• VSS Redundancy, page 4-11
• Multichassis EtherChannels, page 4-14
OL-13013-06
Cisco IOS Software Configuration Guide, Release 12.2SX
4-1
Understanding Virtual Switching Systems
Access
Distribution
Core
• Packet Handling, page 4-16
• System Monitoring, page 4-20
• Dual-Active Detection, page 4-22
• VSS Initialization, page 4-24
• VSS Configuration Guidelines and Restrictions, page 4-27
VSS Overview
Network operators increase network reliability by configuring redundant pairs of network devices and
links. Figure 4-1 shows a typical switch network configuration. Redundant network elements and
redundant links can add complexity to network design and operation. Virtual switching simplifies the
network by reducing the number of network elements and hiding the complexity of managing redundant
switches and links.
A VSS combines a pair of Catalyst 6500 series switches into a single network element. The VSS
manages the redundant links, which externally act as a single port channel.
The VSS simplifies network configuration and operation by reducing the number of Layer 3 routing
neighbors and by providing a loop-free Layer 2 topology.
Chapter 4 Configuring Virtual Switching Systems
Figure 4-1 Typical Switch Network Design
The following sections present an overview of the VSS. These topics are covered in detail in subsequent
chapters:
• Key Concepts, page 4-3
• VSS Functionality, page 4-6
• Hardware Requirements, page 4-8
• Understanding VSL Topology, page 4-11
4-2
Cisco IOS Software Configuration Guide, Release 12.2SX
OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
181321
Virtual Distribution Switch Virtual Distribution Switch
Access
Access
Physical view Logical view
Key Concepts
The VSS incorporates the following key concepts:
• Virtual Switching System, page 4-3
• VSS Active and VSS Standby Chassis, page 4-3
• Virtual Switch Link, page 4-4
• Multichassis EtherChannel, page 4-5
Virtual Switching System
A VSS combines a pair of switches into a single network element. For example, a VSS in the distribution
layer of the network interacts with the access and core networks as if it were a single switch. See
Figure 4-2.
An access switch connects to both chassis of the VSS using one logical port channel. The VSS manages
redundancy and load balancing on the port channel. This capability enables a loop-free Layer 2 network
topology. The VSS also simplifies the Layer 3 network topology because the VSS reduces the number
of routing peers in the network.
Understanding Virtual Switching Systems
Figure 4-2 VSS in the Distribution Network
VSS Active and VSS Standby Chassis
When you create or restart a VSS, the peer chassis negotiate their roles. One chassis becomes the VSS
active chassis, and the other chassis becomes the VSS standby.
The VSS active chassis controls the VSS. It runs the Layer 2 and Layer 3 control protocols for the
switching modules on both chassis. The VSS active chassis also provides management functions for the
VSS, such as module online insertion and removal (OIR) and the console interface.
The VSS active and VSS standby chassis perform packet forwarding for ingress data traffic on their
locally hosted interfaces. However, the VSS standby chassis sends all control traffic to the VSS active
chassis for processing.
OL-13013-06
Cisco IOS Software Configuration Guide, Release 12.2SX
4-3
Understanding Virtual Switching Systems
181322
Virtual switch link
(VSL)
Virtual switch
Chassis 1 Chassis 2
Virtual Switch Link
For the two chassis of the VSS to act as one network element, they need to share control information and
data traffic.
The virtual switch link (VSL) is a special link that carries control and data traffic between the two
chassis of a VSS, as shown in Figure 4-3. The VSL is implemented as an EtherChannel with up to eight
links. The VSL gives control traffic higher priority than data traffic so that control messages are never
discarded. Data traffic is load balanced among the VSL links by the EtherChannel load-balancing
algorithm.
Figure 4-3 Virtual Switch Link
Chapter 4 Configuring Virtual Switching Systems
When you configure VSL all existing configurations are removed from the interface except for specific
allowed commands. When you configure VSL, the system puts the interface into a restricted mode.
When an interface is in restricted mode, only specific configuration commands can be configured on the
interface.
The following VSL configuration commands are not removed from the interface when it becomes
restricted:
• mls qos trust cos
• mls qos channel-consistency
• description
• logging event
• load-interval
• vslp
• port-channel port
When in VSL restricted mode, only these configuration commands are available:
• channel-group
• default
• description
• exit
• load-interval
• logging
• mls
• mls ip
Cisco IOS Software Configuration Guide, Release 12.2SX
4-4
OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
VSL
Chassis 1 Chassis 2
MEC
• mls ipx
• mls netflow
• mls rp
• mls switching
• no
• shutdown
Note The mls qos command is not available when a port is in VSL restricted mode.
Multichassis EtherChannel
An EtherChannel (also known as a port channel) is a collection of two or more physical links that
combine to form one logical link. Layer 2 protocols operate on the EtherChannel as a single logical
entity.
A multichassis EtherChannel (MEC) is a port channel that spans the two chassis of a VSS. The access
switch views the MEC as a standard port channel. See Figure 4-4.
The VSS supports a maximum of 512 EtherChannels. This limit applies to the combined total of regular
EtherChannels and MECs. Because VSL requires two EtherChannel numbers (one for each chassis),
there are 510 user-configurable EtherChannels. If an installed service module uses an internal
EtherChannel, that EtherChannel will be included in the total.
Understanding Virtual Switching Systems
Note For releases earlier than Cisco IOS Release 12.2(33)SXI, the maximum number of EtherChannels is 128,
allowing 126 user-configurable EtherChannels.
Figure 4-4 VSS with MEC
OL-13013-06
Cisco IOS Software Configuration Guide, Release 12.2SX
4-5
Understanding Virtual Switching Systems
VSS Functionality
The following sections describe the main functionality of a VSS:
• Redundancy and High Availability, page 4-6
• Packet Handling, page 4-6
• System Management, page 4-6
• VSS Quad-Sup Uplink Forwarding, page 4-7
• Interface Naming Convention, page 4-8
• Software Features, page 4-8
Redundancy and High Availability
In a VSS, supervisor engine redundancy operates between the VSS active and VSS standby chassis,
using stateful switchover (SSO) and nonstop forwarding (NSF). The peer chassis exchange configuration
and state information across the VSL and the VSS standby supervisor engine runs in hot VSS standby
mode.
The VSS standby chassis monitors the VSS active chassis using the VSL. If it detects failure, the VSS
standby chassis initiates a switchover and takes on the VSS active role. When the failed chassis recovers,
it takes on the VSS standby role.
Chapter 4 Configuring Virtual Switching Systems
Packet Handling
System Management
If the VSL fails completely, the VSS standby chassis assumes that the VSS active chassis has failed, and
initiates a switchover. After the switchover, if both chassis are VSS active, the dual-active detection
feature detects this condition and initiates recovery action. For additional information about dual-active
detection, see the “Dual-Active Detection” section on page 4-22.
The VSS active supervisor engine runs the Layer 2 and Layer 3 protocols and features for the VSS and
manages the DFC modules for both chassis.
The VSS uses VSL to communicate protocol and system information between the peer chassis and to
carry data traffic between the chassis when required.
Both chassis perform packet forwarding for ingress traffic on their interfaces. If possible, ingress traffic
is forwarded to an outgoing interface on the same chassis to minimize data traffic that must traverse the
VSL.
Because the VSS standby chassis is actively forwarding traffic, the VSS active supervisor engine
distributes updates to the VSS standby supervisor engine PFC and all VSS standby chassis DFCs.
The VSS active supervisor engine acts as a single point of control for the VSS. For example, the VSS
active supervisor engine handles OIR of switching modules on both chassis. The VSS active supervisor
engine uses VSL to send messages to and from local ports on the VSS standby chassis.
The command console on the VSS active supervisor engine is used to control both chassis. In virtual
switch mode, the command console on the VSS standby supervisor engine blocks attempts to enter
configuration mode.
The VSS standby chassis runs a subset of system management tasks. For example, the VSS standby
chassis handles its own power management.
4-6
Cisco IOS Software Configuration Guide, Release 12.2SX
OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
Linecard 1
Linecard 2
Linecard N
Supervisor 2:
standby, ICA
Supervisor 3 ICS Supervisor 4 ICS
Linecard 1
Linecard 2
Linecard N
Supervisor 1:
active, ICA
197277
VSL
Active chassis Standby chassis
VSS Quad-Sup Uplink Forwarding
When you use VSS quad-supervisor uplink forwarding, the in-chassis standby (ICS) supervisor engine
acts as a DFC line card. Only one processor, the SP processor, acts as the DFC line card; the RP processor
is reset to ROMMON. During the bootup, once the chassis level role is resolved, the ICS downloads the
image from the in-chassis active (ICA) supervisor engine. Once the supervisor engine is booted with the
image, it will function in the same way as a DFC line card. All applications running in virtual switch
(VS) view the in-chassis standby as a DFC line card.
See Figure 4-6 for the various roles that supervisor engines can assume within a quad-supervisor VSS
system.
Figure 4-5 Typical VSS Quad-Supervisor Configuration
Understanding Virtual Switching Systems
If your supervisor engine is:
• in-chassis active, it can be VSS active or VSS standby.
• in-chassis standby, it can only be an ICS.
• VSS active, it can only be ICA.
• VSS standby, it can only be ICA.
Quad-supervisor uplink forwarding provides these key features:
• eFSU upgrades— You can upgrade or downgrade your VSS system using ISSU. See “Upgrading a
VSS” section on page 4-54 for more information about eFSU upgrades.
• Image version mismatch—Before the bootup, the ICS completes a version check. If there is a
version mismatch, the ICS is set to ROMMON. If you want to boot different images on the ICS and
ICA. You need to configure the no switch virtual in-chassis standby bootup version
mismatch-check command. This command is only valid once all four supervisors are running
software that supports Quad-supervisor uplink forwarding. If one supervisor is running software that
does not support Quad-supervisor uplink forwarding the command will have no effect.
• EARL mode mismatch—If the supervisor engine EARL modes do not match then the supervisor
engine is reset to ROMMON. It is recommended that all four supervisor engines run the same EARL
Lite or EARL Heavy version.
• VSS RPR switchover—On RPR switchover the ICS will be reset. For more information regarding
RPR see “RPR and SSO Redundancy” section on page 4-12.
OL-13013-06
Cisco IOS Software Configuration Guide, Release 12.2SX
4-7
Understanding Virtual Switching Systems
• In-chassis RPR switchover—ICS supervisor engines in the supervisor engine 1 and supervisor
engine 2 positions boot up as RPR-Warm. RPR-Warm is when a supervisor engine acts as a DFC.
When a VSS stateful switchover occurs, the supervisor engine is reset to ROMMON and boot ups
with the supervisor engine image. You can verify the switchover mode of the supervisor engines by
entering the show module command.
• VSS stateful switchover—When the in-chassis active supervisor engine crashes, a switchover occurs
and the whole chassis reloads (including the ICS) during which the standby supervisor engine takes
over as the in-chassis active supervisor engine. A z-switchover operates exactly like a switchover
except that the ICS supervisor engine takes priority and is assigned the in-chassis standby supervisor
engine. You can initiate a z-switchover by entering the redundancy force switchover command on
the in-chassis active supervisor engine. You can verify the switchover mode of the supervisor
engines by entering the show module command.
If you insert a supervisor engine from another system (VS or standalone) in the supervisor engine 1 or
supervisor engine 2 position of your existing two supervisor engine VSS system, the supervisor engine
does a reset to update the supervisor engine number, and then reboots before going online as a DFC.
Interface Naming Convention
In VSS mode, interfaces are specified using the switch number (in addition to slot and port), because the
same slot numbers are used on both chassis. For example, the interface 1/5/4 command specifies port 4
of the switching module in slot 5 of switch 1. The interface 2/5/4 command specifies port 4 on the
switching module in slot 5 of switch 2.
Chapter 4 Configuring Virtual Switching Systems
Software Features
With some exceptions, the VSS has feature parity with the standalone Catalyst 6500 series switch. Major
exceptions include:
• In software releases earlier than Cisco IOS Release 12.2(33)SXI2, the VSS does not support IPv6
unicast or MPLS.
• In software releases earlier than Cisco IOS Release 12.2(33)SXI, port-based QoS and port ACLs
(PACLs) are supported only on Layer 2 single-chassis or multichassis EtherChannel (MEC) links.
Beginning with Cisco IOS Release 12.2(33)SXI, port-based QoS and PACLs can be applied to any
physical port in the VSS, excluding ports in the VSL. PACLs can be applied to no more than 2046
ports in the VSS.
• In software releases earlier than Cisco IOS Release 12.2(33)SXI4, the VSS does not support
supervisor engine redundancy within a chassis.
• Starting in Cisco IOS Release 12.2(33)SXI4, the VSS does support supervisor engine redundancy
within a chassis.
• In releases earlier than Release 12.2(33) SXH2, the VSS feature and the lawful intercept feature
cannot be configured together. (CSCsl77715)
Hardware Requirements
The following sections describe the hardware requirements of a VSS:
• Chassis and Modules, page 4-9
• VSL Hardware Requirements, page 4-9
• PFC, DFC, and CFC Requirements, page 4-10
4-8
Cisco IOS Software Configuration Guide, Release 12.2SX
OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
• Multichassis EtherChannel Requirements, page 4-10
• Service Module Support, page 4-10
Chassis and Modules
Table 4-1 describes the hardware requirements for the VSS chassis and modules.
Table 4-1 VSS Hardware Requirements
Hardware Count Requirements
Chassis 2 The VSS is available on chassis that support VS-S720-10G supervisor
Supervisor Engines 2 The VSS requires Supervisor Engine 720 with 10-Gigabit Ethernet ports.
Switching Modules 2+ The VSS requires 67xx series switching modules.
Understanding Virtual Switching Systems
engines and WS-X6708-10G switching modules.
Note The two chassis need not be identical.
You must use either two VS-S720-10G-3C or two VS-S720-10G-3CXL
supervisor engine modules.
The two supervisor engines must match exactly.
The VSS does not support classic, CEF256, or dCEF256 switching
modules. In virtual switch mode, unsupported switching modules remain
powered off.
VSL Hardware Requirements
The VSL EtherChannel supports only 10-Gigabit Ethernet ports. The 10-Gigabit Ethernet port can be
located on the supervisor engine module or on one of the following switching modules:
• WS-X6708-10G-3C or WS-X6708-10G-3CXL
• WS-X6716-10G-3C or WS-X6716-10G-3CXL
• WS-X6716-10T-3C or WS-X6716-10T-3CXL
Note • Using the 10-Gigabit Ethernet ports on a WS-X6716-10G switching module in the VSL
EtherChannel requires Cisco IOS Release 12.2(33)SXI or a later release.
• Using the 10-Gigabit Ethernet ports on a WS-X6716-10T switching module in the VSL
EtherChannel requires Cisco IOS Release 12.2(33)SXI4 or a later release.
We recommend that you use both of the 10-Gigabit Ethernet ports on the supervisor engines to create
the VSL between the two chassis.
You can add additional physical links to the VSL EtherChannel by using the 10-Gigabit Ethernet ports
on WS-X6708-10G, WS-X6716-10G, or WS-X6716-10T switching modules.
OL-13013-06
Cisco IOS Software Configuration Guide, Release 12.2SX
4-9
Understanding Virtual Switching Systems
Note • When using the 10-Gigabit Ethernet ports on the WS-X6716-10G or WS-X6716-10T switching
module as VSL links, you must operate the ports in performance, not oversubscription, mode. If you
enter the no hw-module switch x slot y oversubscription command to configure
non-oversubscription mode (performance mode), then only ports 1, 5, 9, and 13 are configurable;
the other ports on the module are disabled.
• Port-groups are independent of each other and one, or more, port-groups can operate in
non-oversubscribed (1:1) mode (e.g. for VSL) with the 3 unused ports administratively shutdown,
while the others can still operate in oversubscribed (4:1) mode.
PFC, DFC, and CFC Requirements
The VSS supports any 67xx series switching module with CFC hardware.
The VSS supports DFC3C or DFC3CXL hardware and does not support DFC3A/3B/3BXL hardware.
If any switching module in the VSS is provisioned with DFC3C, the whole VSS must operate in PFC3C
mode. If a 67xx series switching module with a DFC3A/3B/3BXL is inserted in the chassis of a VSS,
the module will remain unpowered, because VSS supports only DFC3C and DFC3CXL.
Chapter 4 Configuring Virtual Switching Systems
If the supervisor engines are provisioned with PFC3C, the VSS will automatically operate in 3C mode,
even if some of the modules are 3CXL. However, if the supervisor engines are provisioned with
PFC3CXL, but some of the modules are 3C, you need to configure the VSS to operate in 3C mode. The
platform hardware vsl pfc mode pfc3c configuration command sets the system to operate in 3C mode
after the next restart. See the “SSO Dependencies” section on page 4-25 for further details about this
command.
Multichassis EtherChannel Requirements
Physical links from any 67xx series switching module can be used to implement a Multichassis
EtherChannel (MEC).
Service Module Support
VSS mode supports these service modules:
• Network Analysis Modules (NAM):
–
WS-SVC-NAM-1
–
WS-SVC-NAM-2
• Application Control Engines (ACE):
–
ACE10-6500-K9
–
ACE20-MOD-K9
• Intrusion Detection System Services Module (IDSM): WS-SVC-IDSM2-K9
• Wireless Services Module (WiSM): WS-SVC-WISM-1-K9
• Firewall Services Module (FWSM): WS-SVC-FWM-1-K9
4-10
Note Before deploying a service module in VSS mode, check the service module release notes and if
necessary, upgrade the service module software.
Cisco IOS Software Configuration Guide, Release 12.2SX
OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
Active
Supervisor
Linecard 1
Linecard 2
Linecard N
Standby
Supervisor
Linecard 1
Linecard 2
Linecard N
Active chassis Standby chassis
181326
VSL
Understanding VSL Topology
A VSS contains two chassis that communicate using the VSL, which is a special port group.
We recommend that you configure both of the 10-Gigabit Ethernet ports on the supervisor engines as
VSL ports. Optionally, you can also configure the VSL port group to contain switching module
10-Gigabit Ethernet ports. This configuration provides additional VSL capacity. See Figure 4-6 for an
example topology.
Figure 4-6 VSL Topology Example
Understanding Virtual Switching Systems
VSS Redundancy
Overview
The following sections describe how redundancy in a VSS supports network high availability:
• Overview, page 4-11
• RPR and SSO Redundancy, page 4-12
• Failed Chassis Recovery, page 4-13
• VSL Failure, page 4-13
• User Actions, page 4-14
A VSS operates stateful switchover (SSO) between the VSS active and VSS standby supervisor engines.
Compared to standalone mode, a VSS has the following important differences in its redundancy model:
• The VSS active and VSS standby supervisor engines are hosted in separate chassis and use the VSL
to exchange information.
• The VSS active supervisor engine controls both chassis of the VSS. The VSS active supervisor
engine runs the Layer 2 and Layer 3 control protocols and manages the switching modules on both
chassis.
• The VSS active and VSS standby chassis both perform data traffic forwarding.
If the VSS active supervisor engine fails, the VSS standby supervisor engine initiates a switchover and
assumes the VSS active role.
OL-13013-06
Cisco IOS Software Configuration Guide, Release 12.2SX
4-11
Understanding Virtual Switching Systems
Active
Supervisor
Linecard 1
Linecard 2
Linecard N
Standby
Supervisor
Linecard 1
Linecard 2
Linecard N
Active chassis Standby chassis
181326
VSL
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.
• VSL-related configuration in the two chassis must match.
• PFC mode must match.
• SSO and nonstop forwarding (NSF) must be configured on each chassis.
See the “SSO Dependencies” section on page 4-25 for additional details about the requirements for SSO
redundancy on a VSS. See Chapter 6, “Configuring NSF with SSO Supervisor Engine Redundancy” for
information about configuring SSO and NSF.
With SSO redundancy, the VSS standby supervisor engine is always ready to assume control following
a fault on the VSS active supervisor engine. Configuration, forwarding, and state information are
synchronized from the VSS active supervisor engine to the redundant supervisor engine at startup and
whenever changes to the VSS active supervisor engine configuration occur. If a switchover occurs,
traffic disruption is minimized.
If a VSS does not meet the requirements for SSO redundancy, the VSS will use route processor
redundancy (RPR). In RPR mode, the VSS active supervisor engine does not synchronize configuration
changes or state information with the VSS standby. The VSS standby supervisor engine is only partially
initialized and the switching modules on the VSS standby supervisor are not powered up. If a switchover
occurs, the VSS standby supervisor engine completes its initialization and powers up the switching
modules. Traffic is disrupted for the normal reboot time of the chassis.
The VSS normally runs stateful switchover (SSO) between the VSS active and VSS standby supervisor
engines (see Figure 4-7). The VSS determines the role of each supervisor engine during initialization.
The supervisor engine in the VSS standby chassis runs in hot standby state. The VSS uses the VSL link
to synchronize configuration data from the VSS active to the VSS standby supervisor engine. Also,
protocols and features that support high availability synchronize their events and state information to the
VSS standby supervisor engine.
Chapter 4 Configuring Virtual Switching Systems
Figure 4-7 Chassis Roles in a VSS
Cisco IOS Software Configuration Guide, Release 12.2SX
4-12
OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
Failed Chassis Recovery
If the VSS active chassis or supervisor engine fails, the VSS initiates a stateful switchover (SSO) and
the former VSS standby supervisor engine assumes the VSS active role. The failed chassis performs
recovery action by reloading the supervisor engine.
If the VSS standby chassis or supervisor engine fails, no switchover is required. The failed chassis
performs recovery action by reloading the supervisor engine.
The VSL links are unavailable while the failed chassis recovers. After the chassis reloads, it becomes
the new VSS standby chassis and the VSS reinitializes the VSL links between the two chassis.
The switching modules on the failed chassis are unavailable during recovery, so the VSS operates only
with the MEC links that terminate on the VSS active chassis. The bandwidth of the VSS is reduced until
the failed chassis has completed its recovery and become operational again. Any devices that are
connected only to the failed chassis experience an outage.
Note The VSS may experience a brief data path disruption when the switching modules in the VSS standby
chassis become operational after the SSO.
Understanding Virtual Switching Systems
VSL Failure
After the SSO, much of the processing power of the VSS active supervisor engine is consumed in
bringing up a large number of ports simultaneously in the VSS standby chassis. As a result, some links
might be brought up before the supervisor engine has configured forwarding for the links, causing traffic
to those links to be lost until the configuration is complete. This condition is especially disruptive if the
link is an MEC link. Two methods are available to reduce data disruption following an SSO:
• Beginning in Cisco IOS Release 12.2(33)SXH2, you can configure the VSS to activate non-VSL
ports in smaller groups over a period of time rather than all ports simultaneously. For information
about deferring activation of the ports, see the “Configuring Deferred Port Activation During VSS
Standby Recovery” section on page 4-44.
• You can defer the load sharing of the peer switch’s MEC member ports during reestablishment of
the port connections. See the “Failed Chassis MEC Recovery” section on page 4-16 for details about
load share deferral.
To ensure fast recovery from VSL failures, fast link notification is enabled in virtual switch mode on all
port channel members (including VSL ports) whose hardware supports fast link notification.
Note Fast link notification is not compatible with link debounce mechanisms. In virtual switch mode, link
debounce is disabled on all port channel members.
If a single VSL physical link goes down, the VSS adjusts the port group so that the failed link is not
selected.
If the VSS standby chassis detects complete VSL link failure, it initiates a stateful switchover (SSO). If
the VSS active chassis has failed (causing the VSL links to go down), the scenario is chassis failure, as
described in the previous section.
OL-13013-06
If only the VSL has failed and the VSS active chassis is still operational, this is a dual-active scenario.
The VSS detects that both chassis are operating in VSS active mode and performs recovery action. See
the “Dual-Active Detection” section on page 4-22 for additional details about the dual-active scenario.
Cisco IOS Software Configuration Guide, Release 12.2SX
4-13
Understanding Virtual Switching Systems
User Actions
From the VSS active chassis command console, you can initiate a VSS switchover or a reload.
If you enter the reload command from the command console, the entire VSS performs a reload.
To reload only the VSS standby chassis, use redundancy reload peer command.
To force a switchover from the VSS active to the VSS standby supervisor engine, use the redundancy
force-switchover command.
To reset the VSS standby supervisor engine or to reset both the VSS active and VSS standby supervisor
engines, use the redundancy reload shelf command.
Multichassis EtherChannels
These sections describe multichassis EtherChannels (MECs):
• Overview, page 4-14
• MEC Failure Scenarios, page 4-15
Chapter 4 Configuring Virtual Switching Systems
Overview
A multichassis EtherChannel is an EtherChannel with ports that terminate on both chassis of the VSS
(see Figure 4-8). A VSS MEC can connect to any network element that supports EtherChannel (such as
a host, server, router, or switch).
At the VSS, an MEC is an EtherChannel with additional capability: the VSS balances the load across
ports in each chassis independently. For example, if traffic enters the VSS active chassis, the VSS will
select an MEC link from the VSS active chassis. This MEC capability ensures that data traffic does not
unnecessarily traverse the VSL.
Each MEC can optionally be configured to support either PAgP or LACP. These protocols run only on
the VSS active chassis. PAgP or LACP control packets destined for an MEC link on the VSS standby
chassis are sent across VSL.
An MEC can support up to eight VSS active physical links, which can be distributed in any proportion
between the VSS active and VSS standby chassis.
4-14
Cisco IOS Software Configuration Guide, Release 12.2SX
OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
Virtual switch
Supervisor
engine
Supervisor
engine
Active chassis Standby chassis
Router, switch
or server
MEC
Figure 4-8 MEC Topology
Understanding Virtual Switching Systems
MEC Failure Scenarios
We recommend that you configure the MEC with at least one link to each chassis. This configuration
conserves VSL bandwidth (traffic egress link is on the same chassis as the ingress link), and increases
network reliability (if one VSS supervisor engine fails, the MEC is still operational).
The following sections describe possible failures and the resulting impacts:
• Single MEC Link Failure, page 4-15
• All MEC Links to the VSS Active Chassis Fail, page 4-15
• All MEC Links to the VSS Standby Chassis Fail, page 4-16
• All MEC Links Fail, page 4-16
• VSS Standby Chassis Failure, page 4-16
• VSS Active Chassis Failure, page 4-16
• Failed Chassis MEC Recovery, page 4-16
Single MEC Link Failure
If a link within the MEC fails (and other links in the MEC are still operational), the MEC redistributes
the load among the operational links, as in a regular port.
All MEC Links to the VSS Active Chassis Fail
If all links to the VSS active chassis fail, the MEC becomes a regular EtherChannel with operational
links to the VSS standby chassis.
OL-13013-06
Data traffic terminating on the VSS active chassis reaches the MEC by crossing the VSL to the VSS
standby chassis. Control protocols continue to run in the VSS active chassis. Protocol messages reach
the MEC by crossing the VSL.
Cisco IOS Software Configuration Guide, Release 12.2SX
4-15
Understanding Virtual Switching Systems
All MEC Links to the VSS Standby Chassis Fail
If all links fail to the VSS standby chassis, the MEC becomes a regular EtherChannel with operational
links to the VSS active chassis.
Control protocols continue to run in the VSS active chassis. All control and data traffic from the VSS
standby chassis reaches the MEC by crossing the VSL to the VSS active chassis.
All MEC Links Fail
If all links in an MEC fail, the logical interface for the EtherChannel is set to unavailable. Layer 2 control
protocols perform the same corrective action as for a link-down event on a regular EtherChannel.
On adjacent switches, routing protocols and Spanning Tree Protocol (STP) perform the same corrective
action as for a regular EtherChannel.
VSS Standby Chassis Failure
If the VSS standby chassis fails, the MEC becomes a regular EtherChannel with operational links on the
VSS active chassis. Connected peer switches detect the link failures, and adjust their load-balancing
algorithms to use only the links to the VSS active chassis.
Chapter 4 Configuring Virtual Switching Systems
VSS Active Chassis Failure
VSS active chassis failure results in a stateful switchover (SSO). See the “VSS Redundancy” section on
page 4-11 for details about SSO on a VSS. After the switchover, the MEC is operational on the new VSS
active chassis. Connected peer switches detect the link failures (to the failed chassis), and adjust their
load-balancing algorithms to use only the links to the new VSS active chassis.
Failed Chassis MEC Recovery
When a failed chassis returns to service as the new VSS standby chassis, protocol messages reestablish
the MEC links between the recovered chassis and connected peer switches.
Although the recovered chassis’ MEC links are immediately ready to receive unicast traffic from the peer
switch, received multicast traffic may be lost for a period of several seconds to several minutes. To
reduce this loss, you can configure the port load share deferral feature on MEC port channels of the peer
switch. When load share deferral is configured, the peer’s deferred MEC port channels will establish
with an initial load share of 0. During the configured deferral interval, the peer’s deferred port channels
are capable of receiving data and control traffic, and of sending control traffic, but are unable to forward
data traffic to the VSS. See the “Configuring Port Load Share Deferral on the Peer Switch” section on
page 4-45 for details about configuring port load share deferral.
Packet Handling
In a VSS, the VSS active supervisor engine runs the Layer 2 and Layer 3 protocols and features for the
VSS and manages the DFC modules for both chassis.
4-16
The VSS uses the VSL to communicate system and protocol information between the peer chassis and
to carry data traffic between the two chassis.
Both chassis perform packet forwarding for ingress traffic on their local interfaces. The VSS minimizes
the amount of data traffic that must traverse the VSL.
Cisco IOS Software Configuration Guide, Release 12.2SX
OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
The following sections describe packet handling in a VSS:
• Traffic on the VSL, page 4-17
• Layer 2 Protocols, page 4-17
• Layer 3 Protocols, page 4-18
• SPAN, page 4-20
Traffic on the VSL
The VSL carries data traffic and in-band control traffic between the two chassis. All frames forwarded
over the VSL link are encapsulated with a special 32-byte header, which provides information for the
VSS to forward the packet on the peer chassis.
The VSL transports control messages between the two chassis. Messages include protocol messages that
are processed by the VSS active supervisor engine, but received or transmitted by interfaces on the VSS
standby chassis. Control traffic also includes module programming between the VSS active supervisor
engine and switching modules on the VSS standby chassis.
The VSS needs to transmit data traffic over the VSL under the following circumstances:
Understanding Virtual Switching Systems
Layer 2 Protocols
• Layer 2 traffic flooded over a VLAN (even for dual-homed links).
• Packets processed by software on the VSS active supervisor engine where the ingress interface is on
the VSS standby chassis.
• The packet destination is on the peer chassis, such as the following examples:
–
Traffic within a VLAN where the known destination interface is on the peer chassis.
–
Traffic that is replicated for a multicast group and the multicast receivers are on the peer chassis.
–
The known unicast destination MAC address is on the peer chassis.
–
The packet is a MAC notification frame destined for a port on the peer chassis.
VSL also transports system data, such as NetFlow export data and SNMP data, from the VSS standby
chassis to the VSS active supervisor engine.
To preserve the VSL bandwidth for critical functions, the VSS uses strategies to minimize user data
traffic that must traverse the VSL. For example, if an access switch is dual-homed (attached with an
MEC terminating on both VSS chassis), the VSS transmits packets to the access switch using a link on
the same chassis as the ingress link.
Traffic on the VSL is load-balanced with the same global hashing algorithms available for
EtherChannels (the default algorithm is source-destination IP).
The VSS active supervisor engine runs the Layer 2 protocols (such as STP and VTP) for the switching
modules on both chassis. Protocol messages that are transmitted and received on the VSS standby chassis
switching modules must traverse the VSL to reach the VSS active supervisor engine.
OL-13013-06
The following sections describe Layer 2 protocols for a VSS:
• Spanning Tree Protocol, page 4-18
• Virtual Trunk Protocol, page 4-18
• EtherChannel Control Protocols, page 4-18
• Multicast Protocols, page 4-18
Cisco IOS Software Configuration Guide, Release 12.2SX
4-17
Understanding Virtual Switching Systems
Spanning Tree Protocol
The VSS active chassis runs Spanning Tree Protocol (STP). The VSS standby chassis redirects STP
BPDUs across the VSL to the VSS active chassis.
The STP bridge ID is commonly derived from the chassis MAC address. To ensure that the bridge ID
does not change after a switchover, the VSS continues to use the original chassis MAC address for the
STP Bridge ID.
Virtual Trunk Protocol
Virtual Trunk Protocol (VTP) uses the IP address of the switch and local current time for version control
in advertisements. After a switchover, VTP uses the IP address of the newly VSS active chassis.
EtherChannel Control Protocols
Link Aggregation Control Protocol (LACP) and Port Aggregation Protocol (PAgP) packets contain a
device identifier. The VSS defines a common device identifier for both chassis to use.
A new PAgP enhancement has been defined for assisting with dual-active scenario detection. For
additional information, see the “Dual-Active Detection” section on page 4-22.
Chapter 4 Configuring Virtual Switching Systems
Multicast Protocols
Layer 3 Protocols
In Release 12.2(33)SXI4 and later releases, fast-redirect optimization makes multicast traffic redirection
between inter-chassis or intra-chassis line cards faster for Layer 2 trunk multichassis EtherChannel or
distributed EtherChannel in case of member port link failure and recovery. This operation occurs mainly
when a member port link goes down (port leaves the EtherChannel) and when the member port link goes
up (port joins or rejoins the EtherChannel). Fast-redirect does not take effect when you add or remove a
member port due to a configuration change or during system boot up.
The MSFC on the VSS active supervisor engine runs the Layer 3 protocols and features for the VSS.
Both chassis perform packet forwarding for ingress traffic on their interfaces. If possible, ingress traffic
is forwarded to an outgoing interface on the same chassis, to minimize data traffic that must traverse the
VSL.
Because the VSS standby chassis is actively forwarding traffic, the VSS active supervisor engine
distributes updates to the VSS standby supervisor engine PFC and all VSS standby chassis DFCs.
The following sections describe Layer 3 protocols for a VSS:
• IPv4, page 4-18
• IPv6 and MPLS, page 4-19
• IPv4 Multicast, page 4-19
• Software Features, page 4-20
IPv4
4-18
The supervisor engine on the VSS active chassis runs the IPv4 routing protocols and performs any
required software forwarding.
Routing updates received on the VSS standby chassis are redirected to the VSS active chassis across the
VSL.
Cisco IOS Software Configuration Guide, Release 12.2SX
OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
Hardware forwarding is distributed across all DFCs on the VSS. The supervisor engine on the VSS active
chassis sends FIB updates to all local DFCs, remote DFCs, and the VSS standby supervisor engine PFC.
All hardware routing uses the router MAC address assigned by the VSS active supervisor engine. After
a switchover, the original MAC address is still used.
The supervisor engine on the VSS active chassis performs all software forwarding (for protocols such
as IPX) and feature processing (such as fragmentation and TTL exceed). If a switchover occurs, software
forwarding is disrupted until the new VSS active supervisor engine obtains the latest CEF and other
forwarding information.
In virtual switch mode, the requirements to support non-stop forwarding (NSF) are the same as in
standalone mode. For additional information about NSF requirements, refer to the Catalyst 6500 Series
Switch Cisco IOS Configuration Guide, Release 12.2SX.
From a routing peer perspective, EtherChannels remain operational during a switchover (only the links
to the failed chassis are down).
The VSS implements path filtering by storing only local paths (paths that do not traverse the VSL) in the
FIB entries. Therefore, IP forwarding performs load sharing among the local paths. If no local paths to
a given destination are available, the VSS updates the FIB entry to include remote paths (reachable by
traversing the VSL).
Understanding Virtual Switching Systems
IPv6 and MPLS
IPv4 Multicast
In Cisco IOS Release 12.2(33)SXI2 and later releases, the VSS supports IPv6 unicast and MPLS.
The IPv4 multicast protocols run on the VSS active supervisor engine. Internet Group Management
Protocol (IGMP) and Protocol Independent Multicast (PIM) protocol packets received on the VSS
standby supervisor engine are transmitted across VSL to the VSS active chassis.
The VSS active supervisor engine sends IGMP and PIM protocol packets to the VSS standby supervisor
engine in order to maintain Layer 2 information for stateful switchover (SSO).
The VSS active supervisor engine distributes multicast FIB and adjacency table updates to the VSS
standby supervisor engine and switching module DFCs.
For Layer 3 multicast in the VSS, learned multicast routes are stored in hardware in the VSS standby
supervisor engine. After a switchover, multicast forwarding continues, using the existing hardware
entries.
Note To avoid multicast route changes as a result of the switchover, we recommend that all links carrying
multicast traffic be configured as MEC rather than Equal Cost Multipath (ECMP).
In virtual switch mode, the VSS active chassis does not program the multicast expansion table (MET)
on the VSS standby chassis. The VSS standby supervisor engine programs the outgoing interface
hardware entries for all local multicast receivers
If all switching modules on the VSS active chassis and VSS standby chassis are egress capable, the
multicast replication mode is set to egress mode; otherwise, the mode is set to ingress mode.
OL-13013-06
In egress mode, replication is distributed to DFCs that have ports in outgoing VLANs for a particular
flow. In ingress mode, replication for all outgoing VLANs is done on the ingress DFC.
For packets traversing VSL, all Layer 3 multicast replication occurs on the ingress chassis. If there are
multiple receivers on the egress chassis, replicated packets are forwarded over the VSL.
Cisco IOS Software Configuration Guide, Release 12.2SX
4-19
Understanding Virtual Switching Systems
Software Features
Software features run only on the VSS active supervisor engine. Incoming packets to the VSS standby
chassis that require software processing are sent across the VSL.
For features supported in hardware, the ACL configuration is sent to the TCAM manager on the VSS
active supervisor engine, the VSS standby supervisor engine, and all DFCs.
SPAN
The VSS supports all SPAN features for non-VSL interfaces. The VSS supports SPAN features on VSL
interfaces with the following limitations:
• If the VSL is configured as a local SPAN source, the SPAN destination interface must be on the same
• VSL cannot be configured as a SPAN destination.
• VSL cannot be configured as a traffic source of RSPAN, ERSPAN, or egress-only SPAN.
The number of SPAN sessions available to a VSS is the same as for a single chassis running in standalone
mode.
Chapter 4 Configuring Virtual Switching Systems
chassis as the source interface.
System Monitoring
The following sections describe system monitoring and system management for a VSS:
• Power Management, page 4-20
• Environmental Monitoring, page 4-20
• File System Access, page 4-21
• VSL Diagnostics, page 4-21
• Service Modules, page 4-21
• Network Management, page 4-22
Power Management
From the VSS active chassis, you can control power-related functions for the VSS standby chassis. For
example, use the power enable switch command to control power to the modules and slots on the VSS
standby chassis. Use the show power switch command to see the current power settings and status.
Environmental Monitoring
Environmental monitoring runs on both supervisor engines. The VSS standby chassis reports
notifications to the VSS active supervisor engine. The VSS active chassis gathers log messages for both
chassis. The VSS active chassis synchronizes the calendar and system clock to the VSS standby chassis.
4-20
Cisco IOS Software Configuration Guide, Release 12.2SX
OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
File System Access
You can access file systems of both chassis from the VSS active chassis. Prefix the device name with
the switch number and slot number to access directories on the VSS standby chassis. For example, the
command dir sw2-slot6-disk0: lists the contents of disk0 on the VSS standby chassis (assuming switch
2 is the VSS standby chassis). You can access the VSS standby chassis file system only when VSL is
operational.
VSL Diagnostics
You can use the diagnostic schedule and diagnostic start commands on a VSS. In virtual switch mode,
these commands require an additional parameter, which specifies the chassis to apply the command.
When you configure a VSL port on a switching module or a supervisor engine module, the diagnostics
suite incorporates additional tests for the VSL ports.
Use the show diagnostic content command to display the diagnostics test suite for a module.
The following VSL-specific diagnostics tests are available on WS-X6708-10G switching modules with
VSL ports. These tests are disruptive:
• TestVslBridgeLink
• TestVslLocalLoopback
Understanding Virtual Switching Systems
Service Modules
The following VSL-specific diagnostics tests are available on a Supervisor Engine 720-10GE with VSL
ports. These tests are disruptive:
• TestVSActiveToStandbyLoopback
• TestVslBridgeLink
• TestVslLocalLoopback
The following VSL-specific diagnostics test is available for VSL ports on the switching module or the
supervisor engine. This test is not disruptive:
• TestVslStatus
See the “ViSN Tests” section on page B-47.
The following system monitoring and system management guidelines apply to service modules
supported by the VSS:
• The supervisor engine in the same chassis as the service module controls the powering up of the
service module. After the service module is online, you initiate a session from the VSS active
supervisor engine to configure and maintain the service module.
• Use the session command to connect to the service module. If the service module is in the VSS
standby chassis, the session runs over the VSL.
• The VSS active chassis performs the graceful shutdown of the service module, even if the service
module is in the VSS standby chassis.
OL-13013-06
Cisco IOS Software Configuration Guide, Release 12.2SX
4-21
Understanding Virtual Switching Systems
Network Management
The following sections describe network management for a VSS:
• Telnet over SSH Sessions and the Web Browser User Interface, page 4-22
• SNMP, page 4-22
• Command Console, page 4-22
Telnet over SSH Sessions and the Web Browser User Interface
A VSS supports remote access using Telnet over SSH sessions and the Cisco web browser user interface.
All remote access is directed to the VSS active supervisor engine, which manages the whole VSS.
If the VSS performs a switchover, Telnet over SSH sessions and web browser sessions are disconnected.
SNMP
The SNMP agent runs on the VSS active supervisor engine.
CISCO-VIRTUAL-SWITCH-MIB is a new MIB for virtual switch mode and contains the following
main components:
• cvsGlobalObjects — Domain #, Switch #, Switch Mode
• cvsCoreSwitchConfig — Switch Priority
Chapter 4 Configuring Virtual Switching Systems
• cvsChassisTable — Chassis Role and Uptime
• cvsVSLConnectionTable — VSL Port Count, Operational State
• cvsVSLStatsTable — Total Packets, Total Error Packets
• cvsVSLPortStatsTable — TX/RX Good, Bad, Bi-dir and Uni-dir Packets
Command Console
Connect console cables to both supervisor engine console ports. You can only use configuration mode
in the console for the VSS active supervisor engine.
The console on the VSS standby chassis will indicate that chassis is operating in VSS standby mode by
adding the characters “-stdby” to the command line prompt. You cannot enter configuration mode on the
VSS standby chassis console.
The following example shows the prompt on the VSS standby console:
Router-stdby> show switch virtual
Switch mode : Virtual Switch
Virtual switch domain number : 100
Local switch number : 1
Local switch operational role: Virtual Switch Standby
Peer switch number : 2
Peer switch operational role : Virtual Switch Active
Dual-Active Detection
4-22
If the VSL fails, the VSS standby chassis cannot determine the state of the VSS active chassis. To ensure
that switchover occurs without delay, the VSS standby chassis assumes the VSS active chassis has failed
and initiates switchover to take over the VSS active role.
Cisco IOS Software Configuration Guide, Release 12.2SX
OL-13013-06
Loading...