Two switches that behave as one to everything downstream, without a single blocked link: that is the entire pitch for virtual PortChannel, and it is why almost every Nexus access layer built in the last decade has a vPC domain in it. What follows is a real build on a two-leaf Nexus 9000v pair running NX-OS 10.6(2), part of the lab behind the data center fabric guide. Every block below is verbatim from that session, including one result more interesting than a textbook-clean lab would have produced.
What vPC is actually replacing
Without vPC, a device dual-homed to two upstream switches has two links and can use one. Spanning tree blocks the other to prevent the loop. The alternatives are worse: single-home and lose redundancy, or stack the switches and accept a shared control plane that reboots together.
vPC splits the difference. The two Nexus switches keep independent control planes, configurations and reload schedules, but present a single LACP system ID downstream. The device below sees one logical partner with two active members, and spanning tree sees no loop, so it blocks nothing. That independence is the source of every complication in this article: two brains lying convincingly about being one brain have to stay in constant agreement about what they are saying.
The four components
vpc <id> on both peers. These are the point of the whole exercise.The build
This is the configuration applied to LEAF1. LEAF2 is the mirror image, with role priority 200 and the keepalive addresses swapped:
feature vpc
vpc domain 1
role priority 100
peer-keepalive destination 192.168.100.12 source 192.168.100.11 vrf management
peer-gateway
ip arp synchronize
interface port-channel1
vpc peer-link
Short, and every line earns its place.
feature vpc is mandatory, as with every NX-OS feature. Nothing under vpc domain exists until it is enabled.
role priority 100 makes this switch the preferred primary. Lower wins. The role matters more than people expect, because the primary is the switch that keeps forwarding when the peers stop agreeing.
The keepalive line is the one to get right. Source and destination are the mgmt0 addresses of the two peers, and vrf management puts the heartbeat in the out-of-band VRF that exists on NX-OS before you configure anything. The keepalive travels a path sharing nothing with the peer-link, which is the entire point.
peer-gateway lets each peer route on behalf of the other's router MAC. Some storage and load-balancer implementations reply to the source MAC of a frame rather than to their configured gateway, and without peer-gateway those replies cross the peer-link and get dropped. Enable it.
ip arp synchronize copies the ARP table between peers over CFS, so after a peer-link recovery the returning switch does not have to relearn everything by flooding.
vpc peer-link promotes an existing port-channel. In this lab that was port-channel1, the LACP bundle built earlier across Ethernet1/3 and Ethernet1/4 and described in the Nexus port-channel and LACP walkthrough. The peer-link must be a port-channel and it must be a trunk, and it inherits every member behaviour from that article, suspended members included.
The two warnings NX-OS gives you as you type
Both of these appeared on the console during the build, and both are worth reading rather than scrolling past:
LEAF1(config-vpc-domain)# role priority 100
Note:
Change will take effect after user has:
1. Triggered "vpc role preempt" (non-disruptive - no traffic loss on STP root switch)
OR 2. Re-initd the vPC peer-link (disruptive)
Warning:
!!:: vPCs will be flapped on current primary vPC switch while attempting option 2 ::!!
LEAF1(config-if)# vpc peer-link
Warning: Bridge Assurance MUST be enabled at the remotely connected interface
The first one catches people constantly. Role priority does not take effect when you type it. If the domain is already up and a role has been elected, changing the priority changes only the configured intent. The operational role stays where it is until you run vpc role preempt (non-disruptive) or re-initialise the peer-link (disruptive, and it flaps every vPC on the current primary, which the warning is at pains to tell you). On a running pair, verify the operational role with show vpc rather than reading the config and assuming.
The second warning says vPC turns Bridge Assurance on for the peer-link automatically and the far end must match. Bridge Assurance expects BPDUs in both directions and blocks the port if they stop arriving, which catches a peer that has gone unidirectional while its links stay up. Both ends of a peer-link are vPC peers, so this normally sorts itself out, but NX-OS cannot check the far end from where it stands.
Reading show vpc
This is the healthy state on LEAF1 after both sides were configured:
show vpc
Legend:
(*) - local vPC is down, forwarding via vPC peer-link
vPC domain id : 1
Peer status : peer adjacency formed ok
vPC keep-alive status : peer is alive
Configuration consistency status : success
Per-vlan consistency status : success
Type-2 consistency status : success
vPC role : primary
Number of vPCs configured : 0
Peer Gateway : Enabled
Dual-active excluded VLANs : -
Graceful Consistency Check : Enabled
Auto-recovery status : Disabled
Delay-restore status : Timer is off.(timeout = 30s)
Delay-restore SVI status : Timer is on.(timeout = 10s, 6s left)
Delay-restore Orphan-port status : Timer is off.(timeout = 0s)
Operational Layer3 Peer-router : Disabled
Virtual-peerlink mode : Disabled
vPC Peer-link status
---------------------------------------------------------------------
id Port Status Active vlans
-- ---- ------ -------------------------------------------------
1 Po1 up 1
The first three lines are the health check, and they are three separate things that fail independently:
Peer status: peer adjacency formed okmeans CFS is running across the peer-link and the control planes are talking. The peer-link's report card.vPC keep-alive status: peer is alivemeans the heartbeat is arriving over the management path. The keepalive's report card, and it says nothing about the peer-link.Configuration consistency status: successmeans the Type-1 parameters match. A configuration report card, and it can fail while the other two are healthy.
Keeping those three separate in your head is most of vPC troubleshooting. The vPC peer-link and keepalive failure matrix goes through what each combination of those states means and what the switches do about it.
Further down, Graceful Consistency Check: Enabled matters more than it looks. With it on, a Type-1 mismatch suspends vPCs on the secondary only and the primary keeps forwarding; with it off, both sides suspend and the dual-homed device loses everything. Auto-recovery status: Disabled is the default and the setting most people should change: without it, a pair that loses the peer-link and then reloads can end up with vPCs that never come up.
The peer-link block shows Po1 up carrying Active vlans 1. On a real box that column is a sanity check: a VLAN missing from the peer-link trunk is a VLAN whose traffic cannot cross between peers.
The keepalive in detail
show vpc gives you a one-line verdict on the heartbeat. The dedicated command gives you the mechanics:
show vpc peer-keepalive
vPC keep-alive status : peer is alive
--Peer is alive for : (32) seconds, (872) msec
--Send status : Success
--Last send at : 2026.08.14 17:44:07 820 ms
--Sent on interface : mgmt0
--Receive status : Success
--Last receive at : 2026.08.14 17:44:07 531 ms
--Received on interface : mgmt0
--Last update from peer : (0) seconds, (824) msec
vPC Keep-alive parameters
--Destination : 192.168.100.12
--Keepalive interval : 1000 msec
--Keepalive timeout : 5 seconds
--Keepalive hold timeout : 3 seconds
--Keepalive vrf : management
--Keepalive udp port : 3200
--Keepalive tos : 192
These are the numbers to remember, because they define how fast vPC reacts to a peer disappearing:
The hold timeout of 3 seconds is the subtle one: it stops vPC acting on keepalive loss before the peer-link state has settled. The 5-second timeout is when the peer is declared dead.
Sent on interface: mgmt0 and Received on interface: mgmt0 confirm the heartbeat really is out of band. A keepalive sourced from a front-panel port that also carries the peer-link cannot distinguish "my peer is gone" from "my peer-link is gone", and those two situations require opposite responses.
Type-1 and Type-2 consistency
Because the two peers have independent configurations, vPC continuously compares the settings that matter. This is the top of that comparison on LEAF1:
show vpc consistency-parameters global | head lines 26
Legend:
Type 1 : vPC will be suspended in case of mismatch
Name Type Local Value Peer Value
------------- ---- ---------------------- -----------------------
STP MST Simulate PVST 1 Enabled Enabled
STP Port Type, Edge 1 Normal, Disabled, Normal, Disabled,
BPDUFilter, Edge BPDUGuard Disabled Disabled
STP MST Region Name 1 "" ""
STP Disabled 1 None None
STP Mode 1 Rapid-PVST Rapid-PVST
STP Bridge Assurance 1 Enabled Enabled
STP Loopguard 1 Disabled Disabled
STP MST Region Instance to 1
VLAN Mapping
STP MST Region Revision 1 0 0
QoS (Cos) 2 ([0-7], [], [], [], ([0-7], [], [], [],
[], [], [], []) [], [], [], [])
Network QoS (MTU) 2 (1500, 1500, 1500, (1500, 1500, 1500,
1500, 0, 0, 0, 0) 1500, 0, 0, 0, 0)
Network Qos (Pause: 2 (F, F, F, F, F, F, F, (F, F, F, F, F, F, F,
T->Enabled, F->Disabled) F) F)
Input Queuing (Bandwidth) 2 (0, 0, 0, 0, 0, 0, 0, (0, 0, 0, 0, 0, 0, 0,
0) 0)
Input Queuing (Absolute 2 (F, F, F, F, F, F, F, (F, F, F, F, F, F, F,
The legend states the rule for Type 1 and leaves Type 2 to inference, so here it is explicitly:
That is the whole distinction, and it is the one people get backwards. Type-1 mismatch suspends vPCs. Type-2 mismatch does not. The suspension also applies to vPC member ports, not to the peering itself. The lab proved that by breaking STP Mode on one peer, and the adjacency and keepalive survived untouched, a test written up in the failure matrix article.
Per-vlan consistency status, success above, is a third scope: it checks per-VLAN Type-1 parameters, and a mismatch there suspends only the affected VLANs rather than the whole vPC.
The honest part: zero vPCs and two orphan ports
Look again at one line from the healthy output:
Number of vPCs configured : 0
That is not a typo and it is not a failure. In this lab SRV1 has a single link to LEAF1 and SRV2 has a single link to LEAF2. Neither server is dual-homed, so neither can have a vPC member port. The domain is fully formed and healthy, the peer-link is up, the keepalive is alive, consistency passes, and there is not a single vPC configured for any of that machinery to protect.
A tutorial that quietly cropped that line would be selling you a nicer lab than the one that ran. It also lands on the more common real-world case, because in vPC terminology both servers are orphan ports.
An orphan port is any port on a vPC peer that carries vPC VLANs but is not itself a vPC member port: single-homed servers, appliances, an uplink to a legacy switch, anything connected to one peer only. They are extremely common and they cause the most surprising vPC outages, for one reason. An orphan port's traffic depends on the peer-link that the vPC member ports are designed not to need.
A dual-homed device with a vPC has a path to both peers, so if one peer fails its traffic hashes onto the surviving member. A single-homed orphan on LEAF1 has one path, and if its destination sits behind LEAF2 that traffic must cross the peer-link. Take the peer-link away and the orphan is isolated, even though its own link is perfectly up.
By default an orphan port stays up when the peer-link goes down, so it stays up while potentially cut off from most of the network. The knob is vpc orphan-port suspend on the interface, which brings the orphan down alongside the vPC member ports on peer-link failure, so a server orphaned on one NIC fails over to its other NIC instead of black-holing. If the device really is single-attached, suspending it turns a partial outage into a total one, so this is a judgement call about what is downstream, not a blanket best practice.
Where this fits
vPC is the Layer 2 redundancy layer at the access edge, and it stops being the whole story once the fabric moves to VXLAN and EVPN, where two vPC peers share an anycast VTEP address and act as one logical VTEP. That interaction is covered in the spine-leaf data center fabric guide, alongside the port-channel and LACP article and the peer-link and keepalive failure matrix.
Key Takeaways
- vPC keeps two independent control planes while presenting one LACP system downstream, so spanning tree blocks nothing.
role prioritydoes not take effect immediately. It needsvpc role preemptor a peer-link re-init, so trustshow vpcover the config for the operational role.- Peer status, keepalive status and consistency status are three independent health checks. Read them as three, not one.
- The keepalive is UDP 3200, 1000 msec interval, 5 second timeout, 3 second hold, in the management VRF out of mgmt0. Keep it off any path that shares fate with the peer-link.
- Type-1 mismatch suspends vPC member ports. Type-2 mismatch only logs. Most Type-1 parameters are spanning tree settings.
Number of vPCs configured : 0is what a healthy domain with only single-homed servers looks like.- Orphan ports are single-homed ports on a vPC peer. They depend on the peer-link, they stay up by default when it fails, and
vpc orphan-port suspendis how you change that.