This document summarizes port channels, virtual port channels (vPC), and multi-chassis etherchannel (MCEC) technologies. It discusses the basic design of vPC including components, initialization stages, best practices, and failure scenarios. Key points covered include vPC domains, roles, peer links, consistency checks, and configuration examples on Nexus 5000/7000/FEX platforms. Enhanced vPC (EvPC) and interactions with first hop redundancy protocols are also summarized.

1. Port Channel &
Virtual Port Channel vPC

2. ETHERCHANNEL

3. Types of Port-Channel

4. Load Balancing

5. Ether channel vs MCEC
• Port Channeling was original between only 2 devices
– 1 downstream device & 1 upstream device
• E.g. end host to Catalyst 2950 via 2 x FastE links
– Increases BW but still has single point of failure
• Multi Chassis EtherChannel (MCEC/MEC) is between
3 devices
– 1 downstream device & 2 upstream devices
• E.g. end host to 2 x Catalyst 3750s via 2 x GigE links
– Increases BW and resiliency
– Logically appears the same as a 2 device Port Channel

6. Types of MCEC
• Catalyst 3750 Cross Stack Port Channels
• Catalyst 6500 Virtual Switching System (VSS)
• Nexus Virtual Port Channel (vPC)

7. vPC Basic Design

8. Feature Overview

9. vPC Overview

10. After vPC

11. Feature Overview

12. Overview

13. vPC Component

14. Stages of vPC Initialization

15. vPC Design Guidance and Best
Practices

16. Order of Operation

17. vPC Domain

18. vPC Role

19. vPC PEER-LINK

20. Peer-Keepalive

21. Configuration…..on 5K…

22. Physical Topology

23. Order of Operation
• Establish IP connectivity for Peer Keepalive
• Enable vPC & LACP features globally
• Create vPC domain
• Define Peer Keepalive address
• Establish Port Channel for vPC Peer Link
• Verify vPC Consistency Parameters
• Disable vPC Member Ports
• Configure vPC Member Ports
• Enable vPC Member Ports on Primary
• Enable vPC Member Ports on Secondary

24. Loop Prevention Method
• Goal of vPC is to hide redundant links from STP
– Could result in layer 2 flooding loops
• Loops are prevented via “vPC Check” behavior
– Frames received in the vPC Peer Link cannot flood out a vPC
Member Port while the remote vPC Peer has active vPC
Members in the same vPC
• vPC Check Exception
– If vPC Peer’s Member Ports are down, the vPC Member
Ports
become “Orphan Ports” and the vPC Check is disabled
– vPC Peer Link is essentially a last resort connection

25. Consistency Check
• CFSoE runs on the vPC Peer Link to synchronize the control plane
• Includes advertisement of “Consistency Parameters” that must
match for vPC to form successfully
– E.g. Line Card Type (M or F), Speed, Duplex, Trunking, LACP mode,
STP configs, etc.
• Three types of consistency checks
– Type 1 Global & Interface Consistency Check
Mismatch results in vPC failing to form if new vPC
Mismatch results in VLANs being suspended if change in an active vPC
– Type 2 Consistency Check
• Mismatch results in log message but not vPC failure
• Can result in failures in the data plane

26. Useful Command
• show port-channel usage
– shows currently used channel numbers
– helps to make sure you don’t reuse an already
defined channel
• show vpc consistency-parameters
– Verifies compatibility between vPC peers for a
given vPC

27. Configuration…..on 7K…

28. Configuration…..on 5K and FEX…
ACTIVE_ACTIVE vPC

29. 5000 Config SYNC
• When FEX has two parent switches, config
mismatches can have negative effects
– Parent switches run separate control and management
planes
• Config Sync allows a template of config to be pushed
between N5Ks and applied simultaneously
– Uses CFSoIP to exchange config parameters
– Not specific to FEX and vPC, but its most common
application
• Applied as config sync mode as opposed to config t

30. Config SYNC

31. Bold Points

32. Enhanced vPC(EvPC)

33. Back-to-Back vPC

34. vPC and FHRP
• Nexus 7000 is typically L2 & L3 network boundary
– N7K is vPC Peer but also end host’s FHRP Default Gateway
• FHRP behavior changes to accommodate active/active forwarding
over vPC
– Traffic received in vPC Member Port of FHRP Standby to FHRP
Virtual MAC is not forwarded over Peer Link to Active FHRP member
– Essentially HSRP Standby acts as HSRP Active
• FHRP vPC can break in certain non-standard vendor applications
– Frames sent to FHRP Standby with physical DST MAC of FHRP
Active are sent out the Peer Link
– peer-gateway hack allows FHRP Standby to forward frames on
behalf of DST MAC of FHRP Active without going over Peer Link

35. Failure Scenario
• Worst case scenario in vPC failure is “Split Brain”
– vPC control plane is broken and both vPC Peers assume vPC Primary Role
• Peer Keepalive and Peer Link have built in protection against this
– Upon failure vPC Secondary suspends its local vPC Member Ports
and SVIs
– Normally the desired behavior to prevent Split Brain
– Can isolate Orphan Ports that use vPC Secondary’s SVI as their
default gateway
 Only surefire workaround is to not have Orphan Ports
 vPC Peers ideally only have vPC Member Ports, e.g. all downstream
devices are dual attached

36. Failure Scenario
• vPC Peer Link goes down…
– Secondary waits for hold-timeout and keepalive timeouts to expire
– After timers expire if keepalive is not received, assume vPC Primary
– Else if keepalive is received, suspend vPC Member Ports
• vPC Secondary is now effectively disabled
• Next, vPC Primary fails completely…
– vPC Secondary already has vPC Member Ports suspended and they
don’t come back
– Secondary does not continually check for vPC Primary
– Now both vPC Primary and vPC Secondary are effectively disabled

37. vPC Auto Recovery
• Allows vPC Secondary to assume Primary in certain failure
Scenarios
• vPC Peer Link goes down…
– Secondary waits for hold-timeout and keepalive timeouts to expire
– Keepalive received, suspend vPC Member Ports
– Primary completely fails
– vPC Secondary actively checks for keepalive
– vPC Secondary promotes itself to Primary and un-suspends vPC
Member Ports
– Upon recovery of Primary, no preemption
• Bouncing Peer Link will return Operational Secondary to Primary

38. vPC Auto Recovery
• Second case is recovery after initial bootup
– Power outage occurs on both Primary and Secondary
– After boot, if vPC Peer Link does not come up, Role
Election cannot occur and vPCs are never brought up
– Auto Recovery allows a single vPC Peer to elect itself
vPC Primary after configured timeout if vPC Peer Link
never comes up after reload

39. vPC Auto Recovery Problems
• Certain failure scenarios will cause Split Brain
– Auto recovery is on
– Link cut on both Peer Link and Peer Keepalive
– Eventually vPC Secondary elects itself Primary
– Dual Primary, traffic forwarding fails
• Operational solution to catastrophic failure like this is to
poweroff secondary or no feature vpc
• Design solution is better physical redundancy
– Dual SUPs
– Redundant power grids
– Peer Link & Keepalive are Port Channels on separate cards

40. vPC PEER SWITCH
• Makes vPC Peers appear as same root bridge
• Same BPDUs generated by both Primary and
Secondary vPC Peers
• Useful in failure scenarios to reduce RSTP
reconvergence time when vPC Primary fails and
then recovers
– With Peer Switch, Secondary vPC Peer does not
need to run RSTP Sync when Primary comes back

41. Question ???