VSS BootCamp

VIRTUAL SWITCHING SYSTEM (VSS)

© 2007 Cisco Systems, Inc. All rights reserved. Cisco Confidential 1

VIRTUAL SWITCHING SYSTEM (VSS)

Introduction to Virtual SwitchConcepts

Virtual Switch System is a new technology break through for the Catalyst 6500 family…

© Cisco Systems 2007 INTERNAL CISCO AUDIENCE ONLY 2

Virtual Switch SystemEnterprise Campus

A Virtual Switch-enabled Enterprise Campus network takes on multiple benefits including simplified management & administration, facilitating greater high availability, while maintaining a flexible and scalable architecture…

L3 Core

Reduced routing neighbors, Minimal L3 reconvergence


Access

L2/L3 Distribution

L3 Core

No FHRPsNo Looped topologyPolicy Management

L3 reconvergence

Multiple active uplinks per VLAN, No STP convergence

Virtual Switch SystemData Center

A Virtual Switch-enabled Data Center allows for maximum scalability so bandwidth can be added when required, but still providing a larger Layer 2 hierarchical architecture free of reliance on Spanning Tree…

L2/L3 Core

Single router node, Fast L2 convergence, Scalable architecture


L2 Distribution

L2 Access

Dual-Homed Servers, Single active uplink per VLAN (PVST), Fast L2 convergence

Dual Active Uplinks, Fast L2 convergence, minimized L2 Control Plane, Scalable


VIRTUAL SWITCH ARCHITECTURE

Forwarding Operation, VSLP - LMP & RRP

Virtual Switch ArchitectureVirtual Switch LinkThe Virtual Switch Link is a special link joining each physical switch together - it extends the out of band channel allowing the active control plane to manage the hardware in the second chassis…


Virtual Switch ArchitectureVSL Initialization

Before the Virtual Switch domain can become active, the Virtual Switch Link (VSL) must be brought online to determine Active and Standby roles. The initialization process essentially consists of 3 steps:

Link Management Protocol (LMP) used to track and reject Unidirectional Links, Exchange Chassis ID and other information between the 2 switches

Link Bringup to determine which ports form the VSL1

2


Role Resolution Protocol (RRP) used to determine compatible Hardware and Software versions to form the VSL as well as determine which switch becomes Active and Hot Standby from a control plane perspective

LMPLMP LMPLMP

RRPRRPRRPRRP

3

Virtual Switch ArchitectureVSLP Ping

A new Ping mechanism has been implemented in VSS mode to allow the user to objectively verify the health of the VSL itself. This is implemented as a VSLP Ping…

VSL

Switch 1 Switch 2

VSLPVSLP VSLPVSLP

VSLPVSLP VSLPVSLP


vss#ping vslp output interface tenGigabitEthernet 1/5/4

Type escape sequence to abort.Sending 5, 100-byte VSLP ping to peer-sup via output port 1/5/4, timeout is 2 seconds:!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 12/12/16 msvss#

The VSLP Ping operates on a per-physical interface basis and parameters such as COUNT, DESTINATION, SIZE, TIMEOUT may also be specified…

Virtual Switch ArchitectureForwarding Operation

In Virtual Switch Mode, while only one Control plane is active, both Data Planes (Switch Fabric’s) are active, and as such, each can actively participate in the forwarding of data …

Switch 1 - Control Plane Active Switch 2 - Control Plane Hot Standby


Virtual Switch Domain


Switch 1 - Data Plane Active Switch 2 - Data Plane Active

Virtual Switch ArchitectureVirtual Switch Domain

A Virtual Switch Domain ID is allocated during the conversion process and represents the logical grouping the 2 physical chassis within a VSS. It is possible to have multiple VS Domains throughout the network…

VS Domain 10


The configurable values for the domain ID are 1-255. It is always recommended to use a unique VS Domain ID for each VS Domain throughout the network…

VS Domain 10

VS Domain 20 VS Domain 30

Virtual Switch ArchitectureRouter MAC Address

In a standalone Catalyst 6500 system, the router MAC address is derived from the Chassis MAC EEPROM and is unique to each Chassis. In a Virtual Switch System, since there is only a single routing entity now, there is also only ONE single router MAC address…


