September 2009 - Bird-users

Memory Usage of BIRD
by Wolfgang Hennerbichler 05 Dec '09

05 Dec '09

Hi Folks, I just made a little experiment: * let BIRD peer with a router that has Full Feed * letting BIRD eat Full Feed (and tweet) - memory footprint ~ 130 MB BTW (64 Bit Linux) * shutting the session down on the router-side * BIRD's memory consumption decreased to 128 MB, but was never freed again. So now I don't know if this is 'by design' (routes are marked dirty and overwritten on next usage) or a bug... Thanks for any replies; Wolfgang -- www.vix.at | www.aco.net wh(a)univie.ac.at | WH844-RIPE Vienna University Computer Center

2 4

1.1.3 segfaults on seeing certain routes
by KORN Andras 22 Sep '09

22 Sep '09

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.

2 6

Wired Bird BGP behaviour
by Dr. Christian Riede 22 Sep '09

22 Sep '09

Hello, i have the following setup: ISP-Router | --+----------+----------+----------+ NET-ISP | | | | Quagga1 Quagga2 Quagga3 Quagga4 Test-Quagga1 Bird | | | | | | | | | | | | --+-|--------+-|--------+-|--------+-|--------+-|--------+ | NET-1 ----+----------+----------+----------+----------+----------+ NET-2 <-------official productive AS----------> <-- private test AS--> Quagga1-4 belong to our official AS. The Test-Quagga and the Bird use a private AS. All six BGP-Routers in NET-1 and NET-2 are fully meshed with BGP sessions over NET-1 and NET-2. Only Quagga1 and Quagga2 have BGP sessions to the ISP-Router. On Quagga1 and Quagga2, I see about 290000 accepted prefixes on the BGP-sessions to the ISP router and on the two sessions between Quagga1 and Quagga2. On Bird, I also see about 290000 accepted prefixes on all sessions. On Test-Quagga1, I see only 3 accepted prefixes on the sessions to Bird (the direct attached networks). When I shut down all eBGP sessions on Test-Quagga1, I get the expected ~290000 accepted prefixes on the two sessions to the Bird. The routing table grows very slowly. If I stop Bird and start Quagga on the same system, I see all expected ~290000 prefixes on Test-Quagga1 via iBGP. It seems that Bird does not re-announce routes to Test-Quagga1 that it learnt via eBGP if it also receives those routes from Test-Quagga1 via iBGP. This behaviour is different to Quagga. Is my suspicion correct? Can anyone explain this behaviour? What is Bird doing differently than Quagga? Is this a sensible behaviour of Bird? Should/can it be fixed? Mit freundlichen Grüßen Dr. Christian Riede Teamleiter Technik Besuchen Sie uns vom 30.09. bis 02.10.2009 auf der Fachmesse www.SAFEKON.de auf dem Stand E.08 der Karlsruher IT-Sicherheitsinitiative (www.ka-it-si.de) -- _________________________________________ =C=O=N=N=E=C=T== Karlsruhe GmbH Computer und Netzwerktechnik Gebrüder-Himmelheber-Straße 7 D-76135 Karlsruhe Amtsgericht Mannheim HRB 110258 Geschäftsführer: Stefan Kratzer Telefon: +49 (0) 721 20120-0 Telefax: +49 (0) 721 20120-500 Internet: www.it-connect.de E-Mail: christian.riede(a)it-connect.de _________________________________________

4 8

BIRD 1.1.3 doesn't build with IPv6 enabled
by Frederic Jaeckel 18 Sep '09

18 Sep '09

Hi there, I tried building BIRD with IPv6 support (--enable-ipv6) on NetBSD (sparc64) today and sadly it failed.. Maybe this is a known issue but I also wanted to report it. :) Complete output: http://nopaste.com/p/abckbQBXq regards, Frederic

2 4

bug found: as-path prepending
by Wolfgang Hennerbichler 18 Sep '09

18 Sep '09

Hi Guys, I found a bug which crashes bird; It seems to be sufficient to use this import filter in a pipe: import filter { if source=RTS_BGP then bgp_path.prepend(1); }; this crashes my bird (amd64). Does it crash yours, too? Wolfgang -- www.vix.at | www.aco.net wh(a)univie.ac.at | WH844-RIPE Vienna University Computer Center

2 3

AS-Path prepending in Pipes or Filters
by Wolfgang Hennerbichler 17 Sep '09

17 Sep '09

Dear BIRD-Users, I'm currently investigating if it's possible to do as-path prepending in bird in filters or pipes. What I could find was this: bgppath BGP path is a list of autonomous system numbers. You can't write literals of this type. too bad. The goal would be to be able to do a prepending per peer within a pipe or filter. Does Anybody know if this is possible? Wolfgang -- www.vix.at | www.aco.net wh(a)univie.ac.at | WH844-RIPE Vienna University Computer Center

