VSS-Virtual Switching System

(Supported by 45xx and 65xx series switching platform )

 PREREQUISTE INFORMATION TO
UNDERSTAND VSS OPERATION
 SUP internal component used in 6500 chasiss:-
CFC/MSFC
PFC
DFC (Line Card)

 Modular chassis supervisor redundancy

1. Route Processor Redundancy(RPR).

2. RPR+
3. Stateful Switchover(SSO)
4. Stateful Switchover(SSO) + NSF

 Module status in switches.

 MEC-Multi chassis ether channel
What is SUP in modular chasis ?

 The Cisco Supervisor Engine is the brain of many of Cisco's switches. The
Supervisor Engine has evolved several times.
Supervisor Engine V
•Cisco Express Forwarding
•Chassis: 4500
Supervisor Engine 6
•Cisco Express Forwarding
•Chassis: 4500 "E" Series
Supervisor Engine 32
•Cisco Express Forwarding
•Chassis: 6000, 6500, 7600
•A low cost, reduced version of the 720
•Policy Feature Card 3b
•MSFC 2A?
Supervisor Engine 720
•Cisco Express Forwarding
•Policy Feature Card 3A, 3B, 3BXL
•Chassis: 6500, 7600
MSFC1-3
•Multi-Layer Switch Feature Card
 Multilayer Switch Feature Card (MSFC)
 Multilayer Switch Feature Card is the Layer 3 switching engine that sites on the Catalyst Supervisor as a daughter card.

 On the MSFC daughter card, the route processor (RP) is located on the MSFC itself. The MSFC provide a means to perform Multilayer
Switching (MLS) and interVLAN routing.

 Equipped with a high performance processor, the MSFC runs layer 2 protocols on one CPU and layer 3 protocols on the second CPU.

 The MSFC builds the Cisco Express Forwarding information Base (FIB) table in software and then downloads this table to the hardware
Application-specific-integrated circuits (ASICs) on the PFC and DFC (if present) that make the forwarding decisions for IP unicast and
multicast traffic.

 The control plane functions in the Cisco Catalyst 6500 are processed by the MSFC and include handling Layer 3 routing protocols,
maintaining the routing table, some access control, flow initiation, and other services not found in hardware.

 Work with the PFC for implementing layer 3 switching & traditional router based input/output ACL's. Note, PFC can implement ACL's
without requiring a MSFC.

 Provide other SW based features (like NAT, Policy Routing, Encryption etc) which are not supported in PFC hardware.

 Performance of the control plane is dependent on the type and number of processes running on the MSFC. The MSFC3 can support
forwarding rates up to 500Kpps.
 Policy Feature Card (PFC)
 The PFC3 is the ASIC-based forwarding engine daughtercard for the Sup720.

 the DFC3 is the ASIC-based forwarding engine daughtercard for various fabric-enabled linecards (CEF256, CEF720).

 Contains the ASICs that are used to accelerate Layer 2 and Layer 3 switching, store and process QoS and security
ACLs, and maintain NetFlow statistics.

 The PFC3/DFC3 generation is built upon a forwarding architecture known as EARL7. Within this generation, there are
three different versions - 'A', 'B', and 'BXL' - that are all based on the same fundamental technologies but that each
have incremental functionality. 'A' is the standard offering; 'B' is the intermediate option, and 'BXL' is the high-end
option.

 The PFC contains a Layer 2 and a Layer 3 forwarding engine.

 There are five versions of the Policy Feature Card in use today. The PFC3A , PFC3B, and PFC3BXL are integrated into
the Supervisor 720-3A, Supervisor 720-3B and Supervisor 720-3BXL respectively. The PFC3B is the only option for the
Supervisor 32, while the PFC3C and PFC3CXL are integrated into the Supervisor 720-10G-3C and Supervisor 720-10G-
3CXL.
Role of PFC Layer 2 engine :-

 Layer 2 MAC address lookups into the Layer 2 CAM table.

 Looking into the packet headers to determine if this switching operation will be a Layer 2 or a Layer 3 operation. If it
