- Bird-users - Mailing Lists

Re: Bird and OpenBSD
by Miłosz Oller 24 Aug '12

24 Aug '12

Configure is OK. When I try to run make, I have: # make "Rules", line 44: Need an operator "Rules", line 48: Need an operator "Rules", line 50: Need an operator "Rules", line 55: Need an operator "Rules", line 64: Need an operator "Rules", line 73: Need an operator "Rules", line 81: Missing dependency operator "Rules", line 82: Could not find depend "Rules", line 83: Need an operator "Rules", line 85: Need an operator Fatal errors encountered - cannot continue -- Miłosz Oller Dnia 2012-08-24, pią o godzinie 00:35 +0200, Crest pisze: > On 24.08.2012 00:26, Miłosz Oller wrote: > > Hi > > > > How can I install BIRD on OpenBSD? In ports is only version 1.3.6. > > In FreeBSD Ports is 1.3.8. > > > Install the dependecies and compile BIRD from source without the ports > infrastructure.

2 2

Bird and OpenBSD
by Miłosz Oller 24 Aug '12

24 Aug '12

Hi How can I install BIRD on OpenBSD? In ports is only version 1.3.6. In FreeBSD Ports is 1.3.8. -- Miłosz Oller

2 3

Unnumbered interface incorrectly marked DOWN
by Tore Anderson 22 Aug '12

22 Aug '12

Hi, I'm trying to migrate to BIRD 1.3.8 from Quagga, and have run across a problem with a unnumbered tun interface. BIRD seems to think that it is DOWN, even though it isn't - and therefore don't export its defined static device routes to the kernel table (they're marked "dormant"). My complete configuration is as follows: log syslog { debug, trace, info, remote, warning, error, auth, fatal, bug }; protocol kernel { scan time 20; export where source = RTS_STATIC_DEVICE; } protocol device { scan time 10; } protocol static { route 172.40.33.3/32 via "nat64"; route 172.40.60.0/26 via "nat64"; } protocol ospf { area 0.47.1.2 { nssa; interface "eth*" { type broadcast; }; stubnet 172.40.33.3/32; stubnet 172.40.60.0/26; }; } Even though the device is clearly UP, BIRD thinks it's DOWN: $ ip address 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:16:3e:d7:0f:8e brd ff:ff:ff:ff:ff:ff inet 172.40.62.91/31 brd 172.40.62.91 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::216:3eff:fed7:f8e/64 scope link valid_lft forever preferred_lft forever 10: nat64: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 500 link/none $ birdc show interfaces BIRD 1.3.8 ready. lo up (index=1) MultiAccess AdminUp LinkUp Loopback Ignored MTU=16436 127.0.0.1/8 (Primary, scope host) eth0 up (index=2) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 172.40.62.91/31 (Primary, opposite 172.40.62.90, scope univ) nat64 DOWN (index=10) PtP Multicast AdminUp LinkUp MTU=1500 $ birdc show static BIRD 1.3.8 ready. 172.40.33.3/32 dev nat64 (dormant) 172.40.60.0/26 dev nat64 (dormant) As soon as I add any bogus IP address to the device, everything starts working just fine: $ ip address add 192.0.2.0/32 dev nat64 $ birdc show interfaces BIRD 1.3.8 ready. lo up (index=1) MultiAccess AdminUp LinkUp Loopback Ignored MTU=16436 127.0.0.1/8 (Primary, scope host) eth0 up (index=2) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 172.40.62.91/31 (Primary, opposite 172.40.62.90, scope univ) nat64 up (index=10) PtP Multicast AdminUp LinkUp MTU=1500 192.0.2.0/32 (Primary, scope univ) $ birdc show static BIRD 1.3.8 ready. 172.40.33.3/32 dev nat64 172.40.60.0/26 dev nat64 $ ip route show proto bird 172.40.33.3 dev nat64 172.40.60.0/26 dev nat64 While this is an acceptable workaround for me, this behaviour must be a bug, right? For what it's worth, Quagga never complained about the unnumbered interface. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com

2 1

Fwd: Bird vs Quagga revisited
by Andrew Latham 22 Aug '12

22 Aug '12

