Date: Tue, 27 Jun 2006 13:22:01 +0400 From: Yar Tikhiy <yar@comp.chem.msu.su> To: David Gilbert <dgilbert@dclg.ca> Cc: freebsd-hackers@freebsd.org Subject: Re: curious 6.1 GRE behaviour. Message-ID: <20060627092201.GC36941@comp.chem.msu.su> In-Reply-To: <17560.50693.145833.875903@canoe.dclg.ca> References: <17560.50693.145833.875903@canoe.dclg.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
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="<blah>" 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<UP,POINTOPOINT,LINK0,MULTICAST> 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<UP,POINTOPOINT,RUNNING,LINK0,MULTICAST> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060627092201.GC36941>