- Bird-users - Mailing Lists

Re: Next-hop check not needed?
by Vincent Bernat 04 Jul '17

04 Jul '17

❦ 28 juin 2017 14:01 +0200, Ondrej Zajicek <santiago(a)crfreenet.org> : > Note that when learning route from the kernel you could workaround it by > using 'onlink' route flag. Great! It seems to work: $ ip route show table public dev eth2 203.0.113.1 scope link metric 10 203.0.113.10 via 203.0.113.1 metric 10 onlink bird> show route table public 203.0.113.10/32 via 203.0.113.1 on eth2 [kernel_public 15:58:09] * (200) 203.0.113.1/32 dev eth2 [kernel_public 15:58:09] * (200) But BIRD (1.6.3) still seems to be a bit confused, since I got this message in a loop: 2017-06-28 16:01:20 <ERR> KRT: Received route 203.0.113.10/32 with strange next-hop 203.0.113.1 2017-06-28 16:01:20 <WARN> Netlink: File exists Other than that, everything works as expected. I don't know how to interpret the first message (is it receiving two routes?) but the second message seems to say that it tries to reinstall the same route it received. -- 10.0 times 0.1 is hardly ever 1.0. - The Elements of Programming Style (Kernighan & Plauger)

2 5

Bird 1.6.3 strange hangup
by Andrew 04 Jul '17

04 Jul '17

