VXLAN EVPN vPC Peer-Link Failure with Orphan Ports
A financial services firm runs a VXLAN EVPN fabric with two spine switches and six leaf switches on NX-OS 10.2(5). Leaf-03 and Leaf-04 form a vPC pair for VLAN 210, whose anycast gateway is 10.20.10.1/24. A dual-homed bare-metal server uses LACP to both leafs; a single-homed backup server connects only to Leaf-04. At 02:14 the vPC peer-link between Leaf-03 and Leaf-04 fails because a conduit is cut. The vPC keepalive remains up over the management network. Leaf-03 becomes vPC primary. The dual-homed server's LACP link to Leaf-04 drops, while the link to Leaf-03 stays up. The backup server loses all connectivity. Remote hosts report about 40 percent packet loss to the dual-homed server. The on-call engineer proposes shutting Leaf-04 or disabling orphan-port suspend globally to restore service.
1. Explain why the backup server loses all connectivity and why the dual-homed server sees about 40 percent loss even though its LACP link to Leaf-03 remains up. What Leaf-04 behavior is responsible?
Read the worked answer
When the vPC peer-link fails, the vPC secondary, Leaf-04, suspends its vPC member ports. By default it also suspends orphan ports, so the single-homed backup server on Leaf-04 goes down. The dual-homed server keeps its LACP bundle to Leaf-03, but Leaf-04 still has the VLAN 210 SVI, anycast gateway, and VXLAN VTEP. It continues to advertise the subnet and anycast gateway MAC into the underlay and EVPN, so remote leafs still ECMP traffic toward Leaf-04. Leaf-04 cannot reach the server because its vPC member ports are suspended and the peer-link is down; those packets are dropped. The roughly 40 percent loss is consistent with ECMP hashing: some flows land on Leaf-03 and are delivered, others land on Leaf-04 and blackhole. ARP or return traffic can make the pattern look intermittent. The backup server is a separate failure: it is an orphan port, so it is suspended by default when the peer-link is lost. That is the key distinction between a dual-homed vPC port and a single-homed orphan port.
2. Which commands confirm the vPC role, suspended ports, and orphan-port state? Why is `no vpc orphan-port suspend` a risky global fix?
Read the worked answer
Use show vpc and show vpc role to confirm Leaf-03 is primary and Leaf-04 secondary; show vpc brief and show vpc consistency-parameters to see peer-link and VLAN consistency; show interface status and show lacp neighbor to see which member ports are suspended; show vpc orphan-ports to list orphan ports; and show spanning-tree vlan 210 to check topology. The global no vpc orphan-port suspend command allows orphan ports on the secondary to stay up during a peer-link failure. That can restore the backup server, but it removes a loop-prevention guard: a single-homed device that is also connected through another path can create a bridging loop or duplicate traffic. It does not fix the dual-homed server's ECMP blackhole, because that is caused by vPC member ports being suspended, not orphan ports. Applying it globally affects every orphan port on the switch, including ports that were deliberately protected. Treat it as a per-design exception, not an incident-wide workaround.
3. Recommend immediate remediation and a long-term design change.
Read the worked answer
Immediate: restore the peer-link first, because that is the only action that returns both the orphan port and the vPC member ports to normal without weakening loop protection. If the conduit cannot be restored quickly, move the backup server to Leaf-03 or another switch, and consider temporarily shutting Leaf-04's VLAN 210 SVI/VTEP or uplinks so remote ECMP stops selecting it; that is a controlled blast-radius decision, not a global orphan-port change. Do not shut Leaf-04 blindly if other vPC pairs depend on it. Long term: give the peer-link a physically diverse path and verify that the keepalive is not sharing fate with the peer-link. For dual-homed servers, consider EVPN multihoming with ESI rather than vPC, because it gives active-active multihoming with per-ESI failover and avoids the secondary-suspends-ports behavior. Remove single-homed orphan ports from vPC pairs where possible, or document them and monitor show vpc orphan-ports. Test peer-link failure in a maintenance window so the ECMP and orphan-port behavior is known before an incident.