June 2018 - Bird-users - Mailing Lists

Adding more then one bgp community at once
by Борис Коваленко 05 May '23

05 May '23

Hello! Is this possible to add many communites at once? bgp_community.add([(1,1), (1,2)]) is wrong "Setting clist attribute to non-clist value" Regards, Boris -- С уважением, Борис Коваленко

4 5

Bug: BFD confuses sessions with identical IPv6 link-local addresses
by Julian Brost 14 Jan '21

14 Jan '21

Hi, I just tried to enable BFD for some OSPF and BGP connections and ran into an issue which BFD sessions flapping up and down and Bird logging many messages like these: bfd1: Bad packet from fe80::2 - unknown session id (130079069) bfd1: Bad packet from fe80::2 - unknown session id (3102513000) bfd1: Bad packet from fe80::2 - unknown session id (3650438750) bfd1: Bad packet from fe80::2 - unknown session id (1597034259) This presumably happens due to this piece of code in bfd_rx_hook() in proto/bfd/packets.c: s = bfd_find_session_by_addr(p, sk->faddr); I use fe80::1/fe80::2 as addresses for most of my IPv6 peering connections and sk->faddr is just a 128 bit value, so it contains no interface identifier, which likely leads to Bird confusing multiple BFD sessions. Regards, Julian

3 5

[PATCH] babel: Set onlink flag for IPv4 routes with unreachable next hop
by Toke Høiland-Jørgensen 14 Apr '20

14 Apr '20

If the next hop of a route is not a reachable address, the route should be installed as onlink. This enables a configuration common in mesh networks where the mesh interface is assigned a /32 and babel handles the routing by installing onlink routes. Signed-off-by: Toke Høiland-Jørgensen <toke(a)toke.dk> --- proto/babel/babel.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/proto/babel/babel.c b/proto/babel/babel.c index 88c4711e..4fd88042 100644 --- a/proto/babel/babel.c +++ b/proto/babel/babel.c @@ -640,6 +640,13 @@ babel_announce_rte(struct babel_proto *p, struct babel_entry *e) .nh.iface = r->neigh->ifa->iface, }; + /* If we cannot find a reachable neighbour, set the entry to be onlink. This + * makes it possible to, e.g., assign /32 addresses on a mesh interface and + * have routing work. + */ + if (!neigh_find2(&p->p, &r->next_hop, r->neigh->ifa->iface, 0)) + a0.nh.flags = RNF_ONLINK; + rta *a = rta_lookup(&a0); rte *rte = rte_get_temp(a); rte->u.babel.seqno = r->seqno; -- 2.17.0

3 4

Bird 1.6.3 removing IPv6 device routes on Linux (3.10.0)
by Ben Arblaster 12 Oct '19

12 Oct '19

Hi, I’m seeing an issue with bird 1.6.3 where IPv6 device routes are unexpectedly removed from the kernel table on Linux (3.10.0, CentOS 7) when bird removes a matching route learned via another protocol (in this case OSPF). To reproduce, I’ve rigged up a very simple test with two bird6 instances running OSPF in a single area 0 over a ptp tunnel. Configs are here - https://gist.github.com/andatche/ca5b5ac120e09b6b8171ec5ca95d2e25 If I add an address/network (e.g. fd00::1/64) to an interface (dummy0) on host A, the route is flooded by A, learned by B and correctly installed in the kernel table on B: fd00::/64 via fe80::5efe:ae2:b006 dev tun0 proto bird metric 1024 If I then add the same address/network (e.g. fd00::1/64) to an interface (dummy0) on host B, at that instant a device route is installed in the kernel table alongside the existing route on host B and it now looks like this: fd00::/64 dev dummy0 proto kernel metric 256 fd00::/64 via fe80::5efe:ae2:b006 dev tun0 proto bird metric 1024 Shortly after, bird picks up the new address/network on dummy0, recalculates the area and correctly selects the connected route as the new best. It then removes the old route via host A from the kernel table, as expected: kernel1 < removed fd00::/64 via fe80::5efe:ae2:b006 on tun0 However, this causes both the route via host A *and* the device route to be removed from the kernel table, leaving the kernel table on host B with no route to fd00::/64 at all. # ip -6 route show fd00::/64 # This is a change in behaviour from 1.4.5 and seems like a bug, rather than the expected behaviour? Regards, Ben -- Ben Arblaster e: ben(a)andatche.com t: +447943860840 w: https://andatche.com

3 3

[PATCH] babel: Don't send routes with empty next hops
by Toke Høiland-Jørgensen 10 Jul '18

10 Jul '18

