Understanding the Impact of Emerging Technologies on the ... · Network (LLDP MED) Extend Power-via-MDI (LLDP MED) Inventory Management (LLDP MED) IEEE 802.3 MAC/PHY Configuration/Status

© 2008 Cisco Systems, Inc. All rights reserved. Cisco Public 1Session_IDPresentation_ID

Understanding the Impact of Emerging Technologies on the Enterprise Campus Architecture

Mike HerbertTME – Enterprise Systems Engineering

© 2008 Cisco Systems, Inc. All rights reserved.Session_IDPresentation_ID Cisco Public


Evolving Campus DesignEvolving Requirements and Technology

Evolving Business ExpectationsOne Time Zone – Real Time

The New Millennial Employee

Changing Application and Endpoint Behaviour

Desktop based Unified Communications

Collaborative applications

High Definition Video

Emerging Technology802.11n, 802.3at, LLDP

Deep packet inspection (Sup32-PISA)

Virtual Switching System (VSS)


Evolving Campus DesignAgenda

SiSiSiSi

SiSiSiSi

SiSi

Data Center

SiSi SiSi

ServicesBlock

Distribution Blocks

SiSi SiSi SiSi

Evolving Edge RequirementsPower over Ethernet

CDP/LLDP

Intelligent Quality of Service

Evolution of the Distribution BlockVirtual Switch System (VSS)

VSS Operation

VSS Campus Design

VSS Recovery

Design Considerations


Evolving UC Network ServicesDynamic Device and Switch Provisioning

Switch Detects IP Phone and Applies Power

CDP Transaction Between Phone and Switch

IP Phone Placed in Proper VLAN

DHCP Request and Call Manager Registration

SiSi

Plug and play provisioning of edge devices (phones and APs) necessary to manage operational overhead

Power negotiation

VLAN configuration

802.1x interoperation

QoS configuration

DHCP

Call Agent (CCM) or LWAPP registration

Endpoints dynamically participate in the overall

Network QoS and Security


Evolving UC Network ServicesEvolving PoE Requirements

Endpoint power requirements are increasingDual Radio AP’s, Remote Controlled Video Camera’s

Green initiatives

802.3at standard estimated to be ratified March 2009

Need for Granular power negotiation ‘and’ increased power

Range of IEEE 802.3af Power

0 Watts0 Watts 15.4 Watts15.4 Watts

AP-1200 802.11b/g 6.2 Watts

IP Phone 7970G

10.25 Watts

Class 2 7 Watts

Class 0 / 315.4 Watts

Proposed Range of IEEE 802.3at Power

30 Watts30 Watts

AP – 1250 802.11n 18.5-20.0

Watts

Class 14 Watts


Evolving UC Network ServicesPoE – 802.3af

Cisco pre-standard devices initially receive 6.3 watts and then optionally negotiate via CDP802.3af devices initially receive 12.95 watts unless PSE able to detect specific PD power classification

Switch (PD) provides 15.4 watt’s (44 and 57 volts DC, 350ma to 400ma)12.95 watts @ 44 volts minimum delivery to the endpoint (PSE) Essentially 380ma @ 48VDC over CAT 5 100 meters

Power negotiation is ‘optional’ behavior for 802.3af devices

Class Usage Minimum Power Levels Output at the PSE

Maximum Power Levels at the Powered Device

0 Default 15.4W 0.44 to 12.95W

1 Optional 4.0W 0.44 to 3.84W

2 Optional 7.0W 3.84 to 6.49W

3 Optional 15.4W 6.49 to 12.95W

4Reserved for

FutureUse

Treat as Class 0Reserved for Future Use: a Class 4 Signature Cannot Be Provided by a Compliant Powered

Device


UC Network ServicesGranular PoE negotiationTwo potential mechanisms that can be used to negotiate power

Layer 1 – e.g. 802.3afLayer 2 – e.g. CDP

CDP originally just provided notification of power

Power Consumption TLVBidirectional CDP (Intelligent Power Management) provides the ability to negotiate power via a 3-way handshake

1.Power Request TLV (32 bit integer measured in mW)

2.Power Available TLV3.Power Consumption TLV

CDP Frame Format


UC Network ServicesEnhanced PoE (EPoE) – 802.11n AP’s

After negotiating enhanced PoE both radios will power up

Class 3 Power Negotiated and Applied

SiSi

Enhanced PoE - greater than class 3, but less than 20 watts/port This is not 802.3at / PoE+

AP1250 comes up as 802.3af class 3 device with radios disabledNegotiating 18.5 watts via bidirectional CDP enables both radios

Power Mode 802.3af Cisco Enhanced PoE

Max Power at PSE 15.4 W 16.8-20 W

# of radios supported 1 or 2 2

MIMO Mode (Tx x Rx) 1 radio: 2x3, 2 radios: 1x3 2x3

Dual radio Limitations Maximum PHY data-rate 157.5 Mbps/radio

Max PHY data-rate 300 Mbps/radio


UC Network ServicesEnhanced PoE and power negotiation

Class 3 Power Negotiated and Applied

SiSi

Step 1 – 802.3af Device Discovery

*Apr 2 09:48:31.715: Ilpower PD device 3 class 6 from interface (Gi2/1)*Apr 2 09:48:31.715: ilpower new power from pd discovery Gi2/1, power_status ok*Apr 2 09:48:31.715: Ilpower interface (Gi2/1) power status change, allocated power 16559

Switch#show power inline g2/1Available:796(w) Used:16(w) Remaining:780(w)

Interface Admin Oper Power(Watts) Device ClassFrom PS To Device

--------- ------ ---------- ---------- ---------- ------------------- -----Gi2/1 auto on 16.6 15.4 Ieee PD 3

Interface AdminPowerMax AdminConsumption(Watts) (Watts)

---------- --------------- --------------------Gi2/1 20.0 15.4


UC Network ServicesEnhanced PoE and power negotiation

Step 2 – AP Boots up

After negotiating enhanced PoE both radios will power up

SiSi

Step 3 – AP negotiates for high-power using CDP

*Apr 2 09:50:53.087: CDP-PA: Packet received from ap on interfaceGigabitEthernet2/1*Apr 2 09:50:53.087: **Entry found in cache***Apr 2 09:50:53.087: Ilpower interface (Gi2/1) process tlv from cdp INPUT:*Apr 2 09:50:53.087: power_consumption = 9000, power_request_id = 28851, power_man_id = 1,*Apr 2 09:50:53.087: power_request_level[] = 20000 9000 0 0 0*Apr 2 09:50:53.087: Interface (Gi2/1) select power 20000*Apr 2 09:50:53.087: Ilpower interface (Gi2/1) power negotiation: consumption = 9000, alloc_power = 21505

Switch#sh power inline g2/1Available:796(w) Used:21(w) Remaining:775(w)

Interface Admin Oper Power(Watts) Device ClassFrom PS To Device

--------- ------ ---------- ---------- ---------- ------------------- -----Gi2/1 auto on 21.5 20.0 AIR-AP1252AG-A-K9 3

Interface AdminPowerMax AdminConsumption(Watts) (Watts)