Forwarded conversation Subject: Bird vs Quagga revisited ------------------------ From: *Hank Nussbacher* <hank(a)efes.iucc.ac.il> Date: Wed, Aug 22, 2012 at 1:19 AM To: nanog(a)nanog.org Sorry to disrupt the bad cabling thread, but I'd like to revisit a thread from 2 years ago. I have read over the NANOG presentations: http://www.nanog.org/meetings/**nanog48/presentations/Monday/** Jasinska_RouteServer_N48.pdf<http://www.nanog.org/meetings/nanog48/presentations/Monday/Jasinska_RouteSe…> http://www.nanog.org/meetings/**nanog48/presentations/Monday/** Filip_BIRD_final_N48.pdf<http://www.nanog.org/meetings/nanog48/presentations/Monday/Filip_BIRD_final…> as well as the NANOG thread: http://www.gossamer-threads.**com/lists/nanog/users/123027<http://www.gossamer-threads.com/lists/nanog/users/123027> But have not found anything worthwhile on the matter over the past 2 years. Both Quagga and BIRD have developed since the comparison in 2010: http://savannah.nongnu.org/**news/?group=quagga<http://savannah.nongnu.org/news/?group=quagga> http://bird.network.cz/?o_news But has anyone performed a more recent comparsion? Does Quagga still suffer from performance issues vs BIRD? Has anyone performed an RFC conformance test to see who complies more strictly to all the various RFCs? If BIRD is so much better than Quagga why is there no instance at Oregon: http://www.routeviews.org/ I also notice that BSD Router Project supports both: http://bsdrp.net/bsdrp How well do the two coexist at the same time? Any migration issues going from Quagga to BIRD? Any feedback appreciated. We now take you back to cable wars :-) Thanks, Hank ---------- From: *Andy Davidson* <andy(a)nosignal.org> Date: Wed, Aug 22, 2012 at 6:38 AM To: nanog(a)nanog.org On 22/08/12 06:19, Hank Nussbacher wrote: > Sorry to disrupt the bad cabling thread, but I'd like to revisit a > thread from 2 years ago. I have read over the NANOG presentations: > http://www.nanog.org/meetings/nanog48/presentations/Monday/Jasinska_RouteSe… > > http://www.nanog.org/meetings/nanog48/presentations/Monday/Filip_BIRD_final… > Much of the Quagga pain discussed openly in 2010 was related to its performance as a route-server (which in a large instance might need to converge many millions of best paths, in a multiple table setup). A route-server is more like a database which uses bgp as its interface, than it is a router. The problems that we felt as exchange operators at this time were different to the ones that people using these packages as a router felt. > Both Quagga and BIRD have developed since the comparison in 2010: > http://savannah.nongnu.org/news/?group=quagga > http://bird.network.cz/?o_news I'm not clear what you care about from a performance point of view - forwarding ? acting as a route-server ? collector ? BIRD is a great, super-fast route-server daemon - much "better" than typical competitors Quagga and OpenBGPd at this job. In a forwarding capacity, I do not know and I would really think that Operating system performance and environment tuning will have more to do with forwarding performance than the daemon used. I am hoping that forwarding best-practice information for Quagga eventually comes out of this project : http://opensourcerouting.org/ Andy -- ~ Andrew "lathama" Latham lathama(a)gmail.com http://lathama.net ~

1 0

Route aggregation in BIRD - how?
by Maciej Wierzbicki 20 Aug '12

20 Aug '12

Hello. Case study: * importing full BGP table from various uplinks * some routes received by BGP are being exported via OSPF to core1, using filters: (source = RTS_BGP && bgp_path ~ [= * ASNXYZ * =]) Question: how to aggregate routes (whenever possible) before exporting them via OSPF to core? Example: lets say that I've received a.b.c.d/22 and a.b.c.d/24 from asnXYZ via BGP. Lets say that I want to export routes with asnXYZ in aspath via ospf to core1 switch. Obviously, a.b.c.d/24 is in a.b.c.d/22, so I would like to export only a.b.c.d/22. Is it doable in bird? If yes, any hint/keywords in doc? -- * Maciej Wierzbicki * At paranoia's poison door * * VOO1-RIPE *

