January 2016 - 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

Re: RIP with MD5 authentication
by Alexander Velkov 29 Jun '16

29 Jun '16

ok great, thank you for your answer! On Thu, Nov 12, 2015 at 7:01 PM, Ondrej Zajicek <santiago(a)crfreenet.org> wrote: > On Thu, Nov 12, 2015 at 05:25:18PM +0100, Alexander Velkov wrote: > > Hi Ondrej, > > > > thank you for your reply! > > > > When is this branch planned to be integrated to main? > > I guess we will release a new version of BIRD containing RIP from rip-new > branch during 2015-12 or 2016-01. > > -- > Elen sila lumenn' omentielvo > > Ondrej 'Santiago' Zajicek (email: santiago(a)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." >

3 7

[PATCH v2 0/2] Add the Babel routing protocol to Bird
by Toke Høiland-Jørgensen 14 Mar '16

14 Mar '16

This is the updated patch to add the Babel protocol to Bird. It is updated quite a bit compared to the previous version. Specifically: - Split up wire serialisation/deserialisation into a separate part from the semantic handling of TLVs. There's now a separate internal representation of the TLVs in host byte order. These are queued for handling and transmission and only serialised/deserialised at read/write from the wire. The get/put functions from unaligned.h are used to ensure alignment. - Reworked handling of route propagation to the core. Babel now keeps separate selected_in and selected_out entries for each prefix and lets the core pick which route to propagate out. - IPv4 routes are explicitly ignored in the handler instead of the parser. - Entries are timestamped and triggered updates only propagate changed entries. - TX failures are handled and transmission of the TLV queue is resumed when the socket is ready to transmit again. - Added reconfiguration support and cli show* support (based on the rip-new RIP implementation). - Added documentation of more functions and user-facing documentation. - The code has been rearranged to have packet handling code in packet.c and the semantic handlers in babel.c. Also, a bunch of code style changes and other adjustments based on the detailed comments from the last submission. I split this up in two commits, where the first one adds formatting of 64-bit router IDs to bvnsprintf() (which is technically a stand-alone change) and the other adds the Babel protocol. Toke Høiland-Jørgensen (2): Teach bvsnprintf() to print 64-bit router IDs. Add the Babel protocol. configure.in | 3 + doc/bird.sgml | 91 +++ lib/bitops.h | 3 +- lib/ip.h | 5 + lib/printf.c | 31 +- nest/proto.c | 3 + nest/protocol.h | 2 +- nest/route.h | 11 +- proto/Doc | 1 + proto/babel/Doc | 2 + proto/babel/Makefile | 5 + proto/babel/babel.c | 1905 ++++++++++++++++++++++++++++++++++++++++++++++++++ proto/babel/babel.h | 348 +++++++++ proto/babel/config.Y | 127 ++++ proto/babel/packet.c | 863 +++++++++++++++++++++++ proto/babel/packet.h | 127 ++++ sysdep/autoconf.h.in | 1 + 17 files changed, 3518 insertions(+), 10 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 create mode 100644 proto/babel/packet.h -- 2.6.4

3 7

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

bird development
by Daniel Wendler 08 Feb '16

08 Feb '16

Hello everybody, the last bird version (1.5.0) was released around 8 month ago and since then, there were no bug fix release or something. On the RIPE 69 "Bird short update" Ondrej mentioned the 1.5 version is the last one of the 1.X releases and shows the future of bird with 2.x in Q1/2015 and final (3.x) in Q3/2015. As we now have Q1/2016 i want to know if there is an updated Roadmap for the bird development? Will there an 1.5.1 release? When could we expect the 2.X or the 3.X release or is the whole development effort actual in the Turris Omnia project? Thanks. -- Mit freundlichen Grüßen --------------------------------- Daniel Wendler

4 3

bgp path metric
by Rohrmann Sascha 29 Jan '16

29 Jan '16

Hi, I have 2 routers which perform an iBGP peer. Now, every route, which they exchange should get a special metric (e.g: received route from same ASN, route metric= route metric + 100). How am I be able to influence that? I've already tried to check from which AS a route came and preprent (I am not sure if this is the correct keyword btw) it. Here's my filter settings so far: export filter { if bgp_path ~ [= ASN =] then { bgp.path.prepend (ASN,100); accept; } }; I'd be thankful for every help.

1 0

BIRD and ECMP on Linux seems flaky
by Arno Töll 27 Jan '16

27 Jan '16