is going to be a Layer 3 operation, then it will hand off the packet to the Layer 3 engine for further processing.

Role of PFC Layer 3 Engine :-

 NetFlow Statistics collection.

 Hardware based forwarding of IPv4, IPv6 and MPLS tagged packets.

 QoS mechanism for ACL classification, marking of packets, and policing (rate limiting).

 Security mechanism for validating ACL rules against incoming packets.

 Maintaining Adjacency entries and statistics.

 Maintaining Security ACL counters.

Centralized Forwarding Card (CFC)

 CFC is a centralized forwarding card for the switching modules which makes
IPv4 routing lookups over the PFC.
 A CFC does not support local forwarding lookups, the forwarding lookup is
done by the PFC in the Supervisor.
 As the forwarding decisions are centralized, the PFC performance, FIB
entries, ACL and lables are shared among the line cards that uses the
Supervisor PFC for forwarding.
 WS-F6700-CFC is the CFC card used on WS-X67xx Ethernet Modules. This
daughter card is supported only by the Supervisor Engine 720.
 Distributed Forwarding Card (DFC)

 Distributed Forwarding Card is a combo daughter card comprising a MSFC and PFC used by a fabric enabled
Cat6500 linecard to perform distributed switching.
 DFCs are located in linecards, not in Supervisors.
 A DFC is used to hold a local copy of the forwarding tables (constructed by the MSFC) along with Security
and QoS policies to facilitate local switching on the linecard.
 The primary MSFC3 will calculate, then push down a FIB table (Forwarding Information Base) giving the
DFC3x its layer 3 forwarding tables.
 The MSFC3 will also push down a copy of the QoS policies so that they are also local to the line card.
Subsequent to this, local switching decisions can reference the local copy of any QoS policies providing
hardware QoS processing speeds and yielding higher levels of performance though distributed switching.

Benefits of DFC:-

 Performance is the biggest and most obvious reason to implement DFCs.

 You move from a 30 Mpps centralized forwarding system anywhere up to a 400 Mpps distributed forwarding
system. This forwarding performance is for all L2 bridging, L3 routing, ACLs, QoS, and Netflow features,
i.e., not just L3.
 Packet Forwarding
 Packet Forwarding is done on the ingress forwarding engine. Therefore,
packets coming into the ports on the Sup720-3B will have forwarding done on
the PFC3B of the Supervisor.
 Packets coming into ports of line cards with DFC3s will have the forwarding
done on the DFC3.
 Packets coming into ports of line cards with CFCs will have the forwarding
done on the PFC3B of the Supervisor.
 The MSFC3 only does forwarding in the cases where the PFC3 or DFC3 cannot
make the forwarding decision.
 Modular chassis redundancy

 Cisco high end switches or routers (4500, 6500, 7600 etc) allow a redundant
Supervisor Engine to take over if the primary Supervisor Engine fails in order
to support fault resistance.
 All administrative and network management functions, such as SNMP, CLI
console, Telnet, STP, CDP and VTP etc. are processed on the active Supervisor
Engine.
 There are below redundancy modes available:

1. Route Processor Redundancy(RPR)

2. RPR+
3. Stateful Switchover(SSO)
 Route Processor Redundancy(RPR)
Standby cold
 In RPR mode, it starts up in a partially-initialized state and is synchronized with the persistent
configuration (Persistent configuration includes the following components: startup-config, boot
variables, config-register, and VLAN database) of the active supervisor engine.
 The redundant supervisor engine pauses the startup sequence after basic system initialization, and
in the event that the active supervisor engine fails, the redundant supervisor engine becomes the
new active supervisor engine.
 In a supervisor engine switchover, traffic is disrupted because in the RPR mode all of the physical
ports restart since there is no state maintained between supervisor engines relating to module types
and statuses. When the redundant supervisor engine completes its initialization, it will read
hardware information directly from the module.
 When the switch is powered on, RPR runs between the two supervisor engines. The supervisor
