Subject: Re: gre encap destination = point-to-point destination
To: None <>
From: David Young <>
List: tech-net
Date: 11/04/2006 12:19:00
On Sat, Nov 04, 2006 at 10:26:51AM +0000, Michael van Elst wrote:
> (David Young) writes:
> >gre5006: flags=d051<UP,POINTOPOINT,RUNNING,LINK0,MULTICAST> mtu 1476
> >        tunnel inet -->
> >        inet -> 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 -> 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 that points at the tunnel
pseudo-interface.  Thus, if you send a packet to, it ought to go
through the tunnel.  The encapsulated packet, whose destination is also, 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      Urbana, IL * (217) 278-3933