A server in the parks department sends jumbo frames that fit the access MTU but exceed what the underlay can carry once VXLAN headers are added. What planning issue does this expose?
Select an answer to reveal the explanation.
Short Explanation
The moving van fit in the driveway but not through the tunnel with the crate stacked on top. Access MTU isn’t enough—you need underlay headroom for the VXLAN wrapper. Size the whole path or watch silent drops and fragmentation drama.
Full Explanation
When a parks-department server sends jumbo frames that fit the access MTU but exceed what the underlay can carry once VXLAN headers are added, the planning issue is that end-to-end MTU must account for VXLAN overhead across the underlay path, not only the access port MTU. An access MTU that admits large frames can still produce underlay packets that exceed spine or core MTU and blackhole intermittently.
VXLAN does not automatically fragment every jumbo frame at the VTEP with no operational impact. Only the spine MTU does not matter while leaf access MTU is ignored after EVPN comes up—both ends of the encapsulated path matter. Jumbo frames are not converted to VXLAN control pings that bypass underlay MTU checks.
Exam caveat: engineer end-to-end MTU including encapsulation overhead; access-only jumbo is a classic civic fabric pitfall.
Operational check: compare access MTU, underlay interface MTUs, and path MTU between VTEPs; send max-sized frames; raise underlay MTU or reduce tenant MTU until encapsulated packets traverse without loss. Standardize a fabric jumbo MTU value in the parks DC build guide and enforce it on every leaf-spine link. Retest after adding a new spine to ensure the new paths inherit the same MTU.