6 14

Next-hop issue using iBGP
by Dean Belev (Neterra NMT) 17 Aug '12

17 Aug '12

Hi all, I was performing a home lab and decided to test a new scenario including iBGP between a router and RS. That's a brief scheme of the lab: ### 5.5.5.1 5.5.5.2 6.6.6.100/24 6.6.6.6/24 6.6.6.101/24 Router3 (as3)---eBGP---> Router2 (as2)---iBGP/not a rs_client---> RS (as2)---eBGP / rs_client--- > Router1 (as1) 3.3.3.0/24 2.2.2.0/24 1.1.1.0/24 ### Since, as route 3.3.3.0/24 is seen in RS directly attached ( first asn is as3) with next-hop 6.6.6.100 (I've set the next-hop manually into the RS's config in bgp_in) I expect that Router1 should see it in the same way - with hext-hop 6.6.6.100. But the route is shown with next-hop 6.6.6.6 instead. The first asn is as3 as expected. Do you have any idea why the next-hop is not propagated from RS to R1 as present in the master table but changed to the local IP address ? I think its related with the "not a rs_client" relation between Router2 and RS. Any idea how this behavior may be changed ? Thank you in advance! -- --- *Dean Belev*

4 4

pptp + bird
by Amadeus 16 Aug '12

16 Aug '12

Hello list, is there any best practise to advertise static routes when interface names change? I have many ppp uplinks running on a server (ppp0, ppp1, ppp2 etc.) with static routes on them which I configure like this: > protocol static { > route 10.0.0.0/28 via 169.254.0.1; > route 10.0.0.1/28 via 169.254.0.1; > route 10.0.0.2/28 via 169.254.0.2; > } On startup, bird recognizes perfectly which interface they belong to but if ppp reconnects, the interface name may change and so does the routing information - so it has to be updated by bird, is that any possible? All I can do right now is "check link on" so routes will disappear at least when interfaces go down. There is no 'scan' option for static routes as far as I understand the documentation, or can this be done any differently? Thanks, Amadeus

3 7

bird-lg, another looking glass
by Job Snijders 15 Aug '12

15 Aug '12

Hi all, I'd like to recommend some software a friend of mine, Mehdi Abaakouk, wrote: a very pretty looking BIRD looking glass! The software is available here: https://github.com/sileht/bird-lg/ A live example how cool bird-lg is can be found here: http://lg.ring.nlnog.net/prefix_bgpmap/lg01/ipv6?q=bird.network.cz http://lg.ring.nlnog.net/prefix_bgpmap/lg01/ipv4?q=bird.network.cz# Kind regards, Job ps. This LG is currently taking 23 IPv4 BGP feeds and 24 IPv6 full table feeds, without a sweat! http://tinyurl.com/d2o27q7 BIRD rocks! :-)

3 7

New release 1.3.8
by Ondrej Filip 15 Aug '12

15 Aug '12

Hi Bird users, Santiago did a great job and we have new version 1.3.8. This release includes many improvements. BGP filters can propagate the best secondary route if the primary is rejected. This feature can simplify design of BGP route servers and can save a lot of memory. I will post some examples to wiki soon. Version 1.3.8 (2012-08-07) o Generalized import and export route limits. o RDNSS and DNSSL support for RAdv. o Include in config file support wildcards. o History deduplication in BIRD client. o New route attributes krt_source, krt_metric. o Different instance ID support for OSPFv3. o Real broadcast mode for OSPFv2. o Several minor bugfixes.

3 4

BGP commands enquiry - advertised-route, received-route, and many more
by Jimmy Halim 15 Aug '12

15 Aug '12

Hi guys, I am very new to BIRD daemon. Can I check with anyone in the mailing list on the equivalent commands for the following in BIRD daemon? - Show ip bgp neighbors 1.1.1.1 advertised-routes (cisco) - Show ip bgp neighbors 1.1.1.1 received-routes (cisco) - Show ip bgp neighbors 1.1.1.1 routes (cisco) - Bgpctl show rib (OpenBGPD) - Bgpctl show fib (OpenBGPD) Thanks in advance! Cheers, Jimmy

3 5