From owner-freebsd-net@FreeBSD.ORG Mon Jul 16 02:40:50 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D7651065670 for ; Mon, 16 Jul 2012 02:40:50 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id AF3B78FC24 for ; Mon, 16 Jul 2012 02:40:49 +0000 (UTC) Received: by obbun3 with SMTP id un3so10944273obb.13 for ; Sun, 15 Jul 2012 19:40:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=cu2MP/yEBWiYCCVOLauhp5gOEvvDPNUA606zP3Ua+I4=; b=eWPR71G8RzEALVyknaBpY8+Brg03Mlve0Z9Wrq5AbYDzYpo0VEPKSvC955D6+S1vXU DQSaI2QOCAnftmlz747ZKuSxv0kNDbcnqstEdGTSBWdtnRNEbXCCqXKv8g+3bqSDwnfq jrjzJWETP6QIoa/ij0fYY9qZHGYji+0XRgJ+Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-gm-message-state; bh=cu2MP/yEBWiYCCVOLauhp5gOEvvDPNUA606zP3Ua+I4=; b=GLxqCDiXGaHIgfgIzVHl2jqfYvwhbj+ZOFYJtIZvLCR0dVWGmBQtx7SNUj1I3Ah5gf yz6Kauv+kYoypKRiZ1on7Xo6gZss2/NPcqCZEMGYEaAcNwgk7ZCtC3lhdUNM0Bn2+kgy eKQlyNfS66ozLLn8UomSSrC/jlaf3U9cVyAtwwiyCcuUl6ddRphX6ldzAE7U/C37kiOz +IgSRN/a96kBl3hACduXhJfpkRzSziter8qwpOaHUTR+UuuN2K+uEVxosI9JRxoMhX64 sMwNROsqrvn4viPBn0+nUW56H3z0bi3Le8eldh0AevRQUcii7B1crEClgVjrsKx5E/hQ T2Yw== Received: by 10.50.161.199 with SMTP id xu7mr3312769igb.68.1342406449227; Sun, 15 Jul 2012 19:40:49 -0700 (PDT) Received: from DataIX.net ([99.181.132.147]) by mx.google.com with ESMTPS id if4sm7720041igc.10.2012.07.15.19.40.46 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 15 Jul 2012 19:40:48 -0700 (PDT) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q6G2egRv090584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Jul 2012 22:40:42 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jh@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q6G2egpd090583; Sun, 15 Jul 2012 22:40:42 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Sun, 15 Jul 2012 22:40:42 -0400 From: Jason Hellenthal To: George Neville-Neil Message-ID: <20120716024042.GA90389@DataIX.net> References: <86liiqrnnq.wl%gnn@neville-neil.com> <4FFDF6C7.3030301@FreeBSD.org> <20120712165502.GA61341@DataIX.net> <096E1D9F-6F88-4063-B59C-34E94E17138D@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9amGYk9869ThD9tj" Content-Disposition: inline In-Reply-To: <096E1D9F-6F88-4063-B59C-34E94E17138D@freebsd.org> X-Gm-Message-State: ALoCoQnuS5KltbaOC0J4Oqw4mb9Vo6AZkbcuDt01zxYKtYPKPnuJ4B5eiGCvBSKM8URIQeq9M476 Cc: Navdeep Parhar , net@freebsd.org Subject: Re: Interface MTU question... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 02:40:50 -0000 --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Filed as, http://www.freebsd.org/cgi/query-pr.cgi?pr=3D169898 Thanks for looking into this when you get time. On Thu, Jul 12, 2012 at 04:49:23PM -0400, George Neville-Neil wrote: >=20 > On Jul 12, 2012, at 12:55 , Jason Hellenthal wrote: >=20 > >=20 > >=20 > > On Thu, Jul 12, 2012 at 10:55:16AM -0400, George Neville-Neil wrote: > >>=20 > >> On Jul 11, 2012, at 17:57 , Navdeep Parhar wrote: > >>=20 > >>> On 07/11/12 14:30, gnn@freebsd.org wrote: > >>>> Howdy, > >>>>=20 > >>>> Does anyone know the reason for this particular check in > >>>> ip_output.c? > >>>>=20 > >>>> if (rte !=3D NULL && (rte->rt_flags & (RTF_UP|RTF_HOST))) { > >>>> /* > >>>> * This case can happen if the user changed the MTU > >>>> * of an interface after enabling IP on it. Because > >>>> * most netifs don't keep track of routes pointing to > >>>> * them, there is no way for one to update all its > >>>> * routes when the MTU is changed. > >>>> */ > >>>> if (rte->rt_rmx.rmx_mtu > ifp->if_mtu) > >>>> rte->rt_rmx.rmx_mtu =3D ifp->if_mtu; > >>>> mtu =3D rte->rt_rmx.rmx_mtu; > >>>> } else { > >>>> mtu =3D ifp->if_mtu; > >>>> } > >>>>=20 > >>>> To my mind the > ought to be !=3D so that any change, up or down, of= the > >>>> interface MTU is eventually reflected in the route. Also, this code > >>>> does not check if it is both a HOST route and UP, but only if it is > >>>> one other the other, so don't be fooled by that, this check happens > >>>> for any route we have if it's up. > >>>=20 > >>> I believe rmx_mtu could be low due to some intermediate node between = this host and the final destination. An increase in the MTU of the local i= nterface should not increase the path MTU if the limit was due to someone e= lse along the route. > >>=20 > >> Yes, it turns out to be complex. We have several places that store th= e MTU. There is the interface, > >> which knows the MTU of the directly connected link, a route, and the h= ost cache. All three of these > >> are used to determine the maximum segment size (MSS) of a TCP packet. = The route and the interface > >> determine the maximum MTU that the MSS can have, but, if there is an e= ntry in the host cache > >> then it is preferred over either of the first two. See tcp_update_mss= () in tcp_input.c to > >> see what I'm talking about. > >>=20 > >> I believe that the quoted code above has been wrong from the day it wa= s written, in that what it > >> really says is "if the route is up" and not "if the route is up and is= a host route" which is > >> what I believe people to read that as. If the belief is that this cod= e is really only there for > >> hosts routes, then the proper fix is to make the sense of the first if= match that belief > >> and, again, to change the > to !=3D so that when the administrator of = the box bumps the MTU in > >> either direction that the route reflects this. It is not possible for= PMTU on a single link > >> to a host route to bump the number down if the interface says it's not= to be bumped. And, > >> even so, any host cache entry will override and avoid this code. > >>=20 > >=20 > > Something else to look into ...=20 > >=20 > > # ifconfig lagg0 mtu 1492 > > ifconfig: ioctl (set mtu): Invalid argument > >=20 > > This is on stable/8 r238264 when the interface was up/up and down/down > >=20 > > Also attempted on the member interfaces dc0 and dc1 > >=20 >=20 > Can you file a bug on that one? >=20 > Best, > George >=20 --=20 - (2^(N-1)) --9amGYk9869ThD9tj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJQA38pAAoJEBSh2Dr1DU7WvJQH/35b7E7xtWAHmUB3HtalxeMc W4JLmWeIXey0uiBprk7dtRnqzFdUq6JVg/yU7XzL9k8HwNsnwuThpHEKI2ZbTpYq 1Jk8d8EcSlzF7QOU08JQuyy88rX0t81uBCgEd7XmdOo5cYmoqIOEMl5RMPY3+xRQ qJsO6zkDpDmrfDhBxX4DmzK5ixQ2ANzhz6PmrMgvrpuxSkCLz7dS/gfnnhwvEjad yOzva9XUPLoAz4VIJRyhHs4YS6lhPhdoI/igGguye6RiCVgl2CnA4hl6ISBcqX1p 6mRUeuUNzStaEKNd2RqOR6t64IGXDqXHP+QBvuJe4MlZSN17VtfjEXd6r3hep9Q= =XcGA -----END PGP SIGNATURE----- --9amGYk9869ThD9tj--