Simplifyingnetworksusingvpcandvss 160329194358

Simplifying Switched
Networks
vPC and VSS
Ross Adams
Systems Engineer
In the Beginning…
© 2016 Cisco and/or its affiliates. All rights reserved. Cisco Public
And it was good…
Except When it Wasn’t…
Complexity
X Stranded
bandwidth & slow
convergence
X X X X Limited options
for access
redundancy
vPC & VSS
Presentation ID © 2016 Cisco and/or its affiliates. All rights reserved. Cisco Public
5
Virtual Path Channel (vPC)
6
vPC Overview
MCEC Multi-Chassis EtherChannel
vPC Peers
•  Available on Nexus platforms
•  Allows a single device to use a port channel across
two neighbor switches (vPC peers)
•  Eliminate STP blocked ports & Provide fast MCEC
convergence upon link/device failure
vPC Peers
•  Maintains independent control planes
MCEC
vPC
! Enable vpc on the switch
dc11-5020-1(config)# feature vpc
! Check the feature status

dc11-5020-1(config)# show feature | include
vpc
vpc 1 enabled
7
vPC Architecture
vPC
vPC - the port channel between the
vPC peers and the downstream device
•  Configuration needs to match other
vPC peer member
•  Configuration inconsistency can
cause a VLAN or an entire port-
vPC
channel may be suspended (e.g. vPC
vPC
MTU mismatch) member
member
port
port
•  Maximum number of active ports
vary by platform. vPC
vPC
member
port
vPC member port - one of a set
of ports (port channels) that form a vPC
9
vPC Domain
The pair of vPC switches participating
in the vPC
•  Provides for definition of global vPC system
parameters
•  You MUST utilize unique Domain id’s for vPC Domains
all vPC pairs defined in a contiguous layer
2 domain
•  The vPC peer devices use the domain id to
automatically assign a unique vPC system
MAC address
10
vPC Peer
One of a pair of switches that makes

up a vPC domain
vPC peer
11
vPC local system-mac
§  vPC peers function as independent devices as well as peers

§  Local ‘system-mac’is used for all non vPC PDUs (LACP, STP, …)
7k_1 # sh vpc role
<snip>
vPC system-mac : 00:23:04:ee:be:14
vPC system-priority : 1024 7K_1 7K_2
vPC local system-mac : 00:0d:ec:a4:53:3c
vPC local role-priority : 1024
Regular (non vPC)

Port Channel G1/4 G1/5 1/1 1/2
5K_2
MCEC (vPC)
dc11-4948--2 EtherChannel
dc11-4948-2#sh lacp neighbor

<snip>
LACP port Admin Oper Port Port
Port Flags Priority Dev ID Age key Key Number State
Gi1/4 SA 32768 000d.eca4.533c 8s 0x0 0x1D 0x108 0x3D
Gi1/5 SA 32768 000d.eca4.533c 8s 0x0 0x1D 0x108 © 2016 Cisco and/or its affiliates. All rights reserved.
0x3D Cisco Public
12
vPC system-mac
§  LACP neighbor sees the same System ID from both vPC peers
§  The vPC ‘system-mac’ is used by both vPC peers
7K_1# sh vpc role 7K_2 # sh vpc role
<snip> <snip>
vPC system-mac : 00:23:04:ee:be:14 vPC system-mac : 00:23:04:ee:be:14
vPC system-priority : 1024 vPC system-priority : 1024
vPC local system-mac : 00:0d:ec:a4:53:3c vPC local system-mac : 00:0d:ec:a4:5f:7c
vPC local role-priority : 1024 vPC local role-priority : 32667
7K_1 7K_2
Regular (non vPC)

Port Channel 1/1 1/2
1/4 1/5
MCEC (vPC)
EtherChannel
dc11-4948-1 5K_2
5K_2#sh lacp neighbor
<snip>
LACP port Admin Oper Port Port
Port Flags Priority Dev ID Age key Key Number State
E1/1 SA 32768 0023.04ee.be14 9s 0x0 0x801E 0x4104 0x3D
E1/2 SA 32768 0023.04ee.be14 21s 0x0 0x801E 0x104 © 2016 Cisco and/or its affiliates. All rights reserved.
0x3D Cisco Public
13
vPC Roles
vPC Domain 10
Dual Layer VPC
§  Primary & Secondary

§  Switch with lower priority becomes primary
(tie breaker = lower system MAC)
§  Role matters for the behavior with peer-link failures! vPC Domain 20
§  Role is non-preemptive

