Simplifying networks using vpc and vss

Ross Adams Systems Engineer

Simplifying Switched Networks vPC and VSS

© 2016 Cisco and/or its affiliates. All rights reserved. Cisco Public

In the Beginning…


And it was good…


Except When it Wasn’t…

Limited options for access redundancy

Complexity

Stranded bandwidth & slow convergence

XXXX

X

© 2016 Cisco and/or its affiliates. All rights reserved. Cisco Public Presentation ID

vPC & VSS

5


Virtual Path Channel (vPC)

6


MCEC

! 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

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

convergence upon link/device failure

•  Maintains independent control planes

7

MCEC

vPC Peers

vPC

vPC Overview MCEC Multi-Chassis EtherChannel


vPC Architecture


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-channel may be suspended (e.g. MTU mismatch)

•  Maximum number of active ports vary by platform.

9

vPC member

port

vPC vPC

member port

vPC vPC

member port

vPC member port - one of a set of ports (port channels) that form a vPC

vPC


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 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 Domains vPC Domains

vPC Domain


One of a pair of switches that makes up a vPC domain

11

vPC peer

vPC Peer


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 0x3D

7k_1 # sh vpc role <snip> vPC system-mac : 00:23:04:ee:be:14 vPC system-priority : 1024 vPC local system-mac : 00:0d:ec:a4:53:3c vPC local role-priority : 1024

§  vPC peers function as independent devices as well as peers

§  Local ‘system-mac’is used for all non vPC PDUs (LACP, STP, …)

MCEC (vPC) EtherChannel 5K_2

7K_1 7K_2

G1/4 G1/5 Regular (non vPC) Port Channel 1/1 1/2

dc11-4948--2

12

vPC local system-mac


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 0x3D

7K_2 # sh vpc role <snip> vPC system-mac : 00:23:04:ee:be:14 vPC system-priority : 1024 vPC local system-mac : 00:0d:ec:a4:5f:7c vPC local role-priority : 32667

7K_1# sh vpc role <snip> vPC system-mac : 00:23:04:ee:be:14 vPC system-priority : 1024 vPC local system-mac : 00:0d:ec:a4:53:3c vPC local role-priority : 1024

dc11-4948-1

§  LACP neighbor sees the same System ID from both vPC peers

§  The vPC ‘system-mac’ is used by both vPC peers

5K_2

7K_1 7K_2

1/4 1/5 Regular (non vPC) Port Channel 1/1 1/2

MCEC (vPC) EtherChannel

13

vPC system-mac


dc11-5020-3(config-vpc-domain)# role priority ? <1-65535> Specify priority value dc11-5020-3# sh vpc <snip> vPC role : secondary, operational primary

Secondary (but may be Operational Primary)

Primary (but may be Operational Secondary)

vPC Domain 20

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!

§  Role is non-preemptive

§  Operational role may differ from the priorities configured under the domain

14

vPC Roles


15

vPC peer-link §  Standard 802.1Q Trunk which carries ‒  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!) ‒  Minimum 2x 10GE ports (on modular switches: use 2 separate cards for best resiliency)

‒  10GE ports in dedicated mode (for oversubscribed modules)

vPC imposes the rule that the peer link should never be blocking !

Always use identical modules on either sides of the peer-link

vPC Peer-link


16

vPC peer-keepalive link

NEXUS 7000 NEXUS 5000/5500 1- Dedicated link(s) (1GE LC) 1- mgmt0 interface

(along with management traffic)

2- mgmt0 interface (along with management traffic)

2- Dedicated link(s) (1/10GE front panel ports)

3- As last resort, can be routed over L3 infrastructure

3 - As last resort, can be routed over L3 infrastructure

Recommendations (in order of preference):

§  Heartbeat between vPC peers

§  Active/Active detection (in case vPC Peer-Link is down)

§  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

vPC PKL messages should NOT be routed over the vPC

PL !

vPC Peer-Keepalive link