---------- --------------- --------------------Gi2/1 20.0 15.4

20W allocation


UC Network ServicesEnhanced PoE (EPoE) – 802.11n AP’s

Supported Switches

Software Release

Notes

Cat3K 3750E:WS-C3750E-24PD-SWS-C3750E-24PD-EWS-C3750E-48PD-SWS-C3750E-48PD-EWS-C3750E-48PD-SFWS-C3750E-48PD-EF

3560E:WS-C3560E-24PD-SWS-C3560E-24PD-EWS-C3560E-48PD-SWS-C3560E-48PD-EWS-C3560E-48PD-SFWS-C3560E-48PD-EF

12.2(44)SEReleased

Supports 2 radio 11n modeSwitch power supply must be correctly sized for PoE load

20 AP’s per 24 Port Switch40 AP’s per 40 Port Switch

Cat4K 4500E Linecards:WS-X4648-RJ45V-EWS-X4648-RJ45V+E

12.2(44)SG Released

Supports 2 radio 11n modeNo limitations on the number of AP1250s that can be used

with a card or chassisChassis power supply must be correctly sized for PoE load

Cat6K Linecards:WS-X6148A-GE-45AFWS-X6148-GE-45AFWS-X6548-GE-45AF

PoE daughter cards:WS-F6K-48-AF=WS-F6K-GE48-AF=

12.2(33)SXH2Released

Supports 2 radio 11n mode No limitations on the number of AP1250s that can be used

with a card or chassisChassis power supply must be correctly sized for PoE load

© 2008 Cisco Systems, Inc. All rights reserved. Cisco Public 12Session_IDPresentation_ID © 2006 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

March, 2005 IEEE-SA Standards Board approved 802.1AB (LLDP) standardIEEE intent that the protocol not be used for configuration purposesDespite IEEE, TIA standards body worked toward an adjunct standard for Link Layer Discovery Protocol for Media Endpoint Discovery (LLDP-MED) TR 41.4Operates in Transmit or Advertise mode only (no state kept between 2 entities)Periodic messages sentSend Device Info, Capabilities, and Media Specific Info802 Link Layer protocol (no frame, ATM, … support)Either LLDP or LLDP-MED runs on a port, not both. LLDP-MED spec details how to transition from LLDP to LLDP-MED if an LLDP-MED endpoint is detected

UC Network ServicesLLDP, LLDP-MED


UC Network ServicesLLDP, LLDP-MED

LLDP-MED

LLDP-MED

Chassis ID

TLVPort ID

TTLTLV

End of LLDPDU

TLV

0 or more Optional TLVs

PortID

TLVTTLTLV

SiSi SiSi

LLDP

LLDP

LLDP PDU

Optional TLVsPort Description System Name System Description System CapabilitiesManagement AddressCapabilities (LLDP MED)Network (LLDP MED)Extend Power-via-MDI (LLDP MED)Inventory Management (LLDP MED)IEEE 802.3 MAC/PHY Configuration/Status (LLDP MED) Port VLAN ID (LLDP MED)

Mandatory TLVsChassis ID, Port ID, TTL

LLDP-MED TLV’s designed to support VoIP endpoints


UC Network ServicesLLDP, LLDP-MEDLLDP is disabled by default, you need to explicitly configure which optional TLV’s to sendLLDP and CDP can coexist on same interfaceLLDP, LLDP-MED support

Catalyst 6500 – 12.2(33)SXHCatalyst 4500 and 4900 – 12.2(44)SGCatalyst 3750, 3560, 2970, 2960 - 12.2(37)SE*

cr32-4500-1(config)#lldp run

cr32-4500-1(config)#lldp tlv-select ?mac-phy-cfg IEEE 802.3 MAC/Phy Configuration/status TLVmanagement-address Management Address TLVport-description Port Description TLVport-vlan Port VLAN ID TLVsystem-capabilities System Capabilities TLVsystem-description System Description TLVsystem-name System Name TLV

cr32-4500-1(config-if)#lldp med-tlv-select ?inventory-management LLDP MED Inventory Management TLVlocation LLDP MED Location TLVnetwork-policy LLDP MED Network Policy TLVpower-management LLDP MED Power Management TLV

Configure Optional Global TLV’sEnable LLDP Globally

Configure Optional Interface TLV’s

* Support for Protocol Media Extension (3750, 3560, 2960) - 12.2(40)SE


UC Network ServicesCDP and LLDPcr40-6500-1# sh lldp entry *. . .Chassis id: 0014.6947.93c0Port id: Te3/1Port Description: TenGigabitEthernet3/1System Name: cr32-4500-1.cisco.com

System Description: Cisco IOS Software, Catalyst 4500 L3 Switch Software (cat4500e-ENTSERVICESK9-M), Version 12.2(44). . .Time remaining: 96 secondsSystem Capabilities: B,REnabled Capabilities: B,RManagement Addresses - not advertisedAuto Negotiation - supported, enabled. .

cr40-6500-1#sh cdp neigh ten 3/7 detail -------------------------Device ID: cr32-4500-1Entry address(es): IP address: 172.26.160.86

Platform: cisco WS-C4507R-E, Capabilities: Router Switch IGMP Interface: TenGigabitEthernet3/7, Port ID (outgoing port): TenGigabitEthernet3/1. . .Version :Cisco IOS Software, Catalyst 4500 L3 Switch Software (cat4500e-ENTSERVICESK9-M), Version 12.2(44). . .VTP Management Domain: 'campus3-test'Native VLAN: 902Duplex: fullManagement address(es): IP address: 172.26.160.86

Currently CDP provides information not supported in LLDP and LLDP-MED


UC Network ServicesCDP and LLDP

CDP LLDP, LLDP-MED

PoE Bi-Directional CDP power negotiation

Power notification only

Inventory Discovery Yes YesLocation Yes Yes, additional data

formatsCapabilities Discovery Yes Yes

QoS Trust Boundary Extension

Yes No

Communication to PC running behind a phone

Yes No, LLDP is a non bridgable frame

802.1x phone bypass Yes NoEmergence Responder (E911) Yes NoNetwork Policy VLAN and QoS

informationVLAN and QoS information (not used by Cisco phones)


UC Network ServicesNext Steps – What you need to watch

Evolving PoE standards

802.3at PoE Plus (PoEP)Ratification sometime in 2009

30 watt’s delivered - Possibly 60 watts (2 pair or 4 pair)

Backwards compatible to 802.3af power devices

Category 5 and higher Ethernet cable (10M, 100M, 1G and maybe 10Gbps)

Recommended 720-mA maximum current per pair

802.3at committee has created an ad-hoc working group to determine how LLDP (not LLDP-MED) can be leveraged to provide layer 2 PoE negotiation in addition to layer 1 802.3at power negotiationLLDP-MED provides info related to how device is powered, power priority, and how much power device needs but currently no mechanism to do 3–way exchangeCisco sits on all the committee and will support all the standards

SiSi



SiSiSiSi

SiSiSiSi

SiSi

Data Center

SiSi SiSi

ServicesBlock

Distribution Blocks

SiSi SiSi SiSi


