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

[PATCH] protocol aggregation
by Alexander V. Chernikov 03 Apr '17

03 Apr '17

2 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

Is it possible to apply filter on OSPF interfaces within the same area?
by Steve Leung 01 Feb '17

01 Feb '17

Hi, Using OSPF, when receiving some routes from a network interface, by default all routes will be re-advertised to other interfaces within the same area without applying the filter rules. Say in the below example. === protocol ospf myospf { table t_ospf; import filter ifilter; export filter ofilter; area 0 { interface "eth*" { hello 10; retransmit 2; wait 10; dead 300; cost 10; }; }; } === Routes received from "eth1" will be _forwarded_ to "eth2" and bypassed all the filters. Is it possible to configure bird.conf so only some of the routes will be re-advertised? (aka apply filters to interface within the same OSPF area) Creating multiple ospf instance and treat the routes as "external routes" (so filter will apply) is not a good idea for me because the environment is quite dynamic, may even have hundreds of dynamic virtual interface, and I hope I do not need to edit the config file all the time. Thank you so much for your time. Best regards, Steve

3 3

Help with migrate
by André Carlim 29 Jan '17

29 Jan '17

Hi guys! I need to migrate the configuration below to the bird, but a few days trying, but to no avail, can anyone give me a hand? Quagga OSPF Config: router ospf ospf router-id 172.16.11.2 log-adjacency-changes redistribute connected route-map OSPFv4_OUT_BLOCK redistribute static passive-interface default no passive-interface bd0 network 10.11.16.0/24 area 0.0.0.1 network 10.11.17.0/24 area 0.0.0.1 network 10.11.18.0/24 area 0.0.0.1 network 10.11.19.0/24 area 0.0.0.1 network 10.11.20.0/24 area 0.0.0.1 network 10.11.21.0/24 area 0.0.0.1 network 10.11.22.0/24 area 0.0.0.1 network 10.11.23.0/24 area 0.0.0.1 network 10.11.24.0/24 area 0.0.0.1 network 10.11.25.0/24 area 0.0.0.1 network 10.11.26.0/24 area 0.0.0.1 network 10.11.27.0/24 area 0.0.0.1 network 10.11.28.0/24 area 0.0.0.1 network 10.11.29.0/24 area 0.0.0.1 network 10.11.30.0/24 area 0.0.0.1 network 10.11.31.0/24 area 0.0.0.1 network 168.XXX.XX.0/22 area 0.0.0.4 network 170.ZZ.ZZ.128/26 area 0.0.0.2 network 170.ZZ.ZZ.192/26 area 0.0.0.2 network 170.YY.YY.0/29 area 0.0.0.3 network 170.YY.YY.8/29 area 0.0.0.3 network 172.16.11.0/24 area 0.0.0.0 area 0.0.0.1 range 10.11.16.0/20 area 0.0.0.2 range 170.ZZ.ZZ.128/25 area 0.0.0.3 range 170.YY.YY.0/28 ! ip prefix-list BLOCK_PUBLIC seq 10 permit 168.AAA.AA.0/22 le 32 ip prefix-list BLOCK_PUBLIC seq 20 permit 138.AAA.BB.0/22 le 32 ! route-map OSPFv4_OUT_BLOCK permit 10 match ip address prefix-list BLOCK_PUBLIC_WANTEL ! route-map OSPFv4_OUT_BLOCK deny 99 Abraços! Atenciosamente, André Carlim Stub Network Analise e Consultoria de Redes Linux & Windows Server

1 0

FIB aggregation
by Andre Nathan 27 Jan '17

27 Jan '17

Hi I was looking for FIB aggregation support in Bird. I managed to find some academic papers on the subject, for things like FIFA [1] and SMALTA [2], and this thread from 5 year ago: http://bird-users.network.narkive.com/Qusamzzd/route-aggregation-in-bird-how Has there been any development in this area for Bird? Cheers, Andre [1] http://ieeexplore.ieee.org/document/6566913/ [2] https://tools.ietf.org/html/draft-uzmi-smalta-01

1 0

print and bgp_large_community
by Robert Sander 27 Jan '17

27 Jan '17

Hi, I need to print the bgp_large_community for debugging purposes but all I get is the output "(lclist )". Are these list not printable? Regards -- Robert Sander Heinlein Support GmbH Schwedter Str. 8/9b, 10119 Berlin http://www.heinlein-support.de Tel: 030 / 405051-43 Fax: 030 / 405051-19 Zwangsangaben lt. §35a GmbHG: HRB 93818 B / Amtsgericht Berlin-Charlottenburg, Geschäftsführer: Peer Heinlein -- Sitz: Berlin

2 7

OSPF on bridged network
by Dean 26 Jan '17

26 Jan '17

Hello, I'm trying to setup OSPF to run between docker containers, and I have connected three containers to a bridge using veth interfaces. However, each container considers itself to be Designated Router for the network, and doesn't even acknowledge the others (none is in the neighbor list). Below is my configuration: log "/bird/rt3/bird.log" all; router id 3; protocol device { scan time 10; } protocol kernel { export all; scan time 15; } protocol ospf { debug all; import all; area 1 { networks { 2001:db9:4::/64; }; interface "v4" { cost 5; type ptp; hello 5; retransmit 2; wait 10; dead 20; }; interface "vn3" { priority 3; cost 5; type broadcast; hello 5; retransmit 2; wait 10; dead 20; }; }; } The two other containers have the pretty much the same configuration. Only the interface names, priority and router ID is different. Any idea what is going on here? Thank you.

1 1