From owner-freebsd-stable@freebsd.org Mon Sep 19 20:59:54 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 92AF5BE169F for ; Mon, 19 Sep 2016 20:59:54 +0000 (UTC) (envelope-from dweimer@dweimer.net) Received: from webmail.dweimer.net (24-240-198-188.static.stls.mo.charter.com [24.240.198.188]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 63A47D27 for ; Mon, 19 Sep 2016 20:59:53 +0000 (UTC) (envelope-from dweimer@dweimer.net) Received: from webmail.dweimer.local (localhost [10.9.5.2]) by webmail.dweimer.net (8.15.2/8.15.2) with ESMTPS id u8JKxqWe009143 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 19 Sep 2016 15:59:52 -0500 (CDT) (envelope-from dweimer@dweimer.net) Received: (from www@localhost) by webmail.dweimer.local (8.15.2/8.15.2/Submit) id u8JKxq6X009142; Mon, 19 Sep 2016 15:59:52 -0500 (CDT) (envelope-from dweimer@dweimer.net) X-Authentication-Warning: webmail.dweimer.local: www set sender to dweimer@dweimer.net using -f To: Lyndon Nerenberg Subject: Re: LAGG and Jumbo Frames MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 19 Sep 2016 15:59:52 -0500 From: "Dean E. Weimer" Cc: FreeBSD Stable Organization: dweimer.net Reply-To: dweimer@dweimer.net Mail-Reply-To: dweimer@dweimer.net In-Reply-To: References: <48926c6013f938af832c17e4ad10b232@dweimer.net> Message-ID: <04c9065ee4a780c6f8986d1b204c4198@dweimer.net> X-Sender: dweimer@dweimer.net User-Agent: Roundcube Webmail/1.2.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 20:59:54 -0000 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. > > --lyndon 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. -- Thanks, Dean E. Weimer http://www.dweimer.net/