March 2024 - Bird-users - Mailing Lists

Adding a downstream ebgp connection. How to keep it separate?
by LU 20 Mar '24

20 Mar '24

Hello. I have two BGP routers with bird 2.4. Each router maintains some eBGP connections to upstreams where I announce my prefixes. These routers have an iBGP connection between themselves to exchange routes learned from those eBGP connections. I do some filtering on the eBGP connections (like setting local preference, as path prepending, setting an internal bgp community so that I know which routes originate from which eBGP connection, etc.) So far this is simple, works great for my own traffic/prefixes and have no trouble maintaining this. But now a need arose that I will be adding a downstream eBGP connection (customer). This means transiting a foreign prefix over my BGP routers and exporting some routes to it. How do I approach this the cleanest and simplest way possible? I suppose I should have two routing tables (currently under Linux/Bird everything is under the default routing/main table): - main table (keep for my own traffic) - customer table But I am unsure what to do with my existing upstream eBGP connections since I do some filtering on them for my own use cases. Should I have a separate Bird table for each upstream eBGP connection? Then use the pipe protocol to put the routes in the main and customer table separately? Then I could place the current filtering of eBGP connections that I use for myself in the pipe protocol that feeds my main table? The customer table will then be piped the raw routes from the eBGP connections. Is my thinking correct? Or this can be done better/differently? Are there perhaps any presentations and/or sample configs of such setups? I am sure this situation comes up quite often. Thanks!

3 4

[PATCH] OSPF: fix next-hop inheriting condition
by Soha Jin 19 Mar '24

19 Mar '24