Hi all. Today I saw strange bird hangup, which results in OSPF failure in areas where router is. BIRD works as OSPF + BGP. All returns to work state after bird was killed by SIGKILL and started again. Here's strange logs records: Jul 2 11:33:46 gw2 bird: I/O loop cycle took 7016 ms for 35 events Jul 2 11:33:57 gw2 bird: I/O loop cycle took 7208 ms for 58 events Jul 2 11:34:06 gw2 bird: I/O loop cycle took 5829 ms for 31 events Jul 2 11:34:16 gw2 upsd[8901]: UPS [ups] data is no longer stale Jul 2 11:34:19 gw2 bird: filters, line 47: AS path expected Jul 2 11:34:19 gw2 bird: filters, line 47: AS path expected Jul 2 11:34:19 gw2 bird: filters, line 47: AS path expected Jul 2 11:34:19 gw2 bird: filters, line 47: AS path expected Jul 2 11:34:19 gw2 bird: filters, line 47: AS path expected Jul 2 11:34:19 gw2 bird: ... Jul 2 11:34:25 gw2 bird: filters, line 47: AS path expected Jul 2 11:34:25 gw2 bird: filters, line 47: AS path expected Jul 2 11:34:25 gw2 bird: filters, line 47: AS path expected Jul 2 11:34:25 gw2 bird: filters, line 47: AS path expected Jul 2 11:34:25 gw2 bird: filters, line 47: AS path expected Jul 2 11:34:25 gw2 bird: ... Jul 2 11:34:28 gw2 bird: I/O loop cycle took 9297 ms for 30 events Jul 2 11:34:28 gw2 bird: Kernel dropped some netlink messages, will resync on next scan. Jul 2 11:34:32 gw2 bird: filters, line 47: AS path expected Jul 2 11:34:32 gw2 bird: filters, line 47: AS path expected Jul 2 11:34:32 gw2 bird: filters, line 47: AS path expected Jul 2 11:34:32 gw2 bird: filters, line 47: AS path expected Jul 2 11:34:32 gw2 bird: filters, line 47: AS path expected Jul 2 11:34:32 gw2 bird: ... Jul 2 11:34:33 gw2 bird: Kernel dropped some netlink messages, will resync on next scan. Jul 2 11:34:35 gw2 upsd[8901]: Data for UPS [ups] is stale - check driver Jul 2 11:34:41 gw2 upsd[8901]: UPS [ups] data is no longer stale Jul 2 11:34:52 gw2 bird: bgp_peer_dg_w: Error: Hold timer expired Jul 2 11:34:58 gw2 upsd[8901]: Data for UPS [ups] is stale - check driver Jul 2 11:34:58 gw2 bird: Kernel dropped some netlink messages, will resync on next scan. Jul 2 11:35:08 gw2 upsd[8901]: UPS [ups] data is no longer stale Jul 2 11:35:08 gw2 bird: bgp_peer_dg_ua: Error: Hold timer expired Jul 2 11:35:08 gw2 bird: I/O loop cycle took 9312 ms for 23 events Jul 2 11:35:17 gw2 bird: I/O loop cycle took 8410 ms for 14 events Jul 2 11:35:17 gw2 bird: Next hop address 77.88.200.157 resolvable through recursive route for 77.88.x.x/30 Jul 2 11:35:24 gw2 upsd[8901]: Data for UPS [ups] is stale - check driver Jul 2 11:35:24 gw2 bird: I/O loop cycle took 6134 ms for 12 events Jul 2 11:35:46 gw2 upsd[8901]: UPS [ups] data is no longer stale Jul 2 11:36:03 gw2 bird: bgp_peer_nas2: Error: Hold timer expired Jul 2 11:36:03 gw2 bird: bgp_peer_nas4: Error: Hold timer expired Jul 2 11:36:03 gw2 bird: bgp_peer_nas4_w: Error: Hold timer expired Jul 2 11:36:03 gw2 bird: I/O loop cycle took 37685 ms for 22 events Jul 2 11:36:07 gw2 upsd[8901]: Data for UPS [ups] is stale - check driver Jul 2 11:36:33 gw2 snmpd[8061]: Connection from UDP: [192.168.x.x]:44096->[10.255.x.x]:161 Jul 2 11:36:33 gw2 snmpd[8061]: send response: Failure in sendto (parse header: message overflow: 10 len + 2 delta > 4 len) Jul 2 11:36:33 gw2 snmpd[8061]: -- IF-MIB::ifOutUcastPkts.11 Jul 2 11:36:39 gw2 bird: bgp_peer_g1: Error: Hold timer expired Jul 2 11:36:39 gw2 bird: I/O loop cycle took 34913 ms for 17 events Jul 2 11:36:39 gw2 bird: Next hop address x.x.x.x resolvable through recursive route for x.x.x.x/30 Jul 2 11:36:46 gw2 upsd[8901]: UPS [ups] data is no longer stale Jul 2 11:36:53 gw2 monit[8133]: 'localhost' loadavg(5min) of 7.4 matches resource limit [loadavg(5min)>7.0] Jul 2 11:36:53 gw2 monit[8133]: 'localhost' loadavg(1min) of 15.3 matches resource limit [loadavg(1min)>10.0] Jul 2 11:36:57 gw2 bird: bgp_peer_nas2_w: Error: Hold timer expired Jul 2 11:37:03 gw2 upsd[8901]: Data for UPS [ups] is stale - check driver Jul 2 11:37:02 gw2 bird: bgp_peer_nas1_w: Error: Hold timer expired Jul 2 11:37:02 gw2 bird: bgp_peer_nas3: Error: Hold timer expired Jul 2 11:37:02 gw2 bird: bgp_peer_g1_w: Error: Hold timer expired Jul 2 11:37:02 gw2 bird: I/O loop cycle took 22598 ms for 21 events Jul 2 11:37:15 gw2 bird: I/O loop cycle took 11770 ms for 15 events Jul 2 11:37:52 gw2 bird: bgp_peer_r2_w: Error: Hold timer expired Jul 2 11:37:52 gw2 bird: bgp_peer_r2: Error: Hold timer expired Jul 2 11:37:52 gw2 bird: I/O loop cycle took 35283 ms for 16 events Jul 2 11:37:56 gw2 monit[8133]: 'localhost' loadavg(5min) of 8.8 matches resource limit [loadavg(5min)>7.0] Jul 2 11:37:56 gw2 monit[8133]: 'localhost' loadavg(1min) of 15.2 matches resource limit [loadavg(1min)>10.0] Jul 2 11:38:19 gw2 bird: I/O loop cycle took 24751 ms for 22 events Jul 2 11:38:32 gw2 upsd[8901]: UPS [ups] data is no longer stale Jul 2 11:38:43 gw2 bird: I/O loop cycle took 23370 ms for 11 events Jul 2 11:38:48 gw2 upsd[8901]: Data for UPS [ups] is stale - check driver Jul 2 11:38:54 gw2 bird: I/O loop cycle took 10864 ms for 11 events Jul 2 11:38:56 gw2 monit[8133]: 'localhost' loadavg(5min) of 9.8 matches resource limit [loadavg(5min)>7.0] Jul 2 11:38:56 gw2 monit[8133]: 'localhost' loadavg(1min) of 14.3 matches resource limit [loadavg(1min)>10.0] ... Jul 2 11:39:56 gw2 monit[8133]: 'localhost' cpu system usage of 85.2% matches resource limit [cpu system usage>60.0%] Jul 2 11:39:56 gw2 monit[8133]: 'localhost' loadavg(5min) of 10.0 matches resource limit [loadavg(5min)>7.0] Jul 2 11:39:56 gw2 monit[8133]: 'localhost' loadavg(1min) of 12.0 matches resource limit [loadavg(1min)>10.0] Jul 2 11:39:57 gw2 snmpd[8061]: Connection from UDP: [192.168.x.x]:59167->[10.255.x.x]:161 Jul 2 11:39:57 gw2 snmpd[8061]: send response: Failure in sendto Jul 2 11:39:57 gw2 snmpd[8061]: -- IF-MIB::ifOutUcastPkts.10 Jul 2 11:39:58 gw2 bird: I/O loop cycle took 13685 ms for 15 events Jul 2 11:40:01 gw2 snmpd[8061]: Connection from UDP: [192.168.x.x]:59167->[10.255.x.x]:161 Jul 2 11:40:01 gw2 snmpd[8061]: send response: Failure in sendto Jul 2 11:40:01 gw2 snmpd[8061]: -- IF-MIB::ifOutUcastPkts.10 Jul 2 11:40:56 gw2 monit[8133]: 'localhost' cpu system usage check succeeded [current cpu system usage=30.7%] Jul 2 11:40:56 gw2 monit[8133]: 'localhost' loadavg(5min) of 8.6 matches resource limit [loadavg(5min)>7.0] Jul 2 11:40:56 gw2 monit[8133]: 'localhost' loadavg(1min) check succeeded [current loadavg(1min)=5.9] Jul 2 11:41:06 gw2 snmpd[8061]: Connection from UDP: [192.168.x.x]:42144->[10.255.x.x]:161 Jul 2 11:41:06 gw2 snmpd[8061]: send response: Failure in sendto Jul 2 11:41:06 gw2 snmpd[8061]: -- LM-SENSORS-MIB::lmSensors Jul 2 11:41:11 gw2 snmpd[8061]: Connection from UDP: [192.168.x.x]:42144->[10.255.x.x]:161 Jul 2 11:41:11 gw2 snmpd[8061]: send response: Failure in sendto Jul 2 11:41:11 gw2 snmpd[8061]: -- LM-SENSORS-MIB::lmSensors Jul 2 11:41:35 gw2 bird: Kernel dropped some netlink messages, will resync on next scan. Jul 2 11:41:36 gw2 bird: filters, line 47: AS path expected Jul 2 11:41:36 gw2 bird: filters, line 47: AS path expected Jul 2 11:41:36 gw2 bird: filters, line 47: AS path expected Jul 2 11:41:36 gw2 bird: filters, line 47: AS path expected Jul 2 11:41:36 gw2 bird: filters, line 47: AS path expected Jul 2 11:41:36 gw2 bird: ... Jul 2 11:41:43 gw2 bird: bgp_peer_nas1: Invalid NEXT_HOP attribute in route yy.yy.yy.yy/30 Jul 2 11:41:43 gw2 bird: I/O loop cycle took 6922 ms for 41 events Jul 2 11:41:43 gw2 bird: Kernel dropped some netlink messages, will resync on next scan. Jul 2 11:41:49 gw2 bird: filters, line 47: AS path expected Jul 2 11:41:49 gw2 bird: filters, line 47: AS path expected Jul 2 11:41:49 gw2 bird: filters, line 47: AS path expected Jul 2 11:41:49 gw2 bird: filters, line 47: AS path expected Jul 2 11:41:49 gw2 bird: filters, line 47: AS path expected Jul 2 11:41:49 gw2 bird: ... There's filter config where error message happens: function rt_client(int asn; prefix set nets) { return (net ~ nets && (bgp_path.first = asn || bgp_path ~ [= my_as asn * =]) && bgp_path.last = asn); } How it used: function net_clients() { return rt_client(xxxxx, [91.yyy.yyy.0/24]); } After restart - all seems to be OK, except periodical messages 'Kernel dropped some netlink messages, will resync on next scan.' in log. What was happened? Bad BGP packets? Or some bug in bird?