CDP/LLDP



VSS Operation

VSS Campus Design

VSS Recovery


© 2008 Cisco Systems, Inc. All rights reserved. Cisco Public 19Session_IDPresentation_ID © 2006 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID © 2006 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

With auto-qos configured default switch behaviour is to not trust edge ports and remark all traffic to configured CoS/DSCP

When switch and phone exchange CDP the trust boundary is extended to IP phone

Phone rewrites CoS from PC port to ‘0’, switch rewrites DSCP

Sup32 PISA provides an intelligent QoS remarking override for specificallydefined applications

Voice VLAN Traffic is Trusted

Data VLAN Traffic untrusted marked

CoS 0PISA remarks RTP

flows to correct DSCPVoice and Video traffic on the

Data VLAN Traffic

Extended Trust Boundary Intelligent Trust Boundary

Evolving UC Network ServicesUC applications migrating to the PC


Evolving UC Network ServicesUC applications migrating to the PC

When a phone is attached a port can be un-trusted, all voice VLAN traffic is trusted and all PC traffic is remarked

When a PC with softphone is attached to a port all traffic is trusted with rate limiters used to control the voice and signaling traffic rate

With voice, video and data originating from all devices there is an evolving need to provide a more intelligent QoS policy

interface GigabitEthernet3/2. . . mls qos trust cosauto qos voip cisco-phone!interface GigabitEthernet3/9. . .auto qos voip cisco-softphoneservice-policy input AUTOQOS-CISCO-SOFT-PHONE!class-map match-any AUTOQOS-CISCO-SOFTPHONE-SIGNALmatch ip dscp af31 match ip dscp cs3

class-map match-all AUTOQOS-CISCO-SOFTPHONE-DATAmatch ip dscp ef

!policy-map AUTOQOS-CISCO-SOFT-PHONEclass AUTOQOS-CISCO-SOFTPHONE-DATApolice cir 320000 bc 2000 conform-action transmit exceed-action policed-dscp-transmit

. . .

Trusted interface with a Cisco Phone

Un-trusted interface with a Cisco Softphone

‘or’


Supervisor 32 PISA Hardware Based Feature Acceleration

PISA Network Processor provides HW accelerated L4-7 IP ServicesTraffic is redirected to PISA when NBAR or FPM is configured on an interface – Traffic redirection granularity is at the interface level

PISA

NBAR/FPM Configured on G1/9 egress

G1/1 G1/8

G1/3 G1/10

No PISA accelerated feature configured

G1/2 G1/9

NBAR/FPM Configured on G1/1 ingress

Traffic Flow through PISATraffic Flow bypassing PISA


8

© 2006 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

Supervisor 32 PISAPISA Inband Channel

To SP

1 2 3 4 5 6 97

SP CPU

To RP

Network Processor

RP CPU

PISA Daughter Card

Classificationand Dispatch Engine PISA

[CDEP]

Port ASIC

PISA Channel

cr32-6500-2(config)#int gig 5/8cr32-6500-2(config-if)#channel-group 256 mode on

cr32-6500-2#sh etherchannel 256 summary <snip>Group Port-channel Protocol Ports------+-------------+-----------+-------------------------------256 Po256(RU) - Gi5/8(P) Gi5/9(P) Gi5/10(P)

interface GigabitEthernet5/8mtu 4160no ip addressspeed nonegotiateno rcv-queue random-detect 1 mls qos trust cosflowcontrol receive onflowcontrol send onno cdp enablechannel-group 256 mode on

In its default configuration, the PISA channel to the backplane is 1Gbps

1GE uplink mgmt port can be re-allocated to provide 2Gbps for the PISA channel

On the WS-S32-GE-PISA, port 8 can also be added to the PISA channel to allow up to 3Gbps to PISA

Note: Leave all Supervisor port QoS configurations in default mode (trust cos)

PISA Channel


Supervisor 32 PISAPISA NBAR interaction with PFC QoS

Scenario 1: NBAR in Ingress Scenario 2: NBAR in Egress

PISA

PFC

Linecard Linecard

Egress MQC:ClassificationPolicingMarking

3

4

CoS/Prec/DSCP RewriteQueuingSchedulingCongestion Avoidance

1QueuingSchedulingCongestion Avoidance

Implicit Trust DSCP

Ingress NBAR/MQC:ClassificationPolicingMarking 2

DSCP Rewrite

PISA

PFC

Linecard Linecard

Ingress MQC:ClassificationPolicingMarking

2

1QueuingSchedulingCongestion AvoidanceMarking

4

CoS/Prec/DSCP RewriteQueuingSchedulingCongestion Avoidance

Egress NBAR/MQC:ClassificationPolicingMarking

3DSCP Rewrite


Evolving UC Network ServicesEnhanced Access Trust Boundary

NBAR works together with QoS to assign QoS actions based on application classification

Modular QoS traffic classification:Define match criteria (class-map)

Associate actions for a given match criteria in a policy-map

Assign policy to an interface

The ability to match L5-7 protocol information provides the basis for an enhanced trust boundary

Policy MapPolicy Map

Class MapClass Map

Policing/Trust actionsPolicing/Trust actions

Policy Map Can Contain Up to 32 Class Maps

Refers to a Set of Classification Criteria for the Following Action Criteria—These Can Be DSCP, ACL, or protocol

Action Settings for Trust and Policing

Switch

Interface

(config)#policy-map NBAR_policy(config-pmap)#class-map myApp

(config)#class-map match-any myApp(config-cmap)#match access-group 101(config-cmap)#match protocol http(config-cmap)#match protocol rtp

(config)#policy-map NBAR_policy(config-pmap)#class-map myApp(config-pmap)#set dscp 40

Application

Access-list

DSCP

QoS Engine:Mark, Police


IP Header UDP Header RTP Header Audio/Video/Data

Evolving UC Network ServicesNBAR Payload Classification

Deep Packet Inspection provides the capability to identify specific traffic flows

Allows protocols like RTP to be classified and trusted on any VLAN from any device


Real-Time Transport Protocol (RTP) is defined by RFC 3550 (obsoletes RFC 1889)

RTP defines specific payload type values for all well known voice and video codecs

Matching on the payload field of the RTP header provides a mechanism to valid voice and video streams in both voice and data VLAN’s

Removes dependencies on UDP Port Range and DSCP markings

CODEC Payload TypeG.711 (Audio) 0 (mu-law) 8 (a-law)

G.721 (Audio) 2

G.722 (Audio) 9

G.723 (Audio) 4

G.728 (Audio) 15

G.729 (Audio) 18

H.261 (Video) 31

MPEG-1 (A/V)MPEG-2 (A/V) 14 (Audio), 32 (Video), 33 (A-V)

Dynamic 96–127

Evolving UC Network ServicesNBAR RTP Classification

cr32-6500-2(config-cmap)#match protocol rtp ?

audio Match voice packets

payload-type Match an explicit PT

video Match video packets

Specifies matching by payload-type values 0-23

Specifies matching by specific payload-type

Specifies matching by payload-type values 24-33


UC Network ServicesEnhanced Access Trust Boundary

