Filed as, http://www.freebsd.org/cgi/query-pr.cgi?pr=169898
Thanks for looking into this when you get time.
On Thu, Jul 12, 2012 at 04:49:23PM -0400, George Neville-Neil wrote:
>
> On Jul 12, 2012, at 12:55 , Jason Hellenthal wrote:
>
> >
> >
> > On Thu, Jul 12, 2012 at 10:55:16AM -0400, George Neville-Neil wrote:
> >>
> >> On Jul 11, 2012, at 17:57 , Navdeep Parhar wrote:
> >>
> >>> On 07/11/12 14:30, g...@freebsd.org wrote:
> >>>> Howdy,
> >>>>
> >>>> Does anyone know the reason for this particular check in
> >>>> ip_output.c?
> >>>>
> >>>> if (rte != 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 = ifp->if_mtu;
> >>>> mtu = rte->rt_rmx.rmx_mtu;
> >>>> } else {
> >>>> mtu = ifp->if_mtu;
> >>>> }
> >>>>
> >>>> To my mind the > ought to be != 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.
> >>>
> >>> 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 != 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.
> >>
> >
> > Something else to look into ...
> >
> > # ifconfig lagg0 mtu 1492
> > ifconfig: ioctl (set mtu): Invalid argument
> >
> > This is on stable/8 r238264 when the interface was up/up and down/down
> >
> > Also attempted on the member interfaces dc0 and dc1
> >
>
> Can you file a bug on that one?
>
> Best,
> George
>
--
- (2^(N-1))
pgpxJ9QsRxtJ2.pgp
Description: PGP signature