Router MAC = 000f.f8aa.9c00

The MAC address allocated to the Virtual Switch System is negotiated at system initialization. Regardless of either switch being brought down or up, the same MAC address will be retained such that neighboring network nodes and hosts do not need to re-ARP for a new address.


ETHERCHANNEL CONCEPTS

Overview, Protocols, Load Balancing, Enhancements with VSL

Etherchannel ConceptsMultichassis EtherChannel (MEC)

Prior to Virtual Switch, Etherchannels were restricted to reside within the same physical switch. In a Virtual Switch environment, the 2 physical switches form a single logical network entity - therefore Etherchannels can now also be extended across the 2 physical chassis…

Virtual Switch Virtual Switch


Regular Etherchannel on single chassis Multichassis EtherChannel across 2 VSL-enabled Chassis

LACP, PAGP or ON Etherchannel modes are supported…

Etherchannel ConceptsEtherchannel Hash for MEC

Deciding on which link of a Multi-chassis Etherchannel to use in a Virtual Switch is skewed in favor towards local links in the bundle - this is done to avoid overloading the Virtual Switch Link (VSL) with unnecessary traffic loads…

Blue Traffic destined for the Server will result in Link A1 in the MEC link

Orange Traffic destined for the Server will result in Link B2 in the MEC link


Link A1 Link B2

Link A1 in the MEC link bundle being chosen as the destination path…

Link B2 in the MEC link bundle being chosen as the destination path…

Server

EtherChannel Concepts

• Localizing the decision to use a link in the bundle that is resident on the local Switch (thus avoiding forwarding over the VSL) is done as shown below

EtherChannel Hash for MEC

Virtual Switch• The BUNDLE_SELECT register

in the port ASIC is programmed to see only the local links of the EtherChannel bundle even


Note: If all links in the local bundle go down, them the BUNDLE_SELECT register is programmed to point packets to the VSL

EtherChannel bundle even though links that may exist in the same bundle are resident in the VS peer chassis

• This behavior is fixed and cannot be changed by any configuration option

EtherChannel Concepts

• A command can be invoked to assist in determining which link in the bundle will be used—it can use various hash inputs to yield an eight-bucket RBH value that will correspond to one of the port channel members

EtherChannel Hash


Vss#sh etherchannel load-balance hash-result interface port-channel 120 ip 192.168.220.10 192.168.10.10

Computed RBH: 0x4Would select Gi1/2/1 of Po120


HARDWARE REQUIREMENTS…

Hardware RequirementsSupervisor

In order to enable the Virtual Switch feature and configure the Virtual Switch Links (VSL) between 2 Catalyst 6500 chassis, the new Catalyst 6500 Virtual Switching Supervisor 720 is required to be used. It is the only Supervisor that will support VSS as it supports both the new PFC3C/XL forwarding engine…


The PFC3C/XL contains new hardware to support the extra LTL indices and mappings required to forward traffic across multiple physical chassis, lookup enhancements as well as MAC address table handling enhancements…

VS-S720-10G-3C/XL

Hardware RequirementsVSL-Capable Interfaces

The VSL is a special link that requires extra headers to be imposed onto the frame. These require new port ASICs that exist only on the 10 GigabitEthernet interfaces on the following modules…

Supervisor 720-10G VSS

Note that these interfaces may also be used as standard network interfaces


These interfaces are supported by a new port ASIC, allowing for frames across the VSL to be encapsulated / de-encapsulated with the VSH…

WS-X6708-10G-3C/XL

Hardware RequirementsOther Supported Modules…

Other modules that may exist in the VSL domain include all CEF720 and dCEF720 cards (WS-X67xx-series), as well as SVC-NAM-1 and SVC-NAM-2. Classic, CEF256 and dCEF256 cards are not supported…


CEF720, dCEF720

and NAM only

Hardware RequirementsDistributed Forwarding Cards

Distributed Forwarding Cards (DFCs) improve the performance of the Catalyst 6500 by offloading the lookup processing from the PFC to the ingress linecard. Only DFC3C or DFC3CXL is supported in a Virtual Switch domain. If DFCs are not used on CEF720 modules, a Centralized Forwarding Card (CFC) must be installed in its place…


