VSS: PART 2: VSL LINK FAILURE, VSS WORKING, MEC FAILURE


TOPICS

VSL: VIRTUAL SWITCH LINK

VSL: LINK FAILURE

VSS WORKING

MEC: MULTICHASSIS ETHER CHANNEL

MEC FAILURE SCENARIOS

RESTRICTION & GUIDELINES: VSS, VSL, MEC

REFERENCE LINKS


 

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

EXAMPLE TOPOLOGY


 

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

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

 

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

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.

 

SSO Dependencies

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,

http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-2SX/configuration/guide/book/nsfsso.html#wp1112624

Initialization Procedure

The following sections describe the VSS initialization procedure:

 

VSL Initialization

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    above in SSO conditions
  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.

 

System Initialization

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.

 

VSL Down

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

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.

 *****************************

 

REFERENCE LINKS

TOPIC: Virtual Switching System (VSS) on Cisco Catalyst 6500

WEBSITE: KEEPING IT CLASSLESS

http://keepingitclassless.net/2011/10/virtual-switching-system-on-cisco-catalyst-6500/

 

TOPIC: VSS

WEBSITE: CISCO

http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-2SX/configuration/guide/book/vss.html#wp1054565

 

TOPIC: VSS FAQ

WEBSITE: CISCO

http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-6500-virtual-switching-system-1440/prod_qas0900aecd806ed74b.html

********************************* 

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s