- Bird-users - Mailing Lists

Bird can't add static route.
by Mikhail Petrov 14 Jan '21

14 Jan '21

4 3

debian buster package signature problem
by Luitz Preßler 12 Jan '21

12 Jan '21

Hello, trying to do a test install of 2.0.7 on Debian buster (2.0.8 to be expected? :-), bird2 in buster backports repo?) I tried to use https://bird.network.cz/?download&tdir=debian/ http://bird.network.cz/debian/apt.key added as proposed, but signature errors for the repo on "apt-get update" Err:2 https://bird.network.cz/debian buster InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY B188E2B695BD4743 ... Any idea? / Please correct, regards Lutz -- Lutz Preßler http://www.SerNet.de/ SerNet Service Network GmbH, Bahnhofsallee 1b, D-37081 Göttingen Tel.: +49-551-370000-0, FAX: +49-551-370000-9 AG Göttingen, HRB 2816, Gesch.F.: Dr. Johannes Loxen, Reinhild Jung

2 1

Bird does not include next hop information in babel retractions, while babeld requires them
by Fabian Bläse 06 Jan '21

06 Jan '21

Hi, when using both bird and babeld in our babel network, babeld regularly complains about malformed packets. This happens when bird sends route retractions without including router-id and next-hop TLVs first. According to rfc6126 the router-id is not used for retractions. The resulting error message was an issue with babeld and has been fixed already [1]. However, babeld also does not like if retractions are not preceded by next-hop TLVs, which are indeed evaluated for retracting a route. Bird does not send next-hop TLVs for route retractions though [3] and ignores next-hop information, when processing received retractions itself [4][5]. I could not find any information which of these behaviours is correct. But other than for the router-id, the encoding description of Update TLVs (rfc6126, section 4.4.9) does not say that the next-hop address is ignored for retractions. Regards, Fabian [1] https://github.com/jech/babeld/issues/66 [3] https://gitlab.nic.cz/labs/bird/-/blob/master/proto/babel/packets.c#L720-731 [4] https://gitlab.nic.cz/labs/bird/-/blob/master/proto/babel/packets.c#L617-619 [5] https://gitlab.nic.cz/labs/bird/-/blob/master/proto/babel/babel.c#L1242-1243

2 1

[PATCH] Nest: Read Babel metric as IGP metric
by James Lu 29 Dec '20

29 Dec '20

Hi all, When testing Babel with Bird 2.0.7, I noticed that unlike OSPF, Babel metrics are not read as an IGP metric for BGP purposes. I've attached a simple patch that adds this support - it seems to do the trick in my local testing. Best, James

4 8

BIRD 2.0.7 segfault in route filters
by Damian Zaremba 28 Dec '20

28 Dec '20

