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