[3809] in linux-net channel archive
Re: Gated keeps adding route to tunnel interface of tunnel's other end
daemon@ATHENA.MIT.EDU (really kuznet@ms2.inr.ac.ru)
Mon Jul 22 11:51:35 1996
From: inr-linux-net@ms2.inr.ac.ru (really kuznet@ms2.inr.ac.ru)
To: linux-net@vger.rutgers.edu
Date: 19 Jul 1996 18:01:47 +0400
ulmo@q.NET wrote:
: But, there's problems. First off, I can't traceroute down it, but
: that's just because no one finished the tunnel driver to handle those
: types of packets, and it's really no big deal to me.
IPIP, to be more exact. ICMP over tunnel is not implemented,
and it would be problematic for IPv4, because the most routers
returns only 8 bytes of initial message (in direct contradiction
with router requirements. Even Ciscos, alas)
: But the worst
: problem is that I haven't been able to figure out how to configure
: gated to *not* insert the route of the other end of the tunnel
: interface into the kernel routing table as going through the tunnel
: device, because, of course, that does not work with the current
: implementation of the tunnel (i.e., any packet routed to the tunnel
: for any reason goes into the tunnel, and then the tunnel encapsulates
: the packet, sending it off to whereever the kernel takes a packet
: destined for the IP# of the other end of the tunnel, which is the
: tunnel; what the tunnel does at this point (with this encapsulation
: loop) I don't know, but I have a feeling that whatever it does it's
: not getting the packet any nearer to its destination).
Advice: do not configure tunnel as pointopoint device.
Use keyword dstaddr instead of pointopoint (or hack gated
by patch, appended below)
: Now, either there's something I forgot with my gated.conf (I've tried
: a number of things already but not everything), or the Linux kernel
: could be modified to have an option within the tunnel interface that
: packets destined to its other end's IP# should then go to the
: next-best route match in the kernel routing table. Is that correct
: behavoir?
Maybe, but unlikely. To be honest, I broke my brains, trying to put tunnels
into "my picture of the world". Ough, they do not fit :-)
Unfortunately, we cannot just mimic behaviour of another OS,
seems no OS have coherent tunnels. Cisco IPIP tunnels
are broken too.
Ideas for now:
1. Axiom: tunnel is not pointopoint device, it is tunnel device.
2. There are two sorts of tunnels:
a) static. When static tunnel goes up, gated (or admin) should clone current
route to other end of tunnel as host route, and only
then add tunnel interface route.
b) dynamic. Route to other end is determined at the moment of routing.
However, configuring another end of dynamic tunnel in subnet routed
to tunnel should be inhibited.
And the last:
never use (if you know about it) hack of adding not-neighbour
gateway route via tunnel. It has effect of setting dstaddr, but will break
all the picture ultimately and hopelessly.
: Is it possible that "next-best route match" is going to be
: too hard to implement in the future when Linux gets a good fast
: routing lookup algorithm, or now?
Well, lookup is very fast now...
: One nice thing is that if I use /sbin/route to remove the offending
: route, while gated is still running it doesn't seem to want to
: reinstall it even if both Linux's are running gated.
Gated reads kernel routing tables only once, and then it assumes
that it is the MASTER of routing, and nobody allowed to change routes.
I tried to teach it to read netlink device, but without success.
Really, it should be easy, but disgusting BSD programming style
makes very hard to understand and hack it.
: Gated will
: reinstall the offending route on restart.
And when you down tunnel device, and then up it again.
: Before I go to the gated-people mailing list and make a fool of myself
: there without reading the entire manual carefully, I'm going to get
: even more familiar with gated configuration to see what my options
: are in that program.
Alas, gated knows NOTHING about tunnels. It is worth to kick
gated people and force them to make something sencible.
Just for now, dirty (very dirty!) patch to krt_ifread_ioctl.c:
} else {
#endif /* SOCKADDR_DL */
size_t n_len = strlen(if_name);
#ifndef NO_ANK_FIX
sockaddr_un *lladdr = krt_lladdr(ifr);
if (ifr->ifr_hwaddr.sa_family = 768 /*ARPHRD_TUNNEL*/)
state &= ~IFS_POINTOPOINT;
#endif
ifl = ifl_addup(tp,
ifl_locate_name(if_name, n_len),
++indx,
state,
metric,
mtu,
if_name,
n_len,
#ifdef NO_ANK_FIX
krt_lladdr(ifr),
#else
lladdr,
#endif
(sockaddr_un *) 0);
If you will find something sensible about tunnels,
please, keep me informed.
Alexey Kuznetsov.
