December 2016 - Bird-users

Version 1.6.2
by Ondrej Filip 31 Aug '17

31 Aug '17

Dear users, a new version of the 1.6.x branch is out: Version 1.6.2 (2016-09-29) o Fixes serious bug introduced in the previous version Upgrade from 1.6.1 is highly recommended. Enjoy it! Ondrej

4 6

BGP Monitoring Protocol (BMP) support in Bird?
by Baptiste Jonglez 11 Jul '17

11 Jul '17

Hi, I am wondering if somebody is working on BGP Monitoring Protocol (BMP) support in Bird? Note that I'm just asking, I'm not requesting our beloved Bird developers to add this feature with a deadline set to yesterday :) I might try to implement it if nobody else already did. Basically, this is just a way to export BGP data over a TCP connection: http://tools.ietf.org/html/rfc7854 This looks like a useful alternative to dumping to mrtdump files, there are already several free software clients: https://code.google.com/archive/p/bmpreceiver/ http://www.openbmp.org/#!index.md Baptiste

3 3

Version 2.0.0pre0
by Ondrej Filip 23 Feb '17

23 Feb '17

Dear BIRD users, it took us a very long time, but we are moving towards 2.0.x branch. Main feature of this branch is IPv4 and IPv6 integration. Please note, 2.0.x will be an _experimental_ branch. We will not guarantee configuration stability etc. And today we release 2.0.0-pre0. So that's experimental version of experimental branch. Keep this in mind and DO NOT USE IT IN PRODUCTION ENVIRONMENT. On the other hand, testers are more than welcome. Please use it and report (either positive or negative)! We will not provide packages for any distribution. Version 2.0.0-pre0 (2016-12-07) o Integrated IPv4 + IPv6 design o Major BGP protocol redesign o BGP multicast support (SAFI 2) o BGP flowspec support (RFC 5575) o New RPKI-Router protocol o New build system o Unit tests Notes: Protocols and tables are now connected using explicit channels, most related protocol options (table, import, export, ...) are now channel options. See doc/bird.conf.example2 for configuration examples. Ondrej

8 11

Route attributes overwritten during reconfiguration
by João Taveira Araújo 17 Feb '17

17 Feb '17

Hi, I've run into a bug which manifests itself during reconfiguration. Unfortunately, the bird config in question is extremely large and I can't easily cut it down to something replicable. I'm running into this particular issue in bird6, but have no reason to believe IPv4 would fair any better. All results are using bird 1.6.2. My setup is as follows: - a static protocol, in which the import stanza adds extended communities: route 2001:db8::/48 via "lo" { bgp_ext_community.add((ro, 2, 0)); bgp_ext_community.add((ro, 3, 0)); ... } - based on these communities, the static route makes its way through a pipe from the master table, to an external table Typically all is fine - we export the route to our transits. Since we have multiple egress devices, a "show route" will show our local, static route, as well as the same route learnt through our providers: sudo birdc6 show route for 2001:db8::/48 BIRD 1.6.2 ready. 2001:db8::/48 dev lo [static_protocol 04:42:26] * (200) via xxx on et1 [transit_1 03:44:07] (100) via xxx on et2 [transit_2 03:44:07] (100) We actually have three transits, but one of our transits does not export any routes we happen to be exporting to them. Such a case happens on reconfiguring BIRD. During a reconfiguration, the static protocol gets reloaded: <TRACE> static_protocol > 2001:db8::/48 added [best] dev lo in this brief moment, a window of opportunity arises for our thus far silent transit to make an unwanted appearance: sudo birdc6 show route for 2001:db8::/48 BIRD 1.6.2 ready. 2001:db8::/48 dev lo [static_protocol 05:44:07] * (200) via xxx on et3 [transit_3 05:44:07] (100) via xxx on et1 [transit_1 03:44:07] (100) via xxx on et2 [transit_2 03:44:07] (100) This, it turns out, is tragic, because somehow the extended communities we apply to the route learnt from transit_3 clobber the ones we apply in static_protocol. I'm pretty sure something screws up the rta associated to the static route, but I'm also confused as to why the static protocol seems to get reloaded at all given there is no configuration change in the first place. We definitely want to allow local as: since the routes are potentially anycast, it is useful to have an alternate route in case we shut down the static announcement. Thanks, - j

