December 2020 - Bird-users

[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

OSPF protocol and export filters for E2 routes
by Nigel Kukard 09 Dec '20

09 Dec '20

Hi guys, I'm wondering if someone knows the answer to this, here is the setup... R1 => R2 => R3 - R1 advertises a route (in this case 0.0.0.0/0) to R2 (from static or kernel) - R2 accepts the route with "import all" - R2 has a filter for the route with "export my_filter;" and in that filter there is a "reject;" - R3 should not receive the route, correct? What I am seeing is this works 100% as expected in RIP. When I try the same thing with OSPF, I am not seeing it being rejected on R2. Infact, I am not seeing the E2 route at all pass through the export filter. But I am receiving it on R3. I just want to make sure this is expected or unexpected behavior? My use case is if R1 advertises a default route via OSPF, I was looking at filtering that default route out on R2 so it is not advertised to R3. -N

2 1

static iBGP IPv4 route with link-local IPv6 next-hop
by Banerjee, Debabrata 08 Dec '20

08 Dec '20

Hello, I’m trying to use RFC 5549 and RFC 2545 to do this route advertisement, and it seems it should work according to the bird documentation. However, bird is sending an empty NLRI whenever I use a v6 next-hop, either link-local or global. I've tried various combinations of specifying the route "via" or "next hop address" with the global or link-local address, I haven't found a combination that it likes. In any case, bird would need to figure out the right tuple (global, link-local) to send in the extended next hop message. Tcpdump: Update Message (2), length: 29 Multi-Protocol Unreach NLRI (15), length: 3, Flags [O]: AFI: IPv6 (2), SAFI: Unicast (1) End-of-Rib Marker (empty NLRI) 0x0000: 0002 01 bird> show static 198.18.235.70/32 via 2001:4878:c1e1:4015::c612:ea44%eth0 Example config: router id 192.18.234.68; protocol device { } protocol kernel { ipv4 { import none; export none; }; } protocol static static2 { ipv4; route 198.18.235.70/32 via 2001:4878:c1e1:4015::c612:ea44 % eth0; } protocol bgp uplink1 { local 198.18.234.68 as 20940; neighbor 198.18.234.65 as 20940; ipv4 { export all; next hop address fe80::216:3eff:fe3c:e58; extended next hop; }; };

1 0

Fwd: ospfv6 cryptographic crashes bird
by Dries 07 Dec '20

07 Dec '20

Hi I am having an issue that crashes bird 2.0.7 running on latest centos 7.9.2009, most of the time, but sometimes not. Running the same config on other machines, and there is no problem, only on this particular one. So I am maybe missing some (cryptographic) libraries? I don't see any error messages during compilation or build. It has to do with ospfv6 because, when I remove this config, it runs fine. Example config that is causing issues: protocol ospf v3 ospfv6 { ipv6 { import filter import_ospfv6; export filter export_ospfv6; }; area 0.0.0.0 { interface "eth1" { cost 1; authentication cryptographic; password "password" { algorithm hmac sha512; }; type broadcast; ttl security yes; }; interface "xenbr0" { cost 100; type broadcast; ttl security yes; }; }; } When bird runs in debug mode, I get these error messages before bird crashes: sometimes this one: Assertion '*plen < ifa->sk->tbsize' failed at proto/ospf/packet.c:147 sometimes this one: Assertion '*plen < ifa->sk->tbsize' failed at proto/ospf/packet.c:97 These messages also appear during startup: ospfv6: Authentication failed for nbr 123.123.123.123 on eth1 - missing authentication trailer (0) Thank you in advance. Kind regards Dries

2 2

Wrong GPG key listed in the download page
by Baptiste Jonglez 06 Dec '20

06 Dec '20

Hi, I know GPG issues with the Debian packages came up several time on the list already, but more specifically, the GPG key listed here is outdated: https://bird.network.cz/?download&tdir=debian/ The files apt.gpg and apt.key contain key AC0E47584A7A714D from 2014-09-09 called "CZ.NIC Labs Archive Automatic Signing Key <ftpmaster(a)labs.nic.cz>". This key is revoked on key servers, and packages are signed with the newer key B188E2B695BD4743. Could you update the key in the webpage listed above? Thanks, Baptiste

1 0

Issue with unsigned integer LOCAL_PREF
by Alexandre Corso 04 Dec '20

04 Dec '20

Hello Bird team, Thank you for the great tool BIRD. I would like to open an issue (bird v2.0.7) about the local_pref. Today we hit an issue with one filter. if ! is_geo_region_local() then { bgp_local_pref = bgp_local_pref - 200; # If not defined, MED has a type of void instead of int if defined(bgp_med) then { bgp_med = bgp_med + 50; } else { bgp_med = 50; } } When some prefixes with the local_pref was below 200 (for example 100), the value overflow: localpref (unsigned integer 4^32) 100 - 200 = -100 = 4 ^ 32 - 100 = 4294967296 - 100 = 4294967196 We had the prefixes with this value 4294967196 X.X.X.X/32 unicast [ipv4_rr01 07:51:49.603 from 100.100.254.137] * (100/84285) [AS65030?] via 100.99.0.100 on eth1.666 Type: BGP univ BGP.origin: Incomplete BGP.as_path: 64619 65030 BGP.next_hop: y.y.y.y BGP.med: 50 BGP.local_pref: 4294967196 BGP.community: (35280,1040) (35280,2070) (35280,3110) BGP.originator_id: y.y.y.y BGP.cluster_list: 0.0.0.30 We had an exception to check the value of local_pref (on the filter) but can we have the something on the code, not to overflow the local_pref, for example SET to 0 if the value overflow? Our filter looks like this now if bgp_local_pref > 200 then bgp_local_pref = bgp_local_pref - 200; else { bgp_local_pref = 0; } Best Alexandre Corso alexandre@ac <mailto:alexandre@acorus.net>orso.fr

3 3

Inject ethernet-based defaults to OSPF
by daniele 04 Dec '20

04 Dec '20

Hello list, I???m looking for some advice from someone that has more experience. I'm running bird 1.6.6. I have two routers R1 and R2, each with a single internet uplink U1 and U2, running OSPF and sharing a LAN ethernet segment. Both U1 and U2 are dhcp-based ethernet segments themselves with a next-hop IP address that can change. I want R1 to be the primary LAN internet gateway and R2 the secondary. Should U1 fail, R1 has to route to R2 in order to reach internet through U2. How would you recommend to inject U1 and U2 default routes into OSPF? I cannot use the next-hop ip address as it changes along time, and an interface-based static route would not work. thanks a lot, d

3 8