© 2016 Cisco and/or its affiliates. All rights reserved. Cisco Public 17

CFS protocol

§ CFS - Cisco Fabric Services protocol, used for state synchronization and configuration validation between vPC peer devices

§ 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 – An orphan port is a interface which connects to an orphan device

Orphan Port

Orphan Device

More vPC Terminology


18

§  Both switches in the vPC Domain maintain distinct control planes

§  CFS provides for protocol state sync between both peers (MAC Address table, IGMP state, …)

§  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

vPC Domain 20

vPC Domain 10

vPC Configuration Consistency


How vPC Works


x x

x

PC A ends a packet to PC B 1 MAC B is not known by left switch à flood 2 MAC B is not known by right switch à flood 3 B receives duplicate frames 4 MAC A will be learned on wrong port on the lower access switch à blackholing traffic to A

5

Frames received on Peer-Link must not be flooded out of VPCs

PC A

PC B

A ← 1

2 3

4

5 A ↑ x

Loop Avoidance


MAC B is not known by left switch à flood 1 Frames received from Peer-Link are never sent out of VPC (except those without operational ports on ingress switch) Egress port ASICs will drop the frame

Frame is still flooded to devices that are solely connected to egress switch

3

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)

1

3

2 2

PC A

PC B

vPC Forwarding


√ √ X √ x

Summary: vPC Forwarding


Design Considerations & Best Practices


SW3 SW4

vPC1 vPC2

vPC_PLink

vPC Peer-keepalive

24

Keepalive Heartbeat

Secondary vPC

P S

S

P Primary vPC

Suspend secondary vPC Member Ports

vPC peer-link failure (link loss): §  Failover gated on CFS message failure §  VPC system checks active status of the

remote vPC peer via peer-keepalive link (heartbeat)

§  If both peers are active, then Secondary vPC peer will disable all vPCs to avoid Dual-Active

§  Data will automatically forward down remaining active port channel ports

§  Orphan devices connected to secondary peer will be isolated

vPC Failure Scenario vPC Peer-link Down


SW3 SW4

vPC1 vPC2

vPC_PLink

vPC Peer-keepalive

25

Secondary vPC

P S

S

P Primary vPC

In rare cases , when both VPC PKL link & PL comes down (in this order) à it may result into Dual-Active situation

§  VPC Peer-Keepalive comes down à VPC still functional

§  VPC Peer-Link comes down but both peers are active

à Peers have no way to detect if other peer is still active

§  Primary Peer remains primary and secondary peer takes over the operational primary role

§  This results in dual-active scenario and can result in traffic loss / uncertain traffic behavior

§  When links are restored, the operational primary (former secondary) keeps the primary role & former primary becomes operational secondary

à 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

P

Traffic Loss / Uncertain Traffic Behavior

vPC Failure Scenario Dual Active


26

STP is running to manage loops outside of vPC domain,

or before initial vPC configuration !

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

§  Logical ports still count

Best Practices:

§  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

Spanning Tree Interoperability


•  STP for vPCs is controlled by the vPC operationally primary switch and only such device sends out BPDUs on STP designated ports

•  •  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

BPD

Us

Primary vPC

Secondary vPC

BPDUs

STP with vPC (Default)


28

vPC Peer-link S1 S2

S3 S4

vPC Primary vPC Secondary

vPC1

Bridge Priority VLAN 1 à 4K VLAN 2 à 8K


STP Root VLAN 1 STP Root

VLAN 2

No STP Topology Changes



STP Root VLAN 1 VLAN 2

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

vPC2

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

vPC Peer Switch


vPC PL

vPC PKL

L3 L2

N7k(config-vpc-domain)# peer-gateway

RMAC A RMAC B

vPC1

vPC2

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

§  Allows a vPC switch to act as the active gateway for packets addressed to the peer router MAC

§  Keeps forwarding of traffic local to the vPC node and avoids use of the peer-link.

§  No impact on traffic and existing functionality

§  Allows Interoperability with features of some NAS or load-balancer devices.

