May 2016 - Bird-users - Mailing Lists

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

systemd unit and ospf script
by Rohrmann Sascha 03 May '16

03 May '16

Hi, I recently noticed, that there isn't a systemd unit for bird. That's why I want to share mine. You could add them into the bird package @ondrej Further information: you need to put this into /etc/systemd/system Furthermore I wrote a script in perl which basicly activates or disables the originating of the default-route into the ospf area relating to incoming BGP routes. The needed perl module is from this page: https://github.com/stephank/nagios-bird You need to download birdctl.pm and put it in the same folder as the script. Next you need to adjust the ENV variable to your folder. As a little extra I created a systemd unit for my script. You need to adjust the path here, too. Greetings, Sascha.

1 0

[PATCH 4/7] Babel: Documentation updates.
by Toke Høiland-Jørgensen 03 May '16

03 May '16

This updates the documentation to correctly mention Babel when protocols are listed, and adds examples and route attribute documentation to the Babel section of the docs. Signed-off-by: Toke Høiland-Jørgensen <toke(a)toke.dk> --- doc/bird.sgml | 33 ++++++++++++++++++++++++++++++--- nest/config.Y | 2 +- nest/rt-attr.c | 2 +- 3 files changed, 32 insertions(+), 5 deletions(-) diff --git a/doc/bird.sgml b/doc/bird.sgml index a0b45f4..71fcb1c 100644 --- a/doc/bird.sgml +++ b/doc/bird.sgml @@ -610,8 +610,8 @@ agreement"). options, in that case for given interface the first matching interface option is used. - This option is allowed in BFD, Direct, OSPF, RAdv and RIP protocols, but - in OSPF protocol it is used in the <cf/area/ subsection. + This option is allowed in Babel, BFD, Direct, OSPF, RAdv and RIP + protocols, but in OSPF protocol it is used in the <cf/area/ subsection. Default: none. @@ -1312,7 +1312,7 @@ clist for most purposes. <cf/RTS_DUMMY/, <cf/RTS_STATIC/, <cf/RTS_INHERIT/, <cf/RTS_DEVICE/, <cf/RTS_STATIC_DEVICE/, <cf/RTS_REDIRECT/, <cf/RTS_RIP/, <cf/RTS_OSPF/, <cf/RTS_OSPF_IA/, <cf/RTS_OSPF_EXT1/, <cf/RTS_OSPF_EXT2/, <cf/RTS_BGP/, - <cf/RTS_PIPE/. + <cf/RTS_PIPE/, <cf/RTS_BABEL/. <tag><m/enum/ cast</tag> Route type (Currently <cf/RTC_UNICAST/ for normal routes, @@ -1475,6 +1475,33 @@ protocol babel [<name>] { yes. </descrip> +<sect1>Attributes + +<p>Babel defines just one attribute: the internal babel metric of the route. It +is exposed as the <cf/babel_metric/ attribute and has range from 1 to infinity +(65535). + +<sect1>Example + +<p><code> +protocol babel { + interface "eth*" { + type wired; + }; + interface "wlan0", "wlan1" { + type wireless; + hello interval 1; + rxcost 512; + }; + interface "tap0"; + + # This matches the default of babeld: redistribute all addresses + # configured on local interfaces, plus re-distribute all routes received + # from other babel peers. + export where (source = RTS_DEVICE) || (source = RTS_BABEL); +} +</code> + <sect><label id="sect-bfd">BFD diff --git a/nest/config.Y b/nest/config.Y index 4566971..ca70564 100644 --- a/nest/config.Y +++ b/nest/config.Y @@ -63,7 +63,7 @@ CF_KEYWORDS(RELOAD, IN, OUT, MRTDUMP, MESSAGES, RESTRICT, MEMORY, IGP_METRIC, CL CF_KEYWORDS(GRACEFUL, RESTART, WAIT, MAX, FLUSH, AS) CF_ENUM(T_ENUM_RTS, RTS_, DUMMY, STATIC, INHERIT, DEVICE, STATIC_DEVICE, REDIRECT, - RIP, OSPF, OSPF_IA, OSPF_EXT1, OSPF_EXT2, BGP, PIPE) + RIP, OSPF, OSPF_IA, OSPF_EXT1, OSPF_EXT2, BGP, PIPE, BABEL) CF_ENUM(T_ENUM_SCOPE, SCOPE_, HOST, LINK, SITE, ORGANIZATION, UNIVERSE, UNDEFINED) CF_ENUM(T_ENUM_RTC, RTC_, UNICAST, BROADCAST, MULTICAST, ANYCAST) CF_ENUM(T_ENUM_RTD, RTD_, ROUTER, DEVICE, BLACKHOLE, UNREACHABLE, PROHIBIT, MULTIPATH) diff --git a/nest/rt-attr.c b/nest/rt-attr.c index 7fa05d6..b57bcd5 100644 --- a/nest/rt-attr.c +++ b/nest/rt-attr.c @@ -1160,7 +1160,7 @@ rta_dump(rta *a) static char *rts[] = { "RTS_DUMMY", "RTS_STATIC", "RTS_INHERIT", "RTS_DEVICE", "RTS_STAT_DEV", "RTS_REDIR", "RTS_RIP", "RTS_OSPF", "RTS_OSPF_IA", "RTS_OSPF_EXT1", - "RTS_OSPF_EXT2", "RTS_BGP" }; + "RTS_OSPF_EXT2", "RTS_BGP", "RTS_PIPE", "RTS_BABEL" }; static char *rtc[] = { "", " BC", " MC", " AC" }; static char *rtd[] = { "", " DEV", " HOLE", " UNREACH", " PROHIBIT" }; -- 2.8.0

2 3

Unable to access https://gitlab.labs.nic.cz
by David S. 03 May '16

03 May '16

Hi All, I'm from Indonesia, I'm unable to access https://gitlab.labs.nic.cz, I have tried to access the url from 3 different network provider and I get same result. Here is the telnet test result: $ telnet gitlab.labs.nic.cz 443 Trying 217.31.192.88... telnet: connect to address 217.31.192.88: Operation timed out Trying 2001:1488:ac15:ff70::88... telnet: connect to address 2001:1488:ac15:ff70::88: No route to host telnet: Unable to connect to remote host Does anyone have information about this? Thank you Best regards, David S. ------------------------------------------------ e. david(a)zeromail.us w. pnyet.web.id p. 087881216110

3 3