Next generation data centers across the world are taking advantage of Cisco’s Virtual PortChannel. As of recent, I’ve moved our core to a pair of Nexus 7010s running vPCs to the user edge, server edge, and some legacy systems. Over the past couple weeks I’ve also learned of a couple of features and wanted to bring them to light for everyone. I’ve also thrown in some information on some features that may not be new, but are still good to have in your tool bag.
vPC Peer Gateway allows devices to act as a gateway for packets that are destined to their vPC peer(s) MAC address. Typically this is used with NAS devices, or load-balancers that do not comply with Ethernet RFC standards. Such behavior can cause packets to be sent across the peer-link and end up being dropped on the other side.
The use of peer-gateway does not circumvent the exclusion from running L3 routing protocols over a vPC, or vPC enabled VLAN.
Peer-Gateway Configuration Example
core01(config)# vpc domain 42 core01(config-vpc-domain)# peer-gateway core01(config-vpc-domain)# sh run vpc vpc domain 42 role priority 100 peer-keepalive destination 10.25.15.249 source 10.25.15.250 vrf vpc-keepalive peer-gateway -- Repeat exactly for core02
The vPC peer switch feature addresses performance concerns around STP convergence, simply put it allows a pair of Cisco Nexus 7000 Series devices to appear as a single STP root in the Layer 2 topology improving vPC convergence if the vPC primary switch fails. In order to avoid loops, the vPC peer link is excluded from the STP computation. In vPC peer switch mode, STP BPDUs are sent from both vPC peer devices to avoid issues related to STP BPDU timeout on the downstream switches, which can cause traffic disruption. They key in our configuration is that our spanning-tree bridge priority is exactly the same between switches.
Example for a pure peer-switch topology in which the devices all belong to the vPC. (Using all VLANs)
core01(config)# vpc domain 42 core01(config-vpc-domain)# peer-switch 2011 Aug 19 16:05:48 hq-core01 %$ VDC-1 %$ %STP-2-VPC_PEERSWITCH_CONFIG_ENABLED: vPC peer-switch configuration is enabled. Please make sure to configure spanning tree "bridge" priority as per recommended guidelines to make vPC peer-switch operational. core01(config-vpc-domain)# spanning-tree vlan 1-3967,4048-4093 priority 8192 -- Repeat exactly for core02
Example for a hybrid peer switch topology in which there is a mixture of vPC and non-vPC devices in the configuration.
core01(config)# spanning-tree pseudo-information core01(config-pseudo)# vlan 1 designated priority 8192 core01(config-pseudo)# vlan 1 root priority 4096 core01(config-pseudo)# vpc domain 42 core01(config-vpc-domain)# peer-switch 2011 Aug 19 16:05:48 hq-core01 %$ VDC-1 %$ %STP-2-VPC_PEERSWITCH_CONFIG_ENABLED: vPC peer-switch configuration is enabled. Please make sure to configure spanning tree "bridge" priority as per recommended guidelines to make vPC peer-switch operational. -- Repeat exactly for core02
See Cisco.com for more details on hybrid peer-switch configurations.
The NX-OS vPC auto-recovery feature brings up the vPC links when one peer is down. This feature performs two operations:
- If both switches reload, and only one switch boots up, auto-recovery allows that switch to assume the role of the primary switch. The vPC links come up after a configurable period of time if the vPC peer-link and the peer-keepalive fail to become operational within that time. If the peer-link comes up but the peer-keepalive does not come up, both peer switches keep the vPC links down. This feature is similar to the reload restore feature in Cisco NX-OS Release 5.0(2)N1(1) and earlier releases. The reload delay period can range from 240 to 3600 seconds.
- When you disable vPCs on a secondary vPC switch because of a peer-link failure and then the primary vPC switch fails, the secondary switch reenables the vPCs. In this scenario, the vPC waits for three consecutive keepalive failures before recovering the vPC links.
The auto-recovery feature in Cisco NX-OS Release 5.0(2)N2(1) and later releases replaces the reload restore feature in Cisco NX-OS Release 5.0(2)N1(1) and earlier releases.
Config Example — this is another tough one! :)
core01(config)# vpc domain 42 core01(config-vpc-domain)# auto-recovery core01(config-vpc-domain)# auto-recovery reload-delay ? <240-3600> Time-out for restoring vPC links (in seconds) core01(config-vpc-domain)# auto-recovery reload-delay 240 Warning: Enables restoring of vPCs in a peer-detached state after reload, will wait for 240 seconds (by default) to determine if peer is un-reachable -- Repeat exactly for core02
vPC IP ARP Synchronization allows for faster convergence of IPv4 and IPv6 address tables between your vPC peers.
core01(config)# vpc domain 42 core01(config-vpc-domain)# ip arp synchronize core01(config-vpc-domain)# ipv6 nd synchronize -- Repeat exactly for core02
Network engineer turned management currently servicing the enterprise data center market. I started working on networks in the ’90s and still feel like that was just a few years ago. Jack of all trades, master of none; I love to learn about everything. Feel free to ask me about photography, woodworking, nhra, watches, or even networking! — For feedback, please leave a comment on the article in question, and I’ll respond as soon as I can. For everything else including fan mail or death threats, contact me via twitter.