Cisco NX-OS vPC Configuration: Step-by-Step with Commands

A virtual port channel (vPC) lets two Cisco Nexus switches present a single port channel to a downstream device, enabling Layer 2 multipathing with full redundancy and doubled bandwidth. This article explains the vPC concepts and walks the official 10-step configuration - peer-keepalive VRF, peer link port-channel, vPC domain and downstream port-channel - with the exact NX-OS commands. It then goes further than the quick-start: primary and secondary roles, system parameters that must never be changed after a domain is built, the interaction with STP and first-hop redundancy, and the failure scenarios that actually page an engineer at 03:00.

vPC Overview and Terminology

• vPC domain - the group of two peer switches acting as one.
• vPC peer link - the port-channel between the two switches carrying control traffic and BPDUs.
• Peer-keepalive link - a Layer 3 link (usually in a dedicated VRF) exchanging heartbeat messages; required before the peer link forms.
• vPC member port-channel - the port-channel to the downstream device, configured as vpc <id> on both peers.
• vPC role - one switch is primary, the other secondary, decided by priority and then by system MAC.
• Orphan port - a single-homed device attached to only one peer while that peer's peer link is down.

Only Layer 2 port channels can be in a vPC, and configuration is manual on both peers - it is never synchronized. That single sentence explains most vPC outages: engineers build the domain and the member ports on one switch, get a green show vpc, and forget that the second chassis needs its own mirrored configuration with mirrored addresses.

Why vPC Instead of Spanning Tree

Before vPC (and before MLAG, VLT or StackWise Virtual in other vendors), two data-centre switches connected to the same downstream switch meant a spanning-tree loop: one of the two uplinks had to be blocked, so half your purchased bandwidth sat idle and failover depended on STP convergence. vPC removes the blocked link from the equation entirely. Both uplinks stay active, the downstream device sees a single logical switch and a single LACP port channel, and a link failure is handled by LACP rather than by reconverging the spanning tree.

There is a second, subtler benefit: because the two peers advertise the same system parameters, the downstream device does not renegotiate its port channel when a link fails. Hashing stays stable, and servers running multi-path I/O do not see a path flap. That is why vPC (and its equivalents) became the default access-layer design in three-tier data centres, and why leaf-spine fabrics without EVPN often use it as a stopgap at the leaf pair.

Roles, System Parameters and the Configuration That Must Be Identical

Every vPC domain has a primary and a secondary peer. The primary forwards BPDUs, handles the peer-link's copy of flooded traffic and runs the vPC role election. Priority decides the election first (lower wins), and the system MAC breaks the tie. Best practice is to set the roles explicitly rather than let the switches decide, because an unplanned role change alters the peer-link forwarding behaviour.

switch(config)# vpc domain 1
switch(config-vpc-domain)# role priority 100        ! lower wins; 32667 default
switch(config-vpc-domain)# system-priority 4000     ! STP system priority for the domain
switch(config-vpc-domain)# system-mac 00:00:11:22:33:44
switch(config-vpc-domain)# peer-switch             ! both peers run STP as one bridge

The system MAC and system priority must be identical on both peers - they are the identity the downstream device sees. The role priority, by contrast, must differ. Never change the system MAC after the domain is live: the peers stop recognising each other as one logical bridge, LACP drops and every vPC member port goes down simultaneously. Vendor release notes are explicit that a system-MAC change requires a maintenance window and, in older releases, a reload of both peers.

Guidelines and Limitations

• Port-channel compatibility parameters must match on both peers.
• Use dedicated ports on different modules for the peer link where possible.
• Verify hardware support with show hardware feature-capability.
• The peer link should be a minimum of two 10G/25G ports on separate line cards; a single-port peer link is a single point of failure for the whole domain.
• Peer-keepalive should be a routed link, not a VLAN riding the peer link - if it shares fate with the peer link it cannot do its job.
• Do not run vPC member ports through a device that changes the LACP system ID; some firewalls and load balancers do.
• Maximum vPCs per domain, and per-chassis limits on peer-link members, vary by platform - check the verified scalability guide.

Step-by-Step Configuration

These steps follow the Nexus 9000 NX-OS interfaces configuration guide. Apply them on both switches, swapping peer-keepalive source and destination addresses.

! 1. Convert two interfaces to dedicated mode for the peer link
switch(config)# interface ethernet 7/1
switch(config-if)# rate-mode dedicated
switch(config-if)# no shutdown
switch(config-if)# exit

! 2. Create the peer link port-channel (active LACP)
switch(config)# interface ethernet 7/1-2
switch(config-if)# switchport
switch(config-if)# switchport mode trunk
switch(config-if)# switchport trunk allowed vlan 1-50
switch(config-if)# switchport trunk native vlan 20
switch(config-if)# channel-group 20 mode active
switch(config-if)# exit

! 3. Create the VLANs
switch(config)# vlan 1-50
switch(config-vlan)# no shutdown
switch(config-vlan)# exit

