vPC

Why it exists

STP blocks one uplink of a dual-homed access switch. vPC lets two Nexus peers present one port channel so both uplinks forward without forming a loop. Cisco Nexus 9000 Series NX-OS Interfaces Configuration Guide, Release 10.5(x) — Configuring vPCs §vPC Overview

The peers remain two control planes with two configurations. Consistency checks synchronise what must match; they do not merge the boxes into a stack. Cisco Nexus 9000 Series NX-OS Interfaces Configuration Guide, Release 10.5(x) — Configuring vPCs §Consistency Check Behavior

One logical channel from two peers

Two Nexus switches share a vPC domain, a peer-link, and a separate peer-keepalive path. Downstream, LACP sees one system ID so both uplinks forward.

How it works

A vPC domain binds two peers. The peer-link carries control traffic and orphan-port traffic. Peer-keepalive is a separate Layer-3 path used when the peer-link fails to decide whether the peer is still alive. Cisco Nexus 9000 Series NX-OS Interfaces Configuration Guide, Release 10.5(x) — Configuring vPCs §Peer-Keepalive Link and Messages

If the peer-link fails and keepalive still reaches the peer, the secondary disables its vPC member ports. One survivor forwards. If keepalive is also gone, both peers may go dual-active. Cisco Nexus 9000 Series NX-OS Interfaces Configuration Guide, Release 10.5(x) — Configuring vPCs §vPC Peer-Link Failure and Peer-Keepalive

Type-1 consistency mismatches can suspend VLANs or members; type-2 mismatches warn. Orphan ports are single-attached and need dual-attach or orphan-port suspend to survive secondary suspension cleanly. Cisco Nexus 9000 Series NX-OS Interfaces Configuration Guide, Release 10.5(x) — Configuring vPCs §Consistency Check Behavior

On the wire

Constructed examples, encoded from the field table below them — not captured traffic.

Configure it

When it breaks

Symptom first, because that is what you have when it happens.

1. A configuration change is rejected, or a VLAN is suspended on the peer link with a consistency-check message.

   Narrow it down

   1. Read the consistency-check output and find which parameter differs.
   2. Distinguish a type-1 mismatch, which suspends VLANs, from a type-2, which warns.
   3. Compare the specific setting on both peers.

   Cause

   The two peers must agree on a defined set of parameters. Type-1 mismatches suspend VLANs on the secondary because forwarding with inconsistent state would loop or blackhole; type-2 only warn.

   Fix

   Fix the parameter rather than disabling the check. It is enumerating a real inconsistency, and the suspension is what stops it becoming an outage.

   Cisco Nexus 9000 Series NX-OS Interfaces Configuration Guide, Release 10.5(x) — Configuring vPCs §Consistency Check Behavior

2. The peer link fails and half the network becomes unreachable, though both switches are up.

   Narrow it down

   1. Check whether the peer keepalive is on a separate path from the peer link.
   2. Confirm which switch is operational primary.
   3. Look at whether the secondary suspended its member ports.

   Cause

   When the peer link fails but keepalive still works, the secondary suspends its virtual port channel members so the primary keeps forwarding alone. That is the design; the outage is anything that was only reachable through the secondary.

   Fix

   Ensure orphan ports are not carrying anything that matters, and keep the keepalive on a genuinely independent path — if both fail together, both switches forward and it is a split brain.

   Cisco Nexus 9000 Series NX-OS Interfaces Configuration Guide, Release 10.5(x) — Configuring vPCs §vPC Peer-Link Failure and Peer-Keepalive

3. A device attached to only one peer loses connectivity during a peer-link event.

   Narrow it down

   1. Identify which ports are orphan ports.
   2. Check whether orphan port suspension is configured.
   3. Confirm what the device depends on reaching.

   Cause

   An orphan port is attached to one peer only and is not part of a virtual port channel. When the secondary suspends its members, an orphan on the secondary is isolated unless it is suspended too so the device fails over by other means.

   Fix

   Dual-attach anything that matters. Where that is impossible, configure orphan port suspension so the device sees a link failure rather than a silent black hole.

   Cisco Nexus 9000 Series NX-OS Interfaces Configuration Guide, Release 10.5(x) — Configuring vPCs §vPC Orphan Ports

