[3753] in linux-net channel archive
Gated keeps adding route to tunnel interface of tunnel's other end
daemon@ATHENA.MIT.EDU (ulmo@q.net)
Thu Jul 18 18:42:00 1996
Date: Wed, 17 Jul 1996 03:48:47 -0400
From: <ulmo@q.net>
To: linux-net@vger.rutgers.edu
cc: ulmo@q.net
I'm about to go bananas playing with source code (new_tunnel.c in
Linux 2.0.7 and the gated source too) and rereading the entire gated
configuration manual, but before I embark on that slippery mission I
wanted to ask quickly if there was anybody who knew what was up with
this.
I run Linux 2.0.7, and my tunnel is to another Linux 2.0.7.
Traceroute shows 12 hops (about 3 AS's -- while only a few blocks in
reality, the packet first has to go through about four states, I'm
sure travelling nearly a thousand miles, in order to make it a few
blocks away from me). The tunnel is great -- my host appears on their
network as a host (using arp on the other end) and of course I get one
of their IP#s (along with all of its permissions); what's best about
it is when I set up a second link directly to that other host (using
PPP), the hosts on its network send the packets back via that PPP link
without my having to modify the routing tables of the router they have
(with RIP I supposed I could get gated to do that anyway, but arp is
kinda an easy solution that works well and prevents packets traversing
the ethernet twice), *and* when I log out I get to keep the same IP#
(I could make it do this anyway with PPP, but then when I let down
that PPP connection all my connections would die); furthermore, I'm
going to be putting one of their hosts onto the network of a remote
LAN where the remote LAN is using illegal IP#s (they are not unique),
and I'll have to have a tunnel into that mess (via the other Linux,
acting as a go-between) as well to work from home while isolating it
all from the Internet for both security of the remote LAN and for not
violating the IP#s of the correct holder (I didn't set up this remote
LAN, I would never have used unassigned IP#s myself).
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. 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).
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? 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?
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 will
reinstall the offending route on restart. Problems with this approach
abound: the correct route to that IP# also gets deleted, so some
annoying heuristic has to be used to guess what it should have been
right now (ppp0? ppp1? eql? on one host, ppp0? gw host via eth0? on
the other), and of course it's necessary (or at least desirable,
depending on the application I'm using) on the machine that was
initially not part of the LAN (mine in this case) to have a route to
that LAN, which would overrule the correct route to the other side of
the tunnel if the specific route wasn't added. Also it's a pain to
have to do these commands -- it's almost like programming my own gated
in shell scripts or something. So gated behavoir would be the best to
change ...
But, if in gated I disable tunl or tunl0 or tunl1 as an interface to
gain routes through, I think these things would happen:
* Gated would still install the route to the device since it's got
that darned pointopoint address for the other side sitting there
and gated likes adding those blasted darned routes (not a bad thing
in most cases but yes a bad thing for this!)
* Anything that the routing protocols could tell me from being on
the remote LAN won't be available to me. While at this point that
is a minor issue, it still bugs me.
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.
Thanks for your attention & help,
Bradley Allen <Ulmo@Q.Net>