Signed-off-by: Soha Jin <soha(a)jin.sh> Co-developed-by: Wende Tan <twd2.me(a)gmail.com> --- proto/ospf/rt.c | 22 ++++++++++++++++++---- 1 file changed, 18 insertions(+), 4 deletions(-) diff --git a/proto/ospf/rt.c b/proto/ospf/rt.c index efcd4e17..7636e9a2 100644 --- a/proto/ospf/rt.c +++ b/proto/ospf/rt.c @@ -1726,10 +1726,24 @@ ospf_rt_spf(struct ospf_proto *p) static inline int -inherit_nexthops(struct nexthop *pn) +inherit_nexthops(struct top_hash_entry *par) { - /* Proper nexthops (with defined GW) or dummy vlink nexthops (without iface) */ - return pn && (ipa_nonzero(pn->gw) || !pn->iface); + struct nexthop *pn = par->nhs; + /* no next-hop to inherit, or the parent is root */ + if (!pn) + return 0; + /* 16.1.1, there is at least one intervening router, can directly inherit */ + if (par->lsa_type == LSA_T_RT) + return 1; + /* + * Now, the parent is a LSA_T_NET, and cannot know whether this net is + * directly connected or not. We can only decide with the next-hop. + * Note: A next-hop to PtP iface may only have no gw. In this condition, the + * next-hop can also be inherited. + */ + return ipa_nonzero(pn->gw) || /* proper next-hops (with defined GW) */ + !pn->iface || /* dummy vlink next-hops (without iface) */ + !(pn->iface->flags & IF_MULTIACCESS); /* iface is PtP */ } static inline ip_addr @@ -1760,7 +1774,7 @@ calc_next_hop(struct ospf_area *oa, struct top_hash_entry *en, en->lsa.id, en->lsa.rt, en->lsa_type); /* Usually, we inherit parent nexthops */ - if (inherit_nexthops(pn)) + if (inherit_nexthops(par)) return pn; /* -- 2.39.2

1 0

RTBH (Remotely Triggered Black Hole) using Bird
by Mazur, Dariusz 19 Mar '24

19 Mar '24

Hello Bird Users, I am trying to implement RTBH (Remotely Triggered Black Hole) in below setup: 0.Simplified Topology: * ebgp fabric * inside fabric we use only IPv6, so we announce IPv4 blocks with IPv6 next hop (extended next hop) * tor --- leaf --- spine---3xstem(3xborder_leaf) --- border * tor announces 192.168.66.1/32 tagged with (65535,666) up to border 1.Border has static route: r04.border01.labkrk05.fab> show route for 23.0.0.255 23.0.0.255/32 blackhole [DISCARD_ROUTE_v4 2024-01-08] * (200) 2.Border learns 192.168.66.1/32. In import filter I change next hop to 23.0.0.255 to blackhole traffic to 192.168.66.1/32. I don’t see this change in “show route” but I see this in “show route all” Can you give me a tip how to change eBGP next hop in this scenario and resolve it recursively via static route? r04.border01.labkrk05.fab> show route for 192.168.66.1/32 Executing "/usr/sbin/birdc show route for 192.168.66.1/32" Table master4: 192.168.66.1/32 unicast [fc00:5:1:502::1__r01.stem01.la 09:24:07.174] * (100) [AS4290000010i] via fc00:5:1:502::1 on ae201 unicast [fc00:5:1:503::1__r02.stem01.la 09:24:07.174] (100) [AS4290000010i] via fc00:5:1:503::1 on ae202 unicast [fc00:5:1:504::1__r03.stem01.la 09:24:07.172] (100) [AS4290000010i] via fc00:5:1:504::1 on ae203 r04.border01.labkrk05.fab> show route for 192.168.66.1/32 all 192.168.66.1/32 unicast [fc00:5:1:502::1__r01.stem01.la 09:24:07.174] * (100) [AS4290000010i] via fc00:5:1:502::1 on ae201 Type: BGP univ BGP.origin: IGP BGP.as_path: 4290000004 4290000005 4290000008 4290000010 BGP.next_hop: 23.0.0.255 BGP.local_pref: 100 BGP.community: (65535,666) unicast [fc00:5:1:503::1__r02.stem01.la 09:24:07.174] (100) [AS4290000010i] via fc00:5:1:503::1 on ae202 Type: BGP univ BGP.origin: IGP BGP.as_path: 4290000004 4290000006 4290000008 4290000010 BGP.next_hop: 23.0.0.255 BGP.local_pref: 100 BGP.community: (65535,666) unicast [fc00:5:1:504::1__r03.stem01.la 09:24:07.172] (100) [AS4290000010i] via fc00:5:1:504::1 on ae203 Type: BGP univ BGP.origin: IGP BGP.as_path: 4290000004 4290000007 4290000008 4290000010 BGP.next_hop: 23.0.0.255 BGP.local_pref: 100 BGP.community: (65535,666) Regards, Dariusz

2 2

Fresh Install Bird 2.14
by Ilham Maulana 17 Mar '24

17 Mar '24

Hello, Is there any step by step tutorial how to downgrade from Bird 2.15 to Bird 2.14? or maybe fresh install Bird 2.14? I have tried these 3 command, and failed. $ ./configure $ make # make install Thank You. [1973a0d2-1aec-4f70-a81a-20c4946d1b2c]

3 4

[PATCH] BSD: macOS Support
by Zhang Maiyun 13 Mar '24

13 Mar '24

Dear all, This patch makes bird build and run on macOS with `sysconfig=bsd`. It is mainly modifying preprocessor directives. I have tested it on macOS 14.3.1 and it is able to establish BGP sessions and at least exchange IPv4 routes. Kind regards, Maiyun Zhang Signed-off-by: Zhang Maiyun <me(a)maiyun.me> --- sysdep/bsd/krt-sock.c | 6 ++++++ sysdep/bsd/sysio.h | 6 +++++- sysdep/unix/io.c | 3 +++ sysdep/unix/random.c | 2 +- 4 files changed, 15 insertions(+), 2 deletions(-) diff --git a/sysdep/bsd/krt-sock.c b/sysdep/bsd/krt-sock.c index d13e20a3..afb66cb3 100644 --- a/sysdep/bsd/krt-sock.c +++ b/sysdep/bsd/krt-sock.c @@ -635,6 +635,7 @@ krt_read_route(struct ks_msg *msg, struct krt_proto *p, int scan) krt_got_route_async(p, e, new, src); } +#ifndef __APPLE__ static void krt_read_ifannounce(struct ks_msg *msg) { @@ -661,6 +662,7 @@ krt_read_ifannounce(struct ks_msg *msg) DBG("KRT: IFANNOUNCE what: %d index %d name %s\n", ifam->ifan_what, ifam->ifan_index, ifam->ifan_name); } +#endif static void krt_read_ifinfo(struct ks_msg *msg, int scan) @@ -725,7 +727,9 @@ krt_read_ifinfo(struct ks_msg *msg, int scan) if (fl & IFF_UP) f.flags |= IF_ADMIN_UP; +#ifndef __APPLE__ if (ifm->ifm_data.ifi_link_state != LINK_STATE_DOWN) +#endif f.flags |= IF_LINK_UP; /* up or unknown */ if (fl & IFF_LOOPBACK) /* Loopback */ f.flags |= IF_MULTIACCESS | IF_LOOPBACK | IF_IGNORE; @@ -873,9 +877,11 @@ krt_read_msg(struct proto *p, struct ks_msg *msg, int scan) case RTM_CHANGE: krt_read_route(msg, (struct krt_proto *)p, scan); break; +#ifndef __APPLE__ case RTM_IFANNOUNCE: krt_read_ifannounce(msg); break; +#endif case RTM_IFINFO: krt_read_ifinfo(msg, scan); break; diff --git a/sysdep/bsd/sysio.h b/sysdep/bsd/sysio.h index b6b42b1e..85081c07 100644 --- a/sysdep/bsd/sysio.h +++ b/sysdep/bsd/sysio.h @@ -32,7 +32,7 @@ #endif -#ifdef __NetBSD__ +#if defined(__NetBSD__) || defined(__APPLE__) #ifndef IP_RECVTTL #define IP_RECVTTL 23 @@ -49,6 +49,10 @@ #define TCP_MD5SIG TCP_SIGNATURE_ENABLE #endif +#ifdef __APPLE__ +#define TCP_MD5SIG TCPOPT_SIGNATURE +#endif + #undef SA_LEN #define SA_LEN(x) (x).sa.sa_len diff --git a/sysdep/unix/io.c b/sysdep/unix/io.c index 9b499020..81e09888 100644 --- a/sysdep/unix/io.c +++ b/sysdep/unix/io.c @@ -12,6 +12,9 @@ #ifndef _GNU_SOURCE #define _GNU_SOURCE #endif +#ifdef __APPLE__ +#define __APPLE_USE_RFC_3542 +#endif #include <stdio.h> #include <stdlib.h> diff --git a/sysdep/unix/random.c b/sysdep/unix/random.c index 4e64e56b..7d68c482 100644 --- a/sysdep/unix/random.c +++ b/sysdep/unix/random.c @@ -16,7 +16,7 @@ #include "sysdep/config.h" #include "nest/bird.h" -#ifdef HAVE_GETRANDOM +#if defined(HAVE_GETRANDOM) || (defined(__APPLE__) && defined(HAVE_GETENTROPY)) #include <sys/random.h> #endif -- 2.44.0