Hi list, I've been experimenting with bird's ECMP features added to the current git head a while back [1] on my Debian based Linux system. I tried the setup below with git head as of today. I have three Linux routers running with bird. Two I called gw (gateway) one being a frontend. The gateways are configured to establish one BGP session to the frontend each, and advertising fd57::1 and fd57::2 to it. The frontend accepts both advertisement, and exports both to the kernel table. All output below comes from this bird. I configured bird like this: log syslog { debug, trace, info, remote, warning, error, auth, fatal, bug }; router id 10.3.101.3; # Filters filter kernel_export { if net ~ [ fd57::/64{128,128} ] then accept; reject; } # BGP Filters filter bgp_import { if net ~ [ fd57::/64{128,128} ] then accept; reject; } filter bgp_export { reject; } # Local devices protocol device { scan time 10; } protocol direct { interface "*"; } protocol kernel { import none; #learn; merge paths on; export filter kernel_export; } # BGP peers protocol bgp 'gw1' { description "gw1"; default bgp_local_pref 100; local fc57::3 as 65001; neighbor fc57::1 as 65000; next hop self; import filter bgp_import; export filter bgp_export; hold time 30; error wait time 5, 30; } protocol bgp 'gw2' { description "gw2"; default bgp_local_pref 100; local fc57::3 as 65001; neighbor fc57::2 as 65000; next hop self; import filter bgp_import; export filter bgp_export; hold time 30; error wait time 5, 30; } On the system I have this address configuration: root@debian:~# ip addr show eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 64000 qdisc pfifo_fast state UP group default qlen 1000 link/ether 02:01:93:0b:5a:e9 brd ff:ff:ff:ff:ff:ff inet 10.10.216.12/24 brd 10.10.216.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fc57::3/64 scope global valid_lft forever preferred_lft forever inet6 fe80::1:93ff:fe0b:5ae9/64 scope link valid_lft forever preferred_lft forever in bird: root@debian:~# birdc6 BIRD 1.5.0 ready. bird> show protocols name proto table state since info device1 Device master up 14:53:54 direct1 Direct master up 14:53:54 kernel1 Kernel master up 14:53:54 static1 Static master up 14:53:54 gw1 BGP master up 14:53:58 Established gw2 BGP master up 14:53:55 Established bird> show route fd57::2/128 via fc57::1 on eth0 [gw1 14:53:58] ! (100) [AS65000i] via fc57::2 on eth0 [gw2 14:53:55] (100) [AS65000i] fd57::1/128 via fc57::1 on eth0 [gw1 14:53:58] ! (100) [AS65000i] via fc57::2 on eth0 [gw2 14:53:55] (100) [AS65000i] fc57::/64 dev eth0 [direct1 14:53:54] * (240) Result being, that the multipath routes are being installed into the kernel routing table as expected once the sessions are up: root@debian:~# ip -6 route show fc57::/64 dev eth0 proto kernel metric 256 fd57::1 via fc57::1 dev eth0 proto bird metric 1024 fd57::1 via fc57::2 dev eth0 proto bird metric 1024 fd57::2 via fc57::1 dev eth0 proto bird metric 1024 fd57::2 via fc57::2 dev eth0 proto bird metric 1024 fe80::/64 dev eth0 proto kernel metric 256 However, after some time, bird seems to confuse itself by the routes it installed and removes the multipath route again. This can be seen again in ip route show: root@debian:~# ip -6 route show fc57::/64 dev eth0 proto kernel metric 256 fd57::1 via fc57::2 dev eth0 proto bird metric 1024 fd57::2 via fc57::2 dev eth0 proto bird metric 1024 fe80::/64 dev eth0 proto kernel metric 256 In bird they are however still received: root@ps:~# birdc6 show route all BIRD 1.5.0 ready. fd57::2/128 via fc57::1 on eth0 [gw1 16:25:25] ! (100) [AS65000i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 65000 BGP.next_hop: fc57::1 fe80::1:bdff:feab:7f12 BGP.local_pref: 100 via fc57::2 on eth0 [gw2 16:25:23] (100) [AS65000i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 65000 BGP.next_hop: fc57::2 fe80::1:bdff:fe05:64b7 BGP.local_pref: 100 fd57::1/128 via fc57::1 on eth0 [gw1 16:25:25] ! (100) [AS65000i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 65000 BGP.next_hop: fc57::1 fe80::1:bdff:feab:7f12 BGP.local_pref: 100 via fc57::2 on eth0 [gw2 16:25:23] (100) [AS65000i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 65000 BGP.next_hop: fc57::2 fe80::1:bdff:fe05:64b7 BGP.local_pref: 100 ... In the bird log, with debug output enabled I can see: Jan 11 15:12:46 ps bird6: gw1: Got KEEPALIVE Jan 11 15:12:49 ps bird6: gw2: Got KEEPALIVE Jan 11 15:12:50 ps bird6: gw1: Sending KEEPALIVE Jan 11 15:12:52 ps bird6: gw2: Sending KEEPALIVE Jan 11 15:12:54 ps bird6: device1: Scanning interfaces Jan 11 15:12:54 ps bird6: kernel1: Scanning routing table Jan 11 15:12:54 ps bird6: kernel1: fd57::1/128: will be updated Jan 11 15:12:54 ps bird6: kernel1: fd57::1/128: already seen Jan 11 15:12:54 ps bird6: kernel1: fd57::2/128: will be updated Jan 11 15:12:54 ps bird6: kernel1: fd57::2/128: already seen Jan 11 15:12:54 ps bird6: kernel1: Pruning table master Jan 11 15:12:54 ps bird6: kernel1: fd57::2/128: updating Jan 11 15:12:54 ps bird6: Netlink: File exists Jan 11 15:12:54 ps bird6: kernel1: fd57::1/128: updating Jan 11 15:12:54 ps bird6: Netlink: File exists After a while, the problem fixes itself, both routes are being installed, and then the problem reappears for the next cycle. Is there a way around this, or is this actually a bug? To me this looks like bird was scanning it's own routes and falsely scans only one of them. Experimenting with "import all", "learn" etc. for the kernel protocol seems to make no difference. [1] https://gitlab.labs.nic.cz/labs/bird/commit/8d9eef17713a9b38cd42bd59c4ce76c… -- Arno Töll GnuPG Key-ID: 0x9D80F36D