If an interface has no configured v4 address, no valid next hop will be found for v4 routes. Rather than send them with an invalid next hop (which will just cause parse errors at the receiver), skip such routes entirely when sending updates. Also, amend the warning on configure to make it clear that v4 routes will not work if there is no v4 address on the interface. Signed-off-by: Toke Høiland-Jørgensen <toke(a)toke.dk> --- proto/babel/babel.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/proto/babel/babel.c b/proto/babel/babel.c index 44c6adb8..d3b5b841 100644 --- a/proto/babel/babel.c +++ b/proto/babel/babel.c @@ -951,8 +951,13 @@ babel_send_update_(struct babel_iface *ifa, btime changed, struct fib *rtable) msg.update.next_hop = ((e->n.addr->type == NET_IP4) ? ifa->next_hop_ip4 : ifa->next_hop_ip6); - - babel_enqueue(&msg, ifa); + /* + * We may get empty next hop addresses here if no v4 address is configured + * on the interface. These will just cause parsing errors at the receiver, + * so don't send them. + */ + if (!ipa_zero(msg.update.next_hop)) + babel_enqueue(&msg, ifa); /* Update feasibility distance for redistributed routes */ if (e->router_id != p->router_id) @@ -1580,7 +1585,8 @@ babel_add_iface(struct babel_proto *p, struct iface *new, struct babel_iface_con ifa->next_hop_ip6 = ipa_nonzero(ic->next_hop_ip6) ? ic->next_hop_ip6 : ifa->addr; if (ipa_zero(ifa->next_hop_ip4) && p->ip4_channel) - log(L_WARN "%s: Cannot find IPv4 next hop addr on %s", p->p.name, new->name); + log(L_WARN "%s: Cannot find IPv4 next hop addr on %s. " + "v4 routes will not work!", p->p.name, new->name); init_list(&ifa->neigh_list); ifa->hello_seqno = 1; @@ -1682,7 +1688,8 @@ babel_reconfigure_iface(struct babel_proto *p, struct babel_iface *ifa, struct b ifa->next_hop_ip6 = ipa_nonzero(new->next_hop_ip6) ? new->next_hop_ip6 : ifa->addr; if (ipa_zero(ifa->next_hop_ip4) && p->ip4_channel) - log(L_WARN "%s: Cannot find IPv4 next hop addr on %s", p->p.name, ifa->ifname); + log(L_WARN "%s: Cannot find IPv4 next hop addr on %s. " + "v4 routes will not work!", p->p.name, ifa->ifname); if (ifa->next_hello > (current_time() + new->hello_interval)) ifa->next_hello = current_time() + (random() % new->hello_interval); -- 2.17.1

1 2

route withdrawals are not sent upon protocol removal
by Thomás S. Bregolin 08 Jul '18

08 Jul '18

Hello, bird (all versions) does not send BGP route withdrawals when a protocol is removed, only when the filter changes or the protocol is disabled. Is this intentional? If not, could it be a configurable option to send route withdrawals upon protocols being removed? I am having an issue where the peers keep stale routes that were removed from bird but were not withdrawn via update messages. Regards, Thomás

4 15

BIRD - Config Support for RFC 3107 - Carrying Label Information in BGP
by LAKSHMANAN, THIRUVAZHIYA 30 Jun '18

30 Jun '18

Dear support-team, In the BIRD 2.0 user guide, I see the support for RFC 3107 - Carrying Label information in BGP. We want to configure a VM with BIRD agent working like a PE for adding MPLS labels for IPv4 and IPv6 unicast routes. Do we have this configuration supported now, and can I get any sample working configuration for this please. Regards, Thiruvazhiyan

5 18

Advertise Loopback interface to the 3107 BGP neighbor
by Thiruvazhiyan Lakshmanan 29 Jun '18

29 Jun '18

Dear Support, I have a VM running with Bird 2.0.2 and peering with a 3107 BGP neighbor. I would like to advertise VM's loopback IP address to the 3107 BGP neighbor (Labeled unicast) with label value of 3 and the nexthop as interface address. Is it possible and how can it be achieved. Thanks & Regards, Thiru ============================================================================================================================ Disclaimer: This message and the information contained herein is proprietary and confidential and subject to the Tech Mahindra policy statement, you may review the policy at http://www.techmahindra.com/Disclaimer.html <http://www.techmahindra.com/Disclaimer.html> externally http://tim.techmahindra.com/tim/disclaimer.html <http://tim.techmahindra.com/tim/disclaimer.html> internally within TechMahindra. ============================================================================================================================

1 0

MP_UNREACH_NLRI RFC8277 compatibility
by Vadim Fedorenko 29 Jun '18

29 Jun '18

Hi! According to RFC 8277, NLRI for withdrawal contains 3 fields: Length, Compatibility and Prefix. "Upon transmission, the Compatibility field SHOULD be set to 0x800000.Upon reception, the value of the Compatibility field MUST be ignored." Right now, BIRD 2.0.2 checks Compatibility field for value 0x800000, and this is not compatible with RFC, and at least Juniper MX do not set this field to 0x800000, and BGP session between BIRD and Juniper resets with Malformed Attribute List. Attached patch fixes this behavior. diff --git a/proto/bgp/packets.c b/proto/bgp/packets.c index 190fd6f..5dcb00d 100644 --- a/proto/bgp/packets.c +++ b/proto/bgp/packets.c @@ -1165,8 +1165,11 @@ bgp_decode_mpls_labels(struct bgp_parse_state *s, byte **pos, uint *len, uint *p ADVANCE(*pos, *len, 3); *pxlen -= 24; - /* Withdraw: Magic label stack value 0x800000 according to RFC 3107, section 3, last paragraph */ - if (!a && !s->err_withdraw && (lnum == 1) && (label == BGP_MPLS_MAGIC)) + /* + * Withdraw: According to RFC 3107, section 2.4, second paragraph + * Upon reception, the value of the Compatibility field MUST be ignored. + */ + if (!a && !s->err_withdraw && (lnum == 1) && (s->mp_unreach_len)) break; } while (!(label & BGP_MPLS_BOS));

2 1

How to upgrade from 1.6.4 to 2.0
by Isaac HO 28 Jun '18

28 Jun '18

Thanks.

1 0