3 7

OSPF socket error on "bge0" invalid argument
by David S. 15 Jan '17

15 Jan '17

Dear All, I have trouble to establish ospf on BIRD 1.6.3 using FreeBSD 11 amd64, here is my topology and BIRD configuration: router-a ------ router-b (directly connected use cat6) router-a: 10.22.40.17/30 router-b: 10.22.40.18/30 bird.conf in router-a router id 10.5.16.1; debug all; import filter ospf_in_routerb; export filter ospf_out_routerb; tick 2; area 0 { interface "bge0" { stub; cost 5; hello 10; retransmit 2; wait 10; dead 40; type pointopoint; }; networks { 103.22.40.16/30; }; interface "*" { cost 1000; stub; }; }; } bird.conf in routerb router id 10.5.16.2; debug all; import filter ospf_in_routera; export filter ospf_out_routera; tick 2; area 0 { interface "bge0" { stub; cost 5; hello 10; retransmit 2; wait 10; dead 40; type pointopoint; }; networks { 103.22.40.16/30; }; interface "*" { cost 1000; stub; }; }; } I found the following error message from bird.log: 2016-12-31 07:52:38 <ERR> ospf1: Socket error on bge0: Invalid argument 2016-12-31 07:52:43 <ERR> ospf1: Socket error on bge0: Invalid argument 2016-12-31 07:52:48 <ERR> ospf1: Socket error on bge0: Invalid argument 2016-12-31 07:52:53 <ERR> ospf1: Socket error on bge0: Invalid argument 2016-12-31 07:52:57 <ERR> ospf1: Socket error on bge0: Invalid argument 2016-12-31 07:53:03 <ERR> ospf1: Socket error on bge0: Invalid argument 2016-12-31 07:53:07 <ERR> ospf1: Socket error on bge0: Invalid argument 2016-12-31 07:53:13 <ERR> ospf1: Socket error on bge0: Invalid argument 2016-12-31 07:53:18 <ERR> ospf1: Socket error on bge0: Invalid argument 2016-12-31 07:53:22 <ERR> ospf1: Socket error on bge0: Invalid argument 2016-12-31 07:53:27 <ERR> ospf1: Socket error on bge0: Invalid argument 2016-12-31 07:53:28 <ERR> ospf1: Socket error on bge0: Invalid argument Show ospf: bird> show ospf ospf1: RFC1583 compatibility: disabled Stub router: No RT scheduler tick: 2 Number of areas: 1 Number of LSAs in DB: 260 Area: 0.0.0.0 (0) [BACKBONE] Stub: No NSSA: No Transit: No Number of interfaces: 25 Number of neighbors: 0 Number of adjacent neighbors: 0 Area networks: 10.22.40.16/30 Advertise bird> show protocols all ospf1 name proto table state since info ospf1 OSPF master up 07:53:28 Alone Router ID: 10.8.60.1 Preference: 150 Input filter: ospf_in_routerb Output filter: ospf_out_routerb Routes: 25 imported, 259 exported, 0 preferred Route change stats: received rejected filtered ignored accepted Import updates: 25 0 0 0 25 Import withdraws: 0 0 --- 0 0 Export updates: 630587 0 630328 --- 259 Export withdraws: 22 --- --- --- 0 Why ospf neighbor can't established? I'm new to ospf and really need help. Thank you Best regards, David S. ------------------------------------------------ e. david(a)zeromail.us w. pnyet.web.id

7 20

old tools
by Alexander Lazarev 02 Jan '17

02 Jan '17

Hello, bird users. Suggestion for developers. Please consider updating tools in your packages. Couldn't rebuild srpm on arm64 CentOS 7 because of old tools/config.guess. Cheers.

3 5

Upgrade to 1.6.3
by Michal 02 Jan '17

02 Jan '17