Best Practice to enable this Feature

vPC Peer Gateway


vPC Supported Server fails over

correctly Active/Standby

Server does not fail over correctly since orphan port is still

active

vPC

30

N5K-2(config)# int eth 100/1/1 N5K-2(config-if)# vpc orphan-port suspend

NX-OS N7K - 5.2 N5K - 5.0(3) N2

eth 100/1/1

§  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 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*

* prior to 6.1.2 release, ‘VPC orphan-port suspend’ command may not work with FEX interface for a FEX connected to N7K due to CSCua35190

Primary Secondary

Orphan-Port Suspend


Catalyst Virtual Switching System (VSS)

31


Catalyst Virtual Switching System Topology Comparisons

32 32

Simplify Operations by Eliminating STP, FHRP and Multiple Touch-Points

Minimizes Convergence with Sub-second Stateful and Graceful Recovery (SSO/NSF)

Double Bandwidth & Reduce Latency with Active-Active Multi-chassis EtherChannel (MEC)

Benefits of Virtual Switching

Traditional

Access Switch

LACP or PAGP

STP or MST

HSRP or VRRP

Access Switch Stack

VSS - Physical

LACP or PAGP

VSL

Access Switch Access Switch Stack

VSS - Logical

Access Switch Stack

Access Switch

MEC


Catalyst Virtual Switching System Simplified Campus Architecture

33

§  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


VSS Architecture


VSS Architecture Key Concepts

35

Virtual Switch Domain

Virtual Switch Link

Special 10GE Port-Channel joins two Catalyst Switches allowing them to operate as a single logical device

Virtual Switch 1 Virtual Switch 2

Catalyst Switch that operates as the Hot Standby Control Plane for the VSS

Defines 2 Catalyst Switches that participate together as a Virtual Switching System (VSS)

Catalyst Switch that operates as the Active Control Plane for the VSS

Active Control Plane

Active Data Plane

Hot Standby Control Plane

Active Data Plane


VSS Architecture Virtual Switch Link (VSL)

36

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

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

Virtual Switch Link

VS Header L2 Hdr L3 Hdr DATA CRC

Switch 1 Switch 2


VSS Architecture Building the Virtual Switch Link

interface Port-channel1 no switchport no ip address switch virtual link 1 mls qos trust cos no mls qos channel-consistency

Port Channel 1 Port Channel 2

Control Link

Data Links

Virtual Switch Link

Switch 1 Switch 2

interface Port-channel2 no switchport no ip address switch virtual link 2 mls qos trust cos no mls qos channel-consistency

Just as other Port Channels, one link is selected as a “Control Link”, for the purpose of transmitting BPDUs and Port Channel status.

The VSL Port-Channel can consist of up to 8 x 10GE

(or 4 x 40GE) member ports

For Your Information

37


VSS

VSS Architecture Load-Balancing for MEC & ECMP

38

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…

Link 1 Link 2

Blue Traffic destined for the Neighbor will result in

Link 1 being chosen

Orange Traffic destined for the Neighbor will result in

Link 2 being chosen

Logical Interface

Physical Interface

Result Bundle Hash (RBH) Value

PO 10 T 1/1/1

PO 10 T2/1/1

Logical Interface

Physical Interface

Result Bundle Hash (RBH) Value

PO 10 T 1/1/1

PO 10 T2/1/1

0,1,2,3,4,5,6,7 0,1,2,3,4,5,6,7


VSS Architecture EtherChannel Hash

39

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

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

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


VSS Enabled Campus Design Unicast ECMP Traffic Flows

40

•  ECMP forwarding also favors locally attached interfaces

•  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)

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 [90/3328] via 10.122.0.22, 2d10h, TenGigabitEthernet2/2/2 [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)

Four ECMP Entries

Two FIB Entries

T1/2/1 T1/2/2

VSS

40


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

41


Dual-Active Scenarios

42


High Availability Dual-Active Detection

43

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

However… IT IS POSSIBLE! L

