August 2015 - Bird-users

New in BIRD
by Ilias Pallikarakis 23 Aug '16

23 Aug '16

Hi, I recently started trying to learn BIRD. I should also mention I have no previous experience with any other Routing daemon either. I want to configure a bgp monitor for both ipv4 and ipv6. I am running BIRD in a Ubuntu 13.10 VM. I managed to install both bird and bird6 but I have some problems with the configurations. In ipv4 : I created a very simple configuration which I attach. The conf is compiled but in birdc the bgp session is considered idle. I tried to do a tcpdump and found that the router sends a TCP SYN on the VM's bgp port but the VM responds with a RST and never tries to set a BGP session itself. In ipv6 : No matter the configuration (my configuration or the sample coming with bird6 or examples found on the web) the configuration is not compiled giving the following error : BIRD ipv6 doesn't run (bird: /usr/local/etc/bird6.conf, line 1: Router ID must be configured manually on IPv6 routers) Could anyone give me some pointers on what I am doing wrong ? Thank you for your help, Ilias Pallikarakis

5 8

OSPF state inconsistency
by Przemyslaw Frasunek 21 Feb '16

21 Feb '16

Dear all, we are using BIRD 1.4.5 with OSPF on PPPoE access servers running FreeBSD 9.3 and mpd 5.7. In order to achieve fail-over, each access server is listening on the same VLANs. The user connects to access server which first responds with PPPoE PADO. Some of our subscribers need additional IPv4 prefix, which is routed via address assigned from pool. Such route is added by mpd on connect and deleted on disconnect or LCP timeout. Unfortunately, we are experiencing OSPF state inconsistency between access servers, when user quickly disconnects from one node and connects to another. This is such example, which caused routing loop: (on 193.138.118.89) # birdc show route for 46.21.220.80/28 BIRD 1.4.5 ready. 46.21.220.80/28 via 193.138.118.90 on vlan0 [ospf1 13:08:12] * E2 (10/10/10000) [193.138.118.90] (on 193.138.118.90) # birdc show route for 46.21.220.80/28 BIRD 1.4.5 ready. 46.21.220.80/28 via 193.138.118.89 on vlan0 [ospf1 13:12:32] * E2 (10/10/10000) [193.138.118.89] Any ideas, how to fix it? This is our bird.conf: log syslog { remote, error, auth, fatal, bug }; router id 193.138.118.90; protocol kernel { learn; scan time 20; export filter { if proto = "static_bgp" then reject; accept; }; } protocol device { scan time 10; } protocol ospf { preference 10; import filter { accept; }; export filter { if net.ip = 0.0.0.0 then reject; if source = RTS_STATIC then accept; if proto = "kernel1" then accept; if proto = "direct1" then accept; reject; }; area 0 { interface "vlan0" { }; interface "vlan*" { stub; }; interface "carp*" { stub; cost 1000; }; }; } protocol direct { import filter { accept; }; };

2 5

Bird as an MPLS RR
by Evelio VILA 16 Feb '16

16 Feb '16

Hi guys, I'm following the instructions from http://bird.mpls.in/projects/mpls-bird/wiki/Bird_rr but I get a syntax error when adding the table statements. I'm using Bird 1.4.5 for Ubuntu utopic installed from this ppa: deb http://ppa.launchpad.net/cz.nic-labs/bird/ubuntu utopic main deb-src http://ppa.launchpad.net/cz.nic-labs/bird/ubuntu utopic main But it seems that version is not yet compiled for VPNv4 (AFI/SAFI 1/128) capabilities. already checked this link with no luck... https://www.mail-archive.com/bird-users%40atrey.karlin.mff.cuni.cz/msg03141… any ideas? Thanks! Evelio Vila

3 2

segfault with BFD
by Michal Humpula 11 Dec '15

11 Dec '15

Hi, I came across this lovely segfault when using BFD in Bird v1.4.5 and v1.5: (gdb) bt #0 bfd_send_ctl (p=0x5555557cf840, s=0x5555557e2cf8, final=0) at ../../../proto/bfd/packets.c:66 #1 0x000055555556fc86 in timers_fire (loop=loop@entry=0x5555557dfba0) at ../../../proto/bfd/io.c:437 #2 0x000055555556fe24 in birdloop_main (arg=0x5555557dfba0) at ../../../proto/bfd/io.c:759 #3 0x00007ffff7bc4182 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #4 0x00007ffff78f147d in clone () from /lib/x86_64-linux-gnu/libc.so.6 Any idea if this is fixed in latest master or that it might be result of misconfiguration? Cheers Michal

3 5

Socket error: TCP_MD5SIG: Cannot allocate memory
by Brian Rak 19 Nov '15

19 Nov '15

