Nexus vPC Peer-Link Troubleshooting: Fix Type-1 Mismatch

A vPC on Nexus makes two switches look like one LACP partner to downstream devices, and nearly every vPC failure traces back to one of two things: the peer-keepalive path or the peer link, or a configuration mismatch between the two peers classified as type-1. The distinction matters because the remediation is completely different — a dead keepalive is a connectivity problem, a type-1 mismatch is a configuration problem, and both produce a vPC that will not come up. This article follows the official troubleshooting order and gives the commands to localise each class of fault.

Why keepalive gates everything

The peer-keepalive link carries periodic heartbeats over Layer 3 connectivity and must be established before the peer link can form. That ordering surprises people: a perfectly cabled peer link stays down until the keepalive is up. The keepalive should be mapped to a dedicated VRF on its own path — if it is not, it lands in the management VRF and requires a management switch connecting both peers' management ports.

switch# show vpc peer-keepalive
switch# show running-config vpc
switch# show vpc

Read show vpc from the top of the output down. "Peer status: peer link is down" with "vPC keep-alive status: Suspended (Destination IP not reachable)" is a keepalive problem; "Peer status: peer link is up" with a configuration consistency failure is a mismatch problem. "Configuration inconsistency reason: Consistency Check Not Performed" appears when the peer link or keepalive has not yet brought the peers into sync — it is a symptom, not a root cause.

The initial checklist

1. Is the peer-keepalive link in a separate VRF, and are both source and destination addresses reachable from that VRF?
2. Is the keepalive link up? The peer link cannot come up without it.
3. Is the peer link configured as a Layer 2 port-channel trunk that allows only vPC VLANs?
4. Is the same vPC number assigned to the downstream port channel on both peers?
5. If system priority was set manually, is it identical on both sides?
6. Do both peers have identical type-1 parameters?
7. Is the primary vPC the primary STP root and the secondary the secondary root?

Type-1 vs type-2 mismatches

A type-1 mismatch suspends the vPC — the vPC will not come up at all. A type-2 mismatch does not suspend the vPC but still breaks forwarding behaviour (for example, a differing MTU). Both are found with the same command family:

switch# show vpc consistency-parameters interface po10
switch# show vpc consistency-parameters global
switch# show vpc consistency-parameters vlans
switch# show vpc consistency-parameters interface port-channel 10

The output prints, per parameter, the local value and the peer value side by side, with the parameters that cause suspension marked type 1. Typical type-1 offenders are STP mode and port cost/priority, allowed VLAN lists, port-channel mode, MTU, and LACP rate. Some of them (allowed VLAN list, MTU, STP settings) can be compared without any traffic impact, which makes this a safe first command rather than a last resort.

When the vPC just will not enable

If show vpc brief errors out because the feature is not enabled, check the feature state before hunting configuration:

switch# show feature
switch# feature vpc
switch# show vpc

Note that vPC requires a license on the platforms where it is not included, so a missing feature is sometimes a licensing issue rather than a typo.

Other documented symptoms and their causes

Verification set to run after every change

switch# show vpc
switch# show vpc peer-keepalive
switch# show vpc consistency-parameters global
switch# show port-channel summary
switch# show spanning-tree
switch# show tech-support vpc

Check that spanning-tree parameters that must match between peers really do: BPDU filter and guard, cost, link type, priority and PVID for PVRST+. Cisco's guidance also requires the primary vPC to be the primary STP root and the secondary peer to be the secondary root; getting this backwards produces asymmetric forwarding that only shows up under failure. show tech-support vpc packages everything for TAC escalation.

For the wider aggregation picture see EtherChannel LACP hashing and load balancing, and for a cross-vendor comparison of aggregation syntax see H3C vs Huawei VLAN and link-aggregation commands.

原文链接：https://www.cisco.com/c/en/us/td/docs/dcn/nx-os/nexus9000/106x/configuration/troubleshooting/cisco-nexus-9000-series-nx-os-troubleshooting-guide-106x/m-troubleshooting-vpcs.html