July 2015 - Bird-users - Mailing Lists

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

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

[PATCH] static: Support for BFD controlled static routes
by Steve Atkinson 02 Aug '15

02 Aug '15

Hi, This is my first submission into the community, it is a change to the static protocol to support the addition / deletion of static routes based on the availability of the gateway as determined by BFD. This was implemented as a proof of concept for one of our customers, it appears to work although has only been tested against the bfd-beacon, with routes exported to a remote BGP associated router. There two non-related changes to the which move the declaration of some variable to the start of the appropriate function, this is because we are using a very only GCC compiler that doesn't allow declaration mid code. Regards Steve ======================= 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.

3 2

bird6: "Netlink: No such process" error from kernel proto on OSPF multipath prefixes
by Israel G. Lugo 30 Jul '15

30 Jul '15

Hello, I am seeing periodic "Netlink: No such process" messages from bird6, apparently related to prefixes learned from OSPF where there are two equal cost paths. I've got ECMP on, and am installing routes to the kernel via kernel protocol. Operating system is GNU/Linux (Debian), kernel 3.16. The problem happens when kernel protocol starts pruning table master. Apparently, it's always deciding to update these multiple-path routes, and has some failure while trying. Log excerpt: bird6: kernel1: fec0:0:0:ffff::2/128: seen bird6: kernel1: fec0:0:0:ffff::3/128: seen bird6: kernel1: ::/0: seen bird6: kernel1: Pruning table master bird6: kernel1: 2001:xxx:yyy:z1::/64: updating bird6: Netlink: No such process bird6: kernel1: 2001:xxx:yyy:z2::/64: updating bird6: Netlink: No such process ... This is what "show route" has to say about one of these routes: bird> show route 2001:xxx:yyy:z1::/64 all 2001:xxx:yyy:z1::/64 multipath [backbone 2015-07-21] * IA (150/20) [193.aa.bb.137] via fe80::21e:bff:fec1:8c4a on eth1 weight 1 via fe80::21e:bff:fec1:8c50 on eth1 weight 1 Type: OSPF-IA unicast univ OSPF.metric1: 20 OSPF.metric2: 16777215 OSPF.tag: 0x00000000 OSPF.router_id: 193.aa.bb.137 "show route" periodically displays these routes with a '!' instead of '*', indicating a synchronization error. These "No such process" messages seem to occur every 40 seconds or so. I am seeing this error both on BIRD 1.4.5 and BIRD 1.5.0. Relevant topology: Four BIRD routers, A, B, C and D. All in area 0. A+B are ABR for area 194, and C+D are ABR for area 165. A and B announce IA prefixes z1, z2, z3, z4, z5, z6, z7 and z8 with equal cost. C and D announce IA prefixes z9 and z10 with equal cost. A and B have the error on prefixes from C and D, and vice-versa. Routes seem to disappear from kernel periodically, and are reinstalled again (monitoring with "ip -6 r"). Other routes, non-multipath from other routers, do not seem affected. Relevant config, from routers C and D: # common to all routers protocol kernel { learn; persist; scan time 20; export all; } protocol ospf backbone { tick 1; ecmp yes; area 0.0.0.0 { stub no; interface "eth1" { check link yes; }; }; area 0.0.165.0 { stub yes; summary yes; interface "eth0.2000" { type ptp; check link yes; }; interface "eth0.141", "eth0.165", "eth0.1411" { stub; check link yes; }; networks { 2001:xxx:yyy:z9::/64; 2001:xxx:yyy:z10::/64; }; }; } Routers A and B are similar but different prefixes of course. I do not see this problem with IPv4 bird (also OSPF, similar configuration). Could this be some bug with kernel protocol and multipath routes? I am available for further explanations or more details (logs, configs). Best regards, -- Israel G. Lugo Núcleo de Redes e Comunicações Direção de Serviços de Informática Instituto Superior Técnico

4 5

ZeroMQ integration for route output
by Sam Russell 28 Jul '15