I have a machine running BIRD 1.4.5, and I'm seeing a lot of these messages when I start it up: 2015-08-24 15:54:26 <ERR> xxxx: Socket error: TCP_MD5SIG: Cannot allocate memory 2015-08-24 15:54:26 <ERR> yyyy: Socket error: TCP_MD5SIG: Cannot allocate memory It also seems like the sessions that report that error do not come up, and show a status of 'Error: Kernel MD5 auth failed'. I'm only trying to configure around 200 BGP sessions here, most of which are advertising a very small number of prefixes. I don't really see any tunable settings here, any suggestions as to how I can correct this?

4 7

Device protocol not recognizing interface address change
by Bernardo Figueiredo 29 Sep '15

29 Sep '15

Hello, When restarting some routers at the institution I work, sometimes bird doesn't start announcing any routes until we either restart bird or restart the device protocol using birdc. I think this happens due to the init scripts responsible for setting the network up finishing before the interfaces are fully configured(without the ip address set up), which allows for the init scripts dependent of the network init script, like bird, to start running. The problem is that bird detects that the interfaces are there, but doesn't recognize that the machine is configured with ip addresses(because the interfaces aren't fully configured yet) in the networks that it is announcing, so it doesn't announce the routes. When this happens: "bird> show ospf (...) Area networks: 10.3.0.0/16 Advertise 10.0.0.0/16 Advertise (...) " ( The problem is that the Area networks aren't active). After restarting the bird process, the output becomes correct(because now bird is starting with the interfaces fully configured): "bird> show ospf Area networks: 10.3.0.0/16 Advertise Active 10.0.0.0/16 Advertise Active " We have the device protocol to scan every 10 seconds in our bird.conf: "protocol device { scan time 10; }" I think that even though when bird first starts it shouldn't immediately start announcing(because it didn't see that the interfaces ip addresses), it should after 10 seconds when it scans again, because then the interfaces are already fully configured. For example, when radvd starts it complains that the interfaces don't have ip addresses configured, so it checks every second for the interfaces until they are fully configured, and the starts running correctly. Our current working workaround is make the networking init script wait for some time before exiting, meaning that when the init dependents start executing, the interfaces are already fully configured. This might work for the machine startup, but it doesn't solve the problem when we add a new ip address in a new network to an already existing interface and make bird start announcing that network without restarting bird (or the interface). I haven't checked that the same behaviour described above happens in this situation, but it should. If you want me to try it I can. If I haven't explained some parts clearly just ask and I'll try to explain it better. Also, if you need any configuration details just ask. This problems happens in both bird "1.4.5-1~bpo70+1" and "1.5.0-4" distributed by Debian. So, my question is, shouldn't the Device protocol scan update see that the ip addresses of an interface have changed and if so, start announcing the route. Thank you, Bernardo Figueiredo

3 11

Route server IPv6 avoid_martians
by Jonathan Stewart 10 Sep '15

10 Sep '15

Hi, This page describes an IPv4 route-server: https://gitlab.labs.nic.cz/labs/bird/wikis/Simple_route_server I like the function avoid_martians(), and use it (mine's even been expanded a bit) I'd like to implement something similar for IPv6. Has anyone else already created a function for IPv6? I'm especially wondering about how to filter out too-long prefixes--i think that's the 0.0.0.0/0{25,32} line. Any pointers, even just to how this syntax works, would be welcome. I hope i can update the wiki with the knowledge gleaned. Thanks, Jonathan MBIX.ca

3 6

not listening on 179 but iface up
by Kai 10 Sep '15

10 Sep '15

Dear bird gurus, :) I'm currently setting up a new iBGP-(only)-member. It is configured to connect to 2 internal peers: -------------------- protocol bgp wiesbaden1 from bgp_ibgp_wi { # lotuswurzel neighbor 10.56.0.23 as wi_as; }; protocol bgp wiesbaden2 from bgp_ibgp_wi { # kaschu neighbor 10.56.0.208 as wi_as; }; -------------------- and these 2 peers are configured to connect vice-versa. They don't connect. Additionally bird on the new member doesn't listen on port 179. I first tried it to listen explicitly on two of the hosts IP addresses (is this possible, by the way?) and now removed the explicit "listen" - so that it should now listen on 0.0.0.0:179, right? It doesn't. :( I found hints that bird may postpone opening the socket, if the network interfaces are not yet up. But at least 4 interfaces _are_ up, including the two where the iBGP peers are connected directly. Any ideas? Cheers, Kai -- "Das ist Demokratie, wenn man sich aussuchen darf, wer einen verarscht." (Hagen Rether) D-55118 Meenz fast: kai_pf (aT] web(dot)de ++ PGP Key fingerprint B567 C43E 99D1 7709 7D64 3BF8 2DE8 1092 0EEF D58E ++ -----BEGIN GEEK CODE BLOCK----- VERSION: 3.12 GCS/IT/CM d- s:- a+>-----(?) C++$ UL++(++++$) P+++ L++ E-(+) W--(+) N !w---($) !O !M V? PS+ PE-() Y+ PGP(+) t R*@ tv--@ b+>++ DI++ G e+++(*) h? y? ------END GEEK CODE BLOCK------

2 3

[PATCH RFC 0/1] Adding the Babel routing protocol to Bird
by Toke Høiland-Jørgensen 26 Aug '15

26 Aug '15

Hi everyone Over the past couple of weeks, I have amused myself with adding support for the Babel routing protocol (RFC 6126) to Bird. Quoting the RFC: Babel is a loop-avoiding distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks. The implementation is a clean-slate implementation from the RFC, and it is now at the state where it is reasonably complete (I think), and communicates with the official babeld implementation. At this stage I'm not proposing this be included in Bird proper: I'm pretty sure I got at least parts of the interaction with the core wrong, and there is probably some cleanup needed; and as you can see from the list of limitations below, some things are still needed for this to be a production-quality implementation of the protocol. However, I thought that having some feedback to guide me at this stage would be useful. I would thus like to solicit your opinion on whether or not this is something you could see eventually making it into Bird proper (given that I perform the necessary rework of the code)? And if so, to comment on the implementation and how it might be improved. In particular, I'm interested in your opinion on what to do about IPv4 support (see below). Limitations of the implementation at this stage are (at least): - The implementation is IPv6-only. The Babel protocol supports carrying IPv4 and IPv6 routes in the same protocol instance, and the official implementation only speaks IPv6. The RFC does specify an IPv4 multicast group, v4 support could conceivably be added in the same manner as the other protocols. - Several of the SHOULDs in the RFC are not implemented. Most notably, this implementation is somewhat more chatty than the official implementation, and the route selection procedure is quite rudimentary. - None of the Babel protocol extensions are currently implemented. - I have only performed rudimentary testing: I have confirmed that the implementation can communicate and exchange routes with the official implementation, and have even had it running on my own Babel-enabled VPN. However, I have not tested it in a position in the network where it is likely to suffer from starvation or even have multiple routes for the same prefixes. The protocol addition is included in the next email as a single big patch. Alternatively, I have a repo on github with the whole thing (including the commit history): https://github.com/tohojo/bird. Looking forward to your comments; and thanks in advance! :) Cheers, -Toke Toke Høiland-Jørgensen (1): Add the Babel routing protocol (RFC 6129) to Bird. configure.in | 3 + lib/ip.h | 1 + nest/proto.c | 4 + nest/protocol.h | 2 +- nest/route.h | 11 +- proto/Doc | 1 + proto/babel/Doc | 2 + proto/babel/Makefile | 5 + proto/babel/babel.c | 1417 ++++++++++++++++++++++++++++++++++++++++++++++++++ proto/babel/babel.h | 427 +++++++++++++++ proto/babel/config.Y | 84 +++ proto/babel/packet.c | 436 ++++++++++++++++ sysdep/autoconf.h.in | 1 + 13 files changed, 2392 insertions(+), 2 deletions(-) create mode 100644 proto/babel/Doc create mode 100644 proto/babel/Makefile create mode 100644 proto/babel/babel.c create mode 100644 proto/babel/babel.h create mode 100644 proto/babel/config.Y create mode 100644 proto/babel/packet.c -- 2.5.0

5 13

Update to BIRD BGPsec Implementation
by Michael Baer 25 Aug '15

25 Aug '15

Hi all, I wanted to announce newer versions of BGPsec supporting code using BIRD: bgpsec-bird-client v1.0 and v0.6 of BGPsec support code for BIRD. They are available as a source tarballs at: http://bgpsec.tislabs.com The bgpsec-bird-client application has two main features. It uses the rpki-rtr protocol (http://datatracker.ietf.org/doc/rfc6810) to download RPKI ROAs and router keys and then loads them into a running BIRD router (e.g. rtr_roa_table). It also supports the RPKI-RTR-MIB (http://datatracker.ietf.org/doc/rfc6945/) The BGPsec supporting BIRD code is currently based on v1.4.5 of BIRD. The main changes from the last release is that the the lack of the configure directive, --enable-bgpsec, will remove most of the BGPsec related code at compile time (i.e. without the --enable-bgpsec, the compiled code will be the same as the standard BIRD v1.4.5). It currently supports draft version 12 of the BGPsec protocol specification. This is an ongoing project following the IETF's SIDR Working Group's RPKI/BGPsec work: http://datatracker.ietf.org/wg/sidr/charter/ http://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ The code is still at the testing stage and should not be use used for production services. If any one wants to test the code, please feel free to email me any questions or bug reports. Thanks, Mike -- Michael Baer PARSONS baerm(a)tislabs.com

1 0