From owner-freebsd-net@FreeBSD.ORG Tue Jul 19 15:18:50 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 20DBC16A41F; Tue, 19 Jul 2005 15:18:50 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8548243D45; Tue, 19 Jul 2005 15:18:49 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix4-1.free.fr (Postfix) with ESMTP id 4D02F318876; Tue, 19 Jul 2005 17:18:47 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id A3EF8405B; Tue, 19 Jul 2005 17:18:39 +0200 (CEST) Date: Tue, 19 Jul 2005 17:18:38 +0200 From: Jeremie Le Hen To: gnn@freebsd.org Message-ID: <20050719151838.GL39292@obiwan.tataz.chchile.org> References: <20050713130042.GV39292@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Cc: freebsd-net@freebsd.org, Jeremie Le Hen Subject: Re: Problem with Path MTU Discovery 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: Tue, 19 Jul 2005 15:18:50 -0000 Hi George, sorry for the delay. > > I set a gif(4)-based IPSec tunnel between my network and a friend's one. > > This works pretty well, except that Path MTU Discovery doesn't work. > > > > Quick draw: > > MTU: 1500 MTU:1280 MTU:1500 > > Comp1 --------- Gate1 -------- Gate2 -----+-- Comp2 > > RELENG_5 RELENG_4 RELENG_5 | RELENG_5 > > | > > +-- Comp3 > > RELENG_5 > > Can you look at the routing table for each of Comp1 and Comp2 and also > use the -W flag to show the path MTU? If there is something wonky in > the routing table then TCP will not hear about the MTU change. There doesn't seem to be strange MTUs in routing table (each host has multiple jails, which explains why the routing table is somewhat large). %%% comp1:root# netstat -rnWf inet Routing tables Internet: Destination Gateway Flags Refs Use Mtu Netif Expire default 192.168.1.1 UGS 0 3878073 1500 em0 127.0.0.1 127.0.0.1 UH 0 4 16384 lo0 192.168.1 link#3 UC 0 0 1500 em0 192.168.1.1 00:09:5b:1a:48:94 UHLW 1 594449 1500 em0 1169 192.168.1.25 00:04:23:89:e5:84 UHLW 0 20232 1500 lo0 => 192.168.1.25/32 link#3 UC 0 0 1500 em0 192.168.1.53 00:04:23:89:e5:84 UHLW 0 24765 1500 lo0 => 192.168.1.53/32 link#3 UC 0 0 1500 em0 192.168.1.178 00:c0:9f:94:39:8f UHLW 0 275 1500 em0 316 192.168.1.241/32 link#3 UC 0 0 1500 em0 comp2:root# netstat -rnWf inet Routing tables Internet: Destination Gateway Flags Refs Use Mtu Netif Expire default 192.168.4.13 UGS 0 58623 1500 xl0 127.0.0.1 127.0.0.1 UH 0 1244 16384 lo0 192.168.4 link#1 UC 0 0 1500 xl0 192.168.4.4 00:60:08:60:fe:10 UHLW 0 20 1500 lo0 192.168.4.13 00:0a:5e:3d:40:cb UHLW 1 1307764 1500 xl0 1012 192.168.4.40 00:60:08:60:fe:10 UHLW 0 1255 1500 lo0 => 192.168.4.40/32 link#1 UC 0 0 1500 xl0 192.168.4.49 00:60:08:60:fe:10 UHLW 0 2317 1500 lo0 => 192.168.4.49/32 link#1 UC 0 0 1500 xl0 192.168.4.50 00:60:08:60:fe:10 UHLW 0 1220 1500 lo0 => 192.168.4.50/32 link#1 UC 0 0 1500 xl0 192.168.4.51 00:60:08:60:fe:10 UHLW 0 4763999 1500 lo0 => 192.168.4.51/32 link#1 UC 0 0 1500 xl0 192.168.4.52 00:60:08:60:fe:10 UHLW 0 1215 1500 lo0 => 192.168.4.52/32 link#1 UC 0 0 1500 xl0 192.168.4.53 00:60:08:60:fe:10 UHLW 0 14393 1500 lo0 => 192.168.4.53/32 link#1 UC 0 0 1500 xl0 192.168.4.54/32 link#1 UC 0 0 1500 xl0 192.168.4.80 00:60:08:60:fe:10 UHLW 0 24577 1500 lo0 => 192.168.4.80/32 link#1 UC 0 0 1500 xl0 %%% Thank you. Regards, -- Jeremie Le Hen hen dot org >< ttz at chchile dot org >