Multi-Pod Data Path MTU Mismatch
Your ACI fabric runs one APIC cluster across two pods. Each pod has two spines and four leaves, and the pods connect through an IPN built on a pair of Nexus switches. Intra-pod traffic works, but hosts in Pod-1 cannot reach hosts in Pod-2. COOP shows the remote spines as reachable and stable, LLDP on the IPN shows every spine uplink up, and the fabric has no faults for the pod connections. The IPN routers are configured with a system jumbo MTU of 9216, but the interfaces facing the spines were left at the default 1500. The ACI spine uplinks use the default fabric MTU of 9150. A ping between the Pod-1 spine TEP (10.0.1.1) and the Pod-2 spine TEP (10.0.2.1) succeeds with a 1400-byte payload and fails with a 1600-byte payload when the DF bit is set. Endpoint counts are normal in both pods, and the TEP pools are 10.0.1.0/24 and 10.0.2.0/24.
1. Which plane is failing, and what is the most likely root cause? Cite the specific evidence from the setup.
Read the worked answer
The control plane is healthy: COOP peer state, LLDP and the absence of pod faults all show that the spines can exchange routing and endpoint information. The failure is in the data path, and the DF-bit ping isolates it to the IPN: 1400-byte payloads fit, 1600-byte payloads do not. A VXLAN-encapsulated frame adds roughly 50 bytes of overhead (outer Ethernet, IP, UDP and VXLAN headers) to the original frame, so a normal 1500-byte host frame becomes about 1550 bytes on the wire. The IPN spine-facing interfaces are at 1500, so every encapsulated data frame is dropped, while the small COOP and LLDP control frames pass. That is why the fabric looks healthy but inter-pod hosts cannot communicate: it is an MTU mismatch on the IPN, not a COOP, endpoint-learning or routing problem.
2. What commands and tests would you use to confirm the diagnosis, and what is the fix?
Read the worked answer
Confirm on the IPN with show interface ethernet <x/y> and show run interface <x/y>: the running MTU must be 9150 (or at least the ACI fabric MTU) on every spine-facing interface and on the vPC peer-link, not just in the global system jumbo mtu setting. On the ACI side, check the spine uplink interfaces and the fabric interface policy: ACI fabric ports default to 9150, so the 1500 side is the IPN. Test with DF-bit pings of increasing size (1400, 1500, 2000, 9000) between the spine TEP addresses. The fix is to set mtu 9150 on the IPN spine-facing interfaces and peer-link, then re-test; if any intermediate device in the IPN path is at 1500, it must be changed too, because the end-to-end path MTU is the minimum.
3. Why does intra-pod traffic still work, and what does that tell you about where to look?
Read the worked answer
Intra-pod traffic never crosses the IPN. Leaf-to-leaf VXLAN within a pod is switched over the spine-leaf fabric links, which run at the ACI fabric MTU (9150), so the encapsulated frame fits and the ping succeeds. The MTU defect is only on the IPN interfaces, which are used exclusively for inter-pod VXLAN between the pod spines. This is also why endpoint learning and COOP look normal: those messages are small and never need the larger MTU. The failure pattern therefore points at the pod-to-pod underlay, not at the leaves, the APIC, or the endpoint database. When you fix the IPN MTU, inter-pod traffic should work without any change to EPGs, BDs or contracts, because the policy has always been correct.