Recommend to deploy the VSL with 2 or more links, distributed across multiple Cards to ensure the highest redundancy

VSL


High Availability Dual-Active Detection

44

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 Dual-Active Detection - using any detection method enabled in the system. 1 Previous VSS Active shuts down ALL interfaces, and enters “Recovery Mode”… to prevent further network disruption 2 Dual-Active Restoration - when the VSL recovers, the switch in Recovery Mode will reload to boot to the VSS Standby state 3

VSL


Standby Active Switch 1 Switch 2

Enhanced PAGP Instant Access (FEX)

VSLP

VSLP Fast Hello

v  Requires ePAGP capable neighbor: v  3750: 12.2(46)SE v  4500: 12.2(44)SE v  6500: 12.2(33)SXH1

v Direct L2 Point-to-Point Connection v  Requires 12.2(33)SXI

v  Requires Dual-Home IA Client v  Only for C6500 / C6800 v  Requires 15.1(2)SY2

v  Sub-Second Convergence v  Typically ~200-250ms

v Sub-Second Convergence v  Typically ~50-100ms

v Sub-Second Convergence v Typically ~150-200ms

High Availability Dual-Active Protocols

45


VSLP



Dual-Active Detection Detection Method – Fast Hello

46

VSS Active VSS Standby VSS Active

Port Channel

Port Channel

VSL

%DUAL_ACTIVE-SW1_SP-1-DETECTION: Dual-active condition detected: all non-VSL and non-excluded interfaces have been shut down

VSLP Fast Hello


Dual-Active Recovery

VSS Active VSS Active

Port Channel

Port Channel %DUAL_ACTIVE-SW1_SP-1-DETECTION: Dual-active condition detected:

all non-VSL and non-excluded interfaces have been shut down

VSLP Fast Hello

Recovery Mode

Recovery Mode: Original VSS Active will admin shutdown ALL of it’s interfaces

and attempt to recover the VSL

47


Dual-Active Restoration

VSS Active

Port Channel

Port Channel

VSLP Fast Hello

Recovery Mode VSL

Chassis Reload

VSS Standby

48


VSS High Availability Dual-Active Detection

VSLP Fast-Hello

Redundant VSL Links

ePAgP

FEX

Recommendations: §  Enable multiple methods of VSS

Dual-Active Detection: §  FEX MEC with ePAgP MEC §  VSLP Fast Hello with FEX MEC

§  Connect multiple redundant VSL links, to prevent Dual-Active

§  Enable ePAgP to Core-layer (if the Access-layer is not ePAgP or FEX capable)

49


VSS High Availability

50


High Availability Redundancy Schemes

51

The default redundancy mechanism between for VSS is SSO

If a mismatch of occurs between the Active & Standby, the Standby will revert to RPR mode

Switch 1 15.1(2)SY4

Switch 2 15.1(2)SY4

Switch 1 15.1(1)SY1

Switch 2 15.1(2)SY4

Active Standby

RPR

SSO

Active Standby


VSS Supervisor Redundancy

52


Virtual Switch Hot Standby Virtual Switch Active