! 4. Create a VRF for peer-keepalive and add a Layer 3 interface
switch(config)# vrf context pkal
switch(config-vrf)# exit
switch(config)# interface ethernet 8/1
switch(config-if)# vrf member pkal
switch(config-if)# ip address 172.23.145.218/24
switch(config-if)# no shutdown
switch(config-if)# exit

! 5. Create the vPC domain with peer-keepalive
switch(config)# vpc domain 1
switch(config-vpc-domain)# peer-keepalive destination 172.23.145.217 source 172.23.145.218 vrf pkal
switch(config-vpc-domain)# exit

! 6. Configure the vPC peer link
switch(config)# interface port-channel 20
switch(config-if)# switchport mode trunk
switch(config-if)# switchport trunk allowed vlan 1-50
switch(config-if)# vpc peer-link
switch(config-if)# exit

! 7. Configure the downstream port-channel and assign the vPC number
switch(config)# interface ethernet 7/9
switch(config-if)# switchport mode trunk
switch(config-if)# switchport trunk allowed vlan 1-50
switch(config-if)# channel-group 50 mode active
switch(config-if)# exit
switch(config)# interface port-channel 50
switch(config-if)# vpc 50
switch(config-if)# exit

! 8. Save the configuration
switch(config)# copy running-config startup-config

Repeat the full configuration on the second Nexus switch with its own IPs (peer-keepalive destination/source swapped) and the same vPC domain and port-channel numbers. The downstream device sees one LACP neighbour, not two.

Spanning Tree, peer-switch and peer-gateway

With peer-switch enabled, both peers agree on a single STP bridge ID and both forward BPDUs for the domain, which removes the transient "root changed" events that a role switch would otherwise cause. peer-gateway solves a different problem: without it, a peer that receives a frame destined to the peer-gateway MAC of its partner forwards it across the peer link instead of routing it locally, wasting peer-link bandwidth and adding a hairpin hop.

switch(config-vpc-domain)# peer-gateway
switch(config-vpc-domain)# auto-recovery reload-delay 240
switch(config-vpc-domain)# delay restore interface-vlan 60

auto-recovery lets a peer that has been isolated by a dual failure bring its vPC member ports back after the reload delay, instead of staying down forever. Set it deliberately on every production domain.

vPC with HSRP and First-Hop Redundancy

The classic pattern is a vPC domain plus HSRP: both peers route for the VLAN, HSRP provides the virtual gateway, and vPC provides the active-active Layer 2 path. Because both peers see the traffic, HSRP alone is not enough - you need the peer-gateway feature above, and you must not configure HSRP on a VLAN that only one peer knows about. The same logic applies to VRRP or any VXLAN anycast-gateway design layered on the vPC pair.

Failure Scenarios and Recovery

• Peer link down, peer-keepalive up. The secondary peer suspends its vPC member ports so the downstream device fails over cleanly to the primary. This is the designed behaviour, not a bug.
• Peer-keepalive down, peer link up. The peer link carries the keepalive traffic as a fallback, so nothing breaks immediately - but the domain has lost its independent heartbeat and you should fix the routed path before a peer-link event.
• Both down (split brain). Each peer believes it is primary and both forward the same member ports, producing duplicate frames, duplicate MAC learning and, in the worst case, a loop. This is what orphan ports and auto-recovery exist to bound.
• Consistency check failed. One parameter differs between the peers; only that parameter's traffic is affected, and the failure is usually silent until a specific VLAN breaks.

Orphan Ports and Devices

An orphan port is one that is not part of a vPC but lives on a peer whose peer link is down - for example a single-homed server, a management port, or a firewall in a one-armed design. When the peer link fails, orphan ports stay up unless peer-gateway and orphan-port suspension handling are configured, which can blackhole their traffic. Design out orphan ports where possible, and explicitly test what happens to them during a peer-link failure.

Verification Commands

switch# show vpc
switch# show vpc brief
switch# show vpc consistency-parameters
switch# show vpc consistency-parameters global
switch# show vpc peer-keepalive
switch# show vpc role
switch# show port-channel summary
switch# show lacp neighbor interface port-channel 50

show vpc brief confirms the peer link and member port-channels are up; show vpc consistency-parameters catches configuration mismatches between the peers; show vpc role proves which chassis won the election. Read all three before you declare a domain healthy - a domain can be up and inconsistent at the same time.

Common Mistakes

• Building the domain on one peer and assuming the second copies it. Nothing is synchronised except the consistency checks.
• Reusing the management VLAN for peer-keepalive, so a management outage isolates the domain too.
• A single-member peer link, giving the "redundant" design one point of failure.
• Changing system-mac or system-priority after go-live and taking every member port down at once.
• Applying a port ACL or QoS policy to only one half of a vPC member port-channel - the pair then fails its consistency check.

Related articles: Nexus vPC peer-gateway, orphan ports and health checks, Cisco Nexus NX-OS VLAN and trunk configuration, Leaf-spine vs three-tier data center design, and Data center ToR switch selection.

原文链接：https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/6-x/interfaces/configuration/guide/b_Cisco_Nexus_9000_Series_NX-OS_Interfaces_Configuration_Guide/configuring_vpcs.html