Subject: dynamic routing for tunnel over cable/DSL....
To: NetBSD User's Discussion List <netbsd-users@NetBSD.ORG>
From: Greg A. Woods <woods@weird.com>
List: netbsd-users
Date: 08/12/2000 15:55:25
I've been running routed in order to announce my network to a router
that's handling it upstream via a raw (no IPsec) GIF tunnel over a cable
modem.
The machines on each end are sort of -current (mine's getting dated, only
at about 1.4V). The routing software on the remote side is Zebra, but I
don't think that's going to be relevant to this question.
The initial problem is that I've been getting zillions of these messages:
# tail /var/log/debug
Aug 12 13:45:27 isit routed[1959]: ne1 (24.42.191.4/24) is duplicated by external(24.42.191.1) (24.42.191.1/24)
Aug 12 13:46:25 isit routed[1959]: ne1 (24.42.191.4/24) is duplicated by external(24.42.191.1) (24.42.191.1/24)
Aug 12 13:48:21 isit last message repeated 2 times
Aug 12 13:49:57 isit last message repeated 2 times
Following are my routed configs, interfaces, and route table (only
barely sanitized -- please don't play naughty games!).
I'm not much of an expert with routed -- this is the most complex thing
I've ever done with it. Even getting this far took a lot of
experimentation because the routed manual page is really convoluted and
sometimes wrong too it seems (not to mention that the concepts all seem
like they've been described from the inside out to me!). BTW, it
doesn't seem to work if I take out the 'net' statement.... If anyone
has any suggestions, let me know!
# cat /etc/gateways
rdisc_interval=45
no_ag
no_super_ag
if=ne1 no_rdisc no_solicit no_rdisc_adv passive
net 24.42.191.0/24 gateway 24.42.191.1 metric 15 external
if=gif0 no_rdisc no_solicit no_rdisc_adv ripv2_out
if=ne0 no_rdisc no_solicit no_rdisc_adv ripv2_out
trust_gateway=204.29.161.54
trust_gateway=24.112.34.79
# netstat -in
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Colls
ne0 1500 <Link> 00:40:33:20:bc:99 18156078 4 8477804 0 4272
ne0 1500 fe80::/64 fe80::240:33ff:fe 18156078 4 8477804 0 4272
ne0 1500 204.92.254 204.92.254.6 18156078 4 8477804 0 4272
ne0 1500 204.29.161.160/27 204.29.161.163 18156078 4 8477804 0 4272
ne1 1500 <Link> 00:40:33:25:ab:94 16793404 0 8717252 0 45230
ne1 1500 fe80::/64 fe80::240:33ff:fe 16793404 0 8717252 0 45230
ne1 1500 24.42.191/24 24.42.191.4 16793404 0 8717252 0 45230
lo0 32972 <Link> 13039 0 13039 0 0
lo0 32972 fe80::/64 fe80::1 13039 0 13039 0 0
lo0 32972 ::1/128 ::1 13039 0 13039 0 0
lo0 32972 127 127.0.0.1 13039 0 13039 0 0
gif0 1280 <Link> 4575895 0 5576652 65521 0
gif0 1280 fe80::/64 fe80::240:33ff:fe 4575895 0 5576652 65521 0
gif0 1280 204.29.161.160/27 204.29.161.163 4575895 0 5576652 65521 0
gif1* 1280 <Link> 0 0 0 0 0
gif2* 1280 <Link> 0 0 0 0 0
gif3* 1280 <Link> 0 0 0 0 0
(I manually fixed the truncated .160 display above -- why can't netstat
be fixed to allow for 3+3+3+3+3+3 character network addresses?!?!? -- do
we really need to mix IF stats with IF parameters?!?!?!?)
# netstat -rn -f inet -L
Routing tables
Internet:
Destination Gateway Flags Refs Use Mtu Interface
default 204.29.161.54 UGS 4 5176685 1280 gif0
24.42.191/24 link#2 UC 0 0 1500 ne1
127.0.0.1 127.0.0.1 UH 1 110 32972 lo0
204.29.161.54 204.29.161.163 UH 0 28657 1280 gif0
204.29.161.160/27 link#1 UC 0 0 1500 ne0
204.29.161.163 127.0.0.1 UH 0 3 32972 lo0
204.92.254 link#1 UC 0 0 1500 ne0
(I've deleted the static routes from above that I use via NAT to get my
HTTP and NNTP traffic to hit the faster @Home servers....)
The next trick is going to be figuring out how to keep the tunnel
working when I'm forced to switch to a dynamic external address (which
is going to happen well before the end of Sept. and perhaps as soon as
the beginning of Sept.). I don't really want to have to run IPsec on
this little 486 box, but then I don't really want to have to establish
any kind of root-level trust in either direction between these gateway
boxes either.... :-)
I can, and probably will, install zebra on this box too -- it would seem
that'll at least make the RIPv2 configuration easier and more flexible,
not to mention open up the possiblity of using some other routing
protocol to announce my network to the upstream.....
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>