5 5

show bfd sessions
by Alexander Zubkov 12 Mar '24

12 Mar '24

Hi all, I noticed in the new version 'show bfd sessions' was extended with 'all' option. But I also noticed that in case of 'show protocols', 'show ospf state|topology' this option comes before [name], but for 'show bfd sessions' it is the other way. I think it would be better to be consistent here and use 'all' keyword before [name] too. I also noticed some incompleteness of the "Remote control" documentation now. I.e. it lists: show protocols [all] When it is actually: show protocols [all] [<protocol>|"<pattern>"] Also "show route ... [options]" does not have clear description of what these options are. It seems there are ways to improve this part of the documentation. I can offer a hand to examine it in more details what else might be missing and maybe prepare patches. Regards, Alexander

2 1

BIRD 2.15
by Ondrej Filip 11 Mar '24

11 Mar '24

Dear BIRD users, we're releasing a new version 2.15. As usually, I am just a messenger, all credits go to my colleagues: Version 2.15 o BGP: Send hold timer o BGP: New options to specify required BGP capabilities o BFD: Improvements to 'show bfd sessions' command o RPKI: New 'local address' configuration option o Linux: Support for more route attributes, including TCP congestion control algorithm o Support for UDP logging o Static routes can have both nexthop and interface specified o Completion of command options in BIRD client o Many bugfixes and improvements Happy routing! Ondrej

