June 2017 - Bird-users - Mailing Lists

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

[PATCH 0/3] babel: Add compression and support for subtlvs
by Toke Høiland-Jørgensen 09 Jun '17

09 Jun '17

This patch series adds compression of outgoing IPv6 prefixes to the Babel protocol, and also adds support to the parser for parsing subtlvs as per RFC6126 bis (see https://tools.ietf.org/html/draft-ietf-babel-rfc6126bis-02#section-4.4) These patches apply to 2.0.0-pre1, and on top of the previously posted patch that adds dualstack support to Babel. I'll roll that up into this series as well once the patches have been reviewed. Toke Høiland-Jørgensen (3): lib: Add ip6_common_octets function babel: Implement IPv6 prefix compression on outgoing updates babel: Parse subtlvs and skip TLVs with a mandatory subtlv lib/ip.c | 14 +++++++ lib/ip.h | 1 + proto/babel/babel.h | 5 +++ proto/babel/packets.c | 104 +++++++++++++++++++++++++++++++++++++++++++++++--- 4 files changed, 119 insertions(+), 5 deletions(-) -- 2.13.0

2 3

[PATCH v2] babel: Implement IPv6 prefix compression on outgoing updates
by Toke Høiland-Jørgensen 09 Jun '17

09 Jun '17

Previously, the Babel protocol would never use prefix compression on outgoing updates (but would parse it on incoming ones). This adds compression of IPv6 addresses of outgoing updates. The compression only works to the extent that the FIB is walked in lexicographic order; i.e. a prefix is only compressed if it shares bytes with the previous prefix in the same packet. Signed-off-by: Toke Høiland-Jørgensen <toke(a)toke.dk> --- proto/babel/packets.c | 34 +++++++++++++++++++++++++++++++++- 1 file changed, 33 insertions(+), 1 deletion(-) diff --git a/proto/babel/packets.c b/proto/babel/packets.c index 0f70898e..8e014955 100644 --- a/proto/babel/packets.c +++ b/proto/babel/packets.c @@ -133,6 +133,8 @@ struct babel_write_state { u8 router_id_seen; u8 next_hop_v4_seen; u8 next_hop_v6_seen; + u8 def_ip6_prefix[16]; /* Previous IPv6 prefix in network order (for compression) */ + u8 def_ip6_pxlen; }; @@ -150,6 +152,14 @@ struct babel_write_state { #define NET_SIZE(n) BYTES(net_pxlen(n)) +static inline uint bytes_equal(u8 *b1, u8 *b2, uint maxlen) +{ + uint i; + for(i = 0; *b1 == *b2 && i < maxlen; i++, b1++, b2++) + ; + return i; +} + static inline u16 get_time16(const void *p) @@ -682,9 +692,31 @@ babel_write_update(struct babel_tlv *hdr, union babel_msg *m, } else { + u8 omit, buf[16] = {}; tlv->ae = BABEL_AE_IP6; tlv->plen = net6_pxlen(&msg->net); - put_ip6_px(tlv->addr, &msg->net); + + put_ip6_px(buf, &msg->net); + omit = bytes_equal(buf, state->def_ip6_prefix, state->def_ip6_pxlen/8); + DBG("%d bytes common between %I and previous prefix\n", omit, + net6_prefix(&msg->net)); + + if (0 < omit) + { + omit = MIN(omit, tlv->plen/8); + memcpy(tlv->addr, buf+omit, BYTES(tlv->plen) - omit); + + tlv->omitted = omit; + tlv->length -= omit; + len -= omit; + } + else + { + put_ip6_px(tlv->addr, &msg->net); + tlv->flags |= BABEL_FLAG_DEF_PREFIX; + put_ip6_px(state->def_ip6_prefix, &msg->net); + state->def_ip6_pxlen = tlv->plen; + } } put_time16(&tlv->interval, msg->interval); -- 2.13.0

2 1

[PATCH] babel: Add documentation for dual-stack operation and options
by Toke Høiland-Jørgensen 09 Jun '17

09 Jun '17

This updates the documentation for the Babel protocol to mention the fact that it now supports dual-stack operation, and adds documentation for the new next hop options. Signed-off-by: Toke Høiland-Jørgensen <toke(a)toke.dk> --- doc/bird.sgml | 32 ++++++++++++++++++++++++++------ 1 file changed, 26 insertions(+), 6 deletions(-) diff --git a/doc/bird.sgml b/doc/bird.sgml index 01b59c6a..4a9177f5 100644 --- a/doc/bird.sgml +++ b/doc/bird.sgml @@ -1596,11 +1596,12 @@ networks. Babel is conceptually very simple in its operation and "just works" in its default configuration, though some configuration is possible and in some cases desirable. -<p>While the Babel protocol is dual stack (i.e., can carry both IPv4 and IPv6 -routes over the same IPv6 transport), BIRD presently implements only the IPv6 -subset of the protocol. No Babel extensions are implemented, but the BIRD -implementation can coexist with implementations using the extensions (and will -just ignore extension messages). +<p>The Babel protocol is dual stack; i.e., it can carry both IPv4 and IPv6 +routes over the same IPv6 transport. For sending and receiving Babel packets, +only a link-local IPv6 address is needed. + +<p>Bird does not implement any Babel extensions, but will coexist with +implementations using extensions (and will just ignore extension messages). <p>The Babel protocol implementation in BIRD is currently in alpha stage. @@ -1623,6 +1624,8 @@ protocol babel [<name>] { rx buffer <number>; tx length <number>; check link <switch>; + next hop ipv4 <address>; + next hop ipv6 <address>; }; } </code> @@ -1680,6 +1683,18 @@ protocol babel [<name>] { routes received from them are withdrawn. It is possible that some hardware drivers or platforms do not implement this feature. Default: yes. + + <tag><label id="babel-next-hop-ipv4">next hop ipv4 <m/address/</tag> + Set the next hop address advertised for IPv4 routes advertised on this + interface. If not set, the first IPv4 address found on the interface will + be used, so it should only be necessary to set this option if this + auto-detection fails or finds the wrong address. + + <tag><label id="babel-next-hop-ipv6">next hop ipv6 <m/address/</tag> + Set the next hop address advertised for IPv6 routes advertised on this + interface. If not set, the same link-local address that is used as the + source for Babel packets will be used. In normal operation, it should not + be necessary to set this option. </descrip> <sect1>Attributes @@ -1708,7 +1723,12 @@ protocol babel { # configured on local interfaces, plus re-distribute all routes received # from other babel peers. - export where (source = RTS_DEVICE) || (source = RTS_BABEL); + ipv4 { + export where (source = RTS_DEVICE) || (source = RTS_BABEL); + }; + ipv6 { + export where (source = RTS_DEVICE) || (source = RTS_BABEL); + }; } </code> -- 2.13.0

2 1