class-map match-all G.729match protocol rtp payload-type "18"

class-map match-all G.711match protocol rtp payload-type "0"

class-map match-all 7985-Voicematch protocol rtp payload-type "9"

class-map match-all 7985-Videomatch protocol rtp payload-type "97"

! policy-map Trusted-Traffic-Flows

class 7985-Voiceset dscp af41

class 7985-Videoset dscp af41

class G.729set dscp ef

class G.711set dscp ef

class class-defaultset dscp default

!interface GigabitEthernet5/1description Routed Uplink to Dist 1. . .service-policy output UC

Define the trusted CODEC types, which voice and video types do you want to allow in the network

Define the required marking, policing or other policy desired

Apply to a layer 3 interface (current 12.2(18)ZY requirement)

Identify all G.711 & G.729 voice streams

Mark all approved voice and video traffic with the desired DSCP markings

Identify G.722 and Video streams for 7985 devices

Mark all other traffic to Best Effort

Apply the Trusted Traffic Service Policy either to local SVI or to uplinks to distribution - 12.2(18)ZY


Migration to common HTTP interface for multiple applications

Challenge to distinguish priority based on port numbers

NBAR deep packet inspection allows marking based on HTTP content

PISA identifies and remarks HTTP flows to desired DSCP

HTTP port overloadingEnhanced Access Trust Boundary

cr32-6500-2(config-cmap)#match protocol http ?content-encoding Encoding mechanism used to package entity bodyfrom E-mail of human controlling the user-agenthost Host name of Origin Server containing resourcelocation Exact location of resource from requestmime Content-Type of entity bodyreferer Address the resource request was obtained fromserver Software used by Origin Server handling requesturl Uniform Resource Locator pathuser-agent Software used by agent sending the request<cr>

class-map match-all Production-Web-Trafficmatch protocol http url "*.cisco.com”

class-map match-all Non-Production-Web-Trafficmatch protocol http url “*.youtube.com”


UC Network ServicesEnhanced Visibility - Protocol Discovery

cr32-6500-2#show ip nbar protocol-discovery top-n 5

Vlan611 Input Output ----- ------

Protocol Packet Count Packet Count Byte Count Byte Count 5min Bit Rate (bps) 5min Bit Rate (bps) 5min Max Bit Rate (bps) 5min Max Bit Rate (bps)

------------------------ ------------------------ ------------------------Remote_Desktop 319 252

157009 47083 0 0 7000 3000

icmp 1591 1591 162282 162282 1000 1000 1000 1000

. . . .http 25 3

2978 2278 0 0 0 0

unknown 21 31 10604 16001 0 0 3000 3000

Total 2057 1964 341956 241144 1000 1000 11000 7000

NBAR Protocol Discovery: discover what apps are running on your network and provide real-time statisticsPer-interface, per-protocol, bi-directional statistics (bit rate (bps); packet count; byte count)SNMP accessible for centralized monitoringSupported by Partner products (Concord, CA, InfoVista, Micromuse, IBM) and MRTG

© 2008 Cisco Systems, Inc. All rights reserved. Cisco Public 30Session_IDPresentation_ID © 2006 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

Enhanced Trust BoundaryCurrent Design Considerations

When ingress NBAR/FPM is applied on an interface, all Layer 3 IPv4 unicast packets are redirected through PISAL2, Multicast, control plane, non-IPv4 packets are not redirected to PISAWith the 12.2(18)ZY release PISA is dependent on having a Routed Access DesignQ3CY08 release will provide

Ability to redirect Layer 2 traffic through PISAACL redirection capabilities

High Availability design considerations:Avoid asymmetrical traffic flows for NBARSSO compatible: Configuration synchronized but

flow state and statistics are not synchronized

INT G5/1IP: 10.1.20.0/24

PISAPFC

VLAN 10IP: 10.1.10.0/24

Note: Please see the campus section of the upcoming release of the QoS SRND for complete design configuration guidance on the use of PISA in the campus access



SiSiSiSi

SiSiSiSi

SiSi

Data Center

SiSi SiSi

ServicesBlock

Distribution Blocks

SiSi SiSi SiSi


CDP/LLDP



VSS Operation

VSS Campus Design

VSS Recovery

Summary


Multilayer Network DesignWell understood best practicesMature, 10+ year old designEvolved due to historical pressuresCost of routing vs. switchingSpeed of routing vs. switchingNon-routable protocolsWell understood optimization of interaction between the various control protocols and the topologySTP Root and HSRP primary tuning to load balance on uplinks

Spanning Tree Toolkit (RootGuard, LoopGuard, …)

etc, …

Root Bridge &

HSRPActive

HSRPStandby

LoopGuard

RootGuard

CISF, BPDU Guard

Note: Please see the Campus High Availability and Convergence Analysis design guides for detailed design information - http://www.cisco.com/go/srnd

http://www.cisco.com/go/srnd


9.1

0.91

50

0

10

20

30

40

50

60

LoopedPVST+ (NoRPVST+)

Non-loopedDefaultFHRP

Non-loopedSub-

SecondFHRP

Multilayer Network DesignGood solid design option, but ….

Utilizes multiple Control Protocols

Spanning Tree (802.1w, …), FHRP (HSRP, …), Routing Protocol (EIGRP, …)

Convergence is dependent on multiple factors

FHRP - 900msec to 9 secondsSpanning Tree - Upto 50 secondsPoor load balancing – single uplink, asymmetric routing etc

STP, if it breaks badly, no inherent mechanism to stop the loop

Multi-Layer Convergence

Seco

nds

of V

OIP

pac

ket l

oss

3/2 3/2

3/1 3/1Switch 1 Switch 2

DST MAC 0000.0000.4444

DST MAC 0000.0000.4444


Routed Access Layer 3 Distribution with Layer 3 Access

Layer 3

Layer 2

Move the Layer 2/3 demarcation to the network edge

Upstream convergence times triggered by hardware detection of light lost from upstream neighbor

Beneficial for the right environment

10.1.120.010.1.20.0

VLAN 120 DataVLAN 20 Voice

GLBP Model

SiSiSiSi

EIGRP/OSPF EIGRP/OSPF

Layer 3

Layer 2EIGRP/OSPF EIGRP/OSPF

10.1.140.010.1.40.0

VLAN 140 DataVLAN 40 Voice


Routed Access Design Advantages, Yes in the Right Environment

Simplified Control PlaneNo STP feature placement (root bridge,

loopguard, …)No matching of STP/HSRP priorityNo L2/L3 multicast topology inconsistencies

Ease of Troubleshooting (leverage well know toolset)

Show ip routeTraceroutePing and extended pingsConsistent end to end troubleshooting

Failure differencesRouted topologies fail closed—i.e. neighbor

lossLayer 2 topologies fail open—i.e. broadcast

and unknowns flooded

Routed Access Convergence

0

2

4

6

8

10

When is VoiceImpacted

Time toRecover

Note: Please see the Campus Routed Access using EIGRP/OSPF design guide for detailed design information - http://www.cisco.com/go/srnd




SiSiSiSi

SiSiSiSi

SiSi

Data Center