engine that boots first becomes the RPR active supervisor engine. The Multilayer Switch Feature
Card and Policy Feature Card become fully operational. The MSFC and PFC on the redundant
supervisor engine come out of reset but are not operational.
 RPR+ Mode
Standby Warm
 In RPR+ mode, the redundant supervisor engine is fully initialized and configured, which
shortens the switchover time.
 Active supervisor engine checks the image version of the redundant SUP when the redundant
SUP comes online to run int RPR+ mode.
 If the image on the redundant SUP does not match the image on the active SUP, RPR
redundancy mode is used.
 The supervisor engine that boots first becomes the active supervisor engine.
 When Switch powered on, the MSFC and PFC on the redundant supervisor engine come out of
reset but are not operational and installed modules are not reloaded they are already
initialized.
 Installed modules are not reloaded, because both the startup configuration and the running
configuration are continually synchronized from the active to the redundant supervisor
engine, installed modules are not reloaded during a switchover.
 RPR+ allows OIR of the redundant supervisor engine for maintenance. When the redundant
supervisor engine is inserted, the active supervisor engine detects its presence and begins to
transition the redundant supervisor engine to fully initialized state.
 Synchronization of OIR events, Manual user-initiated switchover using the redundancy force-
switchover command
 SSO-STATE-FULL SWITCHOVER
standby hot
 In SSO redundant supervisor engine starts up in a fully-initialized state and synchronizes with
the persistent configuration and the running configuration of the active supervisor engine.
 In networking devices running SSO, both supervisor engines must be running the same
configuration so that the redundant supervisor engine is always ready to assume control
following a fault on the active supervisor engine
 It subsequently maintains the state on the protocols listed below, and all changes in hardware
and software states for features that support stateful switchover are kept in sync.
 It offers zero interruption to Layer 2 sessions in a redundant supervisor engine configuration.
Because the redundant supervisor engine recognizes the hardware link status of every link,
ports that were active before the switchover will remain active, including the uplink ports.
 In switch over the redundant supervisor engine become active. This newly active supervisor
engine uses existing Layer 2 switching information to continue forwarding traffic.
 Layer 3 forwarding will be delayed until the routing tables have been repopulated in the
newly active supervisor engine.
 All layer 3 protocols are learned on the the redundant supervisor engine
 NSF(Non Stop Forwarding)
 When a networking device restarts, all routing peers of that device detect
that the device went down and then came up. This transition is called routing
flap. In NSF ,Routing flap doesn’t impact during switchover.
 Cisco NSF always runs with SSO and provides redundancy for Layer 3 traffic.
NSF works with SSO to minimize the amount of time that a network is
unavailable to its users following a switchover.
 The main purpose of NSF is to continue forwarding IP packets to known route
while the routing protocol information is being restored following a supervisor
engine switchover.
 Cisco NSF is supported by the BGP, OSPF, EIGRP, and IS-IS protocols for routing
and is supported by Cisco Express Forwarding (CEF) for forwarding.
 It copy the old CEF entries (FIB table and RIB ) until new RIB populated after
switchover.
 Multichassis EtherChannel:-

 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
 The VSS supports a maximum of 512 EtherChannels. Two for VSL required in
each chaisis. 510 are user configurable port channel.
 MODULE STATUS
The module status of the standby Supervisor Engine in the "show module"
command output is different for the different redundancy modes:
 RPR—Status shows Cold.
Cold redundancy refers to the degree of resiliency that a redundant system
traditionally provides. A redundant system is cold when no state
information is maintained between the backup or standby system and the
system it protects.
 RPR+—Status shows Warm.
Warm redundancy refers to a degree of resiliency beyond the cold standby
system. In this case, the redundant system is partially prepared. However, the
system does not have all the state information that the primary system
knows for an immediate take-over. Some additional information must be
determined or gleaned from the traffic flow or the peer network devices to
handle packet forwarding.
 SSO—Status shows Hot.
Hot redundancy refers to a degree of resiliency where the redundant system is
fully prepared to handle the traffic of the primary system. Substantial state
information is saved, so the network service is continuous, and the effect on
traffic flow is minimal or nil in the case of a failover.
 VSS-Virtual Switching System