28 Jul '15

Hi all, I've been working on integrating BIRD into some SDN packages (VANDERVECKEN/RouteFlow, ONOS), and as part of this I've built zeromq in as an option. It's still beta, but you can stand up BIRD and poll the ZeroMQ socket and it'll reply with a route table dump in JSON. Keen to hear what people think https://github.com/samrussell/bird/tree/zmqintegration Cheers Sam

2 2

Avoiding routes being tagged as 'unreachable' when building a route-server / lg
by Paul S. 27 Jul '15

27 Jul '15

Hi guys, New BIRD user here, I'm trying to use bird to build a looking glass / route collector. All my core routers (I don't have a backbone network, so they run separately) are forwarding the full table by treating the bird system as a rr client. So far, this part of it works fine. The sessions are IBGP (and multihop by nature). My problem is the fact that bird classifies the routes as unreachable (as they indeed are, but I don't intend to use them to forward) and mentions this in the birdc lookups. A sample is given at the bottom, as well as the very simple config that I'm using right now (No tables, but I intend to set up tables per peer ('location') later) My question is how should I deal with this issue? bird> show route 8.8.8.0/24 all 8.8.8.0/24 unreachable [dfw_cr_0 07:39:20 from 10.1.13.1] * (100/-) [AS15169i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 3491 15169 BGP.next_hop: 63.218.23.65 BGP.local_pref: 400 BGP.community: (3491,2000) (3491,2001) (3491,15169) unreachable [syd_ocr_0 07:40:16 from 10.2.1.217] (100/-) [AS15169i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 15169 BGP.next_hop: 103.26.68.56 BGP.med: 0 BGP.local_pref: 106 BGP.community: (58941,0) unreachable [lax_ocr_0 07:39:26 from 10.3.14.1] (100/-) [AS15169i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 15169 BGP.next_hop: 206.72.210.41 BGP.med: 0 BGP.local_pref: 108 BGP.community: (19996,19996) unreachable [jfk_ocr_0 07:39:21 from 10.4.15.1] (100/-) [AS15169i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 174 15169 BGP.next_hop: 38.104.75.221 BGP.med: 10040 BGP.local_pref: 100 BGP.community: (174,21000) (174,22013) Current config, the macros have been removed for obvious reasons. > log "/var/log/bird.log" all; > > router id r_id; > > > protocol device { } > > template bgp peers { > local as myas; > multihop; > import all; > export none; > } > > protocol bgp syd_ocr_0 from peers > { > description "Sydney Open Core 0"; > neighbor syd_ocr_0_ip as peeras; > password syd_ocr_0_password; > } > > protocol bgp lax_ocr_0 from peers > { > description "Los Angeles Open Core 0"; > neighbor lax_ocr_0_ip as peeras; > password lax_ocr_0_password; > } > > protocol bgp jfk_ocr_0 from peers > { > description "New York Open Core 0"; > neighbor jfk_ocr_0_ip as peeras; > password jfk_ocr_0_password; > } > > protocol bgp dfw_ocr_0 from peers > { > description "Dallas Open Core 0"; > neighbor dfw_ocr_0_ip as peeras; > password dfw_ocr_0_password; > }

3 4

Enhanced Route Refresh Capability (rfc7313)
by Arnaud Fenioux 27 Jul '15

27 Jul '15

Hello, We updated one of our Route-server and noticed that a few number of our peers could not establish IPv6 sessions with us. The reason in the logs was "Received: Required capability missing”. After some tcpdump and investigation we found that Enhanced Route Refresh Capability was newly advertised (as explained in the bird release notes). Sadly Juniper boxes do think that this capability is mandatory (only) in IPv6. We have disabled route refresh (enhanced and regular), as a work-around, for these peers. enable route refresh off; Would it be possible to only disable enhanced route refresh in the configuration file for a next release of bird? Cheers, -- Arnaud Fenioux Network Engineer - FranceIX

4 6