2 2

Re: Identifying BGP convergence bottleneck
by Patrick.deNiet＠os3.nl 28 Jun '17

28 Jun '17

Thanks for your info Ondrej, it's much appreciated! I've done both unique, overlapping and identical prefixes on these peers. The unique one costs the routeserver more memory than I had unfortunately. I'll let you know if I have anything to share. Regards, Patrick > On Thu, Jun 22, 2017 at 10:26:03AM +0200, Patrick.deNiet(a)os3.nl wrote: >> Hi everyone! >> >> I am currently looking into the performance of BIRD (bgp) as a >> route-server with ~700 peers with 10k prefixes each. I'm noticing an >> increase in convergence time as I increase these numbers (which is not a >> surprise). >> >> Unfortunately, I do not have a deep enough understanding of the code and >> have not managed to identify these points. Is anyone here able to give >> some pointers as to where in the code we could place these markings to >> measure this? > > Hi > > It is hard to tell, esp. it depends on your setting and configuration and > would need some benchmarking. It is single-table or multi-table route > server [1][2]? Personally i would guess that it is in TX, because you > receive a route and then send it about ~700 times (but that depends on > whether prefixes from different peers are shared or unique). You could > benchmark it with 'export none' to see the difference. > > Also note that hash table used for routing table has max size of 64k > buckets. You could try attached patches to fix that. That may help > significantly. > > I would be interested in your performance results. > > [1] > https://gitlab.labs.nic.cz/labs/bird/wikis/Route_server_with_community_base… > [2] > https://gitlab.labs.nic.cz/labs/bird/wikis/Route_server_with_community_base… > > -- > 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." >