Hi, It appears there is a segfault in the route specific filters, this was initially observed during a `configure`, but appears to be easily reproducible with startup config. Environment: OS: Ubuntu Focal/Xenial (from latest image on DockerHub) GCC: 9.3.0 / 5.4.0 Bird: 2.0.7 (from https://bird.network.cz/download/bird-2.0.7.tar.gz) / 61dae32 from Git Build options: --enable-debug / no options Reproduction configuration file; ``` router id 192.0.2.0; protocol device {} protocol static { ipv4 {}; route 192.0.2.0/24 via "lo" { return false; }; } ``` Backtrace; ``` Reading symbols from bird... BIRD pretty printers loaded OK. BIRD pretty printers loaded OK. (gdb) r -d -c test.conf Starting program: /bird-2.0.7/bird -d -c test.conf warning: Error disabling address space randomization: Operation not permitted [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Filter line 0000558f4c848340 (len=2) Instruction FI_CONSTANT at line 8 value FALSE Instruction FI_RETURN at line 8 Filter line 0000558f4c848340 dump done Interpreting line. Filter line 0000558f4c848340 (len=2) Instruction FI_CONSTANT at line 8 value FALSE Instruction FI_RETURN at line 8 Filter line 0000558f4c848340 dump done Program received signal SIGSEGV, Segmentation fault. 0x0000558f4b269796 in interpret (fs=0x7efd219df730, line=0x558f4c848340, val=0x0) at filter/f-inst.c:890 890 fstk->vcnt = fstk->estk[fstk->ecnt].ventry - 1; (gdb) bt #0 0x0000558f4b269796 in interpret (fs=0x7efd219df730, line=0x558f4c848340, val=0x0) at filter/f-inst.c:890 #1 0x0000558f4b26da99 in f_eval_rte (expr=0x558f4c848340, rte=0x7ffc421efc40, tmp_pool=0x558f4c856060) at filter/filter.c:352 #2 0x0000558f4b2f9c5e in static_announce_rte (p=0x558f4c84e7b0, r=0x558f4c8481e0) at proto/static/static.c:106 #3 0x0000558f4b2fa13a in static_add_rte (p=0x558f4c84e7b0, r=0x558f4c8481e0) at proto/static/static.c:228 #4 0x0000558f4b2fa9d9 in static_start (P=0x558f4c84e7b0) at proto/static/static.c:432 #5 0x0000558f4b29501f in proto_rethink_goal (p=0x558f4c84e7b0) at nest/proto.c:1173 #6 0x0000558f4b294e7f in protos_commit (new=0x558f4c842400, old=0x0, force_reconfig=0, type=1) at nest/proto.c:1132 #7 0x0000558f4b261018 in config_do_commit (c=0x558f4c842400, type=1) at conf/conf.c:271 #8 0x0000558f4b2611ef in config_commit (c=0x558f4c842400, type=1, timeout=0) at conf/conf.c:361 #9 0x0000558f4b30b793 in main (argc=4, argv=0x7ffc421eff58) at sysdep/unix/main.c:908 ``` It would be useful to be able to reject routes from their filter (to enable suppression in function logic, either via return or reject), however in the worst case the syntax should result in an invalid configuration error rather than a crash. Let me know if you need any more info. Cheers - Damian

2 5

Incorrect iBGP next hop in bird2
by Юрий Иванов 22 Dec '20

22 Dec '20

Hi, I've very simple install. Server with two links vlan1 - 50.0.0.1/25 and vlan2 - 10.0.0.7/31 One static default route and one iBGP neighbor: protocol static default_route { ipv4; route 0.0.0.0/0 via 50.0.0.254; } protocol bgp nat_downlink1 { local 10.0.0.7 as 65001; neighbor 10.0.0.6 as 65001; #direct; ipv4 { next hop self; import all; export all; }; } Neighbor sends me a bunch of /32 host routes and all routes received from 10.0.0.6 neigbor has next hop 50.0.0.254. bird> sh route Table master4: 0.0.0.0/0 unicast [default_route 15:23:28.170] * (200) via 50.0.0.254 on vlan1 10.107.1.81/32 unicast [downlink1 16:59:19.320 from 10.0.0.6] * (100/?) [i] via 50.0.0.254 on vlan2 To fix this I can add direct option to me BGP neigbor, but I wonder why this even happens. Is there more correct eay to fix this?

2 1

[RFC] Babel: add v4viav6 support
by Andreas Rammhold 15 Dec '20

15 Dec '20

This is a first attempt at implementing draft-ietf-babel-v4viav6-00 as IPv4 via IPv6 extension to the Babel routing protocol that allows announcing routes to an IPv4 prefix with an IPv6 next-hop, which makes it possible for IPv4 traffic to flow through interfaces that have not been assigned an IPv4 address. I've tried my best to be compliant with the current RFC version. One point that is not entirely clear is how to implement in section 2.2. regarding fallback when the device doesn't support v4-via-v6 routes. (See notes below) The implementation is compatible with the current Babeld PR (https://github.com/jech/babeld/pull/56) I've verified this with a few VMs in the following setup: Bird <- v4 only -> Bird <- v6 only -> Babeld <- v4 only -> Babeld Each routing daemon was running on their own VM and had L2 connectivity to only its direct neighbors. At the nodes at the edges v4 networks have been announced and full end-to-end communication was possible over the mixed AF network. The v6 only link between Babel and Bird (at the "center" of the above setup) did transport the v4 packets via the v6 link-local next hop addresses just as expected. Thanks to Toke Høiland-Jørgensen for early review on this work. -----< notes >------ (My current notes on the current implementation regarding compliance with the current draft) Bird doesn't implement compression for outgoing (send) IPv4 prefixes and thus this also hasn't been implemented for this AE. Best guess is that 4 bytes are cheap enough to not bother with the added complexity? In the RX path compression is supported for IPv4 prefixes (for the IPv4 AE as well as for IPv4-via-IPv6 AE). Especially the part last paragraph of 2.2. remains to be discussed/solved: * If a node cannot install v4-over-v6 routes, eg., due to hardware or software limitations, then routes to an IPv4 prefix with an IPv6 next-hop MUST NOT be selected, as described in Section 3.5.3 of [RFC6126bis]. * What if the kernel doesn't accept the RTA_VIA value we gave it? Does BIRD generally handle this already? One example is hitting: "ipv4: use IS_ENABLED instead of ifdef" (id:20201115224509.2020651-1-flokli@flokli.de @ linux-netdev) Where the kernel does support it but due to a bug fails to add those routes when CONFIG_IPV6=m. Kernel version comparison is probably a bad idea. Which kind of route can we attempt to install to test this functionality without breaking any setup? Section 5: I am using the proposed value 4 to test interoperability with the Babled PR (https://github.com/jech/babeld/pull/56/commits) --- doc/bird.sgml | 7 +++ proto/babel/babel.c | 26 +++++++--- proto/babel/babel.h | 3 ++ proto/babel/config.Y | 4 +- proto/babel/packets.c | 116 ++++++++++++++++++++++++++++++------------ 5 files changed, 117 insertions(+), 39 deletions(-) diff --git a/doc/bird.sgml b/doc/bird.sgml index 5408cb2a..ee895a47 100644 --- a/doc/bird.sgml +++ b/doc/bird.sgml @@ -1770,6 +1770,7 @@ protocol babel [<name>] { check link <switch>; next hop ipv4 <address>; next hop ipv6 <address>; + ipv4 via ipv6 <switch>; }; } </code> @@ -1860,6 +1861,12 @@ protocol babel [<name>] { 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. + + <tag><label id="babel-ipv4-via-ipv6">ipv4 via ipv6 <m/switch/</tag> + If enabled, Bird will accept and emit IPv4-via-IPv6 routes when IPv4 + addresses are absent from the interface as described in draft-ietf-babel-v4viav6. + Default: yes. + </descrip> <sect1>Attributes diff --git a/proto/babel/babel.c b/proto/babel/babel.c index 4b6b9d7f..64a88601 100644 --- a/proto/babel/babel.c +++ b/proto/babel/babel.c @@ -954,8 +954,15 @@ babel_send_update_(struct babel_iface *ifa, btime changed, struct fib *rtable) msg.update.router_id = e->router_id; net_copy(&msg.update.net, e->n.addr); - msg.update.next_hop = ((e->n.addr->type == NET_IP4) ? - ifa->next_hop_ip4 : ifa->next_hop_ip6); + if (e->n.addr->type == NET_IP4 && !ipa_zero(ifa->next_hop_ip4)) { + msg.update.next_hop = ifa->next_hop_ip4; + } else if (e->n.addr->type == NET_IP6 && !ipa_zero(ifa->next_hop_ip6)) { + msg.update.next_hop = ifa->next_hop_ip6; + /* If there is no IPv4 address on the interface (and we are supporting v4viav6) + * send the v6 next hop instead */ + } else if (ifa->cf->ip4_via_ip6 && e->n.addr->type == NET_IP4 && ipa_zero(ifa->next_hop_ip4) && !ipa_zero(ifa->next_hop_ip6)) { + msg.update.next_hop = ifa->next_hop_ip6; + } /* Do not send route if next hop is unknown, e.g. no configured IPv4 address */ if (ipa_zero(msg.update.next_hop)) @@ -1247,6 +1254,12 @@ babel_handle_update(union babel_msg *m, struct babel_iface *ifa) return; } + /* Reject IPv4 via IPv6 routes if disabled */ + if (!ifa->cf->ip4_via_ip6 && msg->net.type == NET_IP4 && ipa_is_ip6(msg->next_hop)) { + DBG("Babel: Ignoring disabled IPv4 via IPv6 route.\n"); + return; + } + /* Regular update */ e = babel_get_entry(p, &msg->net); r = babel_get_route(p, e, nbr); /* the route entry indexed by neighbour */ @@ -1529,7 +1542,7 @@ babel_iface_update_addr4(struct babel_iface *ifa) ifa->next_hop_ip4 = ipa_nonzero(ifa->cf->next_hop_ip4) ? ifa->cf->next_hop_ip4 : addr4; if (ipa_zero(ifa->next_hop_ip4) && p->ip4_channel) - log(L_WARN "%s: Missing IPv4 next hop address for %s", p->p.name, ifa->ifname); + log(L_WARN "%s: Missing IPv4 next hop address for %s", p->p.name, ifa->ifname); // FIXME: make sure we do not log this when it is expected if (ifa->up) babel_iface_kick_timer(ifa); @@ -1894,8 +1907,8 @@ babel_show_interfaces(struct proto *P, const char *iff) } cli_msg(-1023, "%s:", p->p.name); - cli_msg(-1023, "%-10s %-6s %7s %6s %7s %-15s %s", - "Interface", "State", "RX cost", "Nbrs", "Timer", + cli_msg(-1023, "%-10s %-6s %-12s %7s %6s %7s %-15s %s", + "Interface", "State", "IPv4 via Ip6", "RX cost", "Nbrs", "Timer", "Next hop (v4)", "Next hop (v6)"); WALK_LIST(ifa, p->interfaces) @@ -1908,8 +1921,9 @@ babel_show_interfaces(struct proto *P, const char *iff) nbrs++; btime timer = MIN(ifa->next_regular, ifa->next_hello) - current_time(); - cli_msg(-1023, "%-10s %-6s %7u %6u %7t %-15I %I", + cli_msg(-1023, "%-10s %-6s %-12s %7u %6u %7t %-15I %I", ifa->iface->name, (ifa->up ? "Up" : "Down"), + (ifa->cf->ip4_via_ip6 ? "Yes" : "No"), ifa->cf->rxcost, nbrs, MAX(timer, 0), ifa->next_hop_ip4, ifa->next_hop_ip6); } diff --git a/proto/babel/babel.h b/proto/babel/babel.h index e075024c..146d28f5 100644 --- a/proto/babel/babel.h +++ b/proto/babel/babel.h @@ -104,6 +104,7 @@ enum babel_ae_type { BABEL_AE_IP4 = 1, BABEL_AE_IP6 = 2, BABEL_AE_IP6_LL = 3, + BABEL_AE_IPV4_VIA_IPV6 = 4, BABEL_AE_MAX }; @@ -137,6 +138,8 @@ struct babel_iface_config { ip_addr next_hop_ip4; ip_addr next_hop_ip6; + + u8 ip4_via_ip6; /* Enabe IPv4 via IPv6 */ }; struct babel_proto { diff --git a/proto/babel/config.Y b/proto/babel/config.Y index 2f3b637b..f17884eb 100644 --- a/proto/babel/config.Y +++ b/proto/babel/config.Y @@ -25,7 +25,7 @@ CF_DECLS CF_KEYWORDS(BABEL, INTERFACE, METRIC, RXCOST, HELLO, UPDATE, INTERVAL, PORT, TYPE, WIRED, WIRELESS, RX, TX, BUFFER, PRIORITY, LENGTH, CHECK, LINK, NEXT, HOP, IPV4, IPV6, BABEL_METRIC, SHOW, INTERFACES, NEIGHBORS, - ENTRIES, RANDOMIZE, ROUTER, ID) + ENTRIES, RANDOMIZE, ROUTER, ID, VIA) CF_GRAMMAR @@ -65,6 +65,7 @@ babel_iface_start: BABEL_IFACE->tx_tos = IP_PREC_INTERNET_CONTROL; BABEL_IFACE->tx_priority = sk_priority_control; BABEL_IFACE->check_link = 1; + BABEL_IFACE->ip4_via_ip6 = 1; }; @@ -109,6 +110,7 @@ babel_iface_item: | CHECK LINK bool { BABEL_IFACE->check_link = $3; } | NEXT HOP IPV4 ipa { BABEL_IFACE->next_hop_ip4 = $4; if (!ipa_is_ip4($4)) cf_error("Must be an IPv4 address"); } | NEXT HOP IPV6 ipa { BABEL_IFACE->next_hop_ip6 = $4; if (!ipa_is_ip6($4)) cf_error("Must be an IPv6 address"); } + | IPV4 VIA IPV6 bool { BABEL_IFACE->ip4_via_ip6 = $4; } ; babel_iface_opts: diff --git a/proto/babel/packets.c b/proto/babel/packets.c index 415ac3f9..d4c66a53 100644 --- a/proto/babel/packets.c +++ b/proto/babel/packets.c @@ -130,9 +130,11 @@ struct babel_parse_state { u64 router_id; /* Router ID used in subsequent updates */ u8 def_ip6_prefix[16]; /* Implicit IPv6 prefix in network order */ u8 def_ip4_prefix[4]; /* Implicit IPv4 prefix in network order */ + u8 def_ip4viaip6_prefix[4]; /* Implicit IPv4 prefix in network order */ u8 router_id_seen; /* router_id field is valid */ u8 def_ip6_prefix_seen; /* def_ip6_prefix is valid */ u8 def_ip4_prefix_seen; /* def_ip4_prefix is valid */ + u8 def_ip4viaip6_prefix_seen; /* def_ip4viaip6_prefix is valid*/ u8 current_tlv_endpos; /* End of self-terminating TLVs (offset from start) */ u8 sadr_enabled; }; @@ -246,6 +248,8 @@ static int babel_read_update(struct babel_tlv *hdr, union babel_msg *msg, struct static int babel_read_route_request(struct babel_tlv *hdr, union babel_msg *msg, struct babel_parse_state *state); static int babel_read_seqno_request(struct babel_tlv *hdr, union babel_msg *msg, struct babel_parse_state *state); static int babel_read_source_prefix(struct babel_tlv *hdr, union babel_msg *msg, struct babel_parse_state *state); +static int babel_read_update_ip4_prefix(struct babel_tlv_update *tlv, struct babel_msg_update *msg, u8 *def_prefix_seen, + u8 (*def_prefix)[4], ip_addr * next_hop, int len); static uint babel_write_ack(struct babel_tlv *hdr, union babel_msg *msg, struct babel_write_state *state, uint max_len); static uint babel_write_hello(struct babel_tlv *hdr, union babel_msg *msg, struct babel_write_state *state, uint max_len); @@ -398,9 +402,6 @@ babel_read_ihu(struct babel_tlv *hdr, union babel_msg *m, msg->addr = IPA_NONE; msg->sender = state->saddr; - if (msg->ae >= BABEL_AE_MAX) - return PARSE_IGNORE; - /* * We only actually read link-local IPs. In every other case, the addr field * will be 0 but validation will succeed. The handler takes care of these @@ -413,13 +414,13 @@ babel_read_ihu(struct babel_tlv *hdr, union babel_msg *m, if (TLV_OPT_LENGTH(tlv) < 4) return PARSE_ERROR; state->current_tlv_endpos += 4; - break; + return PARSE_SUCCESS; case BABEL_AE_IP6: if (TLV_OPT_LENGTH(tlv) < 16) return PARSE_ERROR; state->current_tlv_endpos += 16; - break; + return PARSE_SUCCESS; case BABEL_AE_IP6_LL: if (TLV_OPT_LENGTH(tlv) < 8) @@ -427,10 +428,10 @@ babel_read_ihu(struct babel_tlv *hdr, union babel_msg *m, msg->addr = ipa_from_ip6(get_ip6_ll(&tlv->addr)); state->current_tlv_endpos += 8; - break; + return PARSE_SUCCESS; } - return PARSE_SUCCESS; + return PARSE_IGNORE; } static uint @@ -530,6 +531,47 @@ babel_read_next_hop(struct babel_tlv *hdr, union babel_msg *m UNUSED, return PARSE_IGNORE; } + +/* This is called directrly from babel_read_next_hop to handle the ip4 address + compression state */ +static int +babel_read_update_ip4_prefix(struct babel_tlv_update *tlv, + struct babel_msg_update *msg, + u8 *def_prefix_seen, + u8 (*def_prefix)[4], + ip_addr *next_hop, + int len) +{ + if (tlv->plen > IP4_MAX_PREFIX_LENGTH) + return PARSE_ERROR; + + /* Cannot omit data if there is no saved prefix */ + if (tlv->omitted && !*def_prefix_seen) + return PARSE_ERROR; + + /* Update must have next hop, unless it is retraction */ + if (ipa_zero(*next_hop) && msg->metric != BABEL_INFINITY) + return PARSE_IGNORE; + + /* Merge saved prefix and received prefix parts */ + u8 buf[4] = {}; + memcpy(buf, *def_prefix, tlv->omitted); + memcpy(buf + tlv->omitted, tlv->addr, len); + + ip4_addr prefix4 = get_ip4(buf); + net_fill_ip4(&msg->net, prefix4, tlv->plen); + + if (tlv->flags & BABEL_UF_DEF_PREFIX) + { + put_ip4(*def_prefix, prefix4); + *def_prefix_seen = 1; + } + + msg->next_hop = *next_hop; + + return PARSE_SUCCESS; +} + /* This is called directly from babel_write_update() and returns -1 if a next hop should be written but there is not enough space. */ static int @@ -579,6 +621,7 @@ static int babel_read_update(struct babel_tlv *hdr, union babel_msg *m, struct babel_parse_state *state) { + int rc; struct babel_tlv_update *tlv = (void *) hdr; struct babel_msg_update *msg = &m->update; @@ -589,7 +632,6 @@ babel_read_update(struct babel_tlv *hdr, union babel_msg *m, /* Length of received prefix data without omitted part */ int len = BYTES(tlv->plen) - (int) tlv->omitted; - u8 buf[16] = {}; if ((len < 0) || ((uint) len > TLV_OPT_LENGTH(tlv))) return PARSE_ERROR; @@ -607,31 +649,20 @@ babel_read_update(struct babel_tlv *hdr, union babel_msg *m, break; case BABEL_AE_IP4: - if (tlv->plen > IP4_MAX_PREFIX_LENGTH) - return PARSE_ERROR; - - /* Cannot omit data if there is no saved prefix */ - if (tlv->omitted && !state->def_ip4_prefix_seen) - return PARSE_ERROR; - - /* Update must have next hop, unless it is retraction */ - if (ipa_zero(state->next_hop_ip4) && (msg->metric != BABEL_INFINITY)) - return PARSE_IGNORE; - - /* Merge saved prefix and received prefix parts */ - memcpy(buf, state->def_ip4_prefix, tlv->omitted); - memcpy(buf + tlv->omitted, tlv->addr, len); - - ip4_addr prefix4 = get_ip4(buf); - net_fill_ip4(&msg->net, prefix4, tlv->plen); + rc = babel_read_update_ip4_prefix(tlv, msg, &state->def_ip4_prefix_seen, + &state->def_ip4_prefix, &state->next_hop_ip4, + len); + if (rc != PARSE_SUCCESS) + return rc; - if (tlv->flags & BABEL_UF_DEF_PREFIX) - { - put_ip4(state->def_ip4_prefix, prefix4); - state->def_ip4_prefix_seen = 1; - } + break; - msg->next_hop = state->next_hop_ip4; + case BABEL_AE_IPV4_VIA_IPV6: + rc = babel_read_update_ip4_prefix(tlv, msg, &state->def_ip4viaip6_prefix_seen, + &state->def_ip4viaip6_prefix, &state->next_hop_ip6, + len); + if (rc != PARSE_SUCCESS) + return rc; break; @@ -644,6 +675,7 @@ babel_read_update(struct babel_tlv *hdr, union babel_msg *m, return PARSE_ERROR; /* Merge saved prefix and received prefix parts */ + u8 buf[16] = {}; memcpy(buf, state->def_ip6_prefix, tlv->omitted); memcpy(buf + tlv->omitted, tlv->addr, len); @@ -746,7 +778,11 @@ babel_write_update(struct babel_tlv *hdr, union babel_msg *m, } else if (msg->net.type == NET_IP4) { - tlv->ae = BABEL_AE_IP4; + if (!ipa_zero(msg->next_hop) && ipa_is_ip6(msg->next_hop)) + tlv->ae = BABEL_AE_IPV4_VIA_IPV6; + else + tlv->ae = BABEL_AE_IP4; + tlv->plen = net4_pxlen(&msg->net); put_ip4_px(tlv->addr, &msg->net); } @@ -814,7 +850,15 @@ babel_read_route_request(struct babel_tlv *hdr, union babel_msg *m, msg->full = 1; return PARSE_SUCCESS; + /* + * When receiving requests, AEs 1 (IPv4) and 4 (v4-via-v6) MUST be + * treated in the same manner: the receiver processes the request as + * described in Section 3.8 of [RFC6126bis]. If an Update is sent, then + * it MAY be sent with AE 1 or TBD, as described in Section 2.1 above, + * irrespective of which AE was used in the request. + */ case BABEL_AE_IP4: + case BABEL_AE_IPV4_VIA_IPV6: if (tlv->plen > IP4_MAX_PREFIX_LENGTH) return PARSE_ERROR; @@ -915,7 +959,15 @@ babel_read_seqno_request(struct babel_tlv *hdr, union babel_msg *m, case BABEL_AE_WILDCARD: return PARSE_ERROR; + /* + * When receiving requests, AEs 1 (IPv4) and TBD (v4-via-v6) MUST be + * treated in the same manner: the receiver processes the request as + * described in Section 3.8 of [RFC6126bis]. If an Update is sent, then + * it MAY be sent with AE 1 or TBD, as described in Section 2.1 above, + * irrespective of which AE was used in the request. + */ case BABEL_AE_IP4: + case BABEL_AE_IPV4_VIA_IPV6: if (tlv->plen > IP4_MAX_PREFIX_LENGTH) return PARSE_ERROR; -- 2.29.2

4 7

BGP binding in v1.6
by Yakov Sh. 14 Dec '20

14 Dec '20

Hi, I'm trying to limit addresses bird is listening to for BGP connections. There are 'listen bgp' option, but using it I was able to set only one address. Multiple statements accepted, but only last one used. Multiple addresses in a single statement works the same way. So, is there a way to listen on some small set of addresses, for example three? Bird version used is 1.6.8. Yakov Sh. telegram: @darkyman

2 2

[PATCH] Preserve MED from eBGP peers
by Trisha Biswas 11 Dec '20

11 Dec '20

Hi all, The attached patch helps preserve MED values to/from eBGP peers. When propagating a route from a true eBGP peer to an internal peer, this avoids resetting the MED attribute to allow propagation of MED to/from external peers. This is enabled via a configuration line: "preserve med", which goes under BGP configs. Without the configuration line this would be a no-op. Thanks, Trisha -- *Trisha Biswas* | Sr. Software Engineer, Network Systems fastly.com | @fastly <https://twitter.com/fastly> | LinkedIn <http://www.linkedin.com/company/fastly>

2 2

Export strongSwan generated routes as plain stub network routes via OSPF
by Gehrkens.IT GmbH | Heiko Wundram 10 Dec '20

10 Dec '20

Hello all, I'm currently trying to get strongSwan generated IPsec rules to play nice with the OSPF implementation of bird. The problem I'm facing is that currently, the strongSwan generated routes are added properly to the corresponding IPsec routing table (for all those that have an IPsec tunnel up with the VPN concentrator), but most of the routes contain a gateway (set up from the default route on the VPN concentrator, pointing to its default gateway, for the VPN network). These gateways are useless with respect to the actual IPsec transport (because the XFRM policy overrides the nexthop target anyway), but are used in source address selection for local outgoing connections from the gateway (that's why strongSwan inserts the routes this way). Now, I'd like to export the routes that are up on the VPN concentrator to the OSPF neighbors of it (all OSPF peers are in the backbone area of this network), which of course means that bird doesn't export a route pointing to the VPN concentrator for the networks that are up (i.e., a stub network), but rather exports the corresponding gateway route. This means that all other hosts try to route packets to the IPsec tunnel via the default gateway that the VPN concentrator has set up, and not via the VPN concentrator itself, which breaks the IPsec routing. I've tried overriding the route type (i.e., to RTD_DEVICE) on import into the OSPF instance, and also clearing out/resetting the gateway, but the former is forbidden, and the latter doesn't do what I expect it to do (I tried setting up the IP address of the VPN concentrator in the corresponding imported route in the OSPF instance as the gateway, but that doesn't seem to properly be propagated). Is there anything I can do to export the networks that the VPN concentrator connects as stub networks, even though they aren't connected through an interface, but just as entries in a routing table (some are RTD_DEVICE, others RTD_ROUTER)? As a twist: I cannot export bigger networks as static stub nets to the corresponding VPN concentrator and then have some policy there which catches currently unroutable networks, as there are multiple (load-balanced) VPN concentrators in the backbone area, and I don't know in advance which networks are connected to which VPN concentrator - that's why I wanted to use OSPF to propagate the actual connections from the strongSwan generated routing table(s). Thanks for any hints on how I might get this to work! Heiko.

2 2