Note that if a lower revision DFC (3A, 3B or 3BXL) is used in a VSL domain, the system will fall to a lowest common

denominator mode which will not allow support for VSL…


OPERATIONAL MANAGEMENT

Virtual Switch CLI, SNMP Support, Netflow, SPAN, EEM…

Operational ManagementVirtual Switching System CLI

Multiple console interfaces exist within a Virtual Switch Domain, but only the active RP/SP consoles are enabled for command interaction…


Operational ManagementReloading the VSS

Should there be a requirement to reload the entire Virtual Switch System (both chassis), the command “reload” can be used to accomplish this task…


vss#reloadProceed with reload? [confirm]

1d04h: %SYS-5-RELOAD: Reload requested by console. Reload Reason: Reload Command.

****** --- SHUTDOWN NOW ---***

1d04h: %SYS-SP-5-RELOAD: Reload requestedSystem Bootstrap, Version 8.5(1)Copyright (c) 1994-2006 by cisco Systems, Inc.Cat6k-Sup720/SP processor with 1048576 Kbytes of main memory<…snip…>

Operational ManagementReloading a member of the VSS

It is also possible to reload each chassis individually by specifying the Switch ID assigned through the following command set…


vss#redundancy reload shelf ?<1-2> shelf id<cr>

vss#redundancy reload shelf 2Reload the entire remote shelf[confirm]Preparing to reload remote shelf

vss#

Operational ManagementSetting the System-wide PFC Mode

Only PFC/DFC 3C/CXL are supported in a VSS. However, it is possible to mix modules in a 3C and 3CXL system, bearing in mind that the system will take the lowest common denominator as the system-wide PFC mode. A new CLI has been implemented to allow the user to pre-configure the system mode to prevent modules from not powering up…


vs-vsl#conf tEnter configuration commands, one per line. End with CNTL/Z.vs-vsl(config)#platform hardware vsl pfc mode pfc3cvs-vsl(config)#^Zvs-vsl#

vs-vsl#sh platform hardware pfc modePFC operating mode : PFC3CConfigured PFC operating mode : PFC3Cvs-vsl#

Operational Management SNMP Support for VSS

The SNMP process for a VSS necessitates support for “Put’s” and “Get’s” across 2 physical chassis, changes to existing MIB’s and support for a new MIB…

SNMP Server

SNMP Get’sSNMP Put’s



Switch 1 - Active Switch 2 - Standby

SNMP Process Active SNMP Process Inactive

SNMP Get’sSNMP Put’s

SNMP Modified MIB’s

SNMP New MIB’s

Operational Management SNMP Modified MIB’s

The following MIB’s have been modified to allow the collection of data in a Virtual Switch configuration…

Virtual Switch


MIB Name Description of Change

CISCO-LAG-MIB Extended to support 6000 ports