1 0

Identifying BGP convergence bottleneck
by Patrick.deNiet＠os3.nl 28 Jun '17

28 Jun '17

Hi everyone! I am currently looking into the performance of BIRD (bgp) as a route-server with ~700 peers with 10k prefixes each. I'm noticing an increase in convergence time as I increase these numbers (which is not a surprise). Currently, I am forcing these convergence times by flapping the link which causes all peers to start sending updates at the same time. My particular interest here is to find out what action specifically is causing this convergence time. With convergence time I mean the time it takes for the bird to process all updates and drop down from 100% cpu to a more "idle" level. In order to identify what is causing this, I'm looking to mark the start and end of each phase as described in RFC4271 9.1. Decision Process. This way I may be able to get an idea of where the cpu time in spent during all this (best path calc, sending out updates, etc..). Unfortunately, I do not have a deep enough understanding of the code and have not managed to identify these points. Is anyone here able to give some pointers as to where in the code we could place these markings to measure this? Other comments and insights are also welcome. Kind regards, Patrick

2 1

Next-hop check not needed?
by Vincent Bernat 28 Jun '17

28 Jun '17

Hey in netlink.c, there is this piece of code: #v+ if (a[RTA_GATEWAY]) { neighbor *ng; ra->dest = RTD_ROUTER; memcpy(&ra->gw, RTA_DATA(a[RTA_GATEWAY]), sizeof(ra->gw)); ipa_ntoh(ra->gw); #ifdef IPV6 /* Silently skip strange 6to4 routes */ if (ipa_in_net(ra->gw, IPA_NONE, 96)) return; #endif ng = neigh_find2(&p->p, &ra->gw, ra->iface, (i->rtm_flags & RTNH_F_ONLINK) ? NEF_ONLINK : 0); if (!ng || (ng->scope == SCOPE_HOST)) { log(L_ERR "KRT: Received route %I/%d with strange next-hop %I", net->n.prefix, net->n.pxlen, ra->gw); return; } } #v- In turns, it calls neigh_find2() which delegates the decision to if_connected(). if_connected() will return an error if it thinks that the gateway is not part of the prefix of one of the configured IP addresses. This means that if I have the following setup: ip route add 203.0.113.4/32 dev vnet2 ip route add 203.0.113.15/32 via 203.0.113.4 dev vnet2 BIRD will complain about "strange next-hop" while the setup is perfectly valid. I don't need an IP address on an interface to route traffic on it. I would think the check should just be removed. If the kernel says this is a valid gateway, it likely is. However, I can't find the reason the check was added. In the past, this was just a warning: #v+ + ng = neigh_find(&p->p, &ra.gw, 0); + if (ng) + ra.iface = ng->iface; + else + /* FIXME: Remove this warning? */ + log(L_WARN "Kernel told us to use non-neighbor %I for %I/%d", ra.gw, net->n.prefix, net->n.pxlen); #v- (commit aa64578641c15b137172acc927d9d7af5914576b) But this was made an error in commit 9d4d38d1a5d67f5485d2b2fa439c879583dfdcb0. #v+ - ng = neigh_find(&p->p, &ra.gw, 0); + ng = neigh_find2(&p->p, &ra.gw, ifa, 0); if (ng && ng->scope) + { + if (ng->iface != ifa) + log(L_WARN "KRT: Route with unexpected iface for %I/%d", net->n.prefix, net->n.pxlen); ra.iface = ng->iface; + } else - /* FIXME: Remove this warning? Handle it somehow... */ + { log(L_WARN "Kernel told us to use non-neighbor %I for %I/%d", ra.gw, net->n.prefix, net->n.pxlen); + return; + } #v- Commit message says "Fixes some problems related to link-local routes in KRT interface". Does this ring any bell? -- Avoid temporary variables. - The Elements of Programming Style (Kernighan & Plauger)

