- Bird-users - Mailing Lists

Version 1.6.0
by Ondrej Filip 31 May '16

31 May '16

Dear Bird users, the long expected version is out: Version 1.6.0 (2016-04-29) o Major RIP protocol redesign o New Babel routing protocol o BGP multipath support o KRT: Add support for plenty of kernel route metrics o KRT: Allow more than 256 routing tables o Static: Allow to specify attributes for static routes o Static: Support for BFD controlled static routes o FreeBSD: Setup password for BGP MD5 authentication o IO: Remove socket number limit o Plenty of bug fixes Upgrade notes: For RIP, most protocol options were moved to interface blocks. Enjoy! Ondrej

17 53

Bird very slow and not importing all routes
by noc＠dolphin-it.de 30 May '16

30 May '16

Hi, I set up bird and bird6 to replace my quagga-setup. I get full-tables for IPv4 and IPv6 but bird fails to import most of them. Example: Quagga needs a maximum of 10 seconds to import 500k routes into main table where bird needs 20 minutes to reach this state: bgp_peer1 BGP master up 19:07:10 Established Preference: 100 Input filter: ACCEPT Output filter: (unnamed) Routes: 226754 imported, 1 exported, 226754 preferred Route change stats: received rejected filtered ignored accepted Import updates: 226754 0 0 0 226754 Import withdraws: 0 0 --- 0 0 Export updates: 226755 226754 0 --- 1 Export withdraws: 0 --- --- --- 0 BGP state: Established Neighbor address: X Neighbor AS: X Neighbor ID: X Neighbor caps: refresh restart-aware AS4 Session: external AS4 Source address: X Hold timer: 72/90 Keepalive timer: 10/30 My config (AS and Net anonymized): # Set local AS define myas=13456; protocol device { scan time 10; } protocol kernel { import all; export all; persist; scan time 15; } protocol static static_bgp { import all; # My net - Set prefixes to be announced (anonymized) route 1.1.1.0/24 reject; } protocol bgp bgp_peer1 { import all; export where proto = "static_bgp"; interpret communities no; missing lladdr ignore; local as myas; neighbor 8.8.8.8 as 1234; password "xxxxxxxxxxxx"; } ------------------ I don't see what is going wrong. Also I don't get why routes are re-exported to bgp_peer1 while "static_bgp" only lists one network. Any ideas? Thanks, Kevin

1 0

Re: Help on customizing BIRD- getting community value
by Martin Mares 26 May '16

26 May '16

