Hi, Background: I'm completely new to BIRD. I have five locations connected via OpenVPN in a full mesh, using Linux 2.6 routers, and I thought I'd try dynamic instead of static routing. At first I just wanted to see how/what BIRD would do, so I set it to use kernel routing table 3 which I don't use for policy routing. I copied the contents of my other routing tables into table 3 and fired up bird, which promptly segfaulted. gdb shows: #0 0x00007ffff7901210 in strlen () from /lib/libc.so.6 #1 0x000000000043fe3c in bvsnprintf (buf=0x7fffffffdab0 "via 172.18.68.254 on ", size=999999979, fmt=0x441b2b "s", args=0x7fffffffd960) at printf.c:232 #2 0x000000000044071c in bsprintf (buf=0x7fffffffdab0 "via 172.18.68.254 on ", fmt=0x441b20 "via %I on %s") at printf.c:372 #3 0x0000000000403b67 in rt_format_via (e=0x683300, via=0x7fffffffdab0 "via 172.18.68.254 on ") at /tmp/bird-1.1.3/nest/rt-table.c:1052 #4 0x0000000000401ded in rte_trace (p=0x6771c0, e=0x683300, dir=62, msg=0x4419af "added [best]") at /tmp/bird-1.1.3/nest/rt-table.c:142 #5 0x0000000000402b17 in rte_trace_in (flag=2, p=0x6771c0, e=0x683300, msg=0x4419af "added [best]") at /tmp/bird-1.1.3/nest/rt-table.c:150 #6 0x00000000004027bb in rte_recalculate (table=0x674640, net=0x682118, p=0x6771c0, src=0x6771c0, new=0x683300, tmpa=0x0) at /tmp/bird-1.1.3/nest/rt-table.c:436 #7 0x0000000000402d8a in rte_update (table=0x674640, net=0x682118, p=0x6771c0, src=0x6771c0, new=0x683300) at /tmp/bird-1.1.3/nest/rt-table.c:633 #8 0x0000000000439b61 in krt_learn_announce_update (p=0x6771c0, e=0x6830f0) at krt.c:283 #9 0x000000000043a039 in krt_learn_prune (p=0x6771c0) at krt.c:386 #10 0x000000000043a9ae in krt_prune (p=0x6771c0) at krt.c:677 #11 0x000000000043aaea in krt_scan (t=0x67fa60) at krt.c:729 #12 0x000000000043723e in tm_shot () at io.c:355 #13 0x0000000000438d80 in io_loop () at io.c:1260 #14 0x000000000043c5c3 in main (argc=4, argv=0x7fffffffe008) at main.c:471 The following routes are sufficient (but maybe not all of them necessary) to reproduce the segfault: # ip ro sh table 3 172.18.68.254 dev tap5 scope link src 172.18.32.254 10.10.107.0/24 via 172.18.68.254 dev tap5 src 172.18.32.254 192.168.12.0/22 via 172.18.68.254 dev tap5 src 172.18.32.254 172.18.64.0/20 via 172.18.68.254 dev tap5 src 172.18.32.254 The bird config reads as follows: log stderr all; router id 172.18.32.254; debug protocols all; protocol direct { interface "tap1", "tap2", "tap3", "tap5"; } protocol kernel { learn; # Learn all alien routes from the kernel persist; # Don't remove routes on bird shutdown scan time 10; # Scan kernel routing table every 20 seconds export all; # Default is export none kernel table 3; # Kernel table to synchronize with (default: main) } protocol device { scan time 10; # Scan interfaces every 10 seconds } protocol static { } protocol ospf vpn { tick 2; area 0 { interface "tap1", "tap2", "tap3", "tap5" { password "secretsecretsecr"; dead 20; type pointopoint; authentication cryptographic; }; }; } Additionally, when running with an empty table 3 on one of the neighbours of this router, it logged messages like: 21-09-2009 12:55:08 <WARN> Received HELLO packet address (172.18.32.254) is inconsistent with the primary address of interface tap4. It indeed is inconsistent, because all tap interfaces have the same address on each router (specific to the router, with a /32 mask), and I use host routes to make them visible on the other end; effectively, my tap links are point to point. This works perfectly for static routing; I hope BIRD's warning doesn't mean that it ignores that Hello message...? Andras -- Andras Korn <korn at elan.rulez.org> - <http://chardonnay.math.bme.hu/~korn/> Everybody wants to go to heaven, but nobody wants to die.
On Mon, Sep 21, 2009 at 01:39:56PM +0200, KORN Andras wrote:
Hi,
Background: I'm completely new to BIRD. I have five locations connected via OpenVPN in a full mesh, using Linux 2.6 routers, and I thought I'd try dynamic instead of static routing. At first I just wanted to see how/what BIRD would do, so I set it to use kernel routing table 3 which I don't use for policy routing. I copied the contents of my other routing tables into table 3 and fired up bird, which promptly segfaulted.
Just a remark - it is usually better idea to use static section in bird.conf to configure static routes than to import alien routes from kernel. But both variants should work.
The following routes are sufficient (but maybe not all of them necessary) to reproduce the segfault:
# ip ro sh table 3 172.18.68.254 dev tap5 scope link src 172.18.32.254 10.10.107.0/24 via 172.18.68.254 dev tap5 src 172.18.32.254 192.168.12.0/22 via 172.18.68.254 dev tap5 src 172.18.32.254 172.18.64.0/20 via 172.18.68.254 dev tap5 src 172.18.32.254
Could you send me shell commands that sets these routes? It seems that problem is that BIRD does not properly import these routes (and does not consider 172.18.68.254 as a neighbor).
Additionally, when running with an empty table 3 on one of the neighbours of this router, it logged messages like:
21-09-2009 12:55:08 <WARN> Received HELLO packet address (172.18.32.254) is inconsistent with the primary address of interface tap4.
It indeed is inconsistent, because all tap interfaces have the same address on each router (specific to the router, with a /32 mask)
BIRD expects that interface uses either 'standard' network address, or address with /32 mask and specified peer address (configured with 'ip address add IP1 peer IP2 dev DEV' or similarly using ifconfig and pointopoint). In both cases there should not be this warning as this warning means that Hello message was ignored. Is seems that you set up /32 peer routes in a different manner. Maybe we could extend BIRD to handle such configuration. -- 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."
On Tue, Sep 22, 2009 at 01:44:04PM +0200, Ondrej Zajicek wrote:
Background: I'm completely new to BIRD. I have five locations connected via OpenVPN in a full mesh, using Linux 2.6 routers, and I thought I'd try dynamic instead of static routing. At first I just wanted to see how/what BIRD would do, so I set it to use kernel routing table 3 which I don't use for policy routing. I copied the contents of my other routing tables into table 3 and fired up bird, which promptly segfaulted.
Just a remark - it is usually better idea to use static section in bird.conf to configure static routes than to import alien routes from kernel. But both variants should work.
Maybe I'll switch to that when things appear to work; however, my intention is for these routes to be created dynamically, automatically, based on OSPF. They are static now because I'm not using dynamic routing at all. I seeded bird with them because I wanted to see whether it would be safe to run bird on the live tables (i.e. whether it wouldn't remove important routes).
The following routes are sufficient (but maybe not all of them necessary) to reproduce the segfault:
# ip ro sh table 3 172.18.68.254 dev tap5 scope link src 172.18.32.254 10.10.107.0/24 via 172.18.68.254 dev tap5 src 172.18.32.254 192.168.12.0/22 via 172.18.68.254 dev tap5 src 172.18.32.254 172.18.64.0/20 via 172.18.68.254 dev tap5 src 172.18.32.254
Could you send me shell commands that sets these routes?
Sure. Just prepend 'ip ro add' and append 'table 3' to each line, like this: ip ro add 172.18.68.254/32 dev tap5 scope link src 172.18.32.254 table 3 ip ro add 10.10.107.0/24 via 172.18.68.254 dev tap5 src 172.18.32.254 table 3 ip ro add 192.168.12.0/22 via 172.18.68.254 dev tap5 src 172.18.32.254 table 3 ip ro add 172.18.64.0/20 via 172.18.68.254 dev tap5 src 172.18.32.254 table 3 Of course, the interface must exist first; you can create it with tunctl or openvpn --mktun --dev tap5. Then give it an address with e.g. ip addr add dev tap5 172.18.32.254/32.
It seems that problem is that BIRD does not properly import these routes (and does not consider 172.18.68.254 as a neighbor).
The first route declares it a neighbour...
Additionally, when running with an empty table 3 on one of the neighbours of this router, it logged messages like:
21-09-2009 12:55:08 <WARN> Received HELLO packet address (172.18.32.254) is inconsistent with the primary address of interface tap4.
It indeed is inconsistent, because all tap interfaces have the same address on each router (specific to the router, with a /32 mask)
BIRD expects that interface uses either 'standard' network address, or address with /32 mask and specified peer address (configured with 'ip address add IP1 peer IP2 dev DEV' or similarly using ifconfig and pointopoint). In both cases there should not be this warning as this warning means that Hello message was ignored.
OK, I will retry with this kind of peer setup, but I think I can't test anything meaningfully while my routes cause a segfault.
Is seems that you set up /32 peer routes in a different manner. Maybe we could extend BIRD to handle such configuration.
I would certainly see that as useful. :) Andras -- Andras Korn <korn at elan.rulez.org> - <http://chardonnay.math.bme.hu/~korn/> Blessed are the young, for they shall inherit the national debt.
On Tue, Sep 22, 2009 at 02:08:40PM +0200, KORN Andras wrote:
The following routes are sufficient (but maybe not all of them necessary) to reproduce the segfault:
# ip ro sh table 3 172.18.68.254 dev tap5 scope link src 172.18.32.254 10.10.107.0/24 via 172.18.68.254 dev tap5 src 172.18.32.254 192.168.12.0/22 via 172.18.68.254 dev tap5 src 172.18.32.254 172.18.64.0/20 via 172.18.68.254 dev tap5 src 172.18.32.254
Could you send me shell commands that sets these routes?
Sure. Just prepend 'ip ro add' and append 'table 3' to each line, like this:
ip ro add 172.18.68.254/32 dev tap5 scope link src 172.18.32.254 table 3 ip ro add 10.10.107.0/24 via 172.18.68.254 dev tap5 src 172.18.32.254 table 3
That i tried but doesn't work for me: rb1:~# ip a a 10.0.0.1/32 dev eth0 rb1:~# ip r a 10.0.1.1/32 dev eth0 scope link src 10.0.0.1 table 3 rb1:~# ip r a 10.0.2.0/24 via 10.0.1.1 dev eth0 src 10.0.0.1 table 3 RTNETLINK answers: No such process
Additionally, when running with an empty table 3 on one of the neighbours of this router, it logged messages like:
21-09-2009 12:55:08 <WARN> Received HELLO packet address (172.18.32.254) is inconsistent with the primary address of interface tap4.
It indeed is inconsistent, because all tap interfaces have the same address on each router (specific to the router, with a /32 mask)
BIRD expects that interface uses either 'standard' network address, or address with /32 mask and specified peer address (configured with 'ip address add IP1 peer IP2 dev DEV' or similarly using ifconfig and pointopoint). In both cases there should not be this warning as this warning means that Hello message was ignored.
OK, I will retry with this kind of peer setup, but I think I can't test anything meaningfully while my routes cause a segfault.
I think that both problems are related. If you use: ip addr add dev tap5 172.18.32.254/32 peer 172.18.68.254 instead of ip addr add dev tap5 172.18.32.254/32 ip ro add 172.18.68.254/32 dev tap5 scope link src 172.18.32.254 table 3 then i expect that both problems would disappear. Of course, we should also fix that segfault anyway. -- 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."
On Tue, Sep 22, 2009 at 03:55:30PM +0200, Ondrej Zajicek wrote:
Sure. Just prepend 'ip ro add' and append 'table 3' to each line, like this:
ip ro add 172.18.68.254/32 dev tap5 scope link src 172.18.32.254 table 3 ip ro add 10.10.107.0/24 via 172.18.68.254 dev tap5 src 172.18.32.254 table 3
That i tried but doesn't work for me:
rb1:~# ip a a 10.0.0.1/32 dev eth0 rb1:~# ip r a 10.0.1.1/32 dev eth0 scope link src 10.0.0.1 table 3 rb1:~# ip r a 10.0.2.0/24 via 10.0.1.1 dev eth0 src 10.0.0.1 table 3 RTNETLINK answers: No such process
Weird. I've been using this setup for years now. What kernel is that? For example, one of the particular interfaces I configure like this (Debian interfaces(5) snippet): auto tap2 iface tap2 inet static address 172.18.68.254 netmask 255.255.255.255 pre-up openvpn --rmtun --dev tap2 || true pre-up openvpn --mktun --dev tap2 pre-up ifconfig tap2 hw ether 00:FF:00:00:05:02 up ip ro add 172.18.17.254/32 dev tap2 src 172.18.68.254 up ip ro add 172.18.16.0/20 via 172.18.17.254 dev tap2 src 172.18.68.254 post-down openvpn --rmtun --dev tap2 I copied my routes from the other tables into table 3 using just ip ro sh | sed 's/^/ip ro add /;s/$/ table 3/' | sh and it worked flawlessly. Andras -- Andras Korn <korn at elan.rulez.org> - <http://chardonnay.math.bme.hu/~korn/> Reality is that which, when you stop believing in it, doesn't go away.
On Tue, Sep 22, 2009 at 02:08:40PM +0200, KORN Andras wrote:
21-09-2009 12:55:08 <WARN> Received HELLO packet address (172.18.32.254) is inconsistent with the primary address of interface tap4.
It indeed is inconsistent, because all tap interfaces have the same address on each router (specific to the router, with a /32 mask)
BIRD expects that interface uses either 'standard' network address, or address with /32 mask and specified peer address (configured with 'ip address add IP1 peer IP2 dev DEV' or similarly using ifconfig and pointopoint). In both cases there should not be this warning as this warning means that Hello message was ignored.
OK, I will retry with this kind of peer setup, but I think I can't test anything meaningfully while my routes cause a segfault.
I can confirm that I indeed don't get the warning this way; however, bird doesn't seem to import some 'alien' routes that are imported if I specify them inside static { }. I had these static routes in my kernel routing table: 172.18.4.0/24 dev wifi proto kernel scope link src 172.18.4.254 172.18.0.0/22 dev intra proto kernel scope link src 172.18.1.254 172.18.8.0/21 dev dmz proto kernel scope link src 172.18.8.254 And bird didn't send them to its peer. When I specified them in static { }, they were missing the "src" attribute but were propagated over OSPF. Nevertheless, bird is approaching usability for me now, although I haven't yet dared try it on my real routing tables. :) I certainly like the approach a lot better than quagga & co. Andras -- Andras Korn <korn at elan.rulez.org> - <http://chardonnay.math.bme.hu/~korn/> Expert - Someone who knows less, but makes more money.
On Tue, Sep 22, 2009 at 03:55:43PM +0200, KORN Andras wrote:
I can confirm that I indeed don't get the warning this way; however, bird doesn't seem to import some 'alien' routes that are imported if I specify them inside static { }.
I had these static routes in my kernel routing table:
172.18.4.0/24 dev wifi proto kernel scope link src 172.18.4.254 172.18.0.0/22 dev intra proto kernel scope link src 172.18.1.254 172.18.8.0/21 dev dmz proto kernel scope link src 172.18.8.254
And bird didn't send them to its peer.
I think the problem might be in 'scope link' - BIRD does not propagate routes with such limited scope through OSPF. -- 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."
participants (2)
-
KORN Andras -
Ondrej Zajicek