After enabling VXLAN on the municipal fabric, operators see MTU blackholes for large tenant frames. What data-plane planning issue is most likely?
Select an answer to reveal the explanation.
Short Explanation
VXLAN wraps the original frame, so the outer packet gets bigger—like a letter plus a thick courier pouch. If the underlay MTU cannot fit that pouch, big civic frames quietly die on the road. Fix underlay MTU or MSS carefully; do not blame Type-2 route length for an MTU blackhole.
Full Explanation
After enabling VXLAN on the municipal fabric, MTU blackholes for large tenant frames most likely mean encapsulation overhead was not planned into underlay MTU or path MTU/MSS handling. VXLAN/UDP/IP headers increase packet size relative to the original tenant frame; if underlay paths remain at a standard 1500-byte MTU without headroom, large frames drop—especially when jumbo frames were enabled only on host access ports.
VXLAN does not shrink underlay headers, so operators must not lower underlay MTU below 500 bytes as a remedy. MTU blackholes do not prove EVPN Type-2 routes are too long and must be disabled. Claiming only multicast BUM needs MTU planning while unicast VXLAN never adds bytes is false—unicast encapsulation consumes the same header overhead on every encapsulated frame.
Exam caveat: raise underlay MTU or carefully manage tenant MSS for VXLAN overhead; do not blame EVPN route length for Ethernet MTU blackholes on JN0-683 items.
Operational check: measure end-to-end underlay MTU between VTEPs, send maximum-sized tenant frames, raise fabric interfaces to the municipal jumbo standard, and retest until blackholes clear for both unicast and BUM encapsulated traffic. Document the overhead budget in the city fabric standard for future leaf additions.