Nexus 7000 vPC Features

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.

Peer Gateway

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

Peer Switch

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.

Auto Recovery

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

ARP Synchronization

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