From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 16:55:20 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1F915106566C for ; Thu, 12 Jul 2012 16:55:20 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-gh0-f182.google.com (mail-gh0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 653CD8FC1A for ; Thu, 12 Jul 2012 16:55:13 +0000 (UTC) Received: by ghbz22 with SMTP id z22so3034292ghb.13 for ; Thu, 12 Jul 2012 09:55:07 -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=u6n7adTerRVvLG1GvIxyg3OdcphKYsCsKXacw2lleIU=; b=Y8tyFV9Bj0KGGJfx9s6b4S/BNw5fff5ThF8ven0ax0PIOpBvusUxSNZdC+2lCy6qOh L5LF8DtqVHPpekqenesTR5CjR5VLzDxDHZxFXRiXUNLmzohHQvnsS/0kjj3QX2vQLrIj tuDLE4L8jex79xoLG3grsVNTb9JFFq8FDeUDE= 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=u6n7adTerRVvLG1GvIxyg3OdcphKYsCsKXacw2lleIU=; b=T4gP9YQKC+Et0wwfgse4U1D6GOAQipExOv7cnm/kzxjbX67/vPD4BJ7LsAj5jqQwnK T0gRgZKVUsB21hrtiLDkGd8fXqDSd/I+jjhkPXFq5VeP+4sWNgFScIGQuiFcOQlB4sWg ausc2XxxpfTaKPXZwK6pFDZ9k1eopAT05/WWItSmn4Xt23WJcJP2v41Gf6SwYH0YOizS Kth+Ar7nVfiE0MJ6VZW0enJiELyvH/gj1v8ajd9+f+dlNbWGCjOiJaHBodcxxQWuoY+i emNf1N0CT0391PfZkMKwi6/ZouSAGIkysqjWMY8s8jytq1RUZJ0RVA+qSXV48RI9atwP 9ALA== Received: by 10.50.163.70 with SMTP id yg6mr17914896igb.70.1342112106232; Thu, 12 Jul 2012 09:55:06 -0700 (PDT) Received: from DataIX.net ([99.109.125.25]) by mx.google.com with ESMTPS id ud8sm9264023igb.4.2012.07.12.09.55.05 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Jul 2012 09:55:05 -0700 (PDT) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q6CGt2I3070513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jul 2012 12:55:03 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jh@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q6CGt2j9070512; Thu, 12 Jul 2012 12:55:02 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Thu, 12 Jul 2012 12:55:02 -0400 From: Jason Hellenthal To: George Neville-Neil Message-ID: <20120712165502.GA61341@DataIX.net> References: <86liiqrnnq.wl%gnn@neville-neil.com> <4FFDF6C7.3030301@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Gm-Message-State: ALoCoQny+qi2hh9jdVDeJutUWqRY7Qe/0rNOET5weGAD941sPNjg91rL/Hqtd8RnpD/QO5Y1LpjA 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: Thu, 12 Jul 2012 16:55:20 -0000 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, gnn@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 -- - (2^(N-1))