- Bird-users - Mailing Lists

OSPF & unnumbered interfaces
by Basile Bluntschli 09 Sep '15

09 Sep '15

Hi All I was trying to have OSPF run with the "ip unnumbered interface /32" methodology. So far it was working when specifing the neighbor on the other end: ip addr add 192.168.2.1 peer 10.10.10.10 dev lan3 Is there a way to have it running without a "neighbor statement"? I would like to bring up the OSPF neighborship without knowing the other end Thanks Basile

2 1

Weird Bird BGP MRT dump
by Domingues Luis Filipe 07 Sep '15

07 Sep '15

Hi, Do anyone uses the mrtdump functionnality of Bird? I am trying to get the update BGP update message from Bird using a MRT Dump file. But when I try to parse the files I have inconsistent data. I use there parsers: https://github.com/rfc1036/zebra-dump-parser https://github.com/YoshiyukiYamauchi/mrtparse The zebra parser give me impossible addresses like 16.167.165/104 while the mrtparse just crashes. Any idea where I can look further? Regards, Luis Domingues

2 1

Does Bird 1.5 support MPLS/LDP
by Madhuri 02 Sep '15

02 Sep '15

Hi, I have compiled the BIRD 1.5 code with --enable-mpls, and it got compiled successfully. But when I declare the table for MPLS labels i am getting the syntax error in configuration. I am not finding any code related to LDP under ../../../proto/ Using Ubuntu 15.04 and kernel 3.19.0-21 Does Bird 1.5 Support MPLS? Or Am I missing something in configuration? Thanks, Madhuri

2 2

BFD Debugging Help
by Leighton, Russell 01 Sep '15

01 Sep '15

I'm doing this: protocol bfd { debug { states, routes, filters, interfaces, events, packets }; ... } But I only get "CTL" messages in the syslog. Is there a way to get the full verbose level of logging (packets, etc)? Thx Russ Russell Leighton Senior Software Development Engineer Amazon Web Services / EC2 Networking leightr(a)amazon.com Mobile: 301.828.8458

1 0

[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

bird-tool update (cacti changes)
by Will Dowling 25 Aug '15

25 Aug '15

Hi All, Just a courtesy email to anyone using my bird-tool scripts over at: https://github.com/dowlingw/bird-tool It’s well overdue (over 2 years), but I’ve finally pushed support for multiple sessions with the tools. Like everything else in the tools, this assumes your sessions are named using the pattern "R_AS####x#”. Everything should work as usual, UNLESS you’re using the Cacti graphing script. In that case, you’ll notice that the cacti script now uses the session name (not AS) as the index. I’m sorry to say you’ll need to update your graphs to use this new index. Please feel free to contact me directly if you have any problems. Cheers :) - Will

1 0

BFD and Juniper?
by Leighton, Russell 19 Aug '15

19 Aug '15

I'm trying to get bird 1.5.0 to have BFD work with Juniper MX Routers. Sessions get stuck in Init state with the Juniper side in Down state. Any suggestions? I'm happy to share Juniper traces if that would lend some insight. Thx in advance. -Russ Russell Leighton Senior Software Development Engineer Amazon Web Services / EC2 Networking leightr(a)amazon.com Mobile: 301.828.8458

4 9

Optimizing large BGP -> Linux kernel additions/removals
by Matthew Walster 18 Aug '15

18 Aug '15

When a BGP sessions comes up/down, there is a period of high CPU while all the new best-routes are computed -- this is understandable. However, on boxes I have where this table is then promoted to the Linux kernel, the CPU usage stays high for some considerable time. For a full (~600,000 prefix) >From the looks of things, a bunch of netlink messages are being generated to the kernel to RTM_DELROUTE then RTM_NEWROUTE -- each of which is causing the kernel's trie to rebalance which is a fairly costly operation. I was wondering if anyone had experimented with anything such as implementing either: 1. a corking mechanism (i.e. stop balancing the trie until a signal is sent to uncork) 2. fib_trie garbage collection (i.e. only rebalance the trie once per time interval) 3. "double buffering" (i.e. for a given operation such as protocol flap, memcpy the trie, perform operations, then update the root node pointer to the new optimised trie) Any and all of these ideas may be horrific, I'm just interested whether anyone's running full tables in linux, filled by (e.g.) BIRD, and have encountered this issue. Unfortunately there doesn't appear to be an RTM_CHANGE or similar in Linux, so the DELROUTE will seemingly cause a tree to either be pruned or re-branched, followed by the NEWROUTE causing a full rebalance run -- whereas a CHANGE would (could) hopefully just over-write the value. Many thanks in advance, Matthew Walster

2 1

Dropped netlink updates during scans
by Shaun Crampton 13 Aug '15

13 Aug '15

Hi, We’re using BIRD to redistribute routes that are programmed into the Linux kernel for routing to local containers or VMs. We set a scan time in the kernel section of the config in order to notice when routes are removed. Normally, BIRD picks up routes that are added extremely quickly. However, if a route is added during a scan, it seems to be missed and it is not picked up until the next scan, many seconds later. Is this a known issue; is there a workaround? For example, is there a way to tell BIRD that a route was removed from my external code rather than having it poll? Thanks, -Shaun

2 4