Hi, I was trying to upgrade my bird instance from v1.6.0 to v1.6.3 today. Unfortunately immediately after start the bird started generating these messages 2016-12-30 12:02:35 <INFO> Started 2016-12-30 12:02:43 <WARN> I/O loop cycle took 8679 ms for 8 events 2016-12-30 12:02:43 <WARN> Kernel dropped some netlink messages, will resync on next scan. 2016-12-30 12:02:43 <WARN> Kernel dropped some netlink messages, will resync on next scan. 2016-12-30 12:02:52 <WARN> Kernel dropped some netlink messages, will resync on next scan. 2016-12-30 12:03:03 <WARN> Kernel dropped some netlink messages, will resync on next scan. 2016-12-30 12:03:10 <WARN> Kernel dropped some netlink messages, will resync on next scan. 2016-12-30 12:03:16 <WARN> Kernel dropped some netlink messages, will resync on next scan It's a full BGP IPv4 instance with just three interfaces. Tested on linux kernels 4.4 or 4.8. Package is from cznic deb repository. I can see the warning log line was added at Dec 20 2016, which ended up in 1.6.3 release. Hence this was happening probably even before the upgrade, but it was not visible. So the question is simple. Does it means there is something terribly wrong with my machine, or the high rate of this warning is expected? Cheers Michal

4 10

Route aggregation
by Paul Donohue 31 Dec '16

31 Dec '16

I see that Alexander V. Chernikov wrote a patch to implement route aggregation back in 2012, and Ondrej Zajicek was planning on merging it with some changes: http://bird.network.cz/pipermail/bird-users/2013-January/003337.html However, it does not look like this was ever actually merged, and the latest version of the patch ("Version 7") seems to be missing from the mailing list archives. Does anyone know where I can find the latest version of this patch? Is there any chance this patch will ever be merged? Thanks! -Paul

1 0

having trouble getting default to be added to route table, says filtered out
by Jerry Scharf 31 Dec '16

31 Dec '16

