Subject: Re: gre encap destination = point-to-point destination
To: None <tech-net@NetBSD.org>
From: David Young <firstname.lastname@example.org>
Date: 11/04/2006 12:19:00
On Sat, Nov 04, 2006 at 10:26:51AM +0000, Michael van Elst wrote:
> email@example.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.
David Young OJC Technologies
firstname.lastname@example.org Urbana, IL * (217) 278-3933