SiSi SiSi

ServicesBlock

Distribution Blocks

SiSi SiSi SiSi


CDP/LLDP



VSS Operation

VSS Campus Design

VSS Recovery



Virtual SwitchVirtual Switching System 1440 (VSS)

Virtual Switching System consists of two Catalyst 6500’s defined as members of the same virtual switch domain Single Control Plane with Dual Active Forwarding PlanesDesign to increase forwarding capacity while increasing availability by eliminating SPT loops Reduced operational complexity by simplifying configuration

SiSiSiSi

Switch 1 + Switch 2

Virtual Switch Domain

Virtual Switch Link

VSS - Single Logical Switch

=


Virtual Switching System Hardware and Software Requirements

Requires 12.2(33)SXH1Native & Modular IOS are supported

Current recommendation 12.2(33)SHX2(a)

Supervisor - VS-S720-10G-3C/XLPFC3C/XL contains new hardware support to forward traffic across multiple physical chassis, lookup enhancements

Virtual Switch LinkVS Header encapsulation requires new port ASIC (R2D4)

VS-S720-10G-3C/XL Supervisor 10G port or WS-X6708-10G-3C/XL

10GE Only

VS-S720-10G-3C/XL

WS-X6708-10G-3C/XL


Virtual Switching System Hardware Requirements

Supported Line CardsWS-X67xx-series DFC(3C and 3CXL) or CFC (non-DFC) cards are required

Any other type of card will be powered down during VSS initialization phase

Supported Service Modules NAM is the only service module supported at FCS (SVC-NAM-1 and SVC-NAM-2)

FWSM/IDSM/ACE 10/20 and WISM planned for Q3CY08

IPv6, MPLS support in 12.2(33)SXI (Q3CY08)



SiSiSiSi

SiSiSiSi

SiSi

Data Center

SiSi SiSi

ServicesBlock

Distribution Blocks

SiSi SiSi SiSi


CDP/LLDP



VSS Operation

VSS Campus Design

VSS Recovery



Virtual Switching SystemSingle Control Plane

Uses one supervisor in each chassis with inter-chassis Stateful Switchover (SSO) technology ACTIVE supervisor synchronizes all SSO compatible protocols to standby supervisor, enabling sub-second recovery ACTIVE supervisor manages the control plane functions & protocols (Routing, EtherChannel, SNMP, Telnet etc) along with hardware control (OIR, port management)Standby supervisor manages local chassis power

Active SupervisorSF RP PFC

CFC or DFC Line Cards





Standby HOT Supervisor

SF RP PFCVSL








DFC – Distributed Forwarding CardSF – Switch FabricRP – Route Processor

PFC – Policy Forwarding CardCFC – Centralize Forwarding Card


Virtual Switching SystemDual Active Forwarding PlanesVirtual Switch operates with a single active supervisor from a control plane perspective but with dual active forwarding planeSupervisor ports and all the line card in both chassis including Distributed Forwarding Engines (DFC’s) are actively forwarding

SiSiSiSi

VSS-Router#show switch virtual redundancy My Switch Id = 1

Peer Switch Id = 2

Switch 1 Slot 5 Processor Information :-----------------------------------------------

Current Software state = ACTIVE. . .

Configuration register = 0x2Fabric State = ACTIVEControl Plane State = ACTIVE

Switch 2 Slot 5 Processor Information :-----------------------------------------------

Current Software state = STANDBY HOT. . .

Configuration register = 0x2Fabric State = ACTIVEControl Plane State = STANDBY

Data planeActive

Data plane Active


Virtual Switching System VSL - Virtual Switch Link

VSL (Virtual Switch Link) provides two functionsControl plane extension and enables synchronization of protocol states and table Data forwarding when needed

VSL is treated as system link thus configuration of many normal port capabilities are restricted e.g. IP address, flow control, QOS etcVSL can only be defined with 10 Gig port on either Sup7200-10G or WS-X5708VSL is defined by a unique port-channel interface on each switch

VS Header L2 L3 Data CRC

Virtual Switch Link

interface Port-channel1description VSL Link on Switch 1no switchportno ip addressswitch virtual link 1mls qos trust cosno mls qos channel-consistency

interface Port-channel2description VSL Link on Switch 2no switchportno ip addressswitch virtual link 2mls qos trust cosno mls qos channel-consistency


Virtual Switching System Link Management Protocol (LMP)

LMPLMP LMPLMP

LMPLMP LMPLMP

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:

Verify neighbor is Bi-DirectionalEnsure the member is connected to another Virtual SwitchTransmit and receive keep-alives to maintain health of the member and the VSL

After successful LMP negotiation, a Peer Group (PG) is formed which is a collection of all VSL members. For each PG, a Peer Group Control Link (PGCL) is elected to carry further control information such as inband SCP and IPC/ICC…

cr2-6500-vss#sh switch virtual link detail VSL Status : UPVSL Uptime : 1 week, 1 day, 34 minutesVSL SCP Ping : PassVSL ICC Ping : PassVSL Control Link : Te1/5/4

. . .------------------------------------------------------------------------------Te1/5/4 vfs operational vfs 0019.a924.e800 2

Te1/5/5 vfs operational vfs 0019.a924.e800 2 . . .

LMP neighborsPeer Group info: # Groups: 1 (* => Preferred PG)

PG # MAC Switch Ctrl Interface Interfaces---------------------------------------------------------------*1 0019.a924.e800 2 Te1/5/4 Te1/5/4, Te1/5/5


Virtual Switching System Role Resolution Protocol (RRP)

RRP also runs on each individual link of the VSL Determines whether hardware and software versions allow a Virtual Switch to formDetermines which chassis will become Active or Hot Standby from a control plane perspective

cr2-6500-vss#sh switch virtual role

Switch Switch Status Preempt Priority Role Session IDNumber Oper(Conf) Oper(Conf) Local Remote

------------------------------------------------------------------LOCAL 1 UP FALSE(N ) 110(110) ACTIVE 0 0 REMOTE 2 UP FALSE(N ) 100(100) STANDBY 4605 3331

RRPRRP RRPRRP

RRPRRP RRPRRP


Virtual Switching System Virtual Switch Domain

Domain ID is used to identify that two switches are intended to be part of the same VSS pairDomain ID enables multiple virtual switch pairs connected in hierarchical mannerOnly one VSS pair can participate in one domain Domain ID is a value between 1 and 255

cr2-6500-vss#sh run...switch virtual domain 10switch mode virtualswitch 1 priority 110switch 2 priority 100

cr2-6500-vss#show switch virtual Switch mode : Virtual SwitchVirtual switch domain number : 10Local switch number : 2Local switch operational role: Virtual Switch ActivePeer switch number : 1Peer switch operational role : Virtual Switch Standby

Domain 20

Domain 10


Virtual Switching System MAC Addresses

The VSS logical pair MAC address pool will be determined during the role resolution negotiation, all interface MAC addresses are derived from ACTIVE chassis EEPROM MAC address remains consistent across the switchover

Avoids updating ARP table in adjacent devices (hosts, routers etc) during switchovers

Individual VSS member MAC address are used during dual active condition

