On 2016-09-19 3:28 pm, Lyndon Nerenberg wrote:
This is almost certainly a PMTUd issue.

Unless your end-to-end paths to everything you talk to have
jumboframes configured, there's no benefit to setting them up on the
lagg.  Just go with the default MTU.


Everything on physical Ethernet has support for it Including the LAN interface of Firewall, and talks to it just fine over a single interface with Jumbo frames enabled. Just when I introduced the LAGG interface other devices with Jumbo frames enabled stopped talking. I was trying to speed up my backups (Bacula runs on one of the jails, NAT Reflection isn't used for the Bacula services) which take about 7.5 hours over a single interface to complete on the weekly fulls, I Have two simultaneous jobs running at the start, and I was hoping that the LAGG would speed them up, but I suspect the loss of Jumbo frames on the transfer would be slower than the single interface. Its also possible it won't have an impact either way and the disk write is the bottle neck. The 930G written in during the backup is the only network load I have that is pushing the network anywhere close to a heavy load.

FYI I do have net.inet.tcp.pmtud_blackhole_detection enabled on the server.

   Dean E. Weimer
freebsd-stable@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Reply via email to