curious 6.1 GRE behaviour.

[Yar Tikhiy]

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 at 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 at pbx:~> ifconfig gre0 up
> [1:3:303]root at 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