Hello! > I am a PhD student at Roma Tre University of Rome, Italy and I am > working on implementation of route server at IXP with BIRD. I want > to have access to community values inside BIRD which are sent by > ASes. Based on received community values I want to customize BIRD > code. > > I found that inside attrs.c file I should decode the data to get > community value, but I do not know how. With sniffing incoming > packets I can see the community values, but not inside BIRD. > > I was wondering may I ask you to help about this. I do not maintain BIRD any longer, but I am forwarding your mail to the bird-users mailing list. Have a nice fortnight -- Martin `MJ' Mares <mj(a)ucw.cz> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Quote of the day: '

1 0

multiple kernel routing tables
by Angel 24 May '16

24 May '16

Hello, In BSDRP how could we activate and work with multiple kernel tables? Regards, Angel.

1 0

reject debug messages
by Angel 23 May '16

23 May '16

Hello, We are configuring a new bird router, and after configure a carrier, we can see following messages on debug every minute: ------------ >>> AS174transit > added [best] 193.148.120.0/24 via 149.6.130.137 on ix0 >>> AS174transit < rejected by protocol 193.148.120.0/24 via 149.6.130.137 on ix0 >>> AS174transit > added [best] 193.148.126.0/24 via 149.6.130.137 on ix0 >>> AS174transit < rejected by protocol 193.148.126.0/24 via 149.6.130.137 on ix0 >>> AS174transit > added [best] 193.148.125.0/24 via 149.6.130.137 on ix0 >>> AS174transit < rejected by protocol 193.148.125.0/24 via 149.6.130.137 on ix0 >>> AS174transit > added [best] 193.148.121.0/24 via 149.6.130.137 on ix0 >>> AS174transit < rejected by protocol 193.148.121.0/24 via 149.6.130.137 on ix0 >>> AS174transit > added [best] 81.17.142.0/24 via 149.6.130.137 on ix0 >>> AS174transit < rejected by protocol 81.17.142.0/24 via 149.6.130.137 on ix0 >>> AS174transit > added [best] 91.198.226.0/24 via 149.6.130.137 on ix0 >>> AS174transit < rejected by protocol 91.198.226.0/24 via 149.6.130.137 on ix0 >>> AS174transit > added [best] 85.140.116.0/22 via 149.6.130.137 on ix0 >>> AS174transit < rejected by protocol 85.140.116.0/22 via 149.6.130.137 on ix0 >>> AS174transit > added [best] 195.128.159.0/24 via 149.6.130.137 on ix0 >>> AS174transit < rejected by protocol 195.128.159.0/24 via 149.6.130.137 on ix0 >>> AS174transit > added [best] 46.225.128.0/19 via 149.6.130.137 on ix0 >>> AS174transit < rejected by protocol 46.225.128.0/19 via 149.6.130.137 on ix0 >>> AS174transit > added [best] 46.225.96.0/19 via 149.6.130.137 on ix0 >>> AS174transit < rejected by protocol 46.225.96.0/19 via 149.6.130.137 on ix0 >>> AS174transit > added [best] 46.224.7.0/24 via 149.6.130.137 on ix0 >>> AS174transit < rejected by protocol 46.224.7.0/24 via 149.6.130.137 on ix0 >>> AS174transit > added [best] 46.225.224.0/19 via 149.6.130.137 on ix0 >>> AS174transit < rejected by protocol 46.225.224.0/19 via 149.6.130.137 on ix0 >>> AS174transit > added [best] 46.225.0.0/19 via 149.6.130.137 on ix0 >>> AS174transit < rejected by protocol 46.225.0.0/19 via 149.6.130.137 on ix0 >>> AS174transit > added [best] 46.224.96.0/19 via 149.6.130.137 on ix0 >>> AS174transit < rejected by protocol 46.224.96.0/19 via 149.6.130.137 on ix0 >>> AS174transit > added [best] 46.225.32.0/19 via 149.6.130.137 on ix0 >>> AS174transit < rejected by protocol 46.225.32.0/19 via 149.6.130.137 on ix0 >>> AS174transit > added [best] 46.224.128.0/19 via 149.6.130.137 on ix0 >>> AS174transit < rejected by protocol 46.224.128.0/19 via 149.6.130.137 on ix0 >>> AS174transit > ignored 109.72.148.0/22 via 149.6.130.137 on ix0 >>> AS174transit > ignored 109.72.147.0/24 via 149.6.130.137 on ix0 >>> AS174transit > ignored 109.72.146.0/24 via 149.6.130.137 on ix0 >>> AS174transit > ignored 109.72.145.0/24 via 149.6.130.137 on ix0 >>> AS174transit > ignored 109.72.144.0/24 via 149.6.130.137 on ix0 >>> AS174transit > ignored 37.46.114.0/24 via 149.6.130.137 on ix0 >>> AS174transit > ignored 109.248.240.0/22 via 149.6.130.137 on ix0 >>> AS174transit > ignored 109.248.242.0/24 via 149.6.130.137 on ix0 >>> AS174transit > ignored 109.248.241.0/24 via 149.6.130.137 on ix0 >>> AS174transit > ignored 109.248.240.0/24 via 149.6.130.137 on ix0 >>> AS174transit > ignored 109.248.225.0/24 via 149.6.130.137 on ix0 >>> AS174transit > ignored 109.248.224.0/24 via 149.6.130.137 on ix0 ------------ We understand that added messages is because carrier sent us new routes, ignored looks like that we know this route, so we do not need to add to our table, but what about rejected messages? How could we fix it? What could be our misconfiguration? Regards,

2 3

Lots of Loglines "Pipe loop detected when sending ..." with 1.6
by Robert Wein 19 May '16

19 May '16

Hello bird community, I upgraded on of our VIX Routeservers from 1.5 to 1.6 recently. When running 1.6 I receive a lot of loglines: ------- May 19 07:33:10 rs1 bird: Pipe loop detected when sending x.y.z.a/b to table Tcxd root@rs1:/var/log# grep "Pipe loop detected" daemon.log | wc -l 1914110 root@rs1:/var/log# ------- (log rotated on a daily base) I guess there exists a kind of race condition when accessing the table for updating. Running 1.5 I didn't find a single line like those. Config remained the same +/- different prefix-lists, install base is Debian 8.4, .debs from bird.network.cz/debian/ any hints? Thank you best regards Robert -- www.vix.at | www.aco.net robert.wein(a)univie.ac.at | RW2586-RIPE Vienna University Computer Center Tel: +43 1 4277-14046 | Fax: -14338

1 0

Babel in Bird
by Ondrej Zajicek 12 May '16

12 May '16

Hi During testing of Babel we noticed a strange behavior and we are not sure if it is a problem in the implementation or in the specification. The sequence of events is like: 1) Router A is running, originated some routes with seqno old_seqno and propagated them to a router B. 2) If router A (or Babel protocol) is restarted, the seqno counter used for originating routes is also reset to 1. 3) Then routes are originated with seqno 1 and propagated to router B. 4) Router B already has these routes with old high seqno, so the update is considered unfeasible and for selected entries, so it is ignored (3.5.4). 5) The routes in the router B's table slowly expire. 6) When routes expire, router B sends seqno request (3.8.2.1) with old_seqno+1. 7) Router A receives seqno request, increases seqno to 2 (3.8.1.2), originates routes with seqno 2 and sends them to router B. 8) Router B still ignores them as 2 < old_seqno. 9) Subsequent updates are still ignored as router B holds old timeouted entry as a selected entry with unreachable metric (as there is no other one) until GC time. I have two questions w.r.t. this sequence of events: 1) How is router restart and seqnos supposed to be handled without waiting for route timeout? 2) If a route is selected, then becomes unreachable/retracted, and there is no other route to be selected, is it still considered selected? I would say that no as the selection process (3.6) forbids retracted routes to be selected, but the BIRD implementation keeps the old selected route (now unreachable) in this case. -- 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 11

Another update to the BGPsec BIRD implementation
by Michael Baer 10 May '16

10 May '16

Hi all, I wanted to announce an updated versions of the BGPsec supporting code using BIRD. The new BGPsec code is version 0.7 and is based on BIRD 1.5.0. It is available as a source tarballs at a new domain: https://securerouting.net/bird The main changes from the last release is that it has been updated to match the most recent BGPsec specification, draft-ietf-sidr-bgpsec-protocol-15, and it has been updated to version 1.5.0 of the BIRD code. 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

[PATCH] netlink: update struct msghdr
by Stijn Tintel 10 May '16

10 May '16

The netlink code assumes an order for the members of struct msghdr. This breaks recvmsg and sendmsg with musl libc on mips64. Fix this by using designated initializers instead. Signed-off-by: Stijn Tintel <stijn(a)linux-ipv6.be> --- sysdep/linux/netlink.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/sysdep/linux/netlink.c b/sysdep/linux/netlink.c index 1ffdff0..b42e7b6 100644 --- a/sysdep/linux/netlink.c +++ b/sysdep/linux/netlink.c @@ -125,7 +125,12 @@ nl_get_reply(struct nl_sock *nl) { struct iovec iov = { nl->rx_buffer, NL_RX_SIZE }; struct sockaddr_nl sa; - struct msghdr m = { (struct sockaddr *) &sa, sizeof(sa), &iov, 1, NULL, 0, 0 }; + struct msghdr m = { + .msg_name = &sa, + .msg_namelen = sizeof(sa), + .msg_iov = &iov, + .msg_iovlen = 1, + }; int x = recvmsg(nl->fd, &m, 0); if (x < 0) die("nl_get_reply: %m"); @@ -1231,7 +1236,12 @@ nl_async_hook(sock *sk, int size UNUSED) { struct iovec iov = { nl_async_rx_buffer, NL_RX_SIZE }; struct sockaddr_nl sa; - struct msghdr m = { (struct sockaddr *) &sa, sizeof(sa), &iov, 1, NULL, 0, 0 }; + struct msghdr m = { + .msg_name = &sa, + .msg_namelen = sizeof(sa), + .msg_iov = &iov, + .msg_iovlen = 1, + }; struct nlmsghdr *h; int x; uint len; -- 2.7.3

2 1

Displaying all route attributes
by Baptiste Jonglez 03 May '16

03 May '16

Hi, Is it possible to display all attributes attached to a route? "show route all" displays only a subset of the attributes, and the names are different (e.g. "BGP.as_path" in "show route all" corresponds to the bgp_path attribute). Thanks, Baptiste

2 1