On Sat, Nov 04, 2006 at 10:26:51AM +0000, Michael van Elst wrote:
> dyoung@pobox.com (David Young) writes:
> 
> >gre5006: flags=d051<UP,POINTOPOINT,RUNNING,LINK0,MULTICAST> mtu 1476
> >        tunnel inet 10.0.0.1 --> 10.0.0.2
> >        inet 10.0.0.3 -> 10.0.0.2 netmask 0xffffffff
> >        inet6 fe80::a00:20ff:fef9:60ee%gre5006 ->  prefixlen 64 scopeid 0x112d
> 
> >Can anybody explain, what is use such a configuration as above?  Is there
> >no other way to create a similar network?
> 
> Maybe 10.0.0.1 -> 10.0.0.2 is a point-to-point route itself or
> the network filters other addresses? Then you have to tunnel
> other addresses and this is one method to avoid additional
> addresses on the target.

This sounds like a hypothetical example.  I am want to ehar from people
who are personally invested in this quirk of gre(4) operation, so that
I can understand why before I change it.

> What exactly is the problem with this configuration?

NetBSD will install a route to 10.0.0.2 that points at the tunnel
pseudo-interface.  Thus, if you send a packet to 10.0.0.2, it ought to go
through the tunnel.  The encapsulated packet, whose destination is also
10.0.0.2, ought to go through the tunnel again.  The doubly-encapsulated
packet, too, will go out the tunnel again.  That is, a reasonable
interpretation of this configuration is that it leads to recursion.
In fact, the same configuration of a gif(4) tunnel does lead to recursion.
Where gif(4) detects the recursion and drops the packet, gre(4) fiddles
with the routing lookup to break the recursion, leading to a surprising
and somewhat arbitrary routing of the encapsulated packet.

Dave

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Urbana, IL * (217) 278-3933