Hi, I did a quick look at the archives and didn't see exactly what I was trying discussed. I have some border machines running bird connected to junpiers that are bgp peering with our ISPS. I have the junipers set up such that they generate a default route and send it to the border machines. I want the border machines to put it in the system routing table and then pass that on to the inside systems. Everyone is speaking bgp, one AS for the outside and one for the inside. I am running 1.4.5 (centos 7 release) here are the parts of the config that are involved: filter load_default { if net = [0.0.0.0/0] then accept; else reject; } template bgp toedge { description "bgp to edge/ISP as"; local as 65401; direct; export filter outside_only; import filter load_default; allow local as; bfd on; source address 172.18.2.10; } protocol bgp edgeA from toedge { neighbor 172.18.2.1 as 65401; debug all; } protocol bgp edgeB from toedge { neighbor 172.18.2.2 as 65401; } here's the debug output: 2016-12-30 11:28:53 <INFO> Started 2016-12-30 11:28:53 <TRACE> edgeA: Started 2016-12-30 11:28:53 <TRACE> edgeA: Connect delayed by 5 seconds 2016-12-30 11:28:57 <TRACE> edgeA: Connecting to 172.18.2.1 from local address 172.18.2.10 2016-12-30 11:28:57 <TRACE> edgeA: Connected 2016-12-30 11:28:57 <TRACE> edgeA: Sending OPEN(ver=4,as=65401,hold=240,id=01020304) 2016-12-30 11:28:57 <TRACE> edgeA: Got OPEN(as=65401,hold=90,id=ac120001) 2016-12-30 11:28:57 <TRACE> edgeA: Sending KEEPALIVE 2016-12-30 11:28:57 <TRACE> edgeA: Got KEEPALIVE 2016-12-30 11:28:57 <TRACE> edgeA: BGP session established 2016-12-30 11:28:57 <TRACE> edgeA: Connected to table master 2016-12-30 11:28:57 <TRACE> edgeA: State changed to feed 2016-12-30 11:28:57 <TRACE> edgeA < added 198.48.100.20/32 dev lo 2016-12-30 11:28:57 <TRACE> edgeA < added 198.48.100.21/32 dev lo 2016-12-30 11:28:57 <TRACE> edgeA < added 8.25.217.22/32 dev lo 2016-12-30 11:28:57 <TRACE> edgeA: State changed to up 2016-12-30 11:28:57 <TRACE> edgeA: Sending UPDATE 2016-12-30 11:28:57 <TRACE> edgeA: Sending End-of-RIB 2016-12-30 11:28:57 <TRACE> edgeA < filtered out 10.200.32.0/28 via 10.200.0.3 on eth4 2016-12-30 11:28:57 <TRACE> edgeA < filtered out 10.200.0.1/32 via 10.200.0.3 on eth4 2016-12-30 11:28:57 <TRACE> edgeA < filtered out 10.200.16.1/32 via 10.200.0.3 on eth4 2016-12-30 11:28:57 <TRACE> edgeA: Got KEEPALIVE 2016-12-30 11:28:57 <TRACE> edgeA: Got UPDATE 2016-12-30 11:28:57 <TRACE> edgeA: Got End-of-RIB 2016-12-30 11:28:57 <TRACE> edgeA: Got UPDATE 2016-12-30 11:28:57 <TRACE> edgeA > filtered out 0.0.0.0/0 via 172.18.2.1 on eth1 2016-12-30 11:28:58 <TRACE> edgeA < filtered out 10.200.16.1/32 via 10.200.16.3 on eth5 As you can see (second line from the bottom of the debug), it got the default advertisement from the peer and bird says it filtered it out (the other filters are correct.) I set allow-local-as for the peer and have a filter that is supposed to match and accept exactly the route that says was filtered. what am I doing wrong? BTW, I am also having trouble with setting localpref in a filter. here's the config pieces: function is_primary() { return net = [198.48.100.10/32, 198.48.100.20/32]; } function is_secondary() { return net = [8.25.217.10/32, 8.25.217.21/32]; } function is_tertiary() { return net ~ [198.48.100.0/24+, 8.25.217.0/24+]; } filter outside_only { if is_primary() then bgp_local_pref=100; else if is_secondary() then bgp_local_pref=80; else if is_tertiary() then bgp_local_pref=60; if net_outside() then accept; else reject; } They all end up on the junipers with locappref of 60. How do I do this right? thanks in advance, jerry

2 2

OSPF: Route attribute "ospf_tag" lost between different OSPF instances
by markus/grundmann 28 Dec '16

28 Dec '16

Hello! I believe that I'm a user with BIRD experiences but current I have no idea why the attribute "ospf_tag" from one OSPF instance to another is unavailable. In this real life example you can see that I receive a default route from my ISP that is tagged with "7b". This tag is not visible on the VPN client. I use for each VPN network a OSPF instance with some filter rules but only static routes (Core VPN) with a "ospf_tag" are usable to filter like "if ospf_tag = xyz then ..." How can I exchange routes based on a "ospf_tag" between two or more OSPF router instances? [Core VPN Router] BIRD 1.6.0 ready. 0.0.0.0/0 via 82.206.X.33 on lagg0 [titan 2016-12-25] * E2 (150/5/10) [7b] [217.173.X.190] [VPN Client] BIRD 1.6.0 ready. 0.0.0.0/0 via 10.82.16.1 on tun2 [lte 00:28:10] * E1 (150/5) [82.206.X.34] via 10.82.17.1 on tun3 [umts 00:28:11] E1 (150/10) [82.206.X.34] -- Static-Tagging Works Fine --- route 11.0.0.0/8 via 82.206.X.33 { ospf_tag=16170; }; filter openvpn9x16171_export { if net = 0.0.0.0/0 then { ospf_metric1 = SEC_M1_VPN; ospf_metric2 = SEC_M2_VPN; accept; } // [...] if ospf_tag = 16171 then { <== WORKS FINE because static route ospf_metric1 = SEC_M1_VPN; ospf_metric2 = SEC_M2_VPN; accept; } reject; } -- Best regards, Markus

2 6