The purpose of this article is to describe a specific MTU issue/scenario that may appear in an EVPN-VXLAN network: After moving some hosts to Juniper QFX5120-48YM switches in an EVPN/VXLAN environment, jumbo frame traffic was failing only for some destinations.
The QFX links were configured for jumbo MTU, and tests across the Juniper fabric passed with large packets using the DF bit(do not fragment). However, some host-to-host and host-to-storage tests still failed when the packet size was increased.
The issue was not affecting all traffic. The same source host could successfully send jumbo frames to one destination, but jumbo frames failed to another destination using a similar path. The topology included QFX switches connected to external switching/storage infrastructure.
Example test method:
ping -M do -s 8972 <destination-ip>
A smaller test worked, but increasing the size slightly caused the ping to fail. This showed that the failing destination path was not allowing jumbo frames end-to-end.
The issue was caused by an MTU misconfiguration on the affected destination host/client side.
The Juniper QFX fabric was not the root cause. Jumbo frame testing across the QFX fabric was successful, and the same source host could send jumbo frames to other destinations. Because the failure was destination-specific, the issue pointed to the destination host or its local access path.
Recommended checks:
-> Correct the MTU setting on the affected destination host/client side.
-> Also verify MTU consistency across the full path:
After the destination host MTU was corrected, jumbo frame traffic passed as expected.
Notes: When testing jumbo frames, always use the DF bit. Otherwise, packets may be fragmented and the test result can be misleading:
Linux
Windows
ping <destination-ip> -f -l 8972
If jumbo frames fail only to specific destinations but work to others from the same source, focus on the affected destination host, its NIC MTU, and the local access path.