vPC Member Ports Suspended After a One-Sided MTU Change
Two Nexus 93180YC-EX switches run NX-OS 10.2(4) as a vPC pair (domain 10). The peer-link is port-channel 10 on Ethernet1/49-50, and the keepalive uses mgmt0 in VRF management. Server access ports Ethernet1/1-2 form vPC 240 toward a downstream pair of Catalyst 9300 switches in a port-channel. During a change window, an engineer raised the interface MTU to 9216 on the Nexus-A member ports only and added VLAN 240 to the downstream trunk. Since then, roughly half of the hosts in VLAN 240 have lost connectivity, and the Catalyst port-channel reports one member suspended. On Nexus-B, show vpc lists vPC 240 as down* with reason "consistency mismatch". show vpc consistency-parameters vpc 240 lists MTU as a type-1 parameter with local 1500 and peer 9216. The peer-link is up, the keepalive is up, and vPC 241 on the same pair is healthy. Traffic that hashes to Nexus-A works; traffic that hashes to Nexus-B fails.
1. Explain why vPC 240 is suspended on Nexus-B but not on Nexus-A. Which commands confirm the diagnosis and rule out a peer-link or keepalive failure?
Read the worked answer
vPC uses a primary/secondary model. Type-1 parameters must match on both sides; when they do not, NX-OS suspends the vPC member ports on the secondary switch only, while the primary keeps its ports forwarding. That is why Nexus-A still passes traffic and Nexus-B does not.
Confirm the role and the mismatch with show vpc role, show vpc brief, and show vpc consistency-parameters vpc 240 on both switches. Rule out peer-link and keepalive problems with the peer-link status in show vpc brief, show vpc peer-keepalive, show port-channel summary interface port-channel 10, and show interface Ethernet1/49-50.
A peer-link failure would suspend every vPC on the secondary with reason "peer-link down", not "consistency mismatch", and vPC 241 would also be down. Because vPC 241 is healthy and the mismatch explicitly names MTU, the peer-link is not the cause.
2. Give the least-disruptive remediation sequence and the verification steps. How would you handle the downstream Catalyst if it cannot support an MTU of 9216?
Read the worked answer
Treat Nexus-B first, because its vPC member ports are already suspended and no production traffic flows there. Change the MTU under the vPC member interfaces on Nexus-B to match (interface range Ethernet1/1-2; mtu 9216), then verify that show vpc consistency-parameters vpc 240 shows no type-1 mismatch and that show vpc brings vPC 240 up on B.
Schedule the Nexus-A change in a window: raising MTU is usually non-disruptive, but any neighbor that cannot handle 9216-byte frames will drop them. If the Catalyst 9300 pair supports only 9198, set all devices to 9198 or revert Nexus-A to 1500 rather than leaving an asymmetric value.
After both changes, confirm vPC 240 is up on both peers, the Catalyst port-channel has both members, and the trunk allowed-VLAN lists for VLAN 240 are identical on both Nexus switches. An allowed-VLAN mismatch is type-2, so it will not suspend the vPC, but it will blackhole traffic. Finish with a large-frame ping with the DF bit set.