§  Operational role may differ from the priorities
configured under the domain
Primary (but may be

Operational Secondary) Secondary (but may be
dc11-5020-3(config-vpc-domain)# role priority ? Operational Primary)
<1-65535> Specify priority value
dc11-5020-3# sh vpc
<snip>
vPC role : secondary, operational primary
14
vPC Peer-link vPC imposes the rule that
the peer link should never
be blocking !
§  Standard 802.1Q Trunk which carries

vPC peer-link
‒  CFS (Cisco Fabric Services) messages
‒  STP BPDUs, HSRP Hellos, IGMP updates, etc.
‒  flooded traffic from the vPC peer
§  Peer-Link member ports must be 10/40/100GE interfaces
§  vPC Peer-link should be a point-to-point connection (No other
device between the vPC peers)
Recommendations (strong ones!)

Always use identical
‒  Minimum 2x 10GE ports
(on modular switches: use 2 separate cards for best resiliency) modules on either sides of
‒  10GE ports in dedicated mode (for oversubscribed modules) the peer-link
15
vPC Peer-Keepalive link vPC PKL messages should
NOT be routed over the vPC
PL !
§  Heartbeat between vPC peers
§  Active/Active detection (in case vPC Peer-Link is down) vPC peer-
keepalive link
§  Non-fatal to the operation of VPC
§  UDP message on port 3200, 96 bytes long (32 byte payload), includes
version, time stamp, local and remote IPs, and domain ID
§  Default timers : interval 1 sec / timeout 5sec
NEXUS 7000 NEXUS 5000/5500

1- Dedicated link(s) (1GE LC) 1- mgmt0 interface
Recommendations (along with management traffic)
(in order of preference): 2- mgmt0 interface 2- Dedicated link(s)
(along with management traffic) (1/10GE front panel ports)
3- As last resort, can be routed over L3 3 - As last resort, can be routed over L3
infrastructure infrastructure © 2016 Cisco and/or its affiliates. All rights reserved. Cisco Public
16
More vPC Terminology
§ CFS - Cisco Fabric Services protocol, used for state

synchronization and configuration validation
between vPC peer devices
CFS protocol
§ Orphan Device – An orphan device is a device

which is on a VPC vlan but only connected to one
VPC peer and not to both Orphan Port
Orphan
Device
§ Orphan Port – An orphan port is a interface which
connects to an orphan device
17
vPC Configuration Consistency
vPC Domain 10
§  Both switches in the vPC Domain maintain distinct control

planes
§  CFS provides for protocol state sync between both peers
(MAC Address table, IGMP state, …) vPC Domain 20
§  System configuration must also be kept in sync

§  Two types of interface consistency checks
§  Type 1 – Will put interfaces into suspend state to
prevent incorrect forwarding of packets. With
Graceful Consistency check (5.2 & later), we only
suspend on secondary peer
§  Type 2 – Error messages to indicate potential for
undesired forwarding behavior
18
How vPC Works
Loop Avoidance
4
x
PC B
1 PC A ends a packet to PC B
x
2 MAC B is not known by left switch à flood
2 3 3 MAC B is not known by right switch à flood
4 B receives duplicate frames
5 MAC A will be learned on wrong port on the lower access switch à

x
blackholing traffic to A
PC A
1
A ↑← 5
x
Frames received on Peer-Link

must not be flooded out of VPCs
vPC Forwarding
PC B
1 MAC B is not known by left switch à flood

Frames received from Peer-Link are never sent out of VPC (except
2 those without operational ports on ingress switch)
2 Egress port ASICs will drop the frame
1
Frame is still flooded to devices that are solely connected to egress
PC A 3 switch
This rule (called ‘VPC check’) stands for all traffic

(L2, L3, unicast, multicast, broadcast, flooded etc) on Nexus 7000
(Nexus 3000/5000 VPC have similar rule, but different
implementation) © 2016 Cisco and/or its affiliates. All rights reserved. Cisco Public
Summary: vPC Forwarding
x
√ √ X √
Design Considerations &
Best Practices
vPC Failure Scenario
vPC Peer-link Down
P S
vPC Peer-keepalive
vPC peer-link failure (link loss):

§  Failover gated on CFS message failure
vPC_PLink
§  VPC system checks active status of the Suspend secondary
remote vPC peer via peer-keepalive link vPC Member Ports
(heartbeat) vPC1 vPC2
§  If both peers are active, then Secondary vPC

peer will disable all vPCs to avoid Dual- SW3 SW4
Active
§  Data will automatically forward down
remaining active port channel ports P Primary vPC Keepalive Heartbeat
S Secondary vPC
§  Orphan devices connected to secondary

peer will be isolated
24
vPC Failure Scenario
Dual Active
P P
S
vPC Peer-keepalive
In rare cases , when both VPC PKL link & PL comes

down (in this order) à it may result into Dual-Active
situation vPC_PLink
§  VPC Peer-Keepalive comes down à VPC still functional
Traffic Loss / Uncertain Traffic
§  VPC Peer-Link comes down but both peers are active Behavior
à Peers have no way to detect if other peer is still active vPC1 vPC2
§  Primary Peer remains primary and secondary peer takes over the
operational primary role SW3 SW4
§  This results in dual-active scenario and can result in traffic loss /
uncertain traffic behavior
§  When links are restored, the operational primary (former secondary) P Primary vPC
keeps the primary role & former primary becomes operational
secondary S Secondary vPC
à In a functional VPC system - Only the operational primary switch

processes BPDUs and acts as STP root, regardless of configured STP
root
§  Roles are not preempted by default
25
Spanning Tree Interoperability
In a VPC system , STP Provides:
§  Loop detection (failsafe to vPC)
§  Non-vPC attached device
§  Loop management on vPC addition/removal

Requirements:
§  Needs to remain enabled, but doesn’t dictate vPC member port state
STP is running to manage
§  Logical ports still count loops outside of vPC domain,
Best Practices: or before initial vPC
configuration !
§  Make sure all switches in your layer 2 domain are running thesame
STP mode Rapid-PVST ,MST
§  Remember to configure portfast (edge port-type) on host facing
interfaces
26
STP with vPC (Default)
Primary Secondary
vPC vPC
•  STP for vPCs is controlled by the vPC operationally

primary switch and only such device sends
BPDUs
out BPDUs on STP designated ports
Us
BPD
• 
•  This happens irrespectively of where the designated
STP Root is located
•  The vPC operationally secondary device proxies STP

BPDU messages from access switches toward the
primary vPC switch
27
vPC Peer Switch
STP Root STP Root
VLAN 1 STP Root
VLAN 1
VLAN 2 VLAN 2
Bridge Priority Bridge Priority

VLAN 1 à 4K VLAN 1 à 8K
vPC Primary vPC Secondary
VLAN Priority
Bridge 2 à 8K VLAN
Bridge2 Priority
à 4K
VLAN 1 à 4K vPC Peer-link VLAN 1 à 4K
VLAN 2 à 4K S1 S2 VLAN 2 à 4K
Nexus 7000(config-vpc-domain)# peer-switch

vPC1 vPC2
No STP Topology Changes
S3 S4
vPC peer-switch feature allows a pair of vPC peer devices to appear as a single STP Root in the
L2 topology (same bridge-id)
Simplifies STP configuration by configuring both vPC with the same STP priority
Eliminates recommendation to pin STP Root to the vPC primary switch.
Improves convergence during vPC primary switch failure/recovery avoiding Rapid-STP Sync
Supports a hybrid topology of vPC and non-vPC connections by using the spanning-tree pseudo-
information
Recommended for Pure VPC topologies 28
vPC Peer Gateway RMAC A RMAC B
L3
§  Allows a vPC switch to act as the active vPC PKL
L2
gateway for packets addressed to the peer
router MAC vPC PL
§  Keeps forwarding of traffic local to the vPC

node and avoids use of the peer-link. vPC vPC
1 2
§  No impact on traffic and existing functionality
§  Allows Interoperability with features of some
NAS or load-balancer devices.
Best Practice to enable this Feature
N7k(config-vpc-domain)# peer-gateway
Find more technical info at:

http://www.cisco.com/en/US/docs/switches/datacenter/sw/4_2/nx-os/interfaces/configuration/guide/if_vPC.html#wp1558675
NX-OS
Orphan-Port Suspend
N7K - 5.2
N5K - 5.0(3) N2
Primary Secondary
§  A vPC orphan port is an non-vPC interface on a switch where other

ports in the same VLAN are configured as vPC interfaces
§  vPC orphan ports have historically been problematic for vPC
mixed server topologies
§  Prior to release 5.0(3)N2 on Nexus 5000/5500 and 5.2 on Nexus 7000
an orphan port was ‘not’ shut down on loss of vPC peer-links
§  With the supported release the orphan ports on the vPC secondary
peer can (configurable) also be shut down triggering NIC teaming
recovery for all teaming configurations
§  Configuration is applied to the physical port*
N5K-2(config)# int eth 100/1/1

N5K-2(config-if)# vpc orphan-port suspend eth 100/1/1
vPC Supported
Server fails over Active/Standby
Server does not fail
correctly
over correctly since
* prior to 6.1.2 release, ‘VPC orphan-port suspend’ command may not work with FEX interface for orphan port is still
a FEX connected to N7K due to CSCua35190 active
30
Catalyst Virtual Switching
System (VSS)
31
Catalyst Virtual Switching System
Topology Comparisons
Traditional VSS - Physical VSS - Logical

HSRP or
VRRP
LACP
or PAGP
VSL
STP or LACP or MEC

MST PAGP
Access Switch Access Switch Access Switch Access Switch Access Switch
Stack
Access Switch
Stack Stack
Benefits of Virtual Switching

Simplify Operations by Eliminating STP, FHRP and Multiple Touch-Points
Double Bandwidth & Reduce Latency with Active-Active Multi-chassis EtherChannel (MEC)
Minimizes Convergence with Sub-second Stateful

32 and Graceful© 2016
Recovery (SSO/NSF)
Cisco and/or its affiliates. All rights reserved. Cisco Public 32
Catalyst Virtual Switching System
Simplified Campus Architecture
§  Simple and Scalable Network Design

•  Centralized and Redundant System Architecture
•  Single Unified Management Per Layer
•  Multi-Terabit Distributed Switching Capacity
§  Deterministic Network Performance

•  Inter-Chassis System and Network-level Redundancy
•  Protocol and Scale Independent Resiliency
§  Supported Catalyst Platforms:

•  C6807-XL – Sup2T or Sup6T
•  C6880-X or C6840-X
•  C6500-E – Sup2T or Sup720
•  C4500-E – Sup7E or Sup8E
•  C4500-X
© 2016 Cisco and/or its affiliates. All rights reserved. Cisco Public 33
VSS Architecture
VSS Architecture
Key Concepts
Catalyst Switch that operates as the Defines 2 Catalyst Switches that participate together
Active Control Plane for the VSS as a Virtual Switching System (VSS)
Virtual Switch Domain

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

Virtual Switch Link
Active Data Plane Active Data Plane
Special 10GE Port-Channel joins two Catalyst Switches Catalyst Switch that operates as the
allowing them to operate as a single logical device Hot Standby Control Plane for the VSS
VSS Architecture
Virtual Switch Link (VSL)
The Virtual Switch Link (VSL) joins two physical chassis together
The VSL provides a control-plane interface to keep both chassis in sync
The VSS “control-plane” uses the VSL for CPU to CPU communications (programming, statistics, etc.) while the “data-plane” uses the VSL
to extend the internal chassis fabric to the remote chassis.
A Virtual Switch Link (VSL) Port-Channel can consist

of up to 8 x 10GE (or 4 x 40GE) members
Virtual Switch Link
Switch 1 Switch 2
VS Header L2 Hdr L3 Hdr DATA CRC
All traffic traversing the VSL is encapsulated in a 32 byte “Virtual Switch

Header” containing Ingress and Egress Port Index, Class of Service (CoS),
VLAN ID, other important information from the Layer 2 and Layer 3 header
VSS Architecture For Your
Information
Building the Virtual Switch Link
Virtual Switch Link

Control Link
Switch 1 Data Links Switch 2

Port Channel 1 Port Channel 2
Just as other Port Channels, one link is selected as a “Control Link”,

for the purpose of transmitting BPDUs and Port Channel status.
interface Port-channel1 interface Port-channel2

no switchport
no ip address
The VSL Port-Channel can no switchport
no ip address
switch virtual link 1
mls qos trust cos
consist of up to 8 x 10GE switch virtual link 2
no mls qos channel-consistency (or 4 x 40GE) member ports mls qos trust cos
no mls qos channel-consistency
VSS Architecture
Load-Balancing for MEC & ECMP
The PFC / DFC hash logic used for MEC and ECMP load-balancing
(to determine the physical port to use) is skewed to always favor LOCAL links!
This avoids overloading the Virtual Switch Link (VSL) with unnecessary traffic loads…
Logical Physical Result Bundle Hash Logical Physical Result Bundle Hash
Interface Interface (RBH) Value Interface Interface (RBH) Value
PO 10 T 1/1/1 0,1,2,3,4,5,6,7 PO 10 T 1/1/1

PO 10 T2/1/1 PO 10 T2/1/1 0,1,2,3,4,5,6,7
VSS
Blue Traffic destined for Orange Traffic destined for
the Neighbor will result in the Neighbor will result in
Link 1 being chosen Link 2 being chosen
Link 1 Link 2
VSS Architecture
EtherChannel Hash
An IOS command can be used to determine which physical link in the MEC will be used
It can use various hash inputs to yield an 8-bucket RBH value that will correspond to one of the ports
VSS
VSS# show etherchannel load-balance hash-result interface port-channel 10 switch 1 ip 10.1.1.1 20.1.1.1
Computed RBH: 0x4

Would select Gi2/2/1 of Po10
When using VSS it is important to add switch <#> with the hash result command,
if not the CLI assumes switch 1 when commuting hash results.
VSS Enabled Campus Design
Unicast ECMP Traffic Flows
•  ECMP forwarding also favors locally attached interfaces

T1/2/1 T1/2/2
•  FIB first inserts entries for ECMP routes using local links
•  If all local links fail, the FIB is programmed to forward across
the VSL (to remote links)
VSS
6500-vss# show ip route 10.121.0.0 255.255.128.0 longer-prefixes

D 10.121.0.0/17
[90/3328] via 10.122.0.33, 2d10h, TenGigabitEthernet2/2/1
[90/3328] via 10.122.0.27, 2d10h, TenGigabitEthernet1/2/1 Four ECMP
[90/3328] via 10.122.0.22, 2d10h, TenGigabitEthernet2/2/2 Entries
[90/3328] via 10.122.0.20, 2d10h, TenGigabitEthernet1/2/2
6500-vss# show mls cef 10.121.0.0 17 switch 1
Codes: decap - Decapsulation, + - Push Label

Index Prefix Adjacency
102400 10.121.0.0/17 Te1/2/2 , 0012.da67.7e40 (Hash: 0001)
Te1/2/1 , 0018.b966.e988 (Hash: 0002) Two FIB Entries
Virtual Switching System
Dual-Attach Whenever Possible
§  Dual-Attach connect to neighbor

devices whenever its possible!
§  EtherChannel and CEF load-balancing
algorithms have been modified for VSS to
always favor locally attached interfaces
§  With a Dual-Attached VSS design
§  Data traffic will not traverse the VSL under

normal conditions, only control-plane traffic
will traverse the VSL
§  Data traffic will traverse the VSL only if there

is a failure event, and no local interfaces are
available
Dual-Active Scenarios
High Availability
Dual-Active Detection
All neighbors view a “VSS” as a

single Entity, single MAC, single IP!
What happens if the VSL is broken?
“Dual-Active” is VERY UNLIKEY,

because the VSL should always be
deployed as a multi-link Port Channel VSL
However… IT IS POSSIBLE! L
Recommend to deploy the VSL with 2 or more links, distributed across multiple Cards to ensure the highest redundancy
High Availability
If the entire VSL bundle fails, the VSS Domain will enter
into a “Dual Active” scenario
Both switches transition to SSO Active state, and share
the same network configuration
•  IP address, MAC address, Router ID, etc.
This can cause communication problems in the network!
3 Step Process
VSL
1 Dual-Active Detection - using any detection method

enabled in the system.
2 Previous VSS Active shuts down ALL interfaces, and

enters “Recovery Mode”… to prevent further network disruption
3 Dual-Active Restoration - when the VSL recovers, the switch in

Recovery Mode will reload to boot to the VSS Standby state
High Availability
Dual-Active Protocols
Enhanced PAGP VSLP Fast Hello Instant Access (FEX)
VSLP VSLP
Switch 1 Switch 2 Switch 1 Switch 2 Switch 1 Switch 2
Active Standby Active Standby Active Standby
v  Requires ePAGP capable neighbor: v  Direct L2 Point-to-Point Connection v  Requires Dual-Home IA Client
v  3750: 12.2(46)SE v  Requires 12.2(33)SXI v  Only for C6500 / C6800
v  4500: 12.2(44)SE v  Requires 15.1(2)SY2
v  6500: 12.2(33)SXH1
v  Sub-Second Convergence v Sub-Second Convergence v Sub-Second Convergence

v  Typically ~200-250ms v  Typically ~50-100ms v Typically ~150-200ms
Detection Method – Fast Hello
%DUAL_ACTIVE-SW1_SP-1-DETECTION: Dual-active condition detected:

all non-VSL and non-excluded interfaces have been shut down
Port Channel
VSLP Fast Hello
VSS Active VSSStandby

VSS Active
VSL
Port Channel
Dual-Active
Recovery
%DUAL_ACTIVE-SW1_SP-1-DETECTION: Dual-active condition detected:

all non-VSL and non-excludedPort
interfaces
Channel have been shut down
VSLP Fast Hello
VSS Active
Recovery Mode VSS Active
Recovery Mode: Original VSS Active Port Channel

will admin shutdown ALL of it’s interfaces
and attempt to recover the VSL
Dual-Active
Restoration
Port Channel
VSLP Fast Hello
VSS Standby
Recovery Mode VSS Active
VSL
Chassis
Reload
Port Channel
VSS High Availability
Recommendations:
§  Enable multiple methods of VSS
Dual-Active Detection:
ePAgP
§  FEX MEC with ePAgP MEC
§  VSLP Fast Hello with FEX MEC Redundant
VSL Links
§  Connect multiple redundant VSL

links, to prevent Dual-Active VSLP
Fast-Hello
§  Enable ePAgP to Core-layer FEX

(if the Access-layer is not ePAgP
or FEX capable)
VSS High Availability
High Availability
Redundancy Schemes
The default redundancy mechanism between for VSS is SSO
Switch 1 Switch 2
15.1(2)SY4 15.1(2)SY4
Active SSO Standby
If a mismatch of occurs between the Active & Standby, the Standby will revert to RPR mode
Switch 1 Switch 2
15.1(1)SY1 15.1(2)SY4
Active RPR Standby
VSS Supervisor
Redundancy
Virtual Switching System
Inter Chassis SSO/NSF
The original Standby Supervisor now takes

2 over as the new Virtual Switch Active
Virtual Switch initiates Graceful Restart (NSF)
Non Stop Forwarding of packets continues

using hardware entries synched to Switch 2
Virtual Switch Active Virtual Switch Hot Standby
NSF Aware neighbors exchange protocol
updates with the new Virtual Switch Active
Switch 1 Switch 2
Switch Is Down Virtual Switch Active
Virtual Switch incurs a failure of the

1 (SSO) Active Supervisor in Switch 1
The Standby Supervisor detects failure

by loss of all VSL ports, or no replies to
SSO keep-alive packets Switch 1 Switch 2
VSS Quad Supervisor Support
Why Are Redundant Supervisors Needed?
1.  A Supervisor failure will decrease
available VSS bandwidth by 50%
2.  Some devices may be single-attach
to the VSS (for whatever reasons)
•  Single NIC Servers, AP’s, Phones, Cameras
•  Service Modules in Local VSS chassis
•  Geographic Separation of VSS chassis
3.  Recovery requires manual intervention

•  Failed Supervisor requires onsite hardware removal
•  Replacement Supervisor requires hardware installation
•  Replacement Supervisor requires software installation
•  Replacement Supervisor requires copy of VSS config
•  Non-Deterministic Outage Time!!!
VSS Single Supervisor
Normal Operation & SSO Redundancy
100%
Bandwidth
Available
50%
Time
Control Plane Active Control Plane Standby

Data Plane Active Data Plane Active
VSS Single Sup Operation
Supervisor Failure Example
100%
Bandwidth
Available
50%
Time
Control Plane Active Control

Control Plane
Plane Standby
Active
Data Plane Active
VSS Single Sup Operation
Supervisor Failure - Manual Repair Example
100%
•  Lose 50% Bandwidth until Repair L
Bandwidth
Available
•  Non-Deterministic Recover Time

50%
Time
•  100% Impact to Single-Attach Devices
Control Plane Standby Control Plane Active

Quad-Sup Uplink Forwarding S720-10G
12.2(33)SXI4
VSS Supervisor Redundancy
100%
Bandwidth
Available
50%
Time
Control Plane Active Control Plane Standby

Control Plane RPR-Warm Control Plane RPR-Warm

Quad-Sup Uplink Forwarding S720-10G
12.2(33)SXI4
For Your
Information
VSS Supervisor Redundancy
100% •  Deterministic Outage Time (Reload)

Bandwidth
Available
50%
•  Automated Chassis & Link Recovery
Time
•  Minimize Outage for Single-Attach Devices
Reload
Control Plane Active PlaneStandby
ControlPlane
Control Active
Control Plane Standby
Control
DataPlane
PlaneRPR-Warm
Active Control Plane RPR-Warm
Reload Time 5 – 15 minutes
Quad-Sup SSO Sup2T & Sup6T
15.1(1)SY1 / 15.3(1)SY
Standby-HOT Redundancy Mode
VSS Switch 1 VSS Switch 2

(SSO – Active) (SSO – Hot Standby)
In-Chassis Active In-Chassis Active
In-Chassis Standby In-Chassis Standby

(Standby Hot (Standby Hot
(Chassis)) (Chassis))
STANDBY HOT (CHASSIS) is a new redundancy mode created for the VSS ICS Supervisor
STANDBY HOT (CHASSIS) mode allows each ICS Supervisor to operate in a separate SSO (RF/CF) Domain, while still also
maintaining the traditional (default) RF/CF Domain between VSS chassis.
The ICS PFC, Switch Fabric and all 1G & 10G uplink ports are Operational and Forwarding
VSS Supervisor Redundancy Sup2T & Sup6T
15.1(1)SY1 / 15.3(1)SY
Sup2T Quad-Sup SSO
100% •  SSO Sub-Second Outage J

Bandwidth
Available
50%
•  Automated Chassis Recovery
50ms – 250ms
•  No Flap for Single-Attach Devices
Time
ControlPlane
Control PlaneStandby
Active
Control Plane Active
Data Plane
Data Plane Active
Active
Data Plane Active
Control Plane Standby

Standby Control Plane Standby
Data(Chassis)
Plane Active (Chassis)
Line Card Data-Plane Sup2T & Sup6T
15.1(1)SY1 / 15.3(1)SY
Redundancy Dependencies (Local Switching)
•  Traffic between ports on the

Same Line Card (e.g. T2/1/1
& T2/1/2) will NOT be affected
by Supervisor SSO events…
T2/1/1
WS-X6908-10G
•  No Card or Port Flaps T2/1/2 WS-X6908-10G
•  ICS SSO Synch of Infrastructure WS-X6848-SFP

WS-X6848-SFP
•  OIR, PM, FM, LTL/FPOE, etc Sup2T
SSO
Sup2T
•  No Packet Loss
•  Local Switching Hardware (DFC4)
•  ICS SSO Synch of L2/L3
•  FIB/ADJ, MAC, Protocol FSM, etc
VSS Switch ID 2
Line Card Data-Plane Sup2T & Sup6T
15.1(1)SY1 / 15.3(1)SY
Redundancy Dependencies (Cross Fabric)
•  Traffic between ports that are on

Different Line Cards (e.g. T2/1/1
& T2/2/1) WILL be affected by
Supervisor SSO events…
T2/1/1
WS-X6908-10G
•  No Card or Port Flaps T2/2/1
WS-X6908-10G
WS-X6848-SFP
ICS SSO Synch of Infrastructure WS-X6848-SFP

Sup2T
SSO
•  50-200ms of Packet Loss
Sup2T
ICS SSO Synch of L2/L3

Loss Time = Active à Standby Fabric
Switch-Over & Channel Initialization
New Cards support HW Notification VSS Switch ID 2
VSS Supervisor Redundancy Comparison For Your
Information
§  Quad-Sup SSO

100%
§  1:1 (active/standby) Supervisor Redundancy for
Bandwidth
single and dual attached devices
Available
-  Automated recovery from Supervisor failure 50%
50ms – 200ms
-  SSO switchover is typically 50ms – 200ms
Time
§  Quad-Sup Uplink Forwarding

100%
-  1+1 (active/active) Supervisor Redundancy for dual
Bandwidth
attached devices
Available
-  Automated recovery from Supervisor failure 50%
-  Deterministic outage duration for single attached

devices Time
§  Single Supervisor (Dual Sup)

-  1+1 (active/active) Supervisor Redundancy for dual 100%
attached devices Bandwidth
Available
-  Requires manual Supervisor replacement 50%

-  Non-deterministic outage duration for single
attached devices
Time
VSS Quad-Sup SSO
Best Practices
•  Always use at least one uplink from each Supervisor as part of the VSL
•  Consider using ALL of the Supervisor uplink ports in the VSL (4 per chassis)
•  If you use all 4 Supervisor uplinks, then “Swap the 5s” or “Swap the 4s” in order to
maintain 20Gbps VSL, even during a Supervisor fail event or reload event
•  Connect uplink and downlink on local Line Cards (if possible), this will minimize traffic
disruption across Supervisor switchover event
•  Must explicitly configure NSF (or NSR if supported) for each routing protocol, to provide
minimum disruption to L3 routed interfaces
•  Use DFC enabled linecards with 512MB of available memory in order to minimize Line
Card reload time during EFSU (warm-reload)
•  Be sure to copy the system image file to all Supervisor file systems in the same location
VSS Deployment Best Practices
DO J
ü  Use a unique Domain ID for multiple VSS in the same network!
ü  Save backup config file to all Supervisor file systems!

In the same location, for example: Switch 1 & Switch 2 bootdisk:
ü  Use a minimum of 1 Supervisor uplink port for the VSL!

This provides for faster VSL bring up
ü  Dual-home connected devices whenever possible!

Use L2 or L3 Multi-Chassis Etherchannel or L3 ECMP
ü  Enable ePAgP and/or VSLP Fast Hello Dual-Active Detection!
ü  Enable NSF or NSR if you use L3 Routing protocols!
ü  Use “virtual mac-address for VSS

VSS Deployment Best Practices
DO NOT L
×  Do NOT Tune VSLP timers!
(unless instructed to do so by Cisco)
×  Do NOT Use VSS preemption!

Preemption has been removed from SXJ and SY release trains
×  Do NOT issue “shutdown” on VSL port-channel interface!
This creates a config mismatch. If you want to test dual-active detection,
simply unplug the VSL cables. That will create a realistic failure scenario
without causing the configurations to get out of sync.
×  Do Not Change VSL hashing algorithm, in production!

This requires a shut / no shut on of the VSL port-channel (see above).
Shutting down VSL will cause traffic disruption and dual-active scenario.
Summary
Please Complete Your Session Evaluation
69
Thank you
Presentation ID © 2016 Cisco and/or its affiliates. All rights reserved. Cisco Public 70
We’re ready. Are you?
VSS Hardware and
Software Requirements
VSS is supported on Catalyst 6500, 6800, 4500-E and 4500-X
6500-E / 6807-XL 6880-X / 6840-X 4500-E 4500-X
Supervisors Sup6T, Fixed (Based on Sup2T) Sup7E, Sup7LE Fixed (based on Sup7E)
Sup2T, Sup8E, Sup8LE
Sup720-10G
Software Trains Sup6T – 15.3(1)SY 6880-X - 15.2(1)SY, 3.8.0E 3.8.0E

Sup2T – 15.2(1)SY, 15.1(1)SY 3.7.0E 3.7.0E
15.1SY, 15.0SY 6840-X – 15.2(2)SY 3.6.0E 3.6.0E
Sup720 – 15.1(2)SY, 3.5.0E 3.5.0E
12.2SXJ,12.2SXI 3.4.0SG 3.4.0SG
15.1(2)SG
Mixed / Asymmetric Yes Yes Yes No
Chassis Support *after release 3.5.0E must use the same
model, 16-port or 32-port
Quad-Sup SSO Sup6T – 15.3(1)SY N/A No N/A
Sup2T – 15.1(1)SY1
Quad-Sup RPR Sup720 –12.2(33)SXI4 N/A Yes N/A
(Uplink Forwarding) *after release 3.8.0E
VSS Requirements
Catalyst 6500 and 6800 VSS Support
Catalyst 6500 Series Catalyst 6800 Series
VSS Requirements
Catalyst 6500 and 6800 VSS Support Matrix
Hardware Chassis Supervisor Modules

Catalyst 6500 C6503-E VS-S720-10G C6800-48P-SFP WS-X6748-SFP/TX
C6504-E VS-S2T-10G C6800-48P-TX WS-X6848-SFP/TX
C6506-E C6800-8P10G WS-X6716-10G/T
C6509-E C6800-16P10G WS-X6816-10G/T
C6513-E C6800-32P10G WS-X6908-10G
WS-X6904-40G
Catalyst 6800 C6807-XL VS-S2T-10G C6800-48P-SFP WS-X6748-SFP/TX
C6800-SUP6T C6800-48P-TX WS-X6848-SFP/TX
C6800-8P10G WS-X6716-10G/T
C6800-16P10G WS-X6816-10G/T
C6800-32P10G WS-X6908-10G
WS-X6904-40G
C6880-X N/A C6880-X-16P10G
C6880-X-LE C6880-X-LE-16P10G
C6816-X-LE N/A N/A

C6832-X-LE
C6824-X-LE-40G
C6840-X-LE-40G Current 6700, 6800 and 6900 series modules are VSL capable
Legacy 6100 to 6500 series modules are not supported
VSS Requirements
Catalyst 4500-E and 4500-X VSS Support
Catalyst 4500-E Series Catalyst 4500-X Series
VSS Requirements
Catalyst 4500-E and 4500-X VSS Support Matrix
Hardware Chassis Supervisor Modules
Catalyst 4500-E 4503+E Sup7-E WS-X4712-SFP+E WS-X4606-X2-E

4506+E Sup7-LE WS-X4748-12X48U WS-X4648-RJ45V-E
4507+E Sup8-E WS-X4748-RJ45+V WS-X4648-RJ45V+E
4510R+E WS-X4748-UPOE+E WS-X4648-RJ45-E
WS-X4748-RJ45-E WS-X4640-CSFP-E
WS-X4624-SFP-E
WS-X4612-SFP-E
Catalyst 4500-X WS-C4500X-32SFP+ N/A C4KX-NM-8SFP+

WS-C4500X-F-32SFP+
WS-C4500X16SFP+
WS-C4500X-F-16SFP+
WS-C4500X-24X-IPB
WS-C4500X-40X-ES
WS-C4500X-24X-ES
Current 4600 and 4700 series modules are VSL capable
Legacy 4500 and 4200 series modules are not supported
Reference Paper for VSS Quad Sup SSO
White Paper describes VSS Quad Sup SSO

benefits, architecture and migration steps
http://www.cisco.com/en/US/prod/collateral/switches/ps5718/
ps708/white_paper_c11-729039.html

Simplifyingnetworksusingvpcandvss 160329194358

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Simplifyingnetworksusingvpcandvss 160329194358

Enviado por

Direitos autorais:

Formatos disponíveis

Simplifying Switched

! Check the feature status

One of a pair of switches that makes

§ vPC peers function as independent devices as well as peers

Regular (non vPC)

dc11-4948-2#sh lacp neighbor

Regular (non vPC)

§ Primary & Secondary

§ Role is non-preemptive

Primary (but may be

§ Standard 802.1Q Trunk which carries

Recommendations (strong ones!)

NEXUS 7000 NEXUS 5000/5500

§ CFS - Cisco Fabric Services protocol, used for state

§ Orphan Device – An orphan device is a device

§ Both switches in the vPC Domain maintain distinct control

§ System configuration must also be kept in sync

2 3 3 MAC B is not known by right switch à flood

4 B receives duplicate frames

5 MAC A will be learned on wrong port on the lower access switch à

Frames received on Peer-Link

1 MAC B is not known by left switch à flood

This rule (called ‘VPC check’) stands for all traffic

vPC peer-link failure (link loss):

(heartbeat) vPC1 vPC2

§ If both peers are active, then Secondary vPC

§ Orphan devices connected to secondary

In rare cases , when both VPC PKL link & PL comes

à In a functional VPC system - Only the operational primary switch

§ Loop detection (failsafe to vPC)

§ Non-vPC attached device

§ Loop management on vPC addition/removal

• STP for vPCs is controlled by the vPC operationally

• The vPC operationally secondary device proxies STP

Bridge Priority Bridge Priority

Nexus 7000(config-vpc-domain)# peer-switch

§ Keeps forwarding of traffic local to the vPC

Find more technical info at:

§ A vPC orphan port is an non-vPC interface on a switch where other

N5K-2(config)# int eth 100/1/1

Traditional VSS - Physical VSS - Logical

STP or LACP or MEC

Benefits of Virtual Switching

Minimizes Convergence with Sub-second Stateful

§ Simple and Scalable Network Design

§ Deterministic Network Performance

§ Supported Catalyst Platforms:

Virtual Switch Domain

Active Control Plane Hot Standby Control Plane

A Virtual Switch Link (VSL) Port-Channel can consist

Virtual Switch Link

All traffic traversing the VSL is encapsulated in a 32 byte “Virtual Switch

Building the Virtual Switch Link

Virtual Switch Link

Switch 1 Data Links Switch 2

Just as other Port Channels, one link is selected as a “Control Link”,

interface Port-channel1 interface Port-channel2

PO 10 T 1/1/1 0,1,2,3,4,5,6,7 PO 10 T 1/1/1

Computed RBH: 0x4

• ECMP forwarding also favors locally attached interfaces

6500-vss# show ip route 10.121.0.0 255.255.128.0 longer-prefixes

6500-vss# show mls cef 10.121.0.0 17 switch 1

Codes: decap - Decapsulation, + - Push Label

§  vPC peers function as independent devices as well as peers

§  Primary & Secondary

§  Role is non-preemptive

§  Standard 802.1Q Trunk which carries

§ CFS - Cisco Fabric Services protocol, used for state

§ Orphan Device – An orphan device is a device

§  Both switches in the vPC Domain maintain distinct control

§  System configuration must also be kept in sync

§  If both peers are active, then Secondary vPC

§  Orphan devices connected to secondary

§  Loop detection (failsafe to vPC)

§  Non-vPC attached device

§  Loop management on vPC addition/removal

•  STP for vPCs is controlled by the vPC operationally

•  The vPC operationally secondary device proxies STP

§  Keeps forwarding of traffic local to the vPC

§  A vPC orphan port is an non-vPC interface on a switch where other

§  Simple and Scalable Network Design

§  Deterministic Network Performance

§  Supported Catalyst Platforms:

•  ECMP forwarding also favors locally attached interfaces

§  Dual-Attach connect to neighbor

§  With a Dual-Attached VSS design

§  Data traffic will not traverse the VSL under

§  Data traffic will traverse the VSL only if there

v  Sub-Second Convergence v Sub-Second Convergence v Sub-Second Convergence

§  Connect multiple redundant VSL

§  Enable ePAgP to Core-layer FEX

3.  Recovery requires manual intervention

•  Non-Deterministic Recover Time

100% •  Deterministic Outage Time (Reload)

100% •  SSO Sub-Second Outage J

•  Traffic between ports on the

•  ICS SSO Synch of Infrastructure WS-X6848-SFP

•  Traffic between ports that are on

§  Quad-Sup SSO

§  Quad-Sup Uplink Forwarding

-  Deterministic outage duration for single attached

§  Single Supervisor (Dual Sup)

-  Requires manual Supervisor replacement 50%

ü  Save backup config file to all Supervisor file systems!

ü  Use a minimum of 1 Supervisor uplink port for the VSL!

ü  Dual-home connected devices whenever possible!

ü  Enable NSF or NSR if you use L3 Routing protocols!

ü  Use “virtual mac-address for VSS

×  Do NOT Use VSS preemption!

×  Do Not Change VSL hashing algorithm, in production!