6 9

[PATCH] OSPF: don't skip next-hop resolve for PtP link for v2 and v3 with IPv6
by Soha Jin 11 Mar '24

11 Mar '24

This is a hack for Linux kernel, who does not support device-only routes for IPv6 multipath. Signed-off-by: Soha Jin <soha(a)jin.sh> --- proto/ospf/rt.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/proto/ospf/rt.c b/proto/ospf/rt.c index efcd4e17..54372070 100644 --- a/proto/ospf/rt.c +++ b/proto/ospf/rt.c @@ -1796,13 +1796,6 @@ calc_next_hop(struct ospf_area *oa, struct top_hash_entry *en, if (ifa->type == OSPF_IT_VLINK) return new_nexthop(p, IPA_NONE, NULL, 0); - /* - * The type of the ospf_iface is PtP and the iface is a physical PtP link, - * so we can simply use the iface, and skip further resolving. - */ - if (ifa->type == OSPF_IT_PTP && !(ifa->iface->flags & IF_MULTIACCESS)) - return new_nexthop(p, IPA_NONE, ifa->iface, ifa->ecmp_weight); - if (ospf_is_v2(p) || ospf_is_ip6(p)) { /* @@ -1819,6 +1812,15 @@ calc_next_hop(struct ospf_area *oa, struct top_hash_entry *en, } else { + /* + * The type of the ospf_iface is PtP and the iface is a physical PtP link, + * so we can simply use the iface, and skip further resolving. + * HACK: Linux kernel doesn't support device-only routes for IPv6 + * multipath, that's why this if-branch is placed here rather than above. + */ + if (ifa->type == OSPF_IT_PTP && !(ifa->iface->flags & IF_MULTIACCESS)) + return new_nexthop(p, IPA_NONE, ifa->iface, ifa->ecmp_weight); + /* * Next-hop is taken from lladdr field of Link-LSA, based on Neighbor * Iface ID (nif) field in our Router-LSA, which is just nbr->iface_id. -- 2.39.2

1 0

Strict Bind usability
by Sebastian Hahn 11 Mar '24

11 Mar '24

Hi list, I've been using strict bind for bgp, but there might be a lack in my understanding or I have a proposal for a new feature. Strict bind seems to be a bit more restrictive than I'd like (and than I think it is necessary): I would like to use dynamic bgp (using a range for neighbour) with auto-configured LL IPv6 adresses. This doesn't work, of course, if I need to statically configure the source address, which I am forced to with the strict bind option. I am wondering, is this restriction really needed? There is only one IP address (the LL one) on the interface in question (and the interface is specified in config). I think this should mean that bird could just pick that IP address and use it for both source as well as to bind to. If that is true, could a "source address auto" option or so be added to allow such a configuration? In addition, it would be great if a strict bind option could be added for the babel protocol. Also let me say Thanks for bird, it's a pleasure to use! Cheers Sebastian

2 3

Bird2 on Rocky9.3
by L Cruzero 08 Mar '24

08 Mar '24

Hi, I'm currently running bird2 on rocky8.6, though I need to do some testing on rocky9. In the near future, will there be a release made available of Bird2 that can run Rocky9 ? Rocky Linux release 9.3 5.14.0-362.8.1.el9_3.x86_64 Best regards, LC

3 3