2 1

Structured output
by Darren O'Connor 26 Jun '17

26 Jun '17

Hi all. I currently use the unix socket to communicate with bird. the issue is that the data I get back is unstructured text. I have quite a bit of code parsing all that data into usable structs. Would it not be possible to add the ability to request structured data back? i.e. receive a response with the data encoded in json, protobuf, or even xml. Thanks Darren

5 5

Re: [PATCH v2] babel: Add support for dual-stack v4/v6 operation
by Toke Høiland-Jørgensen 20 Jun '17

20 Jun '17

Ondrej Zajicek <santiago(a)crfreenet.org> writes: > On Tue, May 30, 2017 at 03:20:42PM +0200, Toke Høiland-Jørgensen wrote: >> This adds support for dual-stack v4/v6 operation to the Babel protocol. Routing >> messages will be exchanged over IPv6, but IPv4 routes can be carried in the >> messages being exchanged. This matches how the reference Babel >> implementation (babeld) works. > > Hi > > Merged. I did some minor modifications. First, adding 'active' > next_hop fields to struct babel_iface, so value in babel_iface_config > is kept unmodified. Second, adding next_hop fields instead of just > next_hop_seen fields to struct babel_write_state, so it is ready for > third-party next hops. Right, fair enough. Your changes look good to me. > BTW, are third-party next hops allowed in Babel? I checked RFC 6126 > but found nothing. Hmm, third-party next hops as in a next hop that is on a different node than the one running the routing protocol? There's no explicit support for it, but I guess you could do that (i.e., there's nothing that explicitly forbids it either). Not sure how babeld will react to non-LL next hop addresses... > Also note that the new next hop options are missing its documentation. > Perhaps you could send following patch with that? Ah yes, sorry about that. Was going to add that in v2, but guess I must have forgotten. Will send a separate patch that updates the documentation :) -Toke

