QA (public) » openQA Project (public) » openQA Tests (public)

Where we have jumbo frames, they are on the uplinks between our devices, not facing the users.
I don't know about GRE tunnels using openvswitch, but it should be easy to test. One is the tracepath command, the other one is ping, as in:

ping -M do -c 1 -s 1500 <destination_IP>

-M do = prohibit fragmentation
decrease 1500 by 10 until ping works and you'll find the lowest MTU, or if MTU issues.

Verifying the connectivity explicitly in tests sounds useful to distinguish real problems from issues with services that are just temporarily not reachable.

I just come to this ticket because I was pointed at a cluster of failing jobs. These jobs already log the mtu, e.g. see step https://openqa.suse.de/tests/12118392#step/before_test/49:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1458 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:12:0c:20 brd ff:ff:ff:ff:ff:ff
    altname enp0s4
    altname ens4
    inet 10.0.2.15/24 brd 10.0.2.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe12:c20/64 scope link 
       valid_lft forever preferred_lft forever

All the other jobs in the cluster also have an mtu of 1458. Not sure whether that value is to be trusted, though. Supposedly it is even wrong (considering our issues) and one had to to a check like in #135200#note-6 to find out what works for real. Then one could try to set that via e.g. ifconfig eth0 mtu … and maybe that'll even help.