4 5

code change to prevent crash in rt-attr.c
by Steve Atkinson 27 Jan '16

27 Jan '16

Hi, We have a port of bird for a powerpc based Znyx (http://www.znyx.com) ZX6000 ATCA Layer 3 Switch. We have discovered that the current mainline cores while processing rt-attr.c function rta_lookup(), we have traced this back to a uninitialized stack variable in linux/netlink.c function nl_parse_route(). The addition of memset(&ra, 0, sizeof(ra)); Just after the creation of ra, was enough to prevent the crash. Steve PS Apologize for not attaching a patch, but our code tree has many unwanted changes port to ZX6000 which is stuck on gcc-2.95.3 and glibc-2.1.3 ======================= Steve Atkinson CEng BEng(hon) MIET Teligent Ltd 2 Kings Hill Avenue West Malling Kent ME19 4AQ Telephone: +44(0) 1732 879 655 Fax: +44 (0) 1732 879601 [YourHomePhoneIsAnywhere] The information in this email is confidential. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient, please notify the sender immediately at the above address. The sender cannot accept any responsibility for the accuracy or completeness of this message as it has been transmitted over a public network. [BSI] Teligent Ltd is registered in England and Wales, registration number 2893478. Registered office Lion House, Red Lion Street, London WC1R 4GB. VAT registration GB639938577.

1 0

Re: [PATCH v2 2/2] Add the Babel protocol.
by Toke Høiland-Jørgensen 18 Jan '16

18 Jan '16

Juliusz Chroboczek <jch(a)pps.univ-paris-diderot.fr> writes: >> I did not read mentioned thread, but note that here the function >> babel_find_source() iterates only through sources for one propagated >> prefix. > > Ah, I missed that. So yeah, no problem. Ah, right. Was wondering why that would be a problem... Yeah, there's a FIB for the prefix lookup :) Hmm, benchmarking would be interesting; maybe I'll try to get a node attached to that Slovenian network and see what breaks :) >> I have one more general question. Is ETX cost algorithm really >> a reasonable idea? [...] It seems to me that in many cases it will lead >> to oscillations, because packet loss in wireless networks usually >> depends on traffic load. It seems to me that dynamic cost algorithms >> based on packet loss should at least use some hysteresis. > > You're right, we're doing hysteresis in babeld. Yeah, that ended up on my "nice to have" list, so didn't implement it in the first round. Related to that: Ondrej, I believe I saw you mention in another thread that the planned 2.0 release will be coming out soonish. Does that mean there will be dual-stack capabilities? That, and source-specific routing, are the two main things missing from Bird to get this Babel implementation to feature parity with babeld... I'll be happy to look into that at some point in the future (after you're finished going over this version with that fine-toothed comb of yours) :) > I'll be deploying one or two nodes with Toke's code as soon as I redo > our bench network (migrating from AHCP to HNCP), we'll see whether it > introduces any pathologies. Yay! Will look forward to the torrent of bug reports ;) -Toke

1 0