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
On Sat, 24 Nov 2001, Mark Glines wrote:
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).
Hi! I'm sorry that I'm answering so late. I'm quite busy now. (But good news is, that one company will pay for my upgrades of Bird, so I'll have more time for it.)
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).
Thank you!
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
:-) No it was really bug in OSPF. Thank you for the fix. I don't understand how this happened. :-(
look pretty similar to this). What happened? I'd love to hear your comments.
Just stupid bug in my last bugfix. :-)
Thanks for your time,
Thank you!
Mark
Feela
On Fri, 7 Dec 2001, Ondrej Feela Filip wrote:
On Sat, 24 Nov 2001, Mark Glines wrote:
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).
Hi! I'm sorry that I'm answering so late. I'm quite busy now. (But good news is, that one company will pay for my upgrades of Bird, so I'll have more time for it.)
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).
Thank you!
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
:-) No it was really bug in OSPF. Thank you for the fix. I don't understand how this happened. :-(
look pretty similar to this). What happened? I'd love to hear your comments.
Just stupid bug in my last bugfix. :-)
Thanks for your time,
Thank you!
And please use this attached patch. Your is not correct (ipa is not u32 when debug in on). Thank you again! Feela
Mark
participants (2)
-
Mark Glines -
Ondrej Feela Filip