Virtual Switch incurs a failure of the (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

1

2 The original Standby Supervisor now takes 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 NSF Aware neighbors exchange protocol updates with the new Virtual Switch Active

Switch 1 Switch 2

Virtual Switching System Inter Chassis SSO/NSF

53

Switch 1 Switch 2

Switch Is Down Virtual Switch Active


VSS Quad Supervisor Support

54

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!!!

Why Are Redundant Supervisors Needed?


Control Plane Standby Data Plane Active

VSS Single Supervisor Normal Operation & SSO Redundancy

55

Control Plane Active Data Plane Active

100%

50%

Avai

labl

e B

andw

idth

Time


VSS Single Sup Operation Supervisor Failure Example

56


100%

50%

Avai

labl

e B

andw

idth

Time




VSS Single Sup Operation Supervisor Failure - Manual Repair Example

57

•  Lose 50% Bandwidth until Repair L •  Non-Deterministic Recover Time

•  100% Impact to Single-Attach Devices


100%

50%

Avai

labl

e B

andw

idth

Time



Quad-Sup Uplink Forwarding VSS Supervisor Redundancy

100%

50%

Avai

labl

e B

andw

idth

Time

Control Plane RPR-Warm Data Plane Active




58

S720-10G 12.2(33)SXI4


Quad-Sup Uplink Forwarding VSS Supervisor Redundancy

•  Deterministic Outage Time (Reload)

•  Automated Chassis & Link Recovery

•  Minimize Outage for Single-Attach Devices



Reload





100%

50%

Avai

labl

e B

andw

idth

Time

Reload Time 5 – 15 minutes


59

S720-10G 12.2(33)SXI4

© 2016 Cisco and/or its affiliates. All rights reserved. Cisco Public 60

VSS Switch 1 (SSO – Active)

In-Chassis Active

In-Chassis Standby (Standby Hot

(Chassis))

In-Chassis Standby (Standby Hot

(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 Switch 2 (SSO – Hot Standby) In-Chassis Active

Quad-Sup SSO Standby-HOT Redundancy Mode

Sup2T & Sup6T 15.1(1)SY1 / 15.3(1)SY


VSS Supervisor Redundancy Sup2T Quad-Sup SSO

•  SSO Sub-Second Outage J •  Automated Chassis Recovery •  No Flap for Single-Attach Devices

Control Plane Standby (Chassis)

Data Plane Active



Control Plane Standby (Chassis)

Data Plane Active



100%

50%

Avai

labl

e B

andw

idth

Time

50ms – 250ms

61

Sup2T & Sup6T 15.1(1)SY1 / 15.3(1)SY


Line Card Data-Plane 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…

•  No Card or Port Flaps •  ICS SSO Synch of Infrastructure •  OIR, PM, FM, LTL/FPOE, etc

•  No Packet Loss •  Local Switching Hardware (DFC4) •  ICS SSO Synch of L2/L3 •  FIB/ADJ, MAC, Protocol FSM, etc

WS-X6908-10G

WS-X6848-SFP

Sup2T

Sup2T

WS-X6908-10G

WS-X6848-SFP

T2/1/1

T2/1/2

SSO

VSS Switch ID 2

62

Sup2T & Sup6T 15.1(1)SY1 / 15.3(1)SY


Line Card Data-Plane Redundancy Dependencies (Cross Fabric)

WS-X6908-10G

WS-X6848-SFP

Sup2T

Sup2T

WS-X6908-10G

WS-X6848-SFP

T2/1/1

T2/2/1

SSO

VSS Switch ID 2

•  Traffic between ports that are on Different Line Cards (e.g. T2/1/1 & T2/2/1) WILL be affected by Supervisor SSO events…

•  No Card or Port Flaps ICS SSO Synch of Infrastructure

•  50-200ms of Packet Loss ICS SSO Synch of L2/L3 Loss Time = Active à Standby Fabric Switch-Over & Channel Initialization New Cards support HW Notification

63

Sup2T & Sup6T 15.1(1)SY1 / 15.3(1)SY


VSS Supervisor Redundancy Comparison

100%

50%

Available

Band

width

Time

§  Quad-Sup Uplink Forwarding -  1+1 (active/active) Supervisor Redundancy for dual

attached devices

-  Automated recovery from Supervisor failure -  Deterministic outage duration for single attached

devices

100%

50%

Available

Band

width

Time

§  Quad-Sup SSO

§  1:1 (active/standby) Supervisor Redundancy for single and dual attached devices

-  Automated recovery from Supervisor failure

-  SSO switchover is typically 50ms – 200ms 50ms – 200ms

100%

50%

Available

Band

width

Time

§  Single Supervisor (Dual Sup) -  1+1 (active/active) Supervisor Redundancy for dual

attached devices

-  Requires manual Supervisor replacement -  Non-deterministic outage duration for single

attached devices


64


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

65


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 66


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.

67


Summary


Please Complete Your Session Evaluation

69

Thank you

© 2016 Cisco and/or its affiliates. All rights reserved. Cisco Public Presentation ID 70

We’re ready. Are you?


VSS Hardware and Software Requirements

72


VSS is supported on Catalyst 6500, 6800, 4500-E and 4500-X

73

6500-E / 6807-XL 6880-X / 6840-X 4500-E 4500-X

Supervisors Sup6T, Sup2T, Sup720-10G

Fixed (Based on Sup2T) Sup7E, Sup7LE Sup8E, Sup8LE

Fixed (based on Sup7E)

Software Trains Sup6T – 15.3(1)SY Sup2T – 15.2(1)SY, 15.1SY, 15.0SY Sup720 – 15.1(2)SY, 12.2SXJ,12.2SXI

6880-X - 15.2(1)SY, 15.1(1)SY 6840-X – 15.2(2)SY

3.8.0E 3.7.0E 3.6.0E 3.5.0E 3.4.0SG 15.1(2)SG

3.8.0E 3.7.0E 3.6.0E 3.5.0E 3.4.0SG

Mixed / Asymmetric Chassis Support

Yes Yes Yes *after release 3.5.0E

No must use the same model, 16-port or 32-port

Quad-Sup SSO Sup6T – 15.3(1)SY Sup2T – 15.1(1)SY1

N/A No N/A

Quad-Sup RPR (Uplink Forwarding)

Sup720 –12.2(33)SXI4 N/A Yes *after release 3.8.0E

N/A


VSS Requirements Catalyst 6500 and 6800 VSS Support

74

Catalyst 6500 Series Catalyst 6800 Series


VSS Requirements Catalyst 6500 and 6800 VSS Support Matrix

75

Hardware Chassis Supervisor Modules Catalyst 6500 C6503-E

C6504-E C6506-E C6509-E C6513-E

VS-S720-10G VS-S2T-10G

C6800-48P-SFP C6800-48P-TX C6800-8P10G C6800-16P10G C6800-32P10G

WS-X6748-SFP/TX WS-X6848-SFP/TX WS-X6716-10G/T WS-X6816-10G/T WS-X6908-10G WS-X6904-40G

Catalyst 6800 C6807-XL VS-S2T-10G C6800-SUP6T

C6800-48P-SFP C6800-48P-TX C6800-8P10G C6800-16P10G C6800-32P10G

WS-X6748-SFP/TX WS-X6848-SFP/TX WS-X6716-10G/T WS-X6816-10G/T WS-X6908-10G WS-X6904-40G

C6880-X C6880-X-LE

N/A C6880-X-16P10G C6880-X-LE-16P10G

C6816-X-LE C6832-X-LE C6824-X-LE-40G C6840-X-LE-40G

N/A N/A

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

76

Catalyst 4500-E Series Catalyst 4500-X Series


VSS Requirements Catalyst 4500-E and 4500-X VSS Support Matrix

77

Hardware Chassis Supervisor Modules

Catalyst 4500-E 4503+E 4506+E 4507+E 4510R+E

Sup7-E Sup7-LE Sup8-E

WS-X4712-SFP+E WS-X4748-12X48U WS-X4748-RJ45+V WS-X4748-UPOE+E WS-X4748-RJ45-E

WS-X4606-X2-E WS-X4648-RJ45V-E WS-X4648-RJ45V+E WS-X4648-RJ45-E WS-X4640-CSFP-E WS-X4624-SFP-E WS-X4612-SFP-E

Catalyst 4500-X WS-C4500X-32SFP+ WS-C4500X-F-32SFP+ WS-C4500X16SFP+ WS-C4500X-F-16SFP+ WS-C4500X-24X-IPB WS-C4500X-40X-ES WS-C4500X-24X-ES

N/A C4KX-NM-8SFP+

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

78

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

Technology

Simplifying networks using vpc and vss