- Bird-users - Mailing Lists

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

auto-cost reference-bandwidth
by Markus Wigge 13 Jun '17

13 Jun '17

Hello, according to a chat I recently had with Elrond I put my question on the mailing list: Is there an option for the OSPF protocol in bird to calculate the interface cost based on the bandwidth like cisco or quagga or juniper or fortigate or ... do? As far as I remember the definition of the interface cost is as follows: 100.000kbps cost = ----------- <bandwidth> The configurable option "auto-cost reference-bandwidth" then manipulates the "100.000". So when you have 40G or 100G links in your network you set the reference to that on all your routers. Regards, Markus

2 1

Re: Order of BGP communities
by Pavlos Parissis 13 Jun '17

13 Jun '17

On 13/06/2017 01:46 μμ, Ondrej Zajicek wrote: > On Wed, Jun 07, 2017 at 03:49:35PM +0200, Pavlos Parissis wrote: >> Hi, >> >> Today, we noticed a difference in the order that communities were added between 1.6.3 and 1.4.5 version. >> >> Does anyone know why ? > > It is true, one reason is that to have that consistent with extended and > long communities. Another reason is that append is a bit more natural, if > you add several communities and then show it, you end with the same > order. > > Also note that order of communities is not significant and in the future > we perhaps end with sorted community attributes. > Thanks for the clarification. Cheers, Pavlos

1 0

Order of BGP communities
by Pavlos Parissis 13 Jun '17

13 Jun '17

Hi, Today, we noticed a difference in the order that communities were added between 1.6.3 and 1.4.5 version. All exported routes pass through a function, which adds three communities: function match_route_north() { bgp_community.add((64813,lookup_live_id(net.ip))); bgp_community.add(DC_ID); bgp_community.add((64813,lookup_fabric_id(net.ip))); return (net ~ ACAST_PS_ADVERTISE && net ~ ANYCAST_NETWORKS_NORTH && !(net ~ ACAST_PS_DISABLED)); } As you see we add first live_id (which is always 1000) and last the fabric_id(which is always 3). With bird 1.6.3 version we see that live_id community is listed 1st: 1.17.1.143/32 dev lo [direct1 2017-06-07 15:30:29 1496842229] * (240) Type: device unicast univ BGP.origin: IGP BGP.as_path: 61115 BGP.next_hop: 10.1.9.1 BGP.local_pref: 0 BGP.community: (64813,1000) (64815,100) (64813,3) but with 1.4.5 version is listed as last: 1.17.16.143/32 dev lo [direct1 2017-03-10 11:24:36 1489141476] * (240) Type: device unicast univ BGP.origin: IGP BGP.as_path: 6115 BGP.next_hop: 10.1.6.1 BGP.local_pref: 0 BGP.community: (64813,3) (61115,100) (64813,1000) Does anyone know why ? Cheers, Pavlos

2 1