RIPng (Sorry for beating a dead horse!)
So I've just started using bird and just wanted to verify with you all what I'm seeing in RIPng. I've scoured the mailing list archives so I'm pretty sure this is the same bug that has been reported before but I figured I would just see if maybe I've actually got a misconfiguration instead. So I'm running BIRD 1.3.2 on a couple of ubuntu boxes: Linux newport 2.6.28-11-server #42-Ubuntu SMP Fri Apr 17 02:45:36 UTC 2009 x86_64 GNU/Linux bird> show status BIRD 1.3.2 setup is pretty simple. I've got two boxes but logically i've made 3 by using two tables on one to simulate two routers. configs exactly are: eth2 - table2 RA - eth0 ---------------------- eth0 RB eth1 ----------------------- eth1 table3 RB -eth3 RouterA: router id 2.2.3.5; table t4; table t5; protocol kernel kern1 { import all; export all; table t4; kernel table 2; scan time 20; } protocol kernel kern2 { import all; export all; table t5; kernel table 3; scan time 20; } protocol device { scan time 10; } protocol direct dir1 { table t4; import all; interface "eth0","eth2"; } protocol direct dir2 { table t5; import all; interface "eth1","eth3"; } protocol rip my_rip1 { table t4; import filter { print "importing"; accept; }; export filter { print "exporting"; accept; }; port 521; honor neighbor; interface "eth0" { metric 2; mode broadcast; }; authentication none; period 30; garbage time 60; } protocol rip my_rip2 { table t5; import filter { print "importing"; accept; }; export filter { print "exporting"; accept; }; port 521; honor neighbor; interface "eth1" { metric 2; mode broadcast; }; authentication none; period 30; garbage time 60; } RouterB: router id 2.2.3.4; protocol kernel kern1 { import all; export all; scan time 20; } protocol device { scan time 10; } protocol direct { import all; interface "eth0","eth1"; } protocol rip my_rip1 { import filter { print "importing"; accept; }; export filter { print "exporting"; accept; }; port 521; honor neighbor; interface "eth0" { metric 2; mode broadcast; }; interface "eth1" { metric 2; mode broadcast; }; authentication none; period 30; garbage time 60; } Now, with mode set to broadcast when using RIPng, I see no updates being sent out on my links. Packet captures turn up nothing and debug <rip instance> all shows nothing. If I change mode broadcast to multicast, I see updates being sent but I then get these messages: bird> debug >>> my_rip2: fe80::215:17ff:fe0d:86f5 send me routing info but he is not my neighbor
my_rip1: fe80::215:17ff:fe0d:86f4 send me routing info but he is not my neighbor my_rip2: fe80::215:17ff:fe0d:86f5 send me routing info but he is not my neighbor my_rip1: fe80::215:17ff:fe0d:86f4 send me routing info but he is not my neighbor my_rip2: fe80::215:17ff:fe0d:86f5 send me routing info but he is not my neighbor my_rip1: fe80::215:17ff:fe0d:86f4 send me routing info but he is not my neighbor my_rip2: fe80::215:17ff:fe0d:86f5 send me routing info but he is not my neighbor my_rip1: fe80::215:17ff:fe0d:86f4 send me routing info but he is not my neighbor my_rip2: fe80::215:17ff:fe0d:86f5 send me routing info but he is not my neighbor my_rip1: fe80::215:17ff:fe0d:86f4 send me routing info but he is not my neighbor
I hadn't seen those messages turn up in anyone elses posts to the mailing list about RIPng so it's making me think I have a misconfiguration somewhere. Thanks David
On Fri, Feb 17, 2012 at 05:09:39PM -0500, David Splittberger wrote:
So I've just started using bird and just wanted to verify with you all what I'm seeing in RIPng. I've scoured the mailing list archives so I'm pretty sure this is the same bug that has been reported before but I figured I would just see if maybe I've actually got a misconfiguration instead.
protocol rip my_rip2 { table t5; import filter { print "importing"; accept; }; export filter { print "exporting"; accept; }; port 521; honor neighbor;
my_rip1: fe80::215:17ff:fe0d:86f4 send me routing info but he is not my neighbor I hadn't seen those messages turn up in anyone elses posts to the mailing list about RIPng so it's making me think I have a misconfiguration somewhere.
First, 'mode broadcast' cannot work with IPv6 (but BIRD should complain about bad config). Your messages are specific to 'honor neighbor' option, but the main problem is in RIPng implementation of BIRD (which is broken from the beginning). You can use attached patch to get RIPng work (at least on Linux, probably also with 'honor neighbor' option, but i didn't checked that). It contains the patch from Roman Hoog Antink [1], does not contain the patch from Goesta Smekal [2] (which is needed just for compatibily with other implementations), but it could be used simuntaneously. [1] http://www.mail-archive.com/bird-users@atrey.karlin.mff.cuni.cz/msg01604.htm... [2] http://www.mail-archive.com/bird-users@atrey.karlin.mff.cuni.cz/msg01824.htm... -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Hi to all, I am very glad, David jumped the same horse I did - which makes it less dead than we thought ;-) Am 2012-02-18 13:06, schrieb Ondrej Zajicek:
You can use attached patch to get RIPng work (at least on Linux, probably also with 'honor neighbor' option, but i didn't checked that).
Yes, "honor neighbor" works fine under Linux. I can happily confirm that RIPng is now a working protocol with BIRD! Thank you very much.
It contains the patch from Roman Hoog Antink [1], does not contain the patch from Goesta Smekal [2] (which is needed just for compatibily with other implementations), but it could be used simuntaneously.
Hmm ... I wonder if interoperability is really that optional for a routing daemon. Anyway, my patch still works against current git version, so it works for me ;-) kind regards Goesta -- #!/usr/bin/perl foreach $c (split(/ /,"47 6f 65 73 74 61 20 53 6d 65 6b 61 6c 0d 0a")) { print pack("C", hex($c));}
participants (3)
-
David Splittberger -
Goesta Smekal -
Ondrej Zajicek