cr2-6500-vss#show switch virtual role

Switch Switch Status Preempt Priority Role------------------------------------------------------------------LOCAL 1 UP FALSE(N ) 110(110) ACTIVEREMOTE 2 UP FALSE(N ) 100(100) STANDBY

VSS-Router#show catalyst6000 chassis-mac-addresses chassis MAC addresses: 1024 addresses from 0019.a927.3000 to 0019.a927.33ff

cr2-6500-vss#sh idprom switch 1 ba detail | inc macmac base = 0019.A927.3000

cr2-6500-vss#sh idprom switch 2 ba detail | inc macmac base = 0019.A924.E800


Virtual Switching System NSF Aware Layer 3 Neighbors

NSF-aware and NSF-capable routers provide for transparent routing protocol recovery

Graceful restart extensions enable neighbor recovery without resetting adjacencies

Routing database re-synchronization occurs in the background

An NSF-capable router continuously forwards packets during an SSO processor recovery

EIGRP, OSPF, IS-IS and BGP are NSF capable and aware protocols

Sup720, Sup32, Sup IV/V and Cat37xx supports NSF functionality

SiSiSiSi

Neighbors should be NSF-Aware

Recommendation is to not tune IGP hello timers, use default Hello and Dead timers for EIGRP/OSPF in a VSS environment



SiSiSiSi

SiSiSiSi

SiSi

Data Center

SiSi SiSi

ServicesBlock

Distribution Blocks

SiSi SiSi SiSi


CDP/LLDP



VSS Operation

VSS Campus Design

VSS Recovery



Virtual Switching SystemMulti-chassis EtherChannel (MEC)

MEC is an advancement of EtherChannel extending link aggregation to two separate physical switches

MEC enables the VSS appear as single logical device to devices connected to VSS, thus significantly simplifying campus topology

Traditionally spanning VLANs over multiple closets would create STP looped topology, MEC with VSS eliminates these loops in the campus topology

MEC replaces spanning tree as the means to provide link redundancy and thus doubling bandwidth available from access

Logical TopologyPhysical Topology

Multi-Chassis EtherChannel

L2

SiSi SiSi

Vlan 30

BW capacity in non-MEC and MEC topology

Vlan 30

Non-MEC MEC


VSS Enabled Campus DesignMEC ConfigurationMEC links on both switches are managed by PAgP or LACP running on the ACTIVESwitch via internal control messages

All the rules and properties of EtherChannel applies to MEC such as negotiation, link characteristics (port-type, trunk), QOS etc.

Do not use “on” and “off” options with PAgP or LACP protocol negotiation

PAgP – Run Desirable-Desirable with MEC links

LACP – Run Active-Active with MEC links

L2 MEC enables loop free topology and doubles the uplink bandwidth as no links are blocked

L3 MEC provides reduced neighbor counts, consistent load-sharing(l2 and l3) and reduced VSL link utilization for multicast flows

SiSiSiSi

L3 MEC

L2 MEC


VSS Enabled Campus DesignTraffic Flows with MEC

In a MEC configuration traffic is forward over local members of the EtherChannel bundle (all 8 buckets hash to a local link)Designed to prevent sending traffic across the VSL link unnecessarilyIf all local links fail the RBH is programmed to forward across the VSL link 1 2 3 4 5 6 7 8

MECRBH (for MEC)8 Link Bundle Example

RBH (for MEC)8 Link Bundle Example

Bit 7Bit 7 Link 1Link 1Bit 6Bit 6 Link 1Link 1Bit 5Bit 5 Link 2Link 2Bit 4Bit 4 Link 2Link 2Bit 3Bit 3 Link 3Link 3Bit 2Bit 2 Link 3Link 3Bit 1Bit 1 Link 4Link 4Bit 0Bit 0 Link 4Link 4


VSS Enabled Campus DesignUnicast ECMP Traffic Flows

SiSiSiSi

ECMP follows a similar behavior, locallinks are preferred and all traffic is forwarded out of a locally attached link

Hardware FIB inserts entries for ECMP routes using locally attached links

If all local links fail the FIB is programmed to forward across the VSL link

cr2-6500-vss#sh ip route 10.121.0.0 255.255.128.0 longer-prefixesD 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

cr2-6500-vss#sh mls cef 10.121.0.0 17 switch 1

Codes: decap - Decapsulation, + - Push LabelIndex Prefix Adjacency 102400 10.121.0.0/17 Te1/2/2 , 0012.da67.7e40 (Hash: 0001)

Te1/2/1 , 0018.b966.e988 (Hash: 0002)

cr2-6500-vss#sh ip route 10.121.0.0 255.255.128.0 longer-prefixesD 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

cr2-6500-vss#sh mls cef 10.121.0.0 17 switch 1

Codes: decap - Decapsulation, + - Push LabelIndex Prefix Adjacency 102400 10.121.0.0/17 Te1/2/2 , 0012.da67.7e40 (Hash: 0001)

Te1/2/1 , 0018.b966.e988 (Hash: 0002)

4 ECMP Entries

2 FIB Entries

Te1/2/2

Te1/2/1

switch 1


VSS Enabled Campus DesignMulticast Traffic Flows

VSS represents a single multicast router which simplifies the multicast topology

A single PIM router on the subnet therefore a single PIM join is sent upstream

A single IGMP querier

With MEC, multicast traffic is forwarded via local line card and does egress replication when DFC line cards available

Single logical multicast router eliminates the non-RPF traffic, efficiently utilizing uplinks

PIM Join

Single logical multicast designated router and IGMP querier


VSS Enabled Campus DesignMulticast Traffic Flows – Non MEC attached devices

Multicast egress replication is currently supported on a per physicalchassis basisEgress replication for multicast traffic arriving on the first switch for OIL’s (out going interface list) on the second switch is performed on the VSL line card connecting to the second switch

cr2-6500-vss#sh ip mroute

(*, 239.192.240.123), 00:07:32/00:03:18, RP 10.122.100.1, flags: SIncoming interface: TenGigabitEthernet1/2/1, RPF nbr 10.122.0.27, Partial-SCOutgoing interface list:

GigabitEthernet2/8/4, Forward/Sparse, 00:02:54/00:02:34, HGigabitEthernet2/8/21, Forward/Sparse, 00:01:12/00:02:49, HGigabitEthernet1/8/24, Forward/Sparse, 00:01:12/00:02:54, H

cr2-6500-vss#sh ip mroute

(*, 239.192.240.123), 00:07:32/00:03:18, RP 10.122.100.1, flags: SIncoming interface: TenGigabitEthernet1/2/1, RPF nbr 10.122.0.27, Partial-SCOutgoing interface list:

GigabitEthernet2/8/4, Forward/Sparse, 00:02:54/00:02:34, HGigabitEthernet2/8/21, Forward/Sparse, 00:01:12/00:02:49, HGigabitEthernet1/8/24, Forward/Sparse, 00:01:12/00:02:54, H

Egress Replication occurs on the VSL line cards for traffic forwarded

out ports on the other switch

Switch 2Switch 1


