Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 12 Jul 2012 16:49:23 -0400
From:      George Neville-Neil <gnn@freebsd.org>
To:        Jason Hellenthal <jhellenthal@dataix.net>
Cc:        Navdeep Parhar <np@freebsd.org>, net@freebsd.org
Subject:   Re: Interface MTU question...
Message-ID:  <096E1D9F-6F88-4063-B59C-34E94E17138D@freebsd.org>
In-Reply-To: <20120712165502.GA61341@DataIX.net>
References:  <86liiqrnnq.wl%gnn@neville-neil.com> <4FFDF6C7.3030301@FreeBSD.org> <C06D346A-97BE-4498-B4E5-0ED85731A8BD@freebsd.org> <20120712165502.GA61341@DataIX.net>

next in thread | previous in thread | raw e-mail | index | archive | help

On Jul 12, 2012, at 12:55 , Jason Hellenthal wrote:

>=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 interface should not increase the path MTU if the limit was due to =
someone else along the route.
>>=20
>> Yes, it turns out to be complex.  We have several places that store =
the MTU.  There is the interface,
>> which knows the MTU of the directly connected link, a route, and the =
host 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 =
entry 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 =
was 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 =
code 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

Can you file a bug on that one?

Best,
George




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?096E1D9F-6F88-4063-B59C-34E94E17138D>