VSL: VIRTUAL SWITCH LINK
VSL: LINK FAILURE
MEC: MULTICHASSIS ETHER CHANNEL
MEC FAILURE SCENARIOS
RESTRICTION & GUIDELINES: VSS, VSL, MEC
VSL: VIRTUAL SWITCH LINK
WHY VSL IS REQUIRED: For the two chassis of the VSS to act as one network element, they need to share control information and data traffic.
WHAT IS VSL: The virtual switch link (VSL) is a special link that carries control and data traffic between the two chassis of a VSS. The VSL is implemented as an Ether Channel 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 Ether Channel load-balancing algorithm.
ROLE OF INTERFACES IN VSL: 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
VSL: LINK FAILURE
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.
A dual-active scenario can have adverse effects 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 dual-active detection and recovery methods are described in the following sections:
- Dual-Active Detection Using Enhanced PAgP
- Dual-Active Detection Using IP BFD
- Dual-Active Detection Using Dual-Active Fast Hello Packets
- Recovery Actions
Dual-Active Detection Using Enhanced PAgP
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 Stateful Switch Over (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
Dual-Active Detection Using IP BFD
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
Dual-Active Detection Using Dual-Active Fast Hello Packets
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
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.
VSS working is described in the following sections:
Virtual Switch Link Protocol
The Virtual Switch Link Protocol (VSLP) consists of several protocols that contribute to virtual switch initialization. The VSLP includes the following protocols:
- Role Resolution Protocol—The peer chassis use Role Resolution Protocol (RRP) to negotiate the role (VSS active or VSS standby) for each chassis.
- Link 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.
Identical software versions – Both supervisor engine modules on the VSS must be running the identical software version.
VSL 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.
PFC mode check – 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.
SSO and NSF must be configured and enabled on both chassis
NSF Benefits and Restrictions
Cisco NSF provides these benefits:
- Improved network availability—NSF continues forwarding network traffic and application state information so that user session information is maintained after a switchover.
- Overall network stability—Network stability may be improved with the reduction in the number of route flaps that had been created when routers in the network failed and lost their routing tables.
- Neighboring routers do not detect a link flap—Because the interfaces remain up throughout a switchover, neighboring routers do not detect a link flap (the link does not go down and come back up).
- Prevents routing flaps—Because SSO continues forwarding network traffic in the event of a switchover, routing flaps are avoided.
- No loss of user sessions—User sessions established before the switchover are maintained.
For more details,
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:
- The VSS initializes all cards with VSL ports, and then initializes the VSL ports.
- The two chassis communicate over VSL to negotiate their roles (VSS active or VSS standby).
- The VSS active chassis completes the boot sequence, including the consistency check described above in SSO conditions
- 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.
- 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
MEC: MULTICHASSIS ETHER CHANNEL
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
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
- All MEC Links to the VSS Active Chassis Fail
- All MEC Links to the VSS Standby Chassis Fail
- All MEC Links Fail
- VSS Standby Chassis Failure
- VSS Active Chassis Failure
- Failed Chassis MEC Recovery
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.
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.
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.
VSS Active Chassis Failure
VSS active chassis failure results in a stateful switchover (SSO). See the “VSS Redundancy” section 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.
RESTRICTION & GUIDELINES: VSS, VSL, MEC
VSS Restrictions and Guidelines
When configuring the VSS, note the following guidelines and restrictions:
- The VSS configurations in the startup-config file must match on both chassis.
- If you configure a new value for switch priority, the change takes effect only after you save the configuration file and perform a restart.
VSL Restrictions and Guidelines
When configuring the VSL, note the following guidelines and restrictions:
- 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.
- The no mls qos channel-consistency command is automatically applied when you configure the VSL. Do not remove this command.
Multichassis EtherChannel Restrictions and Guidelines
When configuring MECs, note the following guidelines and restrictions:
- All links in an MEC must terminate locally on the VSS active or VSS standby chassis of the same virtual domain.
- For 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.
- For an MEC using the LACP control protocol, the maxbundle command argument defines the maximum number of links in the MEC across the whole VSS.
- An MEC can be connected to another MEC in a different VSS domain.
TOPIC: Virtual Switching System (VSS) on Cisco Catalyst 6500
WEBSITE: KEEPING IT CLASSLESS
TOPIC: VSS FAQ