3 3

New release 1.1.3
by Ondrej Filip 17 Sep '09

17 Sep '09

Hello! New version is ready. This version includes two important bug fixes: Version 1.1.3 (2009-09-11) o Bugfix in core o Bugfix in BGP related to AS2->AS4 conversion. RPM and Debian packages are on-line. Ondrej

4 10

Unable to synchronize all routes between 2 nodes running bird with OSPF configured.
by Yoda geek 16 Sep '09

16 Sep '09

Hello there, Need your help in configuring BIRD for ospf. I have 2 nodes running open wrt linux and bird version 1.1.1. The bird binary has been cross-compiled for the ARM platform. OSPF is configured in bird.conf for each node. Node 1 has 3 network interfaces and Node 2 has 4 network interfaces. Below is how Node 1 and 2 topologies are organized Node 1(192.168.3.20) <-------> Node2(192.168.3.10) (192.168.1.1) (192.168.4.10) (192.168.4.20) (192.168.5.10) Please note that Nodes 1 and 2 communicate only via 192.168.3.* network and the other interfaces on each node are independent. Now the issue here is that the routing tables between the 2 nodes aren't synchronized. Node 1 can ping the 192.168.3.10 and 192.168.5.10 IP addresses on Node 2. However there is no route to 192.168.1.* on Node 2. Any help would be highly appreciated. Below is what the bird configuration looks like on each individual node: Node 1 - ifconfig ----------------- root@OpenWrt:~# ifconfig eth0 Link encap:Ethernet HWaddr 00:03:47:DF:33:A0 inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:6515 errors:0 dropped:0 overruns:0 frame:0 TX packets:2076 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:357685 (349.3 KiB) TX bytes:223675 (218.4 KiB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:6 errors:0 dropped:0 overruns:0 frame:0 TX packets:6 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:510 (510.0 B) TX bytes:510 (510.0 B) ra_ap0 Link encap:Ethernet HWaddr 00:0E:8E:20:2B:16 inet addr:192.168.4.20 Bcast:192.168.4.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:5122 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:498002 (486.3 KiB) TX bytes:45008 (43.9 KiB) Interrupt:26 ra_sta0 Link encap:Ethernet HWaddr 00:0E:8E:1A:AD:76 inet addr:192.168.3.20 Bcast:192.168.3.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1321714 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:157112541 (149.8 MiB) TX bytes:176882570 (168.6 MiB) Interrupt:28 Node 1 - bird.conf ------------------ log "/lib/bird.log" { error }; protocol kernel { persist; scan time 20; export all; } protocol device { scan time 10; } protocol ospf { export all; import all; area 0.0.0.0 { interface "eth0"; interface "ra_ap0"; interface "ra_sta0"; }; } Node 1 - birdc output --------------------- BIRD 1.1.1 ready. bird> show ospf neighbor ospf1: Router ID Pri State DTime Router IP Interface 192.168.3.10 1 full/dr 00:38 192.168.3.10 ra_sta0 bird> show route 192.168.1.0/24 dev eth0 [ospf1 01:25] I (150/10) 192.168.3.0/24 dev ra_sta0 [ospf1 01:26] I (150/10) 192.168.4.0/24 dev ra_ap0 [ospf1 01:25] I (150/10) 192.168.5.0/24 via 192.168.3.10 on ra_sta0 [ospf1 01:26] I (150/20) bird> show ospf topology area 0.0.0.0 router 192.168.1.1 network 192.168.3.0/24 metric 10 stubnet 192.168.1.0/24 metric 10 stubnet 192.168.4.0/24 metric 10 router 192.168.3.10 network 192.168.3.0/24 metric 10 stubnet 192.168.4.0/24 metric 10 stubnet 192.168.5.0/24 metric 10 network 192.168.3.0/24 dr 192.168.3.10 router 192.168.3.10 router 192.168.1.1 bird> Node 2 - ifconfig ------------------ root@OpenWrt:~# ifconfig eth0 Link encap:Ethernet HWaddr 00:03:47:DF:33:A8 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) ra_ap0 Link encap:Ethernet HWaddr 00:0E:8E:20:2B:18 inet addr:192.168.3.10 Bcast:192.168.3.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1280530 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:153965150 (146.8 MiB) TX bytes:170985030 (163.0 MiB) Interrupt:28 ra_ap1 Link encap:Ethernet HWaddr 00:0E:8E:1A:AD:96 inet addr:192.168.4.10 Bcast:192.168.4.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:4 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:249 (249.0 B) TX bytes:46040 (44.9 KiB) Interrupt:27 ra_ap2 Link encap:Ethernet HWaddr 00:0E:8E:1A:AF:00 inet addr:192.168.5.10 Bcast:192.168.5.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:39 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4021 (3.9 KiB) TX bytes:46128 (45.0 KiB) Interrupt:26 Node 2 - bird.conf ------------------ log "/lib/bird.log" { error }; protocol kernel { persist; scan time 20; export all; } protocol device { scan time 10; } protocol ospf { export all; import all; area 0.0.0.0 { interface "eth0"; interface "ra_ap0"; interface "ra_ap1"; interface "ra_ap2"; }; } Node 2 - birdc output --------------------- BIRD 1.1.1 ready. bird> show ospf neighbor ospf1: Router ID Pri State DTime Router IP Interface 192.168.1.1 1 full/bdr 00:38 192.168.3.20 ra_ap0 bird> show route 192.168.3.0/24 dev ra_ap0 [ospf1 11:11] I (150/10) 192.168.4.0/24 dev ra_ap1 [ospf1 11:10] I (150/10) 192.168.5.0/24 dev ra_ap2 [ospf1 11:10] I (150/10) bird> show ospf topology area 0.0.0.0 router 192.168.1.1 stubnet 192.168.1.0/24 metric 10 stubnet 192.168.4.0/24 metric 10 stubnet 192.168.3.0/24 metric 10 router 192.168.3.10 network 192.168.3.0/24 metric 10 stubnet 192.168.4.0/24 metric 10 stubnet 192.168.5.0/24 metric 10 network 192.168.3.0/24 dr 192.168.3.10 router 192.168.3.10 router 192.168.1.1 bird>