VSS Enabled Campus DesignMulticast Traffic Flows – Non MEC Layer 3 Access

In routed access environments the use of access to distribution ECMP uplinks can result in multicast traffic forwarded over the VSL linksVSS represents a single Multicast routerAccess PIM joins are sent based on first entry in the routing table out of the two ECMP paths towards the RPVSS sends PIM joins upstream on one of it’s uplinksIf the joins are not sent to ‘and’ from the same physical VSS switch you can get multicast traffic passing across the VSL link

ECMP Uplinks

SiSiSiSi PIM Join

PIM Join

PIM Join


VSS Enabled Campus DesignMulticast Traffic Flows – Use MEC in Layer 3 Access

L3 MEC Uplinks

SiSiSiSiUse MEC uplinks from the access in routed access environments with multicast traffic VSS MEC local switch link preference avoids egress replication across the VSL link during normal conditionsIn the event of access uplink failure multicast traffic will pass across VSL link and will experience local switch replication

PIM Join

ECMP Uplinks

PIM Joins


VSS Enabled Campus DesignCore Design

SiSiSiSiIn a full mesh design two configuration options exist for connecting VSS in the distribution upstream to the core

4 x ECMP links

2 MEC links (results in 2 x ECMP links)

Both MEC and HW FIB prefer local links for egress

Unicast traffic takes the optimal path in both cases (no cross VSL traffic due to the use of one vs. the other)

SiSiSiSi


ECMP or MEC upstream to the coreMulticast Traffic

SiSiSiSiPIM Join

PIM joins will be sent on a single L3 path upstreamIn the ECMP configuration, multicast traffic only uses a single link out of four availableMEC will utilize two links in the same bundle (appears as a single logical path to MCAST)Traffic takes the optimal path in both cases (no cross VSL traffic due to the use of one configuration vs. the other)However, if the PIM join comes from core toward the access layer (many to many multicast sources) then MEC to the core is recommended design option

SiSiSiSiPIM Join


ECMP or MEC upstream to the coreLink Recovery

SiSiSiSi

MEC convergence is consistent,independent of the number of routes

ECMP convergence is currently dependenton the number of routes

Seco

nds

of L

ost V

oice

SiSiSiSi

Note: Convergence results based on 12,000 routes using 6708 lines cards in core and distribution. Please refer to upcoming

Campus VSS SRND for complete design analysis



SiSiSiSi

SiSiSiSi

SiSi

Data Center

SiSi SiSi

ServicesBlock

Distribution Blocks

SiSi SiSi SiSi


CDP/LLDP



VSS Operation

VSS Campus Design

VSS Recovery



Virtual Switching SystemDual Active

SiSiSiSi

VSL is the heart of the VSS functionalityProtecting VSL link bundle is the best practice design

Use one port from Supervisor and other from line cards to form a VSL bundleUse diverse fiber path for each VSL linksManage traffic forwarded over VSL link by avoiding single homed devices

In case of loss of all members of the VSL bundle, the standby supervisor will go active, creating dual active conditionDual active leads to

Two independent routers with same control plane information e.g. IP address, router ID etc.MEC disruptions

Two mechanism to provide dual active state detection

Enhanced PAgPBFD

Active Active


Virtual Switching SystemDual Active - Enhanced PAgP

Enhanced PAgP provides a new TLV to communicate the ID(MAC address) of the active switchIn normal operations all enhanced PAgP neighbors reflects ID of an active switch back upstream. Only ACTIVE switch originates ePAgP messagesOnce the VSL bundle goes down switch 2 goes active, it generate its own ePAgP message with its own ID via ePAgP supporting neighbor to switch 1

ePAgP:Switch 1 is Active

Normal Mode

ePAgP: Switch 1is Active

ePAgP:Switch 2 is Active

cr2-6500-vss#sh switch virtual dual-active summaryPagp dual-active detection enabled: YesBfd dual-active detection enabled: Yes

No interfaces excluded from shutdown inrecovery mode

In dual-active recovery mode: YesTriggered by: PAgP detectionTriggered on interface: Gi2/8/19Received id: 0019.a927.3000Expected id: 0019.a924.e800Dual Active Detection


Virtual Switching SystemDual Active Recovery - Enhanced PAgP

Switch 1 detects that switch 2 is now also active triggering dual active condition thus switch 1 brings down all the local interfaces to reduce network instabilityUntil VSL link restoration occurs, switch 1 is isolated from the network. Once the VSL link comes up, the role negotiation determines that switch 1 needs to come up in STAND_BY mode hence it reboots itself. Finally all interface on switch 1 are brought on line and switch 1 assumes STAND_BY roleIf any configuration change occurs during the dual active recovery stage, the recovered system will go in RPR+ mode and will require manual intervention

Switch 1 All

interfaces down

Switch 1 Reboot and comes up in STAND_BY

mode

Switch 2 inACTIVE mode

VSS RestorationDual Active Recovery


Virtual Switching SystemDual Active Recovery - Enhanced PAgP

cr2-6500-vss(config)#switch virtual domain 10 cr2-6500-vss(config-vs-domain)#dual-active detection pagp trust channel-group 205cr2-6500-vss(config-vs-domain)#dual-active exclude interface <port>

cr2-6500-vss#sh switch virtual dual-active pagp PAgP dual-active detection enabled: YesPAgP dual-active version: 1.1

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

Dual-Active Partner Partner PartnerPort Detect Capable Name Port VersionGi1/8/19 Yes cr7-6500-3 Gi5/1 1.1Gi1/9/19 Yes cr7-6500-3 Gi6/1 1.1

Enhanced PAgP dual active detection is enabled by default,Need to explicitly trust enhanced PAgP neighbors and requires MEC in admin down statePAgP protocol must be running on MEC links

ePAgP is supported in6500 in 12.2(33)SXH and 4500 in 12.2(44)SG29xx, 3750, support in 2HCY08

Use “exclude interface” option to keep specified port to remain up during the dual active recovery. e.g. designated management port


Virtual Switching SystemDual Active Recovery – BFD

Utilizes a direct pt-pt link connected to an interface on each switch

Must have a unique IP subnet on each end of the link

BFD session establishment triggers the dual active conditions and previously active switch undergoes to recovery mode similar to PAgP detection

BFD pt-pt link

interface gigabitethernet 1/5/1no switchportip address 200.230.230.231 255.255.255.0bfd interval 100 min_rx 100 multiplier 5interface gigabitethernet 2/5/1no switchportip address 201.230.230.231 255.255.255.0bfd interval 100 min_rx 100 multiplier 5

switch virtual domain 100dual-active pair interface gig 1/5/1 interface gig 2/5/1 bfd

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

interface gigabitethernet 1/5/1no switchportip address 200.230.230.231 255.255.255.0bfd interval 100 min_rx 100 multiplier 5interface gigabitethernet 2/5/1no switchportip address 201.230.230.231 255.255.255.0bfd interval 100 min_rx 100 multiplier 5

switch virtual domain 100dual-active pair interface gig 1/5/1 interface gig 2/5/1 bfd

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

Requires unique IP

subnets on the two

interfaces


Dual Active RecoveryePAgP or IP-BFD Dual Active convergence

