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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
