Date: Tue, 16 May 2000 13:48:30 +1000 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: stable@FreeBSD.ORG Subject: Routing behaviour in 3-STABLE Message-ID: <00May16.134830est.115227@border.alcanet.com.au>
next in thread | raw e-mail | index | archive | help
I'm having a problem with the behaviour of routed(8) in 3-STABLE.
Specifically, it doesn't appear to be updating the kernel routing
tables as I would expect.
I have a network similar to the following:
eth0 (192.168.126.144/28)
+------------+------------+------------+------------+
| | X | |
+-------+ +-------+ +-------+ +-------+ +-------+
...---| | | | | | | | | |
| rtr | | host1 | | host2 | | host3 | | host4 |
...---| | | | | | | | | |
+-------+ +-------+ +-------+ +-------+ +-------+
| | | | |
+------------+------------+------------+------------+
eth1 (192.168.126.160/28)
Where rtr is a FreeBSD 3-STABLE box with multiple NICs. Two of the
NICs are configured as a dual network to a number of other hosts
(host1 though host4, each running Digital Unix, though that's not
relevant here). In order to provide LAN redundancy, each hostN (but
not rtr) has an application which monitors all the interfaces on each
LAN (using ICMP ECHO packets). If a path fails, then the application
inserts a static routing entry specifying the alternative path. It
also informs rtr using unicast RIPv2 messages.
As an example, if eth0 on host2 failed (as shown by the X above), each
host would effectively perform the following actions:
host1: route add host2-eth0 host2-eth1
host2: route add rtr-eth0 rtr-eth1
host2: route add host1-eth0 host1-eth1
host2: route add host3-eth0 host3-eth1
host2: route add host4-eth0 host4-eth1
host2: send RIPv2 message "host2-eth0/32 gateway host2-eth1 metric 1"
to rtr-eth1
host3: route add host2-eth0 host2-eth1
host4: route add host2-eth0 host2-eth1
This approach of sending RIPv2 messages to redirect connections may
seem unusual, but it does work with CISCO routers, and I would have
expected it to work with FreeBSD.
My problem is that, whilst routed on rtr receives the message:
Add 192.168.126.149/32-->192.168.126.165 metric=1 eth1 10:52:38
the kernel routing table is never updated. A ktrace of routed shows
that routed doesn't write to the kernel routing socket. The path
between table.c:rtadd() (which logs the message) and table.c:rtioctl()
(where the kernel is updated) is not clear to me, and doesn't seem
to include any debugging output.
Has anyone else run into a similar problem? If so, how did you get
around it.
Is there any documentation which explains how routed internally
manages its routing tables - specifically how an incoming route
request is turned into an update within the kernel.
Peter
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?00May16.134830est.115227>