MEC links to core (EIGRP)Currently ePAgP provides for faster detection of dual active condition ePAgP message is sent out as soon as last VSL link is lostIP-BFD currently requires a 3 step process

IP-BFD interface is activated on loss of last VSL linkIP-BFD packets are sentDual active detection occurs

IP-BFD being replaced with an L2 BFD in upcoming release

Note: Convergence numbers for IP-BFD will vary depending on the routing protocol (OSPF/EIGRP) as well as the choice of MEC vs ECMP. Please see upcoming VSS

Campus SRND for detailed design analysis

Seco

nds

of V

oice

Los

s


Dual Active RecoveryMultiple Mechanisms

Ensuring the availability of the VSL link is a high priority

Redundant fiber paths recommended to protect against physical fiber failures

ePAgP only needs to be run on a single neighbor but …

Leveraging enhanced PAgP on allinterfaces will ensure that in the worst case at least one switch (assuming that not all cable paths are affected in the failure condition) is connected to both members of the same VSS pair then a path will exist for the recovery

SiSiSiSi

RedundantVSL Fiber

ePAgP

ePAgP

BFD


VSS Campus DesignFailure Recovery

MEC or ECMP are the primary recovery mechanisms for all link or node failures

SiSiSiSi SiSiSiSiSiSiSiSi SiSiSiSi


Dual Active RecoveryePAgP or IP-BFD Dual Active convergence

MEC links to core (EIGRP)Switchover from Active to Hot_standby chassisL2 MEC – Access Layer

Average convergence for 37xx and 45xx MEC is 200 msec

ESE Campus network environment:

Multilayer best practice enabledNSF aware adjacent node66 MEC access switches with no VLAN’s spanning closetDefault EIGRP & OSPF TimersNative IOS 12.2(33) SXH2

Seco

nds

of V

oice

Los

s

Note: Convergence numbers vary depending on the design. Please see upcoming VSS Campus SRND for detailed design analysis



SiSiSiSi

SiSiSiSi

SiSi

Data Center

SiSi SiSi

ServicesBlock

Distribution Blocks

SiSi SiSi SiSi


CDP/LLDP



VSS Operation

VSS Campus Design

VSS Recovery



VSS Design ConsiderationsMultilayer TopologyOptimized multilayer topology uses “V” shape design where VLANs do not span closets

Deploying VSS in such topology without MEC re-introduces STP loops in the networks

Use of MEC is recommended any time two L2 links from the same devices connected to VSS

Layer 2 loop blocking one link

B

MEC creates single logical link, no loops, no blocked

links

Each access switch hasunique VLAN’sNo layer 2 loopsNo blocked links

SiSi SiSi

Vlan 10 Vlan 20 Vlan 30

L3 VSS

MEC


VSS Design ConsiderationsDaisy Chaining Access Layer Switches

SiSiSiSi

SiSi

SiSiSiSi

B

Layer 2 loop is one switch smaller but still exists

Daisy chained access switch designs challenges

Unicast flooding

Loop - blocked link

The use of a virtual switch in the distribution does address the problem of unicast flooding

You still have a layer 2 loop in the design with an STP blocked link

Traffic recovery times are determined by spanning tree recovery in the event of link or node failures


VSS Design ConsiderationsSingle Homed Devices

Singly attached devices can result in sub-optimal traffic flowsWhen using MEC there is no method to communicate to the core which of the two VSS switches to forward traffic to (it looks like a single switch to the core)On average 50% of all traffic will pass over the VSL link In practice does not differ from a traditional design with single homed subnets using route summarization to the coreMulticast traffic in routed access environment appears as single homed devices, unless MEC is used for VSS connectivityDual NIC server with one active IP also appear and single homed devices

SiSiSiSi


VSS Design ConsiderationsSTP Configuration VSS makes the network loop-free in normal topology

Do NOT disable spanning tree to safeguard against possible loop introduced at the edge due to user error and daisy chainingMake sure VSS remains root of all VLANsDo not use Loop Guard as it will disable the entire MEC channel on fault detection Use Root Guard at the edge port to protect external switch introducing superior BPDUse.g. temporary connectivity PortFast and BPDU Guard is still necessary at the edge switch to prevent accidental loop introduce either due to user error or topology change

SiSiSiSi

Root Bridge

CISF, BPDU Guard


VSS Design ConsiderationsOperational Considerations

Avoid preempt configuration between VSS switchesAvoid making changes to the configuration during VSS dual activerecovery. This will lead to require manual syncing of the configuration and rebootsUnderstand how you configure SPAN

Avoid replication between chassis which can lead to higher VSL link utilizationDistributed SPAN requires IOS 12.2(33)SXH2(a)

Reload vs “redundancy force failover”Reload causes both VSS chassis to rebootUse redundancy force failover option to manage both single chassis or dual chassis reboot

Network management – develop baseline what is acceptable polling and required parameters, since total number of ports in a single chassis has double, which can lead to higher CPU


Virtual Switch DesignIntroduces a new design option*

*NOTE: STP is not the only limiting factor to

L2 Design!!

Fully Redundant Virtual Switch Topology

SiSi SiSi

SiSi SiSi

SiSi SiSi

B = STP Blocked

Link

BB

BB

B BB

B

BB

B

B

STP Based Redundant Topology


Next Generation Campus DesignEvolving the Campus Foundation Architecture

Multi-Tier Access

Routed Access

Virtual Switch

Access Distribution Control Plane

Protocols

Spanning Tree (PVST+, Rapid-PVST+ or MST)

EIGRP or OSPF PAgP, LACP

Spanning Tree Required

STP Required for network

redundancy and to prevent L2 loops

No No

Network Recovery Mechanisms

Spanning Tree and FHRP (HSRP, GLBP, VRRP)

EIGRP or OSPFMulti-Chassis Etherchannel

(MEC)

VLAN spanning wiring closets

Supported (not desirable design) No Supported



Multi-Tier Access

Routed Access

Virtual Switch

Layer 2/3 Demarcation Distribution Access

Distribution (Could be Access)

First Hop Redundancy

Protocol

HSRP, GLBP, VRRP required Not Required Not Required

Load Balancing Per Subnet or Host Per Flow - ECMP Per Flow - MEC

Convergence

900 msec – 50 seconds

(Dependent on STP topology and

FHRP tuning)

50 - 600msec 50 - 600msec



Traditional Layer 2 designs remain valid

Evolving architectures provide

Simplified Control Plane: Remove dependence on STP

Increased Capacity: Provide flow-based load balancing

High Availability: 200 msec or better recovery

Flexibility to provide for the right implementation for each network requirement

SiSi SiSi SiSi SiSi

SiSi SiSi


Campus Design GuidanceWhere to go for more information

http://www.cisco.com/go/srnd & http://www.cisco.com/go/cvd


http://www.cisco.com/go/cvd


Q and A


Documents

Understanding the Impact of Emerging Technologies on the ... · Network (LLDP MED) Extend Power-via-MDI (LLDP MED) Inventory Management (LLDP MED) IEEE 802.3 MAC/PHY Configuration/Status