I've had this idea for a long time (I fixed the kernel to support it in r162205[1]) and even used a manual version of it a long time ago in production for NFS servers, but never got around to producing an automatic version of it.
Now I have: https://github.com/jmgurney/automtud It's a simple script that when run, will configure an interface to it's largest support MTU, set the network route to the default normal 1500 byte MTU so that communication w/ other machines works as normal, and then monitor and probe other hosts to figure out just how large of an MTU that host will accept. Sample run: # sh automtud.sh -i re0 setting up: re0 Setting MTU on interface re0 to 6122. setting normal mtu on interface re0 for network 192.168.0.0/24 change net 192.168.0.0: gateway re0 machine 192.168.0.2 add on interface re0 adjusting 192.168.0.2 mtu to 6122 machine 192.168.0.14 add on interface re0 adjusting 192.168.0.14 mtu to 1504 The adjustment to 1504 on .14 is because the interface also has VLANs, but .14 is untagged, and so we can sneak an extra 4 bytes in the packet. The bad part of this is that the iface still appears to have the normal 1500 byte MTU: npe1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=80008<VLAN_MTU,LINKSTATE> The script should work on all modern releases of FreeBSD, though feedback where it breaks is welcome. I'd like to hear of any issues that you may run into, but I'm pretty sure often it'll be, we need to fix driver X as most drivers do not handle Jumbo frames well. In most cases, it'll be the driver needs to be changed to use either cluster (2k) or page sized clusters instead of 9k or 16k clusters when configured for jumbo frames. On my old 9.2-R box that I tried it on, I ran into issues where I got tons of 9k cluster allocation failures, probably just need to increase the limit, but it'd still be better to use page sized clusters instead: ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP mbuf_jumbo_9k: 9216, 6400, 0, 1110,65208532,814941, 0 I haven't looked at fixed the em driver yet. [1] https://svnweb.freebsd.org/changeset/base/r162205 P.S. Probing time could be made faster if ping -t supported sub-second values as if a host on a local segment hasn't replied in, say, 100ms, it's probably not going to, or you need to fix the network. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
