Date: Thu, 12 Jul 2012 10:55:16 -0400 From: George Neville-Neil <gnn@freebsd.org> To: Navdeep Parhar <np@FreeBSD.org> Cc: net@freebsd.org Subject: Re: Interface MTU question... Message-ID: <C06D346A-97BE-4498-B4E5-0ED85731A8BD@freebsd.org> In-Reply-To: <4FFDF6C7.3030301@FreeBSD.org> References: <86liiqrnnq.wl%gnn@neville-neil.com> <4FFDF6C7.3030301@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 11, 2012, at 17:57 , Navdeep Parhar wrote:
> 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.
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.
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.
Best,
George
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C06D346A-97BE-4498-B4E5-0ED85731A8BD>