- Bird-users - Mailing Lists

2.15, ospf is broken
by Dmitry Melekhov 26 Mar '24

26 Mar '24

Hello! Just upgraded and got: Mar 19 08:07:46 hohr-vpn-1 bird[1523831]: Started Mar 19 08:07:54 hohr-vpn-1 bird[1523831]: MyOSPF: Unexpected case in next hop calculation Mar 19 08:07:54 hohr-vpn-1 bird[1523831]: MyOSPF: Cannot find next hop for LSA (Type: 2002, Id: 192.168.222.221, Rt: 192.168.22.178) Mar 19 08:07:54 hohr-vpn-1 bird[1523831]: MyOSPF: Unexpected case in next hop calculation etc. on all hosts I upgraded. All of them is alma 9. Downgrade to 2.14 solved problem. Is there fix for this or workaround? Thank you!

6 12

Export shows new filters after "configure soft" before any update
by Inrin 25 Mar '24

25 Mar '24

Hiho, I noticed that `birdc show route export <proto>` after a `configure soft` shows the state with the new export filter, even if no update ocurred. The PCAP also shows, as long as no external update comes in, no updates are send out on the wire. Using export tables makes it possible to see the "real" state. For example, until a new external update or a `reload out` it shows the "old filter" state. For import filters it's different. It shows the "old" state until an external update comes in or `reload in` is used. With or without import tables or `keep filtered on`. Since the help states: configure soft ["<file>"] [timeout [<sec>]] Reload configuration and ignore changes in filters it should be like for the import case and show the "old" state until an update comes in or `reload out` is used. Finally to my question: Is this behaviour intentional? Best would be to even make it possible to ignore the new filters until manual reload, but thats probably a bigger change ;) For testing I used 2 exabgp clients and BIRD as intermediate. Configs are attached below. The large community had been just increased to trigger changes. Thanks, Inrin ================================================================= BIRD config ----------------------------------------------------------------- debug protocols all; debug channels all; log syslog all; protocol device { } protocol direct { disabled; ipv4; ipv6; } protocol kernel { disabled; ipv4; } protocol kernel { disabled; ipv6; } template bgp clients { local as 64500; ipv4 { #import table on; #export table on; #import keep filtered on; import none; export none; }; ipv6 { import none; export none; }; } protocol bgp sender4 from clients { neighbor 198.51.100.3 as 64503; ipv4 { import filter { accept; }; export none; }; } protocol bgp receiver4 from clients { neighbor 198.51.100.4 as 64504; ipv4 { import none; export filter { bgp_large_community.add((7,7,7)); accept; }; }; } ----------------------------------------------------------------- Exabgp config sender ----------------------------------------------------------------- template { neighbor rsipv4 { local-address 198.51.100.3; local-as 64503; peer-as 64500; family { ipv4 unicast; } announce { ipv4 { unicast 192.0.2.0/24 next-hop self large-community [64503:4444:0]; } } } } neighbor 198.51.100.251 { inherit rsipv4; } ----------------------------------------------------------------- Exabgp config sender ----------------------------------------------------------------- template { neighbor rsipv4 { local-as 64504; peer-as 64500; local-address 198.51.100.4; family { ipv4 unicast; } } } neighbor 198.51.100.251 { inherit rsipv4; } -----------------------------------------------------------------

2 2

[2.14] show route not showing all tables (rpki)
by Elmar K. Bins 22 Mar '24

22 Mar '24

Hello folks, we're running 2.14 on FreeBSD 13.3 (out of the current bird2-2.14 pkg). A long time ago we set up RPKI feeds that put their routes into tables r4 and r6. I've just added a second RPKI source that feeds into table r44 and r66. "show route count" does NOT include these tables: --------------- bird> show route count 25524 of 25524 routes for 14191 networks in table master4 2775 of 2775 routes for 1808 networks in table master6 421637 of 421637 routes for 421637 networks in table r4 101571 of 101571 routes for 101571 networks in table r6 Total: 551507 of 551507 routes for 539207 networks in 4 tables bird> show route table r44 count 401463 of 401463 routes for 401463 networks in table r44 bird> shor route table r66 count No such command. Press `?' for help. --------------- (yeeees, birdc has been fully restarted, just in case something was hanging). Any idea why? Is this intentional, an oversight, or a bug? I'd like all my tables to show please. Elmar.

3 5

BIRD 2.15.1
by Ondrej Filip 22 Mar '24

22 Mar '24

Dear BIRD users, we're releasing a new version 2.15.1. As the number suggests, it is a bug fixing release: Version 2.15.1 o OSPF: Fix regression in handling PtP links o RPKI: Handle connection resets properly o Static: Reject invalid combination of options o Fix builds with limited set of protocols Happy routing! Ondrej

1 0

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