Skip to main content

Diagnose and fix an MTU mismatch

VKB-1147Troubleshooting
📦 Applies to
XCP-ng
🗓️ Created
2025-03-07
🔄 Updated
2026-08-12
🏷️ Tags
#mtu#networking#jumbo-frames#migration

Symptoms​

Packet loss, timeouts and degraded throughput, especially during high throughput operations such as VM migration. Applications transferring large amounts of data see timeouts or errors, and migrations can fail outright.

Day-to-day operations may look fine while large transfers fail, which is the pattern that points at MTU rather than at general connectivity.

Environment​

Any XCP-ng or XO deployment where devices along a network path may be configured differently, particularly where jumbo frames are in use on some devices but not all.

Diagnosis​

Send a ping that must not be fragmented, with a payload sized to the MTU you expect. Subtract 28 bytes of packet overhead from the ethernet MTU, so 8972 for 9000 and 1472 for 1500:

root@dom0
# ping -c 10 -M do -s <PAYLOAD_SIZE> <TARGET_IP>

-M do forbids fragmentation, so the ping fails rather than quietly succeeding at a smaller size. That failure is the result you are looking for.

Work down the sizes until the ping succeeds: the largest size that gets through is the real path MTU, and if it is below what the devices are configured for, you have found the mismatch.

Cause​

The maximum transmission unit is the largest packet a network can carry without fragmenting. A mismatch is when devices along one path are configured with different values, for example one supporting jumbo frames at 9000 bytes and another limited to the standard 1500.

Devices that cannot handle the larger packet either drop it, causing loss, or fragment it, adding latency and reducing efficiency.

Resolution​

  1. Fix: make the MTU consistent along the whole path. Every device between the endpoints has to agree, including switches and any bond, so a change on the hosts alone is not enough.

  2. Fix: to set a network back to the standard MTU in XCP-ng, get the network UUID from xe network-list, then:

    root@xcp-ng
    # xe network-param-set uuid=<network-uuid> MTU=1500

    Reboot the host after changing the MTU.

  3. Re-test with the ping above and confirm the intended payload size now passes.

  • Check OVS bonds, MTU and link speed on a host

Related articles

  • VKB-1170Reset host networking from the CLI in an emergencyHow-to
  • VKB-1128Migration from VMware to XCP-NGReference
  • VKB-1031Migrate to new XOAHow-to