From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 27 09:22:29 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C03F16A403 for ; Tue, 27 Jun 2006 09:22:29 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB50943D64 for ; Tue, 27 Jun 2006 09:22:25 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.3) with ESMTP id k5R9M7ZV037963; Tue, 27 Jun 2006 13:22:07 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.3/Submit) id k5R9M1aA037958; Tue, 27 Jun 2006 13:22:01 +0400 (MSD) (envelope-from yar) Date: Tue, 27 Jun 2006 13:22:01 +0400 From: Yar Tikhiy To: David Gilbert Message-ID: <20060627092201.GC36941@comp.chem.msu.su> References: <17560.50693.145833.875903@canoe.dclg.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17560.50693.145833.875903@canoe.dclg.ca> User-Agent: Mutt/1.5.9i Cc: freebsd-hackers@freebsd.org Subject: Re: curious 6.1 GRE behaviour. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 09:22:29 -0000 On Wed, Jun 21, 2006 at 12:07:33AM -0400, David Gilbert wrote: > I was using some GRE tunnels on 6.1-RELEASE recently. The odd thing > I'm finding is that the initial creation of the tunnel using > cloned_interfaces and ifconfig_gre0="" results in the gre0 > interface being created without the "running" bit set. > > tcpdump on the interface or even "ifconfig gre0 up" starts it. > > This is also odd because the "UP" flag is set. Ie: > [1:2:301]root@pbx:~> ifconfig > [...] > gre0: flags=9011 mtu 1476 > tunnel inet x.x.x.x --> y.y.y.y > inet6 fe80::240:63ff:fee2:eae9%gre0 prefixlen 64 scopeid 0x5 > inet a.a.a.a --> b.b.b.b netmask 0xfffffffe > [1:2:302]root@pbx:~> ifconfig gre0 up > [1:3:303]root@pbx:~> ifconfig > [...] > gre0: flags=9051 mtu 1476 > tunnel inet x.x.x.x --> y.y.y.y > inet6 fe80::240:63ff:fee2:eae9%gre0 prefixlen 64 scopeid 0x5 > inet a.a.a.a --> b.b.b.b netmask 0xfffffffe FWIW, gre(4) in CURRENT doesn't seem to have this problem. However, it has a different one: the system will lose its default route upon the destruction of a gre interface albeit the default route is via a different interface. Aha, it appears to be due to the activity of /etc/pccard_ether, not gre(4) itself. Looks like a way of fast and easy foot-shooting unless one remembers to set removable_route_flush to NO. Are we drifting from the server/router market to the desktop/mobile market?.. -- Yar