3 2

[PATCH] Don't clamp extended community values to 0..0xffff for EC_GENERICs.
by Lennert Buytenhek 19 Jun '17

19 Jun '17

The bird extended community construct (kind, key, value) is mapped to a 64 bit extended community value in one of three possible ways. kind = rt/ro/numeric, key <= 0xffff ("RFC 4360 3.1. Two-Octet AS Specific Extended Community"): +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | kind | key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ kind = rt/ro/numeric, key >= 0x10000 ("RFC 5668 4-Octet AS Specific BGP Extended Community"): +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | kind | key (upper half) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | key (lower half) | value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ kind = generic: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ filter/config.Y:f_new_ec_item() currently clamps the value part to 0..0xffff whenever key >= 0x10000, which makes sense if key and value together need to fit into 48 bits, but this is not the case for generic extended communities, and performing the clamping for generic extended communities is incorrect. diff --git a/filter/config.Y b/filter/config.Y index 56ef598..370159a 100644 --- a/filter/config.Y +++ b/filter/config.Y @@ -112,7 +112,7 @@ f_new_ec_item(u32 kind, u32 ipv4_used, u32 key, u32 vf, u32 vt) { u64 fm, to; - if (ipv4_used || (key >= 0x10000)) { + if (ipv4_used || (kind != EC_GENERIC && key >= 0x10000)) { check_u16(vf); if (vt == EC_ALL) vt = 0xFFFF;

2 1

[PATCH] Babel: Fix pointer arithmetic in subtlv parsing
by Toke Høiland-Jørgensen 15 Jun '17

15 Jun '17

The subtlv parsing code was doing byte-based arithmetic with non-void pointers, causing it to read beyond the end of the packet. Signed-off-by: Toke Høiland-Jørgensen <toke(a)toke.dk> --- proto/babel/packets.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proto/babel/packets.c b/proto/babel/packets.c index 1088fab7..269f04ef 100644 --- a/proto/babel/packets.c +++ b/proto/babel/packets.c @@ -951,7 +951,7 @@ babel_read_subtlvs(struct babel_tlv *hdr, struct babel_tlv *tlv; for (tlv = (void *) hdr + state->current_tlv_endpos; - tlv < hdr + TLV_LENGTH(hdr); + (void *) tlv < (void *) hdr + TLV_LENGTH(hdr); tlv = NEXT_TLV(tlv)) { /* -- 2.13.1

3 3

roa_check not re-evaluating after roa table update
by Stefan Plug 13 Jun '17

13 Jun '17

Hi guys, Bird 1.6.3 Just testing about with the RPKI roa_check and it seems that my routes are not being re-evaluated after a "configure" when my roa table is updated. I do this check during the import phase so the routes are already in the table once I update the roa table. simple check example: roa table roa_table { roa 200.0.0.0/24 max 24 as 1340; } if (roa_check( roa_table, net, bgp_path.last)) = ROA_INVALID then { if hardFilterRPKI > 0 then { return false; } else { return true; } } Now I update the config to: roa table roa_table { roa 200.0.0.0/24 max 24 as 1340; roa 200.0.0.0/24 max 24 as 1339; } When I now reconfigure BIRD this makes no changes at all. If I restart BIRD and thus the routes get re-sent then they do both get through the check as expected. when adding/deleting roa entries using the command line I see the same behaviour. Do note when I change the "hardFilterRPKI" which decides to actually filter or not, then the routes DO get re-evaluated like they should. Can anyone else also confirm this behaviour? Am I doing something wrong? Stefan

3 4