4. Both peers keep forwarding after a peer-link failure and loops or MAC flaps appear.

   Narrow it down

   1. Check peer-keepalive reachability at the time of the event.
   2. Confirm keepalive is not routed over the peer-link or a dependent path.
   3. Inspect show vpc brief for dual-active indicators.

   Cause

   Peer-link and keepalive failed together, or keepalive was never independent. Each peer concluded it was the survivor.

   Fix

   Restore an independent keepalive path before relying on peer-link failure behaviour; clear dual-active and re-establish the domain cleanly.

   Cisco Nexus 9000 Series NX-OS Interfaces Configuration Guide, Release 10.5(x) — Configuring vPCs §Peer-Keepalive Link and Messages

5. The vPC peer-link will not come up even though the port channel looks healthy.

   Narrow it down

   1. Verify peer-keepalive is up before expecting the peer-link.
   2. Ping between keepalive addresses in the configured VRF.
   3. Confirm source and destination IPs and VRF mapping.

   Cause

   NX-OS requires the peer-keepalive link to be up before the peer-link can form. Misplaced keepalive (wrong VRF, no L3 path) blocks domain formation.

   Fix

   Bring keepalive up on a working Layer-3 path first, then form the peer-link.

   Cisco Nexus 9000 Series NX-OS Interfaces Configuration Guide, Release 10.5(x) — Configuring vPCs §Peer-Keepalive Link and Messages

Design notes

Put peer-keepalive on a path that does not depend on the peer-link — often a dedicated VRF or management path with genuine Layer-3 reachability.

Dual-attach anything that matters. Orphans on the secondary become the hidden outage during the designed peer-link recovery.

Spanning tree still runs. vPC changes how the pair presents itself to neighbors; it does not remove the need for STP on miscabling outside the vPC members.

Misconceptions

“vPC makes the two switches one switch.”

They remain two control planes with two configurations, synchronised by consistency checks rather than merged. That is the difference from a stack or a chassis virtualisation, and it is why every parameter that must match is checked explicitly.

“The peer link carries data traffic between the switches.”

It carries control traffic and orphan-port traffic, and it is deliberately not a data path for virtual port channel members — the receiving peer will not forward a frame that arrived over the peer link out a member port. That rule is what prevents loops.

“Spanning tree is not needed with vPC.”

It still runs and still matters. The pair presents itself as one bridge for the purpose, but a loop introduced by miscabling outside the virtual port channels is caught by spanning tree exactly as it would be otherwise.

More walkthroughs

Terms

vPC peer-link

The Cisco MLAG link between two peers. It is not a member of the downstream vPC. If it fails while keepalive is alive, the secondary suspends member ports.

Check yourself

• Where should peer-keepalive run relative to the peer-link?

  • On the peer-link itself for lowest latency
  • On a separate Layer-3 path that does not depend on the peer-link
  • Only on vPC member ports
  • Only after the peer-link is up
• The peer link fails while the keepalive still works. What happens?

  • Both switches keep forwarding
  • The secondary suspends its virtual port channel members and the primary forwards alone
  • Both suspend
  • The pair reloads
• A VLAN is suspended on the secondary peer with a consistency-check error. What should you do?

  • Disable the consistency check
  • Fix the mismatched parameter — the suspension is preventing a loop or a black hole
  • Reload the secondary
  • Move the VLAN off the peer link
• What is an orphan port?

  • A port with no VLAN
  • A port attached to one peer only, not part of a virtual port channel
  • A suspended port
  • A port on the peer link
• Why will a peer not forward a frame from the peer link out a member port?

  • The peer link is too slow
  • It would duplicate a frame the far end already received directly, so the rule prevents loops
  • The VLAN is suspended
  • Spanning tree blocks it
• How many control planes does a healthy vPC pair have?

  • One merged control plane
  • Two — each peer keeps its own configuration, checked for consistency
  • None — forwarding is purely data-plane
  • Three including the access switch
• Does spanning tree still matter when vPC is in use?

  • No — vPC replaces STP
  • Yes — miscabling outside vPC members is still caught by spanning tree
  • Only on the peer-link
  • Only when LACP is disabled
• What does the access switch see for LACP toward a vPC pair?

  • Two independent system IDs that STP must block between
  • One shared LACP system ID so both member links can forward
  • No LACP — vPC is static only
  • A different key on every frame

Related

• LACP

  A standard handshake that binds parallel links into one logical port — and refuses to forward on a member the far end has not agreed to.

• STP

  Keeps a switched network free of loops by disabling just enough ports to leave one active path between any two bridges.