AKvsStonser_天涯社区
给AKvsStonser发短消息：
最近玩过的游戏Catalyst 6500 Release 12.2SX Software Configuration Guide - Virtual Switching Systems (VSS) [Cisco Catalyst 6500 Series Switches] - Cisco
Catalyst 6500 Release 12.2SX Software Configuration Guide
Book Contents
Book Contents
Available Languages
Download Options
Book Title
Catalyst 6500 Release 12.2SX Software Configuration Guide
Chapter Title
Virtual Switching Systems (VSS)
View with Adobe Reader on a variety of devices
Chapter: Virtual Switching Systems (VSS)
Chapter Contents
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:
oThe Cisco IOS Virtual Switch Command Reference at this&URL:
oThe Cisco IOS Release 12.2 publications at this&URL:
Tip For additional information about Cisco Catalyst 6500 series switches (including configuration examples and troubleshooting information), see the documents listed on this page:
This chapter consists of these sections:
These sections describe a VSS:
Network operators increase network reliability by configuring redundant pairs of network devices and links.
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.
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:
The VSS incorporates the following key concepts:
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 .
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.
Figure&4-2 VSS in the Distribution Network
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.
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 . 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
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:
omls qos trust cos
omls qos channel-consistency
odescription
ologging event
oload-interval
oport-channel port
When in VSL restricted mode, only these configuration commands are available:
ochannel-group
odescription
oload-interval
omls netflow
omls switching
Note The mls qos command is not available when a port is in VSL restricted mode.
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 .
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.
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
The following sections describe the main functionality of a VSS:
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.
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 .
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.
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 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.
for the various roles that supervisor engines can assume within a quad-supervisor VSS system.
Figure&4-5 Typical VSS Quad-Supervisor Configuration
If your supervisor engine is:
oin-chassis active, it can be VSS active or VSS standby.
oin-chassis standby, it can only be an ICS.
oVSS active, it can only be ICA.
oVSS standby, it can only be ICA.
Quad-supervisor uplink forwarding provides these key features:
oeFSU upgrades— You can upgrade or downgrade your VSS system using ISSU. See
for more information about eFSU upgrades.
oImage 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.
oEARL 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.
oVSS RPR switchover—On RPR switchover the ICS will be reset. For more information regarding RPR see .
oIn-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.
oVSS 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.
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.
With some exceptions, the VSS has feature parity with the standalone Catalyst&6500 series switch. Major exceptions include:
oIn software releases earlier than Cisco IOS Release 12.2(33)SXI2, the VSS does not support IPv6 unicast or MPLS.
oIn 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.
oIn software releases earlier than Cisco IOS Release 12.2(33)SXI4, the VSS does not support supervisor engine redundancy within a chassis.
oStarting in Cisco IOS Release 12.2(33)SXI4, the VSS does support supervisor engine redundancy within a chassis.
oIn releases earlier than Release 12.2(33) SXH2, the VSS feature and the lawful intercept feature cannot be configured together. ()
The following sections describe the hardware requirements of a VSS:
describes the hardware requirements for the VSS chassis and modules.
Table&4-1 VSS Hardware Requirements
The VSS is available on chassis that support VS-S720-10G supervisor engines and WS-X6708-10G switching modules.
Note The two chassis need not be identical.
Supervisor Engines
The VSS requires Supervisor Engine 720 with 10-Gigabit Ethernet ports. 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.
Switching Modules
The VSS requires 67xx series switching modules.
The VSS does not support classic, CEF256, or dCEF256 switching modules. In virtual switch mode, unsupported switching modules remain powered off.
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:
oWS-XC or WS-XCXL
oWS-XC or WS-XCXL
oWS-XC or WS-XCXL
NoteoUsing 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.
oUsing 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.
NoteoWhen 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 the other ports on the module are disabled.
oPort-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.
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.
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
for further details about this command.
Physical links from any 67xx series switching module can be used to implement a Multichassis EtherChannel (MEC).
VSS mode supports these service modules:
oNetwork Analysis Modules (NAM):
–WS-SVC-NAM-1
–WS-SVC-NAM-2
oApplication Control Engines (ACE):
–ACE10-6500-K9
–ACE20-MOD-K9
oIntrusion Detection System Services Module (IDSM): WS-SVC-IDSM2-K9
oWireless Services Module (WiSM): WS-SVC-WISM-1-K9
oFirewall Services Module (FWSM): WS-SVC-FWM-1-K9
Note Before deploying a service module in VSS mode, check the service module release notes and if necessary, upgrade the service module software.
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
for an example topology.
Figure&4-6 VSL Topology Example
The following sections describe how redundancy in a VSS supports network high availability:
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:
oThe VSS active and VSS standby supervisor engines are hosted in separate chassis and use the VSL to exchange information.
oThe 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.
oThe 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.
A VSS operates with stateful switchover (SSO) redundancy if it meets the following requirements:
oBoth supervisor engines must be running the same software version.
oVSL-related configuration in the two chassis must match.
oPFC mode must match.
oSSO and nonstop forwarding (NSF) must be configured on each chassis.
for additional details about the requirements for SSO redundancy on a VSS. See
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 ). 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.
Figure&4-7 Chassis Roles in a VSS
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.
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:
oBeginning 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 .
oYou can defer the load sharing of the peer switch's MEC member ports during reestablishment of the port connections. See the
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.
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
for additional details about the dual-active scenario.
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.
These sections describe multichassis EtherChannels (MECs):
A multichassis EtherChannel is an EtherChannel with ports that terminate on both chassis of the VSS (see ). 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.
Figure&4-8 MEC Topology
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:
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.
If all links to the VSS active chassis fail, the MEC becomes a regular EtherChannel with operational links to the VSS standby chassis.
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.
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.
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.
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.
VSS active chassis failure results in a stateful switchover (SSO). See the
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.
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
for details about configuring port load share deferral.
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.
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.
The following sections describe packet handling in a VSS:
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:
oLayer 2 traffic flooded over a VLAN (even for dual-homed links).
oPackets processed by software on the VSS active supervisor engine where the ingress interface is on the VSS standby chassis.
oThe 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.
The following sections describe Layer 2 protocols for a VSS:
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 (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.
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 .
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:
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.
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).
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 i otherwise, the mode is set to ingress mode.
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.
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.
The VSS supports all SPAN features for non-VSL interfaces. The VSS supports SPAN features on VSL interfaces with the following limitations:
oIf the VSL is configured as a local SPAN source, the SPAN destination interface must be on the same chassis as the source interface.
oVSL cannot be configured as a SPAN destination.
oVSL 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.
The following sections describe system monitoring and system management for a VSS:
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 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.
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.
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:
oTestVslBridgeLink
oTestVslLocalLoopback
The following VSL-specific diagnostics tests are available on a Supervisor Engine 720-10GE with VSL ports. These tests are disruptive:
oTestVSActiveToStandbyLoopback
oTestVslBridgeLink
oTestVslLocalLoopback
The following VSL-specific diagnostics test is available for VSL ports on the switching module or the supervisor engine. This test is not disruptive:
oTestVslStatus
The following system monitoring and system management guidelines apply to service modules supported by the VSS:
oThe 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.
oUse 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.
oThe VSS active chassis performs the graceful shutdown of the service module, even if the service module is in the VSS standby chassis.
The following sections describe network management for a VSS:
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.
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:
ocvsGlobalObjects — Domain #, Switch #, Switch Mode
ocvsCoreSwitchConfig — Switch Priority
ocvsChassisTable — Chassis Role and Uptime
ocvsVSLConnectionTable — VSL Port Count, Operational State
ocvsVSLStatsTable — Total Packets, Total Error Packets
ocvsVSLPortStatsTable — TX/RX Good, Bad, Bi-dir and Uni-dir Packets
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
Local switch operational role: Virtual Switch Standby
Peer switch number
Peer switch operational role : Virtual Switch Active
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.
If the original VSS active chassis is still operational, both chassis are now VSS active. This situation is called a dual-active scenario. A dual-active scenario can have adverse affects on network stability, because both chassis use the same IP addresses, SSH keys, and STP bridge ID. The VSS must detect a dual-active scenario and take recovery action.
The VSS supports these three methods for detecting a dual-active scenario:
oEnhanced PAgP—Uses PAgP messaging over the MEC links to communicate between the two chassis through a neighbor switch. Enhanced PAgP is faster than IP BFD, but requires a neighbor switch that supports the PAgP enhancements.
oIP Bidirectional Forwarding Detection (BFD)—Uses BFD messaging over a backup Ethernet connection. IP BFD uses a direct connection between the two chassis and does not require support from a neighbor switch.
odual-active fast-hello—Uses special hello messages over a backup Ethernet connection. Dual-active fast-hello is faster than IP BFD and does not require support from a neighbor switch. This method is available only in Cisco IOS Release 12.2(33)SXI and later releases,
You can configure all three detection methods to be VSS active at the same time.
For line redundancy, we recommend dedicating at least two ports per switch for dual-active detection. For module redundancy, the two ports can be on different switching modules in each chassis, and should be on different modules than the VSL links, if feasible.
The dual-active detection and recovery methods are described in the following sections:
If a VSS MEC terminates on a Cisco switch, you can run the port aggregation protocol (PAgP) on the MEC. If enhanced PAgP is running on an MEC between the VSS and another switch running Release 12.2(33)SXH1 or a later release, the VSS can use enhanced PAgP to detect a dual-active scenario.
The MEC must have at least one port on each chassis of the VSS. In VSS mode, PAgP messages include a new type length value (TLV) that contains the ID of the VSS active switch. Only switches in VSS mode send the new TLV.
When the VSS standby chassis detects VSL failure, it initiates SSO and becomes VSS active. Subsequent PAgP messages to the connected switch from the newly VSS active chassis contain the new VSS active ID. The connected switch sends PAgP messages with the new VSS active ID to both VSS chassis.
If the formerly VSS active chassis is still operational, it detects the dual-active scenario because the VSS active ID in the PAgP messages changes. This chassis initiates recovery actions as described in the .
To use the IP BFD detection method, you must provision a direct Ethernet connection between the two switches. Regular Layer 3 ping will not function correctly on this connection, as both chassis have the same IP address. The VSS instead uses the Bidirectional Forwarding Detection (BFD) protocol.
If the VSL fails, both chassis create BFD neighbors, and try to establish adjacency. If the original VSS active chassis receives an adjacency message, it realizes that this is a dual-active scenario, and initiates recovery actions as described in the .
Note If Flex Links are configured on the VSS, we recommend using the PAgP detection method. Do not configure Flex Links and BFD dual-active detection on the same VSS.
Cisco IOS Release 12.2(33)SXI and later releases support the dual-active fast hello method.
To use the dual-active fast hello packet detection method, you must provision a direct Ethernet connection between the two VSS chassis. You can dedicate up to four non-VSL links for this purpose.
The two chassis periodically exchange special Layer 2 dual-active hello messages containing information about the switch state. If the VSL fails and a dual-active scenario occurs, each switch recognizes from the peer's messages that there is a dual-active scenario and initiates recovery actions as described in the . If a switch does not receive an expected dual-active fast hello message from the peer before the timer expires, the switch assumes that the link is no longer capable of dual-active detection.
An VSS active chassis that detects a dual-active condition shuts down all of its non-VSL interfaces (except interfaces configured to be excluded from shutdown) to remove itself from the network, and waits in recovery mode until the VSL links have recovered. You might need to physically repair the VSL failure. When the shut down chassis detects that VSL is operational again, the chassis reloads and returns to service as the VSS standby chassis.
Loopback interfaces are also shut down in recovery mode. Do not configure loopback interfaces while in recovery mode, because any new loopback interfaces configured in recovery mode will not be shut down.
Note If the running configuration of the chassis in recovery mode has been changed without saving, the chassis will not automatically reload. In this situation, you must save the running configuration and then reload manually.
A VSS is formed when the two chassis and the VSL link between them become operational. The peer chassis communicate over the VSL to negotiate the chassis roles.
If only one chassis becomes operational, it assumes the VSS active role. The VSS forms when the second chassis becomes operational and both chassis bring up their VSL interfaces.
VSS initialization is described in the following sections:
The Virtual Switch Link Protocol (VSLP) consists of several protocols that contribute to virtual switch initialization. The VSLP includes the following protocols:
oRole Resolution Protocol—The peer chassis use Role Resolution Protocol (RRP) to negotiate the role (VSS active or VSS standby) for each chassis.
oLink Management Protocol—The Link Management Protocol (LMP) runs on all VSL links, and exchanges information required to establish communication between the two chassis. LMP identifies and rejects any unidirectional links. If LMP flags a unidirectional link, the chassis that detects the condition brings the link down and up to restart the VSLP negotiation. VSL moves the control traffic to another port if necessary.
For the VSS to operate with SSO redundancy, the VSS must meet the following conditions:
oIdentical software versions—Both supervisor engine modules on the VSS must be running the identical software version.
oVSL configuration consistency—During the startup sequence, the VSS standby chassis sends virtual switch information from the startup-config file to the VSS active chassis. The VSS active chassis ensures that the following information matches correctly on both chassis:
–Switch virtual domain
–Switch virtual node
–Switch priority
–VSL port channel: switch virtual link identifier
–VSL ports: channel-group number, shutdown, total number of VSL ports
–Power redundancy-mode
–Power enable on VSL modules
If the VSS detects a mismatch, it prints out an error message on the VSS active chassis console and the VSS standby chassis comes up in RPR mode.
After you correct the configuration file, save the file by entering the copy running-config startup-config command on the VSS active chassis, and then restart the VSS standby chassis.
oPFC mode check—If both supervisor engines are provisioned with PFC3C, the VSS will automatically operate in PFC3C mode, even if some of the switching modules are equipped with DFC3CXLs.
However, if the supervisor engines are provisioned with PFC3CXL and there is a mixture of DFC3C and DFC3CXL switching modules, the system PFC mode will depend on how the 3C and 3CXL switching modules are distributed between the two chassis.
Each chassis in the VSS determines its system PFC mode. If the supervisor engine of a given chassis is provisioned with PFC3CXL and all the switching modules in the chassis are provisioned with DFC3CXL, the PFC mode for the chassis is PFC3CXL. However, if any of the switching modules is provisioned with DFC3C, the chassis PFC mode will be set to PFC3C. If there is a mismatch between the PFC modes of two chassis, the VSS will come up in RPR mode instead of SSO mode. You can prevent this situation by using the platform hardware vsl pfc mode pfc3c command to force the VSS to operate in PFC3C mode after the next reload.
oSSO and NSF enabled
SSO and NSF must be configured and enabled on both chassis. For detailed information on configuring and verifying SSO and NSF, see
If these conditions are not met, the VSS operates in RPR redundancy mode. For a description of SSO and RPR, see the .
The following sections describe the VSS initialization procedure:
A VSS is formed when the two chassis and the VSL link between them become operational. Because both chassis 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 chassis communicate over VSL to negotiate their roles (VSS active or VSS standby).
3. The VSS active chassis completes the boot sequence, including the consistency check described in the .
4. If the consistency check completed successfully, the VSS standby chassis comes up in SSO VSS standby mode. If the consistency check failed, the VSS standby chassis comes up in RPR mode.
5. The VSS active chassis synchronizes configuration and application data to the VSS standby chassis.
If you boot both chassis simultaneously, the VSL ports become VSS active, and the chassis will come up as VSS active and VSS standby. If priority is configured, the higher priority switch becomes active.
If you boot up only one chassis, the VSL ports remain inactive, and the chassis comes up as VSS active. When you subsequently boot up the other chassis, the VSL links become active, and the new chassis comes up as VSS standby.
If the VSL is down when both chassis try to boot up, the situation is similar to a dual-active scenario.
One of the chassis becomes VSS active and the other chassis initiates recovery from the dual-active scenario. For further information, see the .
The following sections describe restrictions and guidelines for VSS configuration:
When configuring the VSS, note the following guidelines and restrictions:
oThe VSS configurations in the startup-config file must match on both chassis.
oIf you configure a new value for switch priority, the change takes effect only after you save the configuration file and perform a restart.
oEnable the out-of-band MAC address table synchronization among DFC-equipped switching modules by entering the mac-address-table synchronize command.
When configuring the VSL, note the following guidelines and restrictions:
oFor 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.
oThe no mls qos channel-consistency command is automatically applied when you configure the VSL. Do not remove this command.
oVSL ports cannot be Mini Protocol Analyzer sources (the monitor ... capture command). Monitor capture sessions cannot be started if a source is the VSL on the port channel of the standby switch. The following message is displayed when a remote VSL port channel on the standby switch is specified and you attempt to start the monitor capture:
% remote VSL port is not allowed as capture source
The following message is displayed when a scheduled monitor capture start fails because a source is a remote VSL port channel:
Packet capture session 1 failed to start. A source port is a remote VSL.
When configuring MECs, note the following guidelines and restrictions:
oAll links in an MEC must terminate locally on the VSS active or VSS standby chassis of the same virtual domain.
oFor an MEC using the LACP control protocol, the minlinks command argument defines the minimum number of physical links in each chassis for the MEC to be operational.
oFor an MEC using the LACP control protocol, the maxbundle command argument defines the maximum number of links in the MEC across the whole VSS.
oMEC supports LACP 1:1 redundancy. For additional information about LACP 1:1 redundancy, refer to the .
oAn MEC can be connected to another MEC in a different VSS domain.
When configuring dual-active detection, note the following guidelines and restrictions:
oIf Flex Links are configured on the VSS, use PAgP dual-active detection.
oDo not configure Flex Links and BFD dual-active detection on the same VSS.
oFor dual-active detection link redundancy, configure at least two ports per switch for dual-active detection. For module redundancy, the two ports can be on different switching modules in each chassis, and should be on different modules than the VSL, if feasible.
oWhen you configure dual-active fast hello mode, all existing configurations are removed automatically from the interface except for these commands:
–description
–logging event
–load-interval
–rcv-queue cos-map
–rcv-queue queue-limit
–rcv-queue random-detect
–rcv-queue threshold
–wrr-queue bandwidth
–wrr-queue cos-map
–wrr-queue queue-limit
–wrr-queue random-detect
–wrr-queue threshold
–priority-queue cos-map
oOnly these configuration commands are available on dual-active detection fast hello ports:
–description
–dual-active
–load-interval
–shutdown
oASIC-specific QoS commands are not configurable on dual-active detection fast hello ports directly, but are allowed to remain on the fast hello port if the commands were configured on another non-fast hello port in that same ASIC group. For a list of these commands, see the .
When configuring service modules in a VSS, note the following guidelines and restrictions:
oWhen configuring and attaching VLAN groups to a service module interface in a VSS, use the switch {1 | 2} command keyword. For example, the firewall vlan-group command becomes the firewall switch num slot slot vlan-group command.
oWhen upgrading the software image of a service module in a VSS, use the switch {1 | 2} command keyword.
oEtherChannel load balancing (ECLB) is not supported between an IDSM-2 in the VSS active chassis and an IDSM-2 in the VSS standby chassis.
oA switchover between two service modules in separate chassis of a VSS is considered an intrachassis switchover.
Note For detailed instructions, restrictions, and guidelines for a service module in a VSS, see the configuration guide and command reference for the service module.
These sections describe how to configure a VSS:
By default, the Catalyst&6500 series switch is configured to operate in standalone mode (the switch is a single chassis). The VSS combines two standalone switches into one virtual switch, operating in virtual switch mode.
Note When you convert two standalone switches into one VSS, all non-VSL configuration settings on the VSS standby chassis will revert to the default configuration.
To convert two standalone chassis into a VSS, you perform the following major activities:
oSave the standalone configuration files.
oConfigure SSO and NSF on each chassis.
oConfigure each chassis as a VSS.
oConvert to a VSS.
oConfigure the peer VSL information.
In virtual switch mode, both chassis use the same configuration file. When you make configuration changes on the VSS active chassis, these changes are automatically propagated to the VSS standby chassis.
The tasks required to convert the standalone chassis to a VSS are detailed in the following sections:
In the procedures that follow, the example commands assume the configuration shown in .
Figure&4-9 Example VSS
Two chassis, A and B, are converted into a VSS with virtual switch domain 100. Interface 10-Gigabit Ethernet 5/1 on Switch 1 is connected to interface 10-Gigabit Ethernet 5/2 on Switch 2 to form the VSL.
Save the configuration files for both chassis operating in standalone mode. You need these files to revert to standalone mode from virtual switch mode. On Switch 1, perform this task:
Switch-1# copy running-config startup-config
(Optional) Saves the running configuration to startup configuration.
Switch-1# copy startup-config disk0:old-startup-config
Copies the startup configuration to a backup file.
Perform the following task on Switch 2:
Switch-2# copy running-config startup-config
(Optional) Saves the running configuration to the startup configuration file.
Switch-2# copy startup-config disk0:old-startup-config
Copies the startup configuration to a backup file.
SSO and NSF must be configured and enabled on both chassis. On Switch 1, perform this task:
Switch-1(config)# redundancy
Enters redundancy configuration mode.
Switch-1(config-red)# mode sso
Configures SSO. When this command is entered, the redundant supervisor engine is reloaded and begins to work in SSO mode.
Switch-1(config-red)# exit
Exits redundancy configuration mode.
Switch-1(config)# router routing_protocol processID
Enables routing, which places the router in router configuration mode.
Switch-1(config-router)# nsf
Enables NSF operations for the routing protocol.
Switch-1(config-router)# end
Exits to privileged EXEC mode.
Switch-1# show running-config
Verifies that SSO and NSF are configured and enabled.
Switch-1# show redundancy states
Displays the operating redundancy mode.
Perform the following task on Switch 2:
Switch-2(config)# redundancy
Enters redundancy configuration mode.
Switch-2(config-red)# mode sso
Configures SSO. When this command is entered, the redundant supervisor engine is reloaded and begins to work in SSO mode.
Switch-2(config-red)# exit
Exits redundancy configuration mode.
Switch-2(config)# router routing_protocol processID
Enables routing, which places the router in router configuration mode.
Switch-2(config-router)# nsf
Enables NSF operations for the routing protocol.
Switch-2(config-router)# end
Exits to privileged EXEC mode.
Switch-2# show running-config
Verifies that SSO and NSF are configured and enabled.
Switch-2# show redundancy states
Displays the operating redundancy mode.
For detailed information on configuring and verifying SSO and NSF, see
You must configure the same virtual switch domain number on both chassis of the VSS. The virtual switch domain is a number between 1 and 255, and must be unique for each VSS in your network (the domain number is incorporated into various identifiers to ensure that these identifiers are unique across the network).
Within the VSS, you must configure one chassis to be switch number&1 and the other chassis to be switch number&2.
To configure the virtual switch domain and switch number on both chassis, perform this task on Switch&1:
Switch-1(config)# switch virtual domain 100
Configures the virtual switch domain on Chassis A.
Switch-1(config-vs-domain)# switch 1
Configures Chassis A as virtual switch number 1.
Switch-1(config-vs-domain)# exit
Exits config-vs-domain.
Perform the following task on Switch 2:
Switch-2(config)# switch virtual domain 100
Configures the virtual switch domain on Chassis B.
Switch-2(config-vs-domain)# switch 2
Configures Chassis B as virtual switch number 2.
Switch-2(config-vs-domain)# exit
Exits config-vs-domain.
Note The switch number is not stored in the startup or running configuration, because both chassis use the same configuration file (but must not have the same switch number).
The VSL is configured with a unique port channel on each chassis. During the conversion, the VSS configures both port channels on the VSS active chassis. If the VSS standby chassis VSL port channel number has been configured for another use, the VSS comes up in RPR mode. To avoid this situation, check that both port channel numbers are available on both of the chassis.
Check the port channel number by using the show running-config interface port-channel command. The command displays an error message if the port channel is available for VSL. For example, the following command shows that port channel 20 is available on Switch 1:
Switch-1 # show running-config interface port-channel 20
% Invalid input detected at '^' marker.
To configure the VSL port channels, perform this task on Switch 1:
Switch-1(config)# interface port-channel 10
Configures port channel 10 on Switch 1.
Switch-1(config-if)# switch virtual link 1
Associates Switch 1 as owner of port channel 10.
Switch-1(config-if)# no shutdown
Activates the port channel.
Switch-1(config-if)# exit
Exits interface configuration.
Perform the following task on Switch 2:
Switch-2(config)# interface port-channel 20
Configures port channel 20 on Switch 2.
Switch-2(config-if)# switch virtual link 2
Associates Switch 2 as owner of port channel 20.
Switch-2(config-if)# no shutdown
Activates the port channel.
Switch-2(config-if)# exit
Exits interface configuration mode.
You must add the VSL physical ports to the port channel. In the following example, interfaces 10-Gigabit Ethernet 3/1 and 3/2 on Switch&1 are connected to interfaces 10-Gigabit Ethernet 5/2 and 5/3 on Switch&2.
Tip 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.
To configure the VSL ports, perform this task on Switch 1:
Switch-1(config)# interface range tengigabitethernet&3/1-2
Enters configuration mode for interface range tengigabitethernet 3/1-2 on Switch 1.
Switch-1(config-if)# channel-group 10 mode on
Adds this interface to channel group 10.
witch-1(config-if)# no shutdown
Activates the port.
Perform the following task on Switch 2:
Switch-2(config)# interface range tengigabitethernet 5/2-3
Enters configuration mode for interface range tengigabitethernet 5/2-3 on Switch 2.
Switch-2(config-if)# channel-group 20 mode on
Adds this interface to channel group 20.
Switch-2(config-if)# no shutdown
Activates the port.
Conversion to virtual switch mode requires a restart for both chassis. After the reboot, commands that specify interfaces with module/port now include the switch number. For example, a port on a switching module is specified by switch/module/port.
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 on the RP. This file is assigned a default name, but you are also prompted to override the default name if you want to change it.
Prior to the conversion, ensure that the PFC operating mode matches on both chassis. If they do not match, VSS comes up in RPR redundancy mode. Enter the show platform hardware pfc mode command on each chassis to display the current PFC mode. If only one of the chassis is in PFC3CXL mode, you can configure it to use PFC3C mode with the platform hardware vsl pfc mode pfc3c command.
To verify the PFC operating mode, perform this task:
Switch-1# show platform hardware pfc mode
Ensures that the PFC operating mode matches on both chassis, to ensure that the VSS comes up in SSO redundancy mode.
Switch-2# show platform hardware pfc mode
Ensures that the PFC operating mode matches on both chassis, to ensure that the VSS comes up in SSO redundancy mode.
Switch-1(config)# platform hardware vsl pfc mode pfc3c
(Optional) Sets the PFC operating mode to PFC3C on Chassis A.
Switch-2(config)# platform hardware vsl pfc mode pfc3c
(Optional) Sets the PFC operating mode to PFC3C on Chassis B.
To convert Chassis 1 to virtual switch mode, perform this task:
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 RP bootflash.
To convert Chassis 2 to virtual switch mode, perform this task on Switch 2:
Switch-2# switch convert mode virtual
Converts Switch 2 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 RP bootflash.
Note After you confirm the command (by entering yes at the prompt), the running configuration is automatically saved as the startup configuration and the chassis reboots. After the reboot, the chassis is in virtual switch mode, so you must specify interfaces with three identifiers (switch/module/port).
After the reboot, each chassis contains the module provisioning for its own slots. In addition, the modules from the VSS standby chassis have been automatically provisioned on the VSS active chassis with default configuration.
Configurations for the VSS st}