Virtual Switching
System (VSS)
on the Catalyst 6500
March 2008
Lila Rousseaux
Consulting Systems Engineer
[email protected]
Virtual Switching Architecture
Etherchannel Concepts
Integrated Services Routers
Introduction to VSS
Agenda
Hardware Requirements
Conversion Process
Operational Management
High Availability
Quality of Service
Current Network Challenges
Enterprise Campus
Traditional Enterprise Campus deployments have been designed in such a way that allows for scalability, differentiated services and high availability. However they also face many
challenges, some of which are listed in the below diagram…
Access L2/L3 Distribution L3 Core FHRP, STP, Asymmetric routing, Policy Management Extensive routing topology, Routing reconvergence
Single active uplink per VLAN (PVST), L2 reconvergence
Current Network Challenges
Data Center
Traditional Data Center designs are requiring ever increasing Layer 2 adjacencies between Server nodes due to prevalence of Virtualization technology. However, they are pushing the limits of Layer 2 networks, placing more burden on loop-detection protocols such as Spanning Tree… L2/L3 Core L2 Distribution L2 Access Dual-Homed Servers to
single switch, Single active uplink per VLAN (PVST), L2
reconvergence
Single active uplink per VLAN (PVST), L2 reconvergence, excessive BPDUs FHRP, HSRP, VRRP Spanning Tree Policy Management
Virtual Switching System
Introduction
Virtual Switching System
Enterprise 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…
Access L2/L3 Distribution L3 Core No FHRPs No Looped topology Policy Management Reduced routing neighbors, Minimal L3 reconvergence Multiple active
uplinks per VLAN, No STP convergence
Virtual Switching System
Data 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
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
Single router node, Fast L2 convergence,
Virtual Switching System
Virtual Switching System
Control Plane
While the Data Planes in both switches are active, only one switch has an active control plane - hence there is only one management point from which to manage the Virtual Switching System…
Virtual Switching System
Data Plane
The Data Planes in both switches are active - hence each has a full copy of the forwarding tables and Security/QOS policies in hardware such that each can make a fully informed local forwarding decision…
Virtual Switching System
Virtual Switch Link
The 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 Switching System
Multi Chassis Etherchannel
Virtual Switching System
Virtual Switching Architecture
Etherchannel Concepts
Integrated Services Routers
Introduction to VSS
Agenda
Hardware Requirements
Conversion Process
Operational Management
High Availability
Quality of Service
Virtual Switch Architecture
Virtual Switch Link
The 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
Virtual Switch Architecture
VSL 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:
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
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 LMP LMP LMPLMP RRP RRP RRP RRP
Link Management Protocol (LMP) used to track and reject Unidirectional Links, Exchange Chassis ID and other information between the 2 switches
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 VSL
Link Bringupto determine which ports form the VSL
1 2
Virtual Switch Architecture
Link Bringup
Pre-Parse Config Switch 1 Pre-Parse Config
Switch 1 Pre-Parse ConfigSwitch 2
Pre-Parse Config Switch 2
Each member of the Virtual Switch domain must determine which links are candidate for VSL very early on in the bootup cycle. The Switch Processor (SP) pre-parses the configuration to determine which links are configured for VSL…
Virtual Switch Architecture
Link Management Protocol (LMP)
LMP runs on each individual link that is part of the VSL, and is used to program information such as member details, forwarding indices, as well as perform the following checks:
LMP
LMP LMPLMP
LMP
LMP LMPLMP
Verify neighbor is Bi-Directional
Ensure the member is connected to another Virtual Switch
Transmit and receive keepalives to maintain health of the member and the VSL 1
2 3
After successful LMP negotiation, a Peer Group (PG) is formed which is a collection of all VSL members that connects to the same VS. For each PG, a Peer Group Control Link (PGCL) is elected to carry further control information…
Virtual Switch Architecture
Role Resolution Protocol (RRP)
RRP is used to negotiate the role (active or standby) for each chassis:
Determine whether hardware and software versions allow a Virtual Switch to form Determine which chassis will become Active and Hot Standby from a control plane perspective 1 2 RRP RRP RRPRRP RRP RRP RRPRRP VSL
Virtual Switch Architecture
VSL Configuration Consistency Check
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:
Switch Virtual Domain ID
Switch Virtual Domain ID
Switch Virtual Node Type
Switch Virtual Node Type
Switch Priority
Switch Priority
Switch Preempt
Switch Preempt
VSL Port Channel Link ID
VSL Port Channel Link ID
VSL Port state, interfaces…
VSL Port state, interfaces…
Power Redundancy mode
Power Redundancy mode
Power Enable on VSL cards
Power Enable on VSL cards
Note that if configurations do not match, the standby switch will revert to RPR mode, disabling all non-VSL interfaces…
Note that if configurations do not match, the standby switch will revert to RPR mode, disabling all non-VSL interfaces…
Virtual Switch Architecture
VSLP 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 VSLP VSLP VSLPVSLP VSLP VSLP 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 ms vss#
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 ms vss#
The VSLP Ping operates on a per-physical interface basis and parameters such as COUNT, DESTINATION, SIZE, TIMEOUT may also be specified…
Virtual Switch Architecture
Forwarding 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 …
Virtual Switch Domain
Switch 1 - Control Plane Active Switch 2 - Control Plane Hot Standby
Virtual Switch Domain
Virtual Switch Architecture
Virtual 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…
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…
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
Virtual Switch Architecture
Router 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 Router MAC = 000f.f8aa.9c00
The MAC address allocated to the Virtual Switch System is derived from the MAC EEPROM of the Active Virtual Switch upon initial system bring up. 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.
Virtual Switching Architecture
Etherchannel Concepts
Integrated Services Routers
Introduction to VSS
Agenda
Hardware Requirements
Conversion Process
Operational Management
High Availability
Etherchannel Concepts
An Etherchannel combines multiple physical links into a single logical link. Ideal for load sharing or link redundancy – can be used by both layer 2 and Layer 3 subsystems…
Physical View
Multiple ports aredefined as being part of an Etherchannel group
Logical View
Subsystems runningon the switch only see one logical link
An Etherchannel can be defined on Ethernet, Fast Ethernet, Gigabit Ethernet or 10 Gigabit Ethernet Ports
An Etherchannel can be defined on Ethernet, Fast Ethernet, Gigabit Ethernet or 10 Gigabit Ethernet Ports
The distribution of traffic across the members of the Etherchannel done through different hash schemes.
With the PFC3C running 12.2(33)SXH software, there are 13 possible different hash schemes to choose from:
Etherchannel Concepts
Traffic Distribution and Hashing
Selection of the hash scheme of choice is largely dependent on the traffic mix through the EtherChannel
Etherchannel Concepts
Multichassis EtherChannel (MEC)
Prior to VS, Etherchannels were restricted to reside within the same physical switch. In a Virtual Switch environment, Etherchannels can now also be extended across the 2 physical chassis…
As a result, MECs allows for new network designs to be implemented where true layer 2 Multi-pathing can be implemented without the reliance on protocols such as Spanning Tree.
Regular Etherchannel on single chassis Multichassis EtherChannel across 2
VSL-Virtual Switch Virtual Switch
Both LACP and PAGP Etherchannel protocols and Manual ON modes are
supported…
Both LACP and PAGP Etherchannel protocols and Manual ON modes are
Etherchannel Concepts
Multichassis EtherChannel
Support for Etherchannel management is performed by the Control plane on the Active Switch in the Virtual Switch Domain…
Standby Control Plane Active Control Plane
• MEC links on both the switches in the VS
domain are managed by PAgP or LACP running on the Active Switch via internal control messages.
• PAgP or LACP packets destined to a MEC
link on the standby core will be sent across VSL
• MEC links on both the switches in the VS
domain are managed by PAgP or LACP running on the Active Switch via internal control messages.
• PAgP or LACP packets destined to a MEC
link on the standby core will be sent across VSL
Etherchannel Concepts
Etherchannel 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…
Link A1 Link B2
Blue Trafficdestined for the Server will result in Link A1 in the MEC link bundle being chosen as the destination path…
Orange Traffic destined for the Server will result in Link B2 in the MEC link bundle being chosen as the destination path…
Server
Etherchannel Concepts
Etherchannel Hash for MEC
The Result Bundle Hash (RBH) values are reprogrammed for each core to reflect only the local links that are in the Etherchannel bundle…
Virtual Switch
Switch 1 Switch 2
RBH (No MEC) 8 Link Bundle Example
RBH (No MEC)
8 Link Bundle Example 8 Link Bundle ExampleRBH (for MEC)
RBH (for MEC) 8 Link Bundle Example Bit 7
Bit 7 Link 1Link 1 Bit 6
Bit 6 Link 2Link 2 Bit 5
Bit 5 Link 3Link 3 Bit 4
Bit 4 Link 4Link 4 Bit 3
Bit 3 Link 5Link 5 Bit 2
Bit 2 Link 6Link 6 Bit 1
Bit 1 Link 7Link 7
Bit 7
Bit 7 Link 1Link 1 Bit 6
Bit 6 Link 1Link 1 Bit 5
Bit 5 Link 2Link 2 Bit 4
Bit 4 Link 2Link 2 Bit 3
Bit 3 Link 3Link 3 Bit 2
Bit 2 Link 3Link 3 Bit 1
Bit 1 Link 4Link 4
1 2 3 4 5 6 7 8
MEC
Access-SW A
Etherchannel Concepts
Etherchannel Hash Distribution Enhancement
A new hash distribution algorithm has been introduced with the 12.2(33)SXH release which allows for members of a port channel to be added or removed without the requirement for all traffic on the existing members to be temporarily dropped…
RBH (for MEC) 2 Link Bundle Example
RBH (for MEC)
2 Link Bundle Example 3 Link Bundle ExampleRBH (for MEC) RBH (for MEC) 3 Link Bundle Example Flow 1
Flow 1 Flow 2Flow 2 Flow 4
Flow 4 Flow 5Flow 5 Flow 7
Flow 7 Flow 8Flow 8
Flow 3 Flow 3
Flow 6 Flow 6
The existing hash distribution algorithm requires 100% of flows to be temporarily dropped such that duplicate frames are not sent into the network for the duration of time it takes to reprogram the port ASICs with the new member information…
Link 1
Link 1 Link 2Link 2 Flow 1
Flow 1 Flow 2Flow 2 Flow 3
Flow 3 Flow 4Flow 4 Flow 5
Flow 5 Flow 6Flow 6 Flow 7
Flow 7 Flow 8Flow 8
Link 1
Etherchannel Concepts
Etherchannel Hash Distribution Enhancement
Now, when ports are added or removed from an EtherChannel, the load result does not need to be reset on existing member ports, resulting in better recovery times of traffic.
Hence it does not affect 100% of the traffic in an Etherchannel.
Example below: only Flow 7 and 8 are affected by the addition of an extra link to the Channel
RBH (for MEC) 2 Link Bundle Example
RBH (for MEC)
2 Link Bundle Example 3 Link Bundle ExampleRBH (for MEC) RBH (for MEC) 3 Link Bundle Example Flow 1
Flow 1 Flow 2Flow 2 Flow 3
Flow 3 Flow 4Flow 4 Flow 5
Flow 5 Flow 6Flow 6
Flow 7 Flow 7
Flow 8 Flow 8 Link 1
Link 1 Link 2Link 2 Flow 1
Flow 1 Flow 2Flow 2 Flow 3
Flow 3 Flow 4Flow 4 Flow 5
Flow 5 Flow 6Flow 6 Flow 7
Flow 7 Flow 8Flow 8
Link 1
Link 1 Link 2Link 2 Link 3Link 3
vss#conf t
Enter configuration commands, one per line. End with CNTL/Z.
vss(config)#port-channel hash-distribution adaptive vss(config)# ^Z
vss#
vss#conf t
Enter configuration commands, one per line. End with CNTL/Z.
vss(config)#port-channel hash-distribution adaptive
vss(config)# ^Z
vss#
Although this new load-distribution algorithm requires configuration for regular EtherChannel and Multi-Chassis EtherChannel (MEC) interfaces, it will be the default load-distribution
Etherchannel Concepts
Determination of Hash Result
vss#sh etherchannel load-balance hash-result interface port-channel 120 ip 192.168.220.10 192.168.10.10
Computed RBH: 0x4
Would select Gi1/2/1 of Po120
vss#sh etherchannel load-balance hash-result interface port-channel 120 ip 192.168.220.10 192.168.10.10
Computed RBH: 0x4
Would select Gi1/2/1 of Po120
A command can be invoked to allow users to determine which physical link a given flow of traffic will leverage within a port channel group.
The user will need to provide inputs to the command and the hashing algorithm will compute the physical link that will be selected for the traffic mix and algorithm.
Virtual Switching System
Deployment Considerations
Virtual Switching Architecture
Etherchannel Concepts
Integrated Services Routers
Introduction to VSS
Agenda
Hardware Requirements
Conversion Process
Operational Management
High Availability
Quality of Service
Virtual Switching System
VSL Hardware Considerations
Virtual Switching System
Virtual Switching System
Software Considerations
Along with the hardware considerations, Virtual Switching System also has some software considerations…
Hardware Requirements
Distributed 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…
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
Catalyst 6500 Supervisors
PFC3A vs. PFC3B vs. PFC3C
No 4K Yes Yes Yes 500K 64K (32K) 256K (230K) 1M 1M 12.2(17d)SXB1 Sup720 PFC3B-XL Yes 4K Yes Yes Yes 128K 96K(80K) 128K (115K) 1M 256K 12.2(33)SXH Sup720-10GbE PFC3C Yes 4K Yes Yes Yes 500K 96(80K) 256K(230K) 1M 1M 12.2(33)SXH 12.2(33)SXH Sup720-10GbE PFC3C-XL 12.2(17)SXB / 12.2(18)SXF 12.2(17)SXB SW Sup720 / Sup32 Sup720 Supervisor No 512 No No No 128K 64K (32K) 128K (64K) 1M 256K PFC3A No VSL 4K Yes Yes Yes 128K 64K (32K) 128K (115K) 1M 256K PFC3B ACL Labels ACE Counters EoMPLS Native MPLS IPv6 FIB Entries MAC Table NetFlow Table Adjacency Table FIB TCAM Sup/Feature http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/product_data_sheet09186a0080159856_ps4835_Products_Data_Sheet.html
Virtual Switching Architecture
Etherchannel Concepts
Integrated Services Routers
Introduction to VSS
Agenda
Hardware Requirements
Conversion Process
Operational Management
High Availability
Quality of Service
Conversion Process
Conversion to VSS
The conversion process requires configuration of both switches that will form part of the Virtual Switch Domain and requires a reboot on the part of both switches during the
conversion…
It is recommended to have the interfaces forming the VSL be connected prior to the conversion process as it will minimize the number of times the chassis will be reloaded.
It is also recommended to begin the conversion process using a default configuration as the conversion process will remove any previous configuration that pre-exists on the
Conversion Process
Conversion to VSS
For the purposes of this explanation - let’s assume the following setup is required…
Switch - 1 Switch - 2 VSL Link Bundle T5/4 T5/5 T5/4 T5/5 Port-Channel 1 Port-Channel 2 Switch Virtual Domain #10
Conversion Process
Step 1:
Configure Virtual Switch ID and Domain
On the two switches, configure the same VS Domain number (in this case it is 10), but
unique Switch IDs
Switch - 1 Switch - 2
Router(config)#host VSS
VSS(config)#switch virtual domain 10
Domain ID 10 config will take effect only after the exec command 'switch convert mode virtual' is issued
VSS(config-vs-domain)#switch 1
VSS(config-vs-domain)#exit
Router(config)#host VSS
VSS(config)#switch virtual domain 10
Domain ID 10 config will take effect only after the exec command 'switch convert mode virtual' is issued
VSS(config-vs-domain)#switch 2
VSS(config-vs-domain)#exit
Note: The Domain ID is retained in the configuration, but the Switch ID is not – this is stored as a variable in ROMMON. To see this value:
Conversion Process
Step 2:
VSL Configuration – Configure the VSL Port
Channel and member ports
Choose unique Port Channel IDs for each chassis to form the VSL and configure them with the corresponding Switch ID
Add the ports on each switch to the port channel that corresponds to the respective side of the VSL
Switch - 1 Switch - 2
VSS(config)#interface port-channel 1 ! Associates Switch 1 as owner of port channel 1
VSS(config-if)#switch virtual link 1
VSS(config-if)#interface range tenG 5/4 - 5 ! Adds this interface to channel group 1
VSS(config-if-range)#channel-group 1 mode on
VSS(config-if)#interface port-channel 2 ! Associates Switch 2 as owner of port channel 2
VSS(config-if)#switch virtual link 2
VSS(config-if)#interface range tenG 5/4 - 5 ! Adds this interface to channel group 2
Conversion Process
Step 3:
Convert to Virtual Switch Mode
Convert both switches to Virtual Switch mode using the following exec command:
Switch - 1 Switch - 2
vss#switch convert mode virtual
This command will convert all interface names to naming convention "interface-type switch-number/slot/port", save the running config to startup-config and reload the switch.
Do you want to proceed? [yes/no]: yes Converting interface names
Building configuration... [OK]
Saving converted configuration to bootflash: ...
Destination filename
[startup-config.converted_vs-20071031-150039]?
vss#switch convert mode virtual
This command will convert all interface names to naming convention "interface-type switch-number/slot/port", save the running config to startup-config and reload the switch.
Do you want to proceed? [yes/no]: yes Converting interface names
Building configuration... [OK]
Saving converted configuration to bootflash: ...
Destination filename
[startup-config.converted_vs-20071031-150018]? AT THIS POINT THE SWITCH WILL REBOOT
Conversion Process
When the two switches are brought online, they will proceed with VSL initialization and bring up their respective VSL ports.
The two switches communicate with each other and determine Active and Standby role.
Switch - 1 Switch - 2
SWITCH CONSOLE OUTPUT
<…snip…>
System detected Virtual Switch configuration... Interface TenGigabitEthernet 1/5/4 is member of PortChannel 1
Interface TenGigabitEthernet 1/5/5 is member of PortChannel 1
<…snip…>
00:00:26: %PFREDUN-6-ACTIVE: Initializing as ACTIVE processor for this switch
Initializing as Virtual Switch ACTIVE processor
<…snip…>
00:01:19: %VSLP-5-RRP_ROLE_RESOLVED: Role resolved as ACTIVE by VSLP
00:01:19: %VSL-5-VSL_CNTRL_LINK: New VSL
SWITCH CONSOLE OUTPUT
<…snip…>
System detected Virtual Switch configuration... Interface TenGigabitEthernet 2/5/4 is member of PortChannel 2
Interface TenGigabitEthernet 2/5/5 is member of PortChannel 2
<…snip…>
00:00:26: %PFREDUN-6-ACTIVE: Initializing as ACTIVE processor for this switch
Initializing as Virtual Switch STANDBY processor
<…snip…>
00:01:02: %VSLP-5-RRP_ROLE_RESOLVED: Role resolved as STANDBY by VSLP
Conversion Process
Step 4:
Finalize Virtual Switch Configuration
This command will get the VSL related commands from the Standby Switch and update the startup-configuration with the new merged configurations
Note that only VSL-related configurations are merged with this step – all other configuration will be lost and requires manual intervention.
This step is only applicable for a first-time conversion.
Switch - 1
SWITCH CONSOLE OUTPUT
<…snip…>
vss-demo#switch accept mode virtual
This command will populate the above VSL configuration from the standby switch into the running configuration.
The startup configuration will also be updated with the new merged configuration if merging is successful.
Do you want to proceed? [yes/no]: yes Merging the standby VSL configuration...
Building configuration...
00:11:33: %PFINIT-SW1_SP-5-CONFIG_SYNC: Sync'ing the startup configuration to the standby Router. [OK]
Conversion Process
Conversion to VSS
Configuration for the conversion takes the following path…
Switch - 1 Switch - 2
vss#sh switch virtual
Switch mode : Virtual Switch Virtual switch domain number : 10
Local switch number : 1
Local switch operational role: Virtual Switch Active Peer switch number : 2
Peer switch operational role : Virtual Switch Standby vss-demo#
vss-sdby>en
Standby console disabled
vss-sdby>
Both switches are now converted with Switch 1 as the Master (Active) and Switch 2 as the Standby
Switch 2 console is now disabled for normal console activity…
Conversion Process
Boot-up Priority
Normal operation is for first switch to boot to assume VS Active role - this behavior can be changed allowing a pre defined switch to assume Active role by specifying a priority (higher priority uses a higher number)…
VSS#sh switch virtual role
Switch Switch Status Preempt Priority Role Session ID Number Oper(Conf) Oper(Conf) Local Remote ---LOCAL 1 UP FALSE(N) 110(110) ACTIVE 0 0 REMOTE 2 UP FALSE(N) 100(100) STANDBY 9114 1391
VSS#sh switch virtual role
Switch Switch Status Preempt Priority Role Session ID Number Oper(Conf) Oper(Conf) Local Remote ---LOCAL 1 UP FALSE(N) 110(110) ACTIVE 0 0 REMOTE 2 UP FALSE(N) 100(100) STANDBY 9114 1391
Switch Preemption
Once the active and standby roles have been determined, they cannot be changed
without manual intervention
If we need to always prefer a particular physical switch to assume the Virtual Switch
Active role, then we can leverage the Switch Preemption feature.
Please Note: Use this feature with caution since preemption is not advisable in most
designs.
The SSO behavior requires that in order for switch 1 to become active
switch 2 will have to reboot to come up in standby mode. So unlike HSRP
pre-emption where we have reasons to pre-empt and we have very little impact to active
traffic flows in the VSS case there is no reason to move the active role (and we do
suffer from a full reboot of one of the two switches
Virtual Switching Architecture
Etherchannel Concepts
Integrated Services Routers
Introduction to VSS
Agenda
Hardware Requirements
Conversion Process
Operational Management
High Availability
Operational Management
Virtual Switch CLI
Multiple console interfaces exist within a Virtual Switch Domain, but only the active RP/SP consoles are enabled for command interaction…
Operational Management
Reloading the VSS and reloading a member
The command “reload” will reload
entire Virtual Switch System (both chassis)
To reload each chassis individually we need to specify the Switch ID
vss#reload
Warning: This command will reload the entire Virtual Switching System (Active and Standby Switch).
Proceed with reload? [confirm]
1d04h: %SYS-5-RELOAD: Reload requested by console. Reload Reason: Reload Command.
***
*** SHUTDOWN NOW ---***
1d04h: %SYS-SP-5-RELOAD: Reload requested System Bootstrap, Version 8.5(1)
vss#reload
Warning: This command will reload the entire Virtual Switching System (Active and Standby Switch).
Proceed with reload? [confirm]
1d04h: %SYS-5-RELOAD: Reload requested by console. Reload Reason: Reload Command.
***
*** SHUTDOWN NOW ---***
1d04h: %SYS-SP-5-RELOAD: Reload requested System Bootstrap, Version 8.5(1)
Copyright (c) 1994-2006 by cisco Systems, Inc.
vss#redundancy reload shelf ?
<1-2> shelf id <cr>
vss#redundancy reload shelf 2
Reload the entire remote shelf[confirm]
Preparing to reload remote shelf vss#
vss#redundancy reload shelf ?
<1-2> shelf id <cr>
vss#redundancy reload shelf 2
Reload the entire remote shelf[confirm]
Preparing to reload remote shelf
Operational Management
Setting the System-wide PFC Mode
• Only PFC/DFC 3C/CXL are supported in a VSS.
• It is possible to mix modules in a 3C and 3CXL system: the system will take the lowest common denominator as the system-wide PFC mode.
• In a VSL environment is basically the mode negotiation happens even before the modules are brought up
• 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 t
Enter configuration commands, one per line. End with CNTL/Z.
vs-vsl(config)#platform hardware vsl pfc mode pfc3c
vs-vsl(config)#^Z vs-vsl#
vs-vsl#conf t
Enter configuration commands, one per line. End with CNTL/Z.
vs-vsl(config)#platform hardware vsl pfc mode pfc3c
vs-vsl(config)#^Z vs-vsl#
vs-vsl#sh platform hardware pfc mode PFC operating mode : PFC3C
Configured PFC operating mode : PFC3C
vs-vsl#sh platform hardware pfc mode
PFC operating mode : PFC3C
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…
Virtual Switch Domain
Switch 1 -Active Switch 2 -Standby
SNMP Process Active SNMP Process Inactive
SNMP Server SNMP Get’s SNMP Put’s SNMP Modified MIB’s SNMP Modified MIB’s SNMP New MIB’s SNMP New MIB’s
Operational Management
Slot/Port Numbering
After conversion, port definitions for switches within the Virtual Switch Domain inherit the Chassis ID as part of their naming convention…
Router#show ip interface brief
Interface IP-Address OK? Method Status Protocol Vlan1 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>
Router#show ip interface brief
Interface IP-Address OK? Method Status Protocol Vlan1 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>
PORT NUMBERING: <CHASSIS-ID><SLOT-NUMBER><PORT-NUMBER> PORT NUMBERING: <CHASSIS-ID><SLOT-NUMBER><PORT-NUMBER>
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…
Active Supervisor - Slot 5 Hot Standby Supervisor - Slot 5
Virtual Switch Domain
e.g. OLD: disk0: NEW: sw1-slot5-disk0: Switch 1 Switch 2 e.g. OLD: slavedisk0: NEW: sw2-slot5-disk0: SW<NUMBER>SLOT<NUMBER>FILESYSTEM SW<NUMBER>SLOT<NUMBER>FILESYSTEM AN EXAMPLE
Operational Management
File System Naming
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.dat 2 -rwx 150198412 Feb 7 2007 17:28:56 +00:00 s72033-adventerprisek9_wan_dbg-vz.0124_all vs-vsl#dir sw1-slot5-sup-bootdisk: Directory of sup-bootdisk:/ 1 -rwx 33554496 Jan 10 2007 14:53:16 +00:00 sea_log.dat 2 -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.dat 2 -rwx 150678668 Feb 9 2007 16:45:14 +00:00 s72033-adventerprisek9_wan_dbg-vz.cef vs-vsl#dir sw2-slot5-sup-bootdisk: Directory of slavesup-bootdisk:/ 1 -rwx 33554464 Feb 9 2007 16:39:02 +00:00 sea_log.dat 2 -rwx 150678668 Feb 9 2007 16:45:14 +00:00 s72033-adventerprisek9_wan_dbg-vz.cef
Operational Management
File 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 SWITCH VIRTUAL SWITCH sw<number_1>slot<number>disk0: sw<number_1>slot<number>disk0: PREVIOUS PREVIOUS disk0: disk0: sw<number_1>slot<number>bootflash: sw<number_1>slot<number>bootflash: bootflash: bootflash: sw<number_1>slot<number>sup-bootdisk: sw<number_1>slot<number>sup-bootdisk: sup-bootdisk: sup-bootdisk: sw<number_1>slot<number>nvram: sw<number_1>slot<number>nvram: nvram: nvram: sw<number_2>slot<number>disk0: sw<number_2>slot<number>disk0: slavedisk0: slavedisk0: sw<number_2>slot<number>bootflash: sw<number_2>slot<number>bootflash: slavebootflash: slavebootflash: sw<number_2>slot<number>sup-bootdisk: sw<number_2>slot<number>sup-bootdisk: slavesup-bootdisk: slavesup-bootdisk: sw<number_2>slot<number>nvram: sw<number_2>slot<number>nvram: slavenvram: slavenvram:
Operational Management
File System Naming
Operational Management
Netflow
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 Domain
VS State : Active
Control Plane: Active
Data Plane: Active
Netflow Collection: Active
Netflow Export: Active
VS State : Standby
Control Plane: Standby
Data Plane: Active
Netflow Collection: Active
Netflow 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 Management
Netflow Export
The Virtual Switch Link will be used as the transit path to allow the standby Sup to forward
Netflow data to the active Supervisor for Netflow export - the VS Link should be dimensioned to accommodate the expected Netflow export load…
Virtual Switch Domain
VS State : Active
Netflow Collection: Active
Netflow Export: Active
VS State : Standby
Netflow Collection: Active
Netflow Export: In-Active
VSL Netflow Data Netflow Data Netflow Export Netflow Collector
IOS Image Upgrade
SW1-Slot5 SW2-Slot5
Switch 1 Switch 2
Full image upgrade process using Fast Software Upgrade (FSU): similar to that of two
supervisor engines within a standalone chassis today
NAME
NAME CONTROL PLANECONTROL PLANE FABRIC STATEFABRIC STATE SW1-SLOT5
SW1-SLOT5 ActiveActive ActiveActive SW2-SLOT5
SW2-SLOT5 Hot StandbyHot Standby ActiveActive
REDUNDANCY REDUNDANCY -SSO SSO
IOS Image Upgrade
Manually copy the new image or filesystem onto the appropriate flash device of each supervisor. No impact to forwarding.
1
SW1-Slot5 SW2-Slot5
Switch 1 Switch 2
NAME
NAME CONTROL PLANECONTROL PLANE FABRIC STATEFABRIC STATE SW1-SLOT5
SW1-SLOT5 ActiveActive ActiveActive SW2-SLOT5
SW2-SLOT5 Hot StandbyHot Standby ActiveActive
REDUNDANCY REDUNDANCY -SSO SSO
IOS Image Upgrade
1 Commands to copy the new image to the flash file system of both supervisors (Active and Hot Standby)
IOS Image Upgrade
Modify boot variables to point to the new image or filesystem and reload Switch 2. Switch 2 should reset and boot into the new image in RPR mode. System bandwidth falls to 50% 2
SW1-Slot5 SW2-Slot5
Switch 1 Switch 2
NAME
NAME CONTROL PLANECONTROL PLANE FABRIC STATEFABRIC STATE SW1-SLOT5
SW1-SLOT5 ActiveActive ActiveActive SW2-SLOT5
SW2-SLOT5 ColdCold StandbyStandby
REDUNDANCY REDUNDANCY -RPR RPR
IOS Image Upgrade
Modify the boot variable on Switch 1 (Active VS) to point to the new image or file system and save the configuration – this will synchronize the boot variable to Switch 2 (Standby VS) as well.
IOS Image Upgrade
Schedule a change window and when possible, reload Switch 2 (Standby VS). 2.2
<snip> <snip>
IOS Image Upgrade
After successful boot up of the Switch 2 (Standby VS), verify the peer relationship between Supervisors are in RPR state (Cold Standby).
IOS Image Upgrade
Switch over Active supervisor to Switch 2 when desired. System capacity will drop to 0% temporarily and return to 50% once SW2-Slot5 completely boots up and becomes active. SW1-Slot5 will continue to boot up…
3
SW1-Slot5 SW2-Slot5
Switch 1 Switch 2
NAME
NAME CONTROL PLANECONTROL PLANE FABRIC STATEFABRIC STATE SW1-SLOT5
SW1-SLOT5 ColdCold StandbyStandby SW2-SLOT5
SW2-SLOT5 ActiveActive ActiveActive
REDUNDANCY REDUNDANCY RPR RPR
-IOS Image Upgrade
When possible, perform a supervisor or chassis switchover such that Switch 2 (previous Standby VS) now assumes the Active role whilst Switch 1 (previous Active VS) is reloaded. At this time, a total VSS outage will be expected as Switch 2 transitions from an RPR Cold Standby state to the Active state.
IOS Image Upgrade
Once Switch 2 is completely online, it will re-peer with its neighbors and form any applicable relationships and traffic will be forwarded through the VSS again at 50% capacity while
Switch 1 continues to boot up with the new image or filesystem. 3.2
IOS Image Upgrade
After Switch 1 comes online again, it will return to SSO mode as it will now be running the new version of software and traffic will return to 100% capacity…
4
SW1-Slot5 SW2-Slot5
Switch 1 Switch 2
NAME
NAME CONTROL PLANECONTROL PLANE FABRIC STATEFABRIC STATE SW1-SLOT5
SW1-SLOT5 Hot StandbyHot Standby ActiveActive SW2-SLOT5
SW2-SLOT5 ActiveActive ActiveActive
REDUNDANCY REDUNDANCY SSO SSO
-IOS Image Upgrade
After Switch 1 is completely brought back online and all interfaces are active, it will enter into NSF/SSO state with Switch 2.
4
<snip>
IOS Image Upgrade
The following graph illustrates the aggregate traffic for the VSL system during the full image upgrade:
1 2.1 2.2 2.3 3.1 3.2 4
1] Copy new image in both switches 2.1] Change bootvar in both switches 2.2] Reboot SW2 2.3] SW2 comes back in RPR 3.1] Switchover from SW1 to SW2
3.2] SW2 comes back from the Cold Standby mode
4] SW1 is completely rebooted and comes back in SSO mode
Virtual Switching Architecture
Etherchannel Concepts
Integrated Services Routers
Introduction to VSS
Agenda
Hardware Requirements
Conversion Process
Operational Management
High Availability
High Availability
Redundancy 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.
Only in NSF/SSO mode does the Standby supervisor PFC, Switch Fabric, modules and their associated DFCs become active…
VSL
Should a mismatch of information occur between the Active and Standby Chassis, the Standby Chassis will revert to RPR mode, where all the modules will be powered down (except for the VSL ports)
Switch 1 12.2(33)SXH1 Active Switch 2 12.2(33)SXH1 NSF/SSO VSL Switch 1 12.2(33)SXH1 Active Switch 2 12.2(33)SXH2 RPR
High Availability
Dual-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…
Virtual Switch Domain
VS State : Active
Control Plane: Active
Data Plane: Active
VS State : Standby
Control Plane: Standby
Data Plane: Active
VSL
Switch 1 Supervisor Switch 2 Supervisor
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
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 Availability
Dual-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…
Virtual Switch Domain
VS State : Active
Control Plane: Active
Data Plane: Active
VS State : Active
Control Plane: Active
Data Plane: Active
VSL
Switch 1 Supervisor Switch 2 Supervisor
2 mechanisms have been implemented in the initial release to detect and recover from a Dual Active scenario:
Enhanced Port Aggregation Protocol (PAgP+): uses MEC links to communicate between the two chassis
Dual-Active Detection over IP-BFD: uses a backup Ethernet connection. 1
High Availability
Dual-Active Detection - Enhanced PAgP
PAgP+ adds new TLV (switch ID of the active switch) to remote devices connected via 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…
Switch 1 Switch 2
Active: Switch 1 Active: Switch 1
Switch 1 Switch 2
Active: Switch 1 Active: Switch 2
Should the VSL go down, the Standby switch will transition immediately to Active state and start sending PAgP message with the new Active switch ID
High Availability
Dual-Active Detection - Enhanced PAgP
The Enhnaced PAgP-capable neighbor will send the new Active Switch ID to all ports of the port channel that it received the new Active Switch ID on
This includes the the previous-active Virtual switch (Switch 1) …
Switch 1 Switch 2
High Availability
Dual-Active Detection - Enhanced PAgP
Switch 1 Switch 2
Active: Switch 2 Active: Switch 2
Switch 1 Switch 2
Active: Switch 2
When Switch 1 receives PAgP messages with Active Switch = 2, it will know that a Dual-Active scenario has occurred
Recovery Mode: Switch 1 will then bring down all non-VSL interfaces (except interfaces configured to be excluded from shutdown)
Dual-Active!!
vs-vsl#sh switch virtual dual-active pagp
Channel group 20 dual-active detect capability w/nbrs Dual-Active version: 1.1
Dual-Active configured: Yes
Dual-Active Partner Partner Partner Port Detect Capable Name Port Version Gi1/8/1 Yes vs-access-1 Gi5/1 1.1 Gi2/8/1 Yes vs-access-1 Gi5/2 1.1 vs-vsl#sh switch virtual dual-active pagp
Channel group 20 dual-active detect capability w/nbrs Dual-Active version: 1.1
Dual-Active configured: Yes
Dual-Active Partner Partner Partner Port Detect Capable Name Port Version
Gi1/8/1 Yes vs-access-1 Gi5/1 1.1 Gi2/8/1 Yes vs-access-1 Gi5/2 1.1
High Availability
Dual-Active Detection - Enhanced PAgP
vs-vsl#conf t
Enter configuration commands, one per line. End with CNTL/Z.
vs-vsl(config)#switch virtual domain 10
vs-vsl(config-vs-domain)#dual-active detection pagp
vs-vsl(config-vs-domain)#dual-active trust channel-group 20 vs-vsl#
vs-vsl#conf t
Enter configuration commands, one per line. End with CNTL/Z.
vs-vsl(config)#switch virtual domain 10
vs-vsl(config-vs-domain)#dual-active detection pagp
vs-vsl(config-vs-domain)#dual-active trust channel-group 20
vs-vsl#
Dual-Active Detection capabilities require that the neighboring device be Dual-Active Detection Aware. This can be verified with the following command…
High Availability
Dual-Active Detection - IP-BFD
This method uses a dedicated L3 direct link heartbeat mechanism between the Virtual Switches.
IP-BFD (Bi-Directional Forwarding Detection) is used to assist the fast detection of a failed VSL
If the VSL goes down, both chassis create BFD neighbors, and try to establish adjacency. If the original active chassis receives an adjacency message, it realizes that this is dual-active
If the VSL goes down, both chassis create BFD neighbors, and try to establish adjacency. If the original active chassis receives an adjacency message, it realizes that this is dual-active
VSL
IP-BFD Heartbeat Link
Switch 1 Switch 2
VSL
IP-BFD Heartbeat Link
Switch 1 Switch 2
BFD
High Availability
Dual-Active Detection - IP-BFD
vss(config)#interface gigabitethernet 1/5/1 vss(config-if)#no switchport
vss(config-if)#ip address 200.230.230.231 255.255.255.0 vss(config-if)#bfd interval 100 min_rx 100 multiplier 50 vss(config-if)#interface gigabitethernet 2/5/1
vss(config-if)#no switchport
vss(config-if)#ip address 201.230.230.231 255.255.255.0 vss(config-if)#bfd interval 100 min_rx 100 multiplier 50 vss(config)#switch virtual domain 100
vss(config-vs-domain)#dual-active detection bfd
vss(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 pair adding a static route 201.230.230.0 255.255.255.0 Gi1/5/1 for this dual-active pair vss(config)#interface gigabitethernet 1/5/1
vss(config-if)#no switchport
vss(config-if)#ip address 200.230.230.231 255.255.255.0 vss(config-if)#bfd interval 100 min_rx 100 multiplier 50
vss(config-if)#interface gigabitethernet 2/5/1 vss(config-if)#no switchport
vss(config-if)#ip address 201.230.230.231 255.255.255.0 vss(config-if)#bfd interval 100 min_rx 100 multiplier 50
vss(config)#switch virtual domain 100
vss(config-vs-domain)#dual-active detection bfd
vss(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 pair adding a static route 201.230.230.0 255.255.255.0 Gi1/5/1 for this dual-active pair Two directly-connected interfaces must be configured as BFD message links…
The IP-BFD Heartbeat link may exist on any interface but must have an IP address assigned to it on a different network
Static routes are automatically added for the remote addresses and will only be installed in the RIB should a Dual-Active scenario occur.
As a result of this, no packets will be forwarded between the switches via the heartbeat interfaces until the VSL is brought down
If the Virtual Switch Standby has taken over as active, a BFD “adjacency up” event will be generated, indicating a Dual-Active situation has occurred.
High Availability
Dual-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 t
Enter configuration commands, one per line. End with CNTL/Z.
vs-vsl(config)#switch virtual domain 100
vs-vsl(config-vs-domain)#dual-active exclude interface Gig 1/5/1 vs-vsl(config-vs-domain)#dual-active exclude interface Gig 2/5/1 vs-vsl(config-vs-domain)# ^Z
vs-vsl#
vs-vsl#conf t
Enter configuration commands, one per line. End with CNTL/Z.
vs-vsl(config)#switch virtual domain 100
vs-vsl(config-vs-domain)#dual-active exclude interface Gig 1/5/1
vs-vsl(config-vs-domain)#dual-active exclude interface Gig 2/5/1
vs-vsl(config-vs-domain)# ^Z
High Availability
Dual-Active Recovery
The network administrator is notified of the Dual-Active situation through the CLI, syslog,etc 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…
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… VSL Up! Reload… Switch 1 Switch 2 Switch 1 Switch 2 VSLP VSLP VSLPVSLP
Virtual Switching Architecture
Etherchannel Concepts
Integrated Services Routers
Introduction to VSS
Agenda
Hardware Requirements
Conversion Process
Operational Management
High Availability
Quality of Service
Classification & Policing
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
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 class class-default set ip dscp 40 interface GigabitEthernet 2/3/48 switchport
service-policy input CLASSIFY
policy-map CLASSIFY class class-default
set ip dscp 40
interface GigabitEthernet 2/3/48 switchport
service-policy input CLASSIFY
policy-map CLASSIFY class class-default
set ip dscp 40
interface PortChannel 10 switchport
service-policy input CLASSIFY
policy-map CLASSIFY class class-default
set ip dscp 40
interface PortChannel 10 switchport
policy-map POLICE class class-default
police average 10000000
Interface GigabitEthernet 1/2/10 channel-group 20 mode desireable
Interface GigabitEthernet 2/2/10 channel-group 20 mode desireable
interface PortChannel 20 service-policy input POLICE
policy-map POLICE class class-default
police average 10000000
Interface GigabitEthernet 1/2/10 channel-group 20 mode desireable Interface GigabitEthernet 2/2/10
channel-group 20 mode desireable interface PortChannel 20
service-policy input POLICE
Quality of Service - C
lassification & 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…Quality of Service
QoS 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 enabled 2
Service Policies are not supported on the VSL 3 VSL Switch 1 Switch 2 VSLP VSLP FTP FTP HTTP HTTP
CoS Maps, Thresholds and Queues are not configurable on the VSL 4