(Supported by 45xx and 65xx series switching platform )

 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.
 VSS Hardware Requirements

PFC, DFC, and CFC Requirements

• VSS supports any 67xx series switching module with CFC hardware.
• 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
 VSS Active and VSS Standby Chassis

 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.
 All control plane functions are centrally managed by the active
supervisor engine of the active virtual switch chassis,including:

1. Management (Simple Network Management Protocol [SNMP], Telnet, Secure Shell

[SSH] Protocol, etc.)
2. Layer 2 Protocols (bridge protocol data units [BPDUs], protocol data units [PDUs],
Link Aggregation Control
Protocol [LACP], etc.)
3. Layer 3 Protocols (routing protocols, etc.)
4. Software data path
 Virtual Switch Link
 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.
 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.
 VSL topology for redundancy

• A VSS contains two chassis that communicate using the VSL, which is a special
port group.
• It is recommended 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.
>>>Trimmed output for the # sh switch virtual link
port-channel
 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

1. The peer chassis use Role Resolution Protocol (RRP) to negotiate the role (VSS active or
VSS standby) for each chassis.

• Link Management Protocol

1. The Link Management Protocol (LMP) runs on all VSL links, and exchanges information
required to establish communication between the two chassis.
2. LMP identifies and rejects any unidirectional links.
3. 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.
 DUAL ACTIVE DETECTION
 Name suggest it deal with dual active state(Both chasis become 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
 DUAL ACTIVE DETECTION METHOD
 Enhancement to PAgP used in MEC with connecting Cisco switches:

1. 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.
2. When the VSS standby chassis detects VSL failure, it initiates SSO and becomes VSS active.
3. Subsequent PAgP messages to the connected switch from the newly VSS active chassis contain the new VSS active ID.
4. The connected switch sends PAgP messages with the new VSS active ID to both VSS chassis.
5. 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.

 L3 Bidirectional Forwarding Detection (BFD) configuration on a directly connected link (besides VSL) between virtual switch members or through an L2 link
through an access layer switch.
1. 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.
2. 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.

 L2 Fast-Hello Dual-Active Detection configuration on a directly connected link (besides VSL) between virtual switch members
1. To use the dual-active fast hello packet detection method, you must provision a direct Ethernet connection between the two VSS chassis

2. The two chassis periodically exchange special Layer 2 dual-active hello messages containing information about the switch state.

3. 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.

4. 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.

Note:- In this slide I will be implementing L2 Fast-Hello.

  BFD detection method in VSS:-

Switch6500_1(config)#switch virtual domain 1 Switch6500_2(config)#switch virtual domain 1

Switch6500_1(config-vs-domain)#dual-active detection bfd Switch6500_2(config-vs-domain)#dual-active detection bfd

Switch6500_1(config)#interface gigabitethernet 1/3/8 Switch6500_2(config)#interface gigabitethernet 1/2/3

Switch6500_1(config-if)#ip address 1.1.1.1 255.255.255.0 Switch6500_2(config-if)#ip address 1.1.1.2 255.255.255.0
Switch6500_1(config-if)#bfd interval 100 min_rx 100 multiplier 3 Switch6500_2(config-if)#bfd interval 100 min_rx 100 multiplier 3

Switch6500_1(config)#interface gigabitethernet 2/3/8 Switch6500_2(config)#interface gigabitethernet 2/3/5

Switch6500_1(config-if)#ip address 1.1.2.1 255.255.255.0 Switch6500_2(config-if)#ip address 1.1.2.2 255.255.255.0
Switch6500_1(config-if)#bfd interval 100 min_rx 100 multiplier 3 Switch6500_2(config-if)#bfd interval 100 min_rx 100 multiplier 3

Switch6500_2(config)#switch virtual domain 1 Switch6500_2(config)#switch virtual domain 1

Switch6500_1(config-vs-domain)#dual-active pair interface gi1/3/8 Switch6500_2(config-vs-domain)#dual-active pair interface gi1/2/3
interface gi2/3/8 bfd interface gi2/3/5 bfd
 Pagp Dual detection Method:-
 Recovery Actions

1. 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.
2. You might need to physically repair the VSL failure.
3. When the shut down chassis detects that VSL is operational again, the chassis
reloads and returns to service as the VSS standby chassis.
4. Loopback interfaces are also shut down in recovery mode.
5. Do not configure loopback interfaces while in recovery mode, because any new
loopback interfaces configured in recovery mode will not be shut down.
 VSS Functionality
 Redundancy and High Availability
1. In a VSS, supervisor engine redundancy operates between the VSS active and VSS
standby chassis, using stateful switchover (SSO) and nonstop forwarding (NSF).
2. 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.
3. 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.
 Packet Handling
1. 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.
2. The VSS uses VSL to communicate protocol and system information between the peer
chassis and to carry data traffic between the chassis when required.
3. 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.
4. 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.
 System Management
1. VSS active supervisor engine handles OIR of switching modules on both chassis.
2. The VSS active supervisor engine uses VSL to send messages to and from local
ports on the VSS standby chassis.
3. 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.
4. The VSS standby chassis runs a subset of system management tasks. For example,
the VSS standby chassis handles its own power management.
 Interface Naming Convention
1. 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.
2. 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.
 To convert two standalone chassis into a VSS,
perform the following activities:

 Configure each chassis as a VSS

 Convert to a VSS
 Configure the dual-active detection (optional)
 Configure the switch priority (optional)
 Configure each chassis as a VSS

1. Define a switch virtual domain ID to identify the VSS. The ID must be the same on
each 6500; in this example the ID ‘100’ is used:
 Configure the VSL port channel and member ports:
1. Choose unique port-channel IDs for each chassis to form the VSL and configure
them with the corresponding switch ID:
 Convert to a VSS
1. The running configuration of the individual switch is converted into a three-level virtual switch
interface notation. Two-level interface configurations (such as 10 GigabitEthernet 5/4) are
converted into three-level interfaces (such as 10 GigabitEthernet 1/5/4 in Switch 1 and 10
GigabitEthernet 2/5/4 in Switch 2) like in a stack.
2. The startup configuration is updated with the three-number notation.
3. A copy of the original startup configuration converted to three-number notation is written to
the bootflash of the respective switch.
4. Both switches reload.

CiscozineA#switch convert mode

virtual
 After the conversion, you will notice three things:
1. The name of the VSS is CiscozineA; rename it to “CiscozineVSS”.
2. The interface name is converted into three-level interface. The first number (one
or two) identify the switch.
3. By default, the console port on the standby switch is locked; if you try to use it,
this message will be displayed:

4. If you want to enable console in standby chasis:

Configure the dual-active detection
(optional)
 Configure the switch priority (optional)
My suggestion is to statically define the switch priority (an higher-priority value
assumes the active virtual switch role):

 Changing the priority, a log message is generated:

%VSLP-SW1_SP-5-RRP_RT_CFG_CHG: Configured priority value is different from operational value. Change will take effect
after config is saved and switch 1 is reloaded.
%VSLP-SW2_SPSTBY-5-RRP_RT_CFG_CHG: Configured priority value is different from operational value.
Change will take effect after config is saved and switch 1 is reloaded.
No

1. It affect role determination if both virtual switches areinitiated simultaneously.

2. If either switch (regardless of priority) is initiated prior to the subsequent switch, it
always assumes the role of the active virtual switch.

VSS CONFIGURED ….
 Useful show commands
show switch virtual dual-active fast-hello

 show switch virtual-To show basic VSS informations:

 show switch virtual dual-active fast-hello

To find informations about fast-hello detection:
 show switch virtual role To identify the role/priority of the two switches:
 To find more informations about the VSS status: Sh switch virtual redundancy
 Reload commands:
redundancy reload shelf
where either Switch 1 or Switch 2 can be specified.

 To force a switchover:
redundancy force-switchover