Nexus vPC: Peer-Gateway, Orphan Ports and Health Checks

2026年9月14日 LOG admin

A vPC build is easy to copy from a template and hard to debug when it misbehaves. Two switches present one port-channel to the access layer, one becomes primary and keeps forwarding when the peers disagree, and a keepalive over the management VRF decides who is still alive. The interesting failures live in the details: tools that reply to the router MAC instead of the gateway MAC, single-homed devices connected to one peer, and type-1 parameter mismatches that refuse to bring a port-channel up. This guide covers those three, plus the health checks worth running before any change window.

The Non-Negotiables of the Build

Peer-keepalive must use a path independent of the peer-link — typically mgmt0 in the management VRF. If keepalive and peer-link share fate, a link failure looks like a dual-active event.
Role priority decides the primary, and the primary is the switch that keeps forwarding when peers stop agreeing. Verify the operational role with show vpc rather than assuming from config.
The peer-link is a trunk port-channel carrying control traffic and any orphan traffic that must cross; use at least two high-speed links and let Bridge Assurance do its job.
vPC number, port-channel mode and allowed VLANs must match on both peers. These are type-1 parameters and a mismatch shows up as a failed vPC, not a warning.

Nexus-1(config)# feature vpc
Nexus-1(config)# feature lacp
Nexus-1(config)# vpc domain 1
Nexus-1(config-vpc-domain)# role priority 20
Nexus-1(config-vpc-domain)# peer-keepalive destination 10.1.1.2 source 10.1.1.1 vrf management
Nexus-1(config-vpc-domain)# ip arp synchronize
Nexus-1(config-vpc-domain)# peer-gateway

Nexus-1(config)# interface port-channel 10            ! peer-link
Nexus-1(config-if)# switchport mode trunk
Nexus-1(config-if)# vpc peer-link

Nexus-1(config)# interface port-channel 30            ! downstream vPC
Nexus-1(config-if)# switchport mode trunk
Nexus-1(config-if)# vpc 30

Configure keepalive before the peer-link: a domain that forms without a reachable heartbeat has no protection against a split.

Peer-Gateway: Why Storage and Load Balancers Need It

peer-gateway lets each peer route on behalf of the other's router MAC. The reason it exists: some storage arrays and load balancers reply to the source MAC of a frame rather than to their configured gateway MAC. Without peer-gateway those replies arrive on the wrong peer, cross the peer-link and are dropped — which looks exactly like a flaky application problem. Enable it, and pair it with ip arp synchronize so the two peers share their ARP tables: after a peer-link or device recovery, the returning switch does not have to relearn everything by flooding.

Orphan Ports: Single-Homed Devices on a vPC Domain

Any device connected to only one member of the pair is on an orphan port. It works fine in steady state, but during a peer-link or keepalive failure the secondary peer suspends its vPC ports — and the orphan port on the wrong side can black-hole traffic. NX-OS gives you an explicit control:

Nexus-1(config)# interface Ethernet1/10
Nexus-1(config-if)# vpc orphan-port suspend

Declaring the port as an orphan makes it shut down when the peer suspends its vPC ports, forcing the connected device to fail over cleanly rather than half-work. Cisco's own guidance for orphan ports in VXLAN/EVPN designs goes further and recommends configuring vpc orphan-port suspend on both vPC nodes to prevent traffic disruption when the NVE fails. If you cannot use suspend, make the single-homed device's own redundancy (bonding/NIC teaming with two links to different peers) carry the load.

Verification: Read the Health Output, Not the Config

show vpc
show vpc brief
show vpc consistency-parameters global
show vpc consistency-parameters interface port-channel 30
show port-channel summary
show vpc role
show vpc peer-keepalive

What good output looks like: peer-link status up with the expected active VLAN list, every vPC showing success consistency, peer-gateway enabled, and — per Cisco's checklist — the primary vPC also being the primary STP root, and the secondary the secondary root.

Troubleshooting the Usual Suspects

Symptom	Check and fix
All vPCs show failed — Peer-link is down	The peer-link is the single dependency for every vPC. Verify the port-channel membership on both sides and that allowed VLANs match.
"Received Type 1 configuration element mismatch"	`show vpc consistency-parameters interface`. Type-1 mismatch: identical port-channel settings, VLAN lists, MTU, speed/duplex and vPC number are required.
Keepalive in the default VRF	If the keepalive ends up in the management VRF by default, confirm both management ports are actually reachable through it — otherwise duplicate role detection cannot work.
Servers behind vPC ports cannot ping a single-homed server	Traffic between orphan ports on different peers depends on the peer-link and on the design. Check whether both hosts are truly vPC members; duplicated traffic is dropped by design.
Interrupted forwarding during peer-link recovery	Enable ARP synchronisation and review orphan-port suspend settings; also check for a vPC that is inconsistent only during reconvergence.
Role changed unexpectedly after a reload	Verify `role priority` on both peers; the primary role determines which node keeps forwarding.

Change-Window Checklist

Record show vpc and show vpc consistency-parameters global output before the change as your baseline.
Confirm keepalive reachability over the out-of-band path, not through the peer-link itself.
Confirm STP root roles match vPC primary/secondary.
After the change, verify both sides again — and test a real server-to-server flow, not just VLAN reachability.

原文链接：Cisco Nexus 9000 NX-OS Troubleshooting Guide - Troubleshooting vPCs

作者：admin

链接：https://gitgit.ee/cisco-nexus-vpc-orphan-port-peer-gateway-guide.html

文章版权归作者所有，未经允许请勿转载。