2 1

Re: BIRD Route-Server template configuration
by Wolfgang Hennerbichler 11 Sep '09

11 Sep '09

On 11.09.2009, at 10:27, Ondrej Filip wrote: > On 11.9.2009 08:58, Wolfgang Hennerbichler wrote: >> Good Morning Ondrej, > > Hi Wolfgang! > great news! However please wait for next release. I fixes one more BGP > related bug. Hi Ondrej, thanks for answering. before we go into production maybe 2 months or so will pass, so no problem, I guess the next release will be out before us going productive :) >> >> I've got bird running in a test-setup where it's already working >> great >> as a route-server with an extremely low memory footprint. Grats for >> that! I'm also getting more and more confident in working with, >> understanding and using bird. However a question that came to my >> mind is >> the strategy you chose here: >> >> On 21.08.2009, at 22:50, Ondrej Filip wrote: >>> >>> All session are unfiltered (except max prefix limit) and >>> connected to routing table named T<AS#>. So it means all prefixes >>> received from R25192x1 and R25192x2 are store in routing table >>> called >>> T25192. Each AS has its own routing table. All those routing table >>> are >>> connected to the master RT by pipe protocols named P<AS#>. Filtering >>> (both in and out) is applied on those PIPE protocols. >> >> >> Why don't you filter in the BGP sessions directly instead of in the >> pipe-protocol, this saves you some precious memory and doesn't do any >> harm, or am I wrong in my thinking? > > That is because I wanted to know what the IXP members sent to me > before filtering. I want them to have good export filters, so I > compare difference before and after filtering. That should be the same > in optimal scenario. I see. So this is your way of 'soft reconfiguration'. > But you way is correct as well of course. Good to know :) > Ondrej > > >> >> Wolfgang >> > > > -- > ( CZ.NIC z.s.p.o. ) > ------------------------------------------------- > Ondrej Filip - CEO > > Office : Americka 23, Praha 2, Czech Republic > Email : ondrej.filip(a)nic.cz http://www.nic.cz > Private: feela(a)network.cz > ------------------------------------------------- > -- www.vix.at | www.aco.net wh(a)univie.ac.at | WH844-RIPE Vienna University Computer Center

1 0

Re: BIRD Route-Server template configuration
by Wolfgang Hennerbichler 11 Sep '09

11 Sep '09

Good Morning Ondrej, I've got bird running in a test-setup where it's already working great as a route-server with an extremely low memory footprint. Grats for that! I'm also getting more and more confident in working with, understanding and using bird. However a question that came to my mind is the strategy you chose here: On 21.08.2009, at 22:50, Ondrej Filip wrote: > > All session are unfiltered (except max prefix limit) and > connected to routing table named T<AS#>. So it means all prefixes > received from R25192x1 and R25192x2 are store in routing table called > T25192. Each AS has its own routing table. All those routing table are > connected to the master RT by pipe protocols named P<AS#>. Filtering > (both in and out) is applied on those PIPE protocols. Why don't you filter in the BGP sessions directly instead of in the pipe-protocol, this saves you some precious memory and doesn't do any harm, or am I wrong in my thinking? Wolfgang -- www.vix.at | www.aco.net wh(a)univie.ac.at | WH844-RIPE Vienna University Computer Center

1 0