Hi! We've been attempting to use bird 1.0.5 on our test network,
but OSPF didn't seem to be propogating correctly. Rather, it was
talking amongst its peer routers properly, and propogating routes
correctly, but forgetting to set the gateways (which kinda defeats
the purpose).
For instance, we have one machine (test1, 192.168.0.254) which is
directly attached to 192.168.0.0/24 (obviously) and 192.168.1.0/24,
as well as our uplink to the internet. Another machine
(192.168.0.60) is directly attached to 192.168.0.0/24 (obviously),
192.168.4.0/24 and 192.168.7.0/24.
Once they had flooded LS's and entered OSPF "full" mode with
eachother, test1's routing table looked like:
test1:~# ip route
XXX.XXX.XXX.XXX/27 dev eth0 proto kernel scope link src XXX.XXX.XXX.XXX
192.168.7.0/24 dev eth2 proto bird
192.168.4.0/24 dev eth2 proto bird
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.254
192.168.0.0/24 dev eth2 proto kernel scope link src 192.168.0.254
default via XXX.XXX.XXX.XXX dev eth0 proto bird
I rooted around in the source for a while, and managed to make it work.
Attached is the patch (which also includes a small documentation fix).
This patch makes bird set gateways properly:
test1:~# ip route
XXX.XXX.XXX.XXX/27 dev eth0 proto kernel scope link src XXX.XXX.XXX.XXX
192.168.7.0/24 via 192.168.0.60 dev eth2 proto bird
192.168.4.0/24 via 192.168.0.60 dev eth2 proto bird
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.254
192.168.0.0/24 dev eth2 proto kernel scope link src 192.168.0.254
default via XXX.XXX.XXX.XXX dev eth0 proto bird
Since this seems like such a silly bug and is so unlikely to be
overlooked (because it rendered bird's OSPF mostly useless), I have
to ask if we configured something wrong, or managed to mess something
else up. Please also find attached one of our config files (they all
look pretty similar to this). What happened? I'd love to hear your
comments.
Thanks for your time,
Mark