CISCO-EXT-BRIDGE-MIB Supports extension of BRIDGE-MIB (which is a standard and cannot be changed. Extended to support up to 6000 ports.

CISCO-VLAN-MEMBERSHIP-MIB Extended to support 6000 ports

CISCO-ENVMON-MIB Virtual Switch Chassis number will be included in the “Description” field

CISCO-STACK-MIB No longer supported

CISCO-OLD-CHASSIS-MIB No longer supported

CISCO-CAT6K-CROSSBAR-MIB Support Standby Core with a different naming scope

Operational Management New Virtual Switch MIB

CISCO-VIRTUAL-SWITCH-MIB has been defined to support SNMP access to the Virtual Switch Configuration - the following MIB variables are accessible to an SNMP manager…

cvsGlobalObjects - Domain #, Switch #, Switch Mode

cvsCoreSwitchConfig - Switch Priority and Preempt


CISCO-VIRTUAL-SWITCH-MIBcvsChassisTable - Chassis Role and Uptime

cvsVSLConnectionTable - VSL Port Count, Operational State

cvsVSLStatsTable - Total Packets, Total Error Packets

cvsVSLPortStatsTable - TX/RX Good, Bad, Bi-dir and Uni-dir Packets

This MIB will be the main vehicle though which Network Management stations access information relevant to the operation of the Virtual Switch…

Operational ManagementSlot/Port Numbering

After conversion, port definitions for switches within the Virtual Switch Domain inherit the Chassis ID as part of their naming convention…

PORT NUMBERING: <CHASSIS-ID><SLOT-NUMBER><PORT-NUMBER>

Chassis-ID WILL ALWAYS be either a “1” or a “2”


VSS#show ip interface briefInterface IP-Address OK? Method Status ProtocolVlan1 unassigned YES NVRAM up up Port-channel1 unassigned YES NVRAM up up Te1/1/1 10.1.1.1 YES unset up up Te1/1/2 192.168.1.2 YES unset up up Te1/1/3 unassigned YES unset up up Te1/1/4 unassigned YES unset up up GigabitEthernet1/2/1 10.10.10.1 YES unset up up GigabitEthernet1/2/2 10.10.11.1 YES unset up up <snip>

Operational ManagementFile System Naming

After the conversion to a Virtual Switch, some of the File System naming conventions have changed to accommodate the new setup - an example of the new setup is shown below…

e.g.OLD: disk0:NEW: sw1-slot5-disk0:

e.g.OLD: slavedisk0:NEW: sw2-slot5-disk0:

SW<NUMBER>SLOT<NUMBER>FILESYSTEM

AN EXAMPLE


Active Supervisor - Slot 5 Hot Standby Supervisor - Slot 5


Switch 1 Switch 2

RESOURCE: Operational ManagementFile System Naming

Some filenames have remained the same - others have changed - some examples of file system names in a Virtual Switch include the following…

VIRTUAL SWITCHPREVIOUS


sw<number>slot<number>disk0:disk0:

sw<number>slot<number>bootflash:bootflash:

sw<number>slot<number>sup-bootdisk:sup-bootdisk:

sw<number>slot<number>nvram:nvram:

sw<number>slot<number>disk0:slavedisk0:

sw<number>slot<number>bootflash:slavebootflash:

sw<number>slot<number>sup-bootdisk:slavesup-bootdisk:

sw<number>slot<number>const_nvram:const_nvram:

Operational ManagementNetflow

In a Virtual Switch, with both Data Planes active, Netflow data collection is performed on each Supervisor’s PFC - while Netflow export is only performed by the Control Plane on the VS Active …

Virtual Switch DomainSwitch 1 Supervisor Switch 2 Supervisor


VS State : ActiveControl Plane: ActiveData Plane: ActiveNetflow Collection: ActiveNetflow Export: Active

VS State : StandbyControl Plane: StandbyData Plane: ActiveNetflow Collection: ActiveNetflow Export: In-Active

VSL

Netflow operation in a Virtual Switch is similar to the way in which Netflow operates in a single chassis with Distributed Forwarding Card’s (DFC) present…

Operational ManagementSPAN

In a Virtual Switch Domain, the number of SPAN sessions is limited to what the VS Active Supervisor can provide. SPAN capacity on the VS Standby is not factored into available SPAN sessions…


VSL

Switch 1 Supervisor Switch 2 Supervisor


VS State : ActiveControl Plane: ActiveData Plane: ActiveSPAN Management: ActiveReplication: Active

VS State : StandbyControl Plane: StandbyData Plane: ActiveSPAN Management: In-ActiveReplication: Active

Virtual Switch is supported in Whitney 1 which introduces the following SPAN capabilities per Virtual Switch Domain…

TX SPAN Sessions RX/Both SPAN Sessions Total SPAN Sessions

Virtual Switch Domain 14 2 16

Operational ManagementEEM Script Registration

Embedded Event Manager provides a means of users to run scripts that can be invoked when given events occur - running a script requires the script and directory holding the script to be registered - BUT - the normal process will generate a warning message on a Virtual Switch -WHY?????…

vs-vsl(config)#event manager policy autoqos.tclEmbedded Event Manager configuration on STANDBY: policy file autoqos.tcl could not be found


Active Supervisor - Slot 5 Standby Supervisor - Slot 5


Switch 1 Switch 2


HIGH AVAILABILITY

Link Failure, Redundancy Schemes, Dual-Active Detection, GOLD

High AvailabilityLink Failure Recovery

Access Uplink Failure~200 msec



Routed Uplink Failure~250 msec



Active VS Failure~200 msec


High AvailabilityRedundancy Schemes

The default redundancy mechanism between the 2 VSS chassis and their associated supervisors is NSF/SSO, allowing state information and configuration to be synchronized. Additionally, only in NSF/SSO mode does the Standby supervisor PFC, Switch Fabric, modules and their associated DFCs become active…

Switch 112.2(33)SXH1Active

Switch 212.2(33)SXH1NSF/SSO


VSL

Should a mismatch of information occur between the Active and Standby Chassis, the Standby Chassis will revert to RPR mode, where only configuration is synchronized, but PFC, Switch Fabric and modules will not be brought up

VSL

Switch 112.2(33)SXH1Active

Switch 212.2(33)SXH2RPR

High AvailabilitySSO-Aware Protocols

As of 12.2(33)SXH, there are over 90 protocols that are SSO-aware. These include information such as ARP, DHCP Snooping, IP Source Guard, NAC Posture database, etc… In a VSS environment, failure of either VS will not require this information to be re-populated again…

Virtual SwitchSwitch 1 Switch 2


DHCP SnoopingBinding Table

IP Add MAC Add10.10.10.10 00:50:56:01:e1:02172.26.18.2 00:02:b3:3f:3b:99

172.26.19.34 00:16:a1:c2:ee:3210.10.10.43 00:16:cb:03:d3:44

VLAN10181910

InterfacePo10Po10Po20Po20

High AvailabilityNSF/SSO Requirements

After the roles have been resolved through RRP, a Configuration Consistency Check is performed across the VSL switches to ensure proper VSL operation. The following items are checked for consistency. If these do not match, then the Standby switch will enter into RPR mode…

Switch Virtual Domain ID

Switch Virtual Node Type

Switch Priority


Switch Priority

Switch Preempt

VSL Port Channel Link ID

VSL Port state, interfaces…

Power Redundancy mode

Power Enable on VSL cards

Additionally, software version, installed patches and PFC modes also need to be consistent for NSF/SSO mode to be entered…

High AvailabilityDual-Active Detection

In a Virtual Switch Domain, one switch is elected as Active and the other is elected as Standby during bootup by VSLP. Since the VSL is always configured as a Port Channel, the possibility of the entire VSL bundle going down is remote, however it is a possibility…


VSL



VS State : ActiveControl Plane: ActiveData Plane: Active

VS State : StandbyControl Plane: StandbyData Plane: Active

VSL

It is always recommended to deploy the VSL with 2 or more links and distribute those interfaces across multiple modules to ensure the greatest redundancy

High AvailabilityDual-Active Detection

If the entire VSL bundle should happen to go down, the Virtual Switch Domain will enter a Dual Active scenario where both switches transition to Active state and share the same network configuration (IP addresses, MAC address, Router IDs, etc…) potentially causing communication problems through the network…


VSL





VSL

2 mechanisms have been implemented in the initial release to detect and recover from a Dual Active scenario:

Enhanced Port Aggregation Protocol (PAgP)

Dual-Active Detection over IP-BFD

1

2

High Availability

• Enhanced PAgP allows for new TLVs to be relayed from the individual Virtual Switches to a remote device that is EtherChanneled to the Virtual Switch Domain. During normal operation the Virtual Switches will send the ID of the Active VS to the PAgP neighbor, and it will respond with the same Active ID

Dual-Active Detection: Enhanced PAgP

Switch 2Switch 1 Switch 2Switch 1


Active: Switch 1 Active: Switch 1 Active: Switch 1 Active: Switch 2

• Should the VSL go down, the Standby switch will transition immediately to Active state and start sending PAgP messages with the new Active switch ID

High Availability

• The Enhanced PAgP-capable neighbor will proceed to send the new Active Switch ID to all member ports of the port channel that it received the new Active Switch ID on, including the previous-active Virtual switch (Switch 1)


Dual-Active!Switch 2Switch 1 Switch 2Switch 1


• On Switch 1, upon reception of PAgP messages with the Active ID of Switch 2, it will be aware that a Dual-Active scenario has occurred and will proceed to bring down all local interfaces

Active: Switch 2 Active: Switch 2 Active: Switch 2

High Availability

• Dual-Active Detection capabilities require that the neighboring device be Dual-Active Detection Aware. It must also be configured to be trusted from the switch virtual configuration submode


vss#conf tEnter configuration commands, one per line. End with CNTL/Z.vss(config)#switch virtual domain 100vss(config-vs-domain)#dual-active detection pagp


vss(config-vs-domain)#dual-active trust channel-group20vss(config-vs-domain)#

vss#sh switch virtual dual-active pagpPAgP dual-active detection enabled: YesPAgP dual-active version: 1.1

Channel group 20 dual-active detect capability w/nbrsDual-Active trusted group: Yes

Dual-Active Partner Partner PartnerPort Detect Capable Name Port VersionTe1/1/1 Yes vs-access-2 Te5/1 1.1Te2/1/1 Yes vs-access-2 Te5/2 1.1

High Availability

• Dual-Active Detection with IP-BFD allows for the detection of a Dual-Active scenario subsequent to the Standby RP becoming Active. This mechanism requires that a direct heartbeat link be used to carry the IP-BFD frames from Switch 1 to Switch 2

VSL

Dual-Active Detection: IP-BFD


BFD

Switch 1 Switch 2

IP-BFD Heartbeat Link

VSL

Switch 1 Switch 2

IP-BFD Heartbeat Link

BFD

• The IP-BFD Heartbeat Link may exist on any interface but must have an IP address assigned to it on a different network

High Availability

• To enable IP BFD as the detection mechanism, two directly-connected interfaces must be configured as BFD message links

vss(config)#interface gigabitethernet 1/5/1vss(config-if)#no switchportvss(config-if)#ip address 200.230.230.231 255.255.255.0vss(config-if)#bfd interval 100 min_rx 100 multiplier 50vss(config-if)#no shutdownvss(config-if)#interface gigabitethernet 2/5/1

Dual-Active Detection: IP-BFD


vss(config-if)#interface gigabitethernet 2/5/1vss(config-if)#no switchportvss(config-if)#ip address 201.230.230.231 255.255.255.0vss(config-if)#bfd interval 100 min_rx 100 multiplier 50vss(config-if)#no shutdownvss(config-if)#exitvss(config)#switch virtual domain 100vss(config-vs-domain)#dual-active detection bfdvss(config-vs-domain)#dual-active pair interface g 1/5/1 interface g 2/5/1 bfd

adding a static route 200.230.230.0 255.255.255.0 Gi2/5/1 for this dual-active pairadding a static route 201.230.230.0 255.255.255.0 Gi1/5/1 for this dual-active pair

vss(config-vs-domain)#

High Availability

• Upon the restoration of one or more VSL interfaces, VSLP will detect this and will proceed to reload Switch 1 so that it may be able to re-negotiate Active/Standby role after bootup

Dual-Active Recovery


VSLP

Switch 2

Switch 1 Switch 2

VSLP

VSL Up! Reload…

• After role has been resolved and SSO Hot Standby mode is possible, interfaces will be brought up and traffic will resume back to 100% capacity

Switch 1

High AvailabilityDual-Active Detection - Exclude Interfaces

Upon detection of a Dual Active scenario, all interfaces on the previous-Active switch will be brought down so as not to disrupt the functioning of the remainder of the network. The exception interfaces include VSL members as well as pre-determined interfaces which may be used for management purposes…

vs-vsl#conf tEnter configuration commands, one per line. End with CNTL/Z.vs-vsl(config)#switch virtual domain 100vs-vsl(config-vs-domain)#dual-active exclude interface Gig 1/5/1


vs-vsl(config-vs-domain)#dual-active exclude interface Gig 1/5/1vs-vsl(config-vs-domain)#dual-active exclude interface Gig 2/5/1vs-vsl(config-vs-domain)# ^Zvs-vsl#

High AvailabilityDual-Active Recovery

Upon the restoration of one or more VSL interfaces, VSLP will detect this and will proceed to reload Switch 1 so that it may be able to re-negotiate Active/Standby role after bootup…

VSL Up! Reload…

Switch 1 Switch 2


After role has been resolved and SSO Hot Standby mode is possible, interfaces will be brought up and traffic will resume back to 100% capacity…

VSL Up! Reload…

Switch 1 Switch 2VSLP VSLP

High AvailabilityGeneric OnLine Diagnostics (GOLD)

Some enhancements to the GOLD framework have been implemented in a VSS environment, which leverages a Distributed GOLD environment. In this case, each supervisor runs an instance of GOLD, but is centrally managed by the Active Supervisor in the Active chassis…

VSLSwitch 1 Switch 2


VS State : ActiveLocal GOLD: Active

VS State : StandbyLocal GOLD: Active

Distributed GOLD Manager

There are 4 new tests that are available in VSS mode:

TestVSLLocalLoopback

TestVSLBridgeLink

TestVSLStatus

1

2

3

TestVSActiveToStandbyLoopback4


QUALITY OF SERVICE

Trust, Classification & Policing, VSL QoS

Quality of ServiceClassification & Policing

Both Classification and Policing functions are handled by PFC QoS, and is executed by either the PFC on the Active and Hot Standby Supervisor, or the ingress linecard DFC. There are 2 important caveats which must be understood whilst implementing these functions…

Policies must either be applied on L3 interfaces (SVIs or Physical interfaces), or Port Channels. Policies on L2 interfaces are not supported in this release.

1

policy-map CLASSIFY


policy-map CLASSIFYclass class-defaultset ip dscp 40

interface GigabitEthernet 2/3/48switchportservice-policy input CLASSIFY

policy-map CLASSIFYclass class-defaultset ip dscp 40

interface PortChannel 10switchportservice-policy input CLASSIFY

Quality of ServiceClassification & Policing

Aggregate policers that are applied on SVIs or Port Channels that have interfaces distributed across multiple forwarding engines are subject to Distributed Policing caveats…

2


policy-map POLICEclass class-defaultpolice average 10000000

Interface GigabitEthernet 1/2/10channel-group 20 mode desireable

Interface GigabitEthernet 2/2/10channel-group 20 mode desireable

interface PortChannel 20service-policy input POLICE

Quality of ServiceQoS on the VSL

The VSL itself has QoS provisioned by default and in the FCS release of the software, it is not configurable. A few important aspects relating to VSL QoS are as follows:

VSLP and other Control frames are always marked as Priority packets and are always queued and classified as such

1

VSL is always configured as “Trust CoS” and hence ingress queuing is enabled2

Service Policies are not supported on the VSL3


Service Policies are not supported on the VSL3

VSL

Switch 1 Switch 2

VSLPVSLPFTPFTPHTTPHTTP

CoS Maps, Thresholds and Queues are not configurable on the VSL4


IMAGE MANAGEMENT

File System Naming Convention

Image ManagementManaging the File System

The Filesystems in a VSS environment are completely managed from the Active Switch’s console. All filesystem activities take place at single centralized location…

vs-vsl#dir sw1-slot5-sup-bootdisk:Directory of sup-bootdisk:/

1 -rwx 33554496 Jan 10 2007 14:53:16 +00:00 sea_log.dat2 -rwx 150198412 Feb 7 2007 17:28:56 +00:00 s72033-adventerprisek9_wan_dbg-vz.0124_all


vs-vsl#dir sw2-slot5-sup-bootdisk:Directory of slavesup-bootdisk:/

1 -rwx 33554464 Feb 9 2007 16:39:02 +00:00 sea_log.dat2 -rwx 150678668 Feb 9 2007 16:45:14 +00:00 s72033-adventerprisek9_wan_dbg-vz.cef

Image ManagementFile System Naming

Some filenames have remained the same - others have changed - some examples of file system names in a Virtual Switch include the following…

VIRTUAL SWITCHPREVIOUS


sw<number>slot<number>disk0:disk0:

sw<number>slot<number>bootflash:bootflash:

sw<number>slot<number>sup-bootdisk:sup-bootdisk:

sw<number>slot<number>nvram:nvram:

slavedisk0:slavedisk0:

slavebootflash:slavebootflash:

slavesup-bootdisk:slavesup-bootdisk:

sw<number>slot<number>const_nvram:const_nvram:


SUMMARY…

Virtual Switch SystemDeployment Considerations

Virtual Switch will incorporate some deployment considerations as best practice…


Virtual Switch SystemBenefits


Virtual Switch SystemSummary


Date post:	27-Nov-2014
Category:	Documents
Upload:	bakh777196
View:	1,057 times
Download:	8 times

VSS BootCamp

Documents