- Bird-users - Mailing Lists

More BFD issues
by Nico Schottelius 11 Sep '24

11 Sep '24

Good morning bird'ers, we have a bit of a strange error in regards to bfd, on two sessions we get continuously the following error message: server142: -------------------------------------------------------------------------------- 2024-08-10 09:50:25.533 <ERR> bfd1: Socket error: Destination address required 2024-08-10 09:50:25.738 <RMT> bfd1: Bad packet from 2a0a:e5c0:10:1:fa5e:3cff:fe2d:eafc - wrong TTL (254) 2024-08-10 09:50:25.840 <RMT> bfd1: Bad packet from 2a0a:e5c0:10:1:fa5e:3cff:fe2d:eb04 - wrong TTL (254) 2024-08-10 09:50:26.287 <ERR> bfd1: Socket error: Destination address required 2024-08-10 09:50:26.512 <RMT> bfd1: Bad packet from 2a0a:e5c0:10:1:fa5e:3cff:fe2d:eafc - wrong TTL (254) 2024-08-10 09:50:26.639 <RMT> bfd1: Bad packet from 2a0a:e5c0:10:1:fa5e:3cff:fe2d:eb04 - wrong TTL (254) -------------------------------------------------------------------------------- The two devices with the incorrect TTL are openwrt devices. All routers are running BIRD version 2.15.1. Now things are getting even more interesting, but let me first show the rough topology: -------------------------------------------------------------------------------- s141 ------|------s123 (alpine linux) | (alpine linux) s142 -- ibgp ---s122 (alpine linux) | (alpine linux) | vigir28 ----------- vigir29 (openwrt) (openwrt) All connections are layer2, direct, vigirs only connect to servers, not to each other. -------------------------------------------------------------------------------- So now comes the interesting facts: - s141 has bfd up with s122, s123, s142, vigir28 - s142 has bfd up with s122, s123, s141, no vigir - s122 has bfd up with s123, s141, s142, no vigir - s123 has bfd up with s122, s141, s142, vigir29 - vigir28 has bfd s141 - vigir29 has bfd s123 Each and every device can ping the other one, so I am strangely confused as to what is going on. Additionally, probably correctly, the bgp sessions fail to initiate and/or are down: -------------------------------------------------------------------------------- s122: ibgp_s123 BGP --- up 2024-07-10 Established ibgp_s141 BGP --- up 2024-08-04 Established ibgp_s142 BGP --- up 2024-08-08 Established ibgp_vigir28 BGP --- start 10:17:53.412 Idle BGP Error: Hold timer expired ibgp_vigir29 BGP --- start 10:23:57.781 Idle BGP Error: Hold timer expired s123: (bfd & bgp fluctuate for vigir28) ibgp_s122 BGP --- up 2024-07-10 Established ibgp_s141 BGP --- up 2024-08-04 Established ibgp_s142 BGP --- up 2024-08-08 Established ibgp_vigir28 BGP --- up 10:21:16.449 Established ibgp_vigir29 BGP --- up 2024-08-08 Established s141: ibgp_s122 BGP --- up 2024-08-04 Established ibgp_s123 BGP --- up 2024-08-04 Established ibgp_s142 BGP --- up 2024-08-08 Established ibgp_vigir28 BGP --- start 10:20:42.819 OpenSent Socket: Connection closed ibgp_vigir29 BGP --- start 10:25:10.338 OpenSent BGP Error: Hold timer expired s142: ibgp_s122 BGP --- up 2024-08-08 Established ibgp_s123 BGP --- up 2024-08-08 Established ibgp_s141 BGP --- up 2024-08-08 Established ibgp_vigir28 BGP --- start 10:27:20.079 OpenSent BGP Error: Hold timer expired ibgp_vigir29 BGP --- start 10:26:21.088 OpenSent BGP Error: Hold timer expired vigir28: bgp1 BGP --- start 10:26:00.453 OpenConfirm Received: Hold timer expired bgp2 BGP --- up 10:21:30.592 Established bgp3 BGP --- start 10:25:09.416 OpenConfirm BGP Error: Hold timer expired bgp4 BGP --- start 10:25:07.000 OpenConfirm Socket: Host is unreachable vigir29: bgp1 BGP --- start 10:24:21.241 OpenConfirm Socket: Host is unreachable bgp2 BGP --- up 2024-08-08 Established bgp3 BGP --- start 10:25:15.541 OpenConfirm Socket: Host is unreachable bgp4 BGP --- start 10:28:48.584 Idle Received: Hold timer expired -------------------------------------------------------------------------------- Some configuration samples: -------------------------------------------------------------------------------- vigir28: log syslog all; router id 0.0.1.28; protocol device { } protocol bfd { } # Just announce, no kernel interaction protocol static static6 { ipv6; route 2a0a:e5c0:10:10::/96 unreachable; } # for getting iBGP routes protocol babel { interface "br-lan", "wan" { type wired; authentication mac; password "..."; }; ipv6 { export where (source = RTS_DEVICE) || (source = RTS_BABEL); }; } protocol kernel kernel_v6 { ipv6 { export where source ~ [ RTS_BABEL ]; }; } protocol bgp { local as 213081; neighbor 2a0a:e5c0:10:1::122 as 213081; direct; bfd on; ipv6 { import none; export where source ~ [ RTS_STATIC ]; }; } (repeat bgp session for each ibgp peer) -------------------------------------------------------------------------------- And s141: -------------------------------------------------------------------------------- log stderr all; protocol device { } # Using BFD virtually everywhere, enable it globally protocol bfd { } protocol babel { interface "eth*" { type wired; authentication mac; password "..."; }; # This matches the default of babeld: redistribute all addresses # configured on local interfaces, plus re-distribute all routes received # from other babel peers. ipv4 { export where (source = RTS_DEVICE) || (source = RTS_BABEL); }; ipv6 { export where (source = RTS_DEVICE) || (source = RTS_BABEL); }; } protocol bgp ibgp_vigir28 { local as myas; neighbor 2a0a:e5c0:10:1:fa5e:3cff:fe2d:eafc as myas; direct; bfd on; ipv6 { import all; export filter static_and_bgp; gateway recursive; }; ipv4 { import all; export filter static_and_bgp; gateway recursive; extended next hop on; }; } (repeat bgp session for each ibgp peer) -------------------------------------------------------------------------------- s122 + s123 are virtually identical, as well as s141+s142, their configurations are generated. Any help in this direction would be appreciated. My next try will probably be to disable bfd on all sessions to see if the bgp sessions then stay up. Best regards, Nico -- Sustainable and modern Infrastructures by ungleich.ch

2 1

<WARN> xxxx.ipv4: Automatic RPKI reload not active for import
by ushiroz＠ate-mahoroba.jp 11 Sep '24

11 Sep '24

Hi The warning log is outputting something like “<WARN> xxxx.ipv4: Automatic RPKI reload not active for import”. I am using roa_check() and rpki_reload switch is set to default (on). The help page on “rpki reload switch” says that the BGP channel requires import table for automatic reload, so I am aware that if I add the definition of “import table on”, this warning will no longer appear. However, in the help section on “import table switch Note that currently the import table breaks routes with recursive nexthops (e.g. ones from IBGP, see gateway recursive (p. 47)), they are not properly updated after next hop change. and we have not been able to fully determine the contents of this message. Is there any way around this warning other than “import table switch”?

2 5

Issues with parsing config for IPv6 link-local BGP sessions
by Sander P 10 Sep '24

10 Sep '24

Hi, I'm on Bird 2.0.8 The background is that I'm trying to configure link local BGP sessions towards Juniper switches. I'm trying to follow the the documentation that indicates that it should be possible to define a interface. https://bird.network.cz/?get_doc&v=20&f=bird-6.html#ss6.4 interface *string* Define interface we should use for link-local BGP IPv6 sessions. Interface can also be specified as a part of neighbor address (e.g., neighbor fe80::1234%eth0 as 65000;). The option may also be used for non link-local sessions when it is necessary to explicitly specify an interface, but only for direct (not multihop) sessions Here is my config: template bgp ebgp_client_v6 { local as system_as_number; ipv6 { import all; export filter export_bgp; }; bfd graceful; connect delay time 1; connect retry time 5; error wait time 1,5; error forget time 10; }; protocol bgp auto_disc_2 from ebgp_client_v6 { interface "enp67s0f0np0"; }; and from my understanding it should be enough with just that. But I do get the error: /etc/bird/peers.conf:53:1 Neighbor must be configured I've also tried to add "neighbor as asn_of_neighbor;" To the config with the same results. Any help would be much appreciated! Br, Sander

2 5

Bird is not adding routes into kernel anymore
by Nico Schottelius 09 Sep '24

09 Sep '24

Good morning, yesterday we upgrade in a lab from 2.13.1 to 2.14 and (great idea) at the same time modified some configuration bits. Since then bird does not seem to write routes into the kernel anymore, even though relevant bits seem to be in the configuration. The config (in parts) looks like this: -------------------------------------------------------------------------------- protocol device { } protocol kernel kernel_v4 { ipv4 { export all; }; } protocol kernel kernel_v6 { ipv6 { export all; }; } ... protocol static { ipv6; route 2a0a:5480::/48 unreachable; # LAN route 2a0a:5480:1::/48 unreachable; # k8s route 2a0a:5480:3::/48 unreachable; # router specific route 2a0a:5480:0:c001::/96 via 2a0a:5480::20d:b9ff:fe5a:816c; # jool } protocol static { ipv4; route 185.203.113.0/24 unreachable; } protocol bfd { # openvpn interface "tun*" { interval 500 ms; idle tx interval 2 s; }; # transfer interface "eth0" { interval 500 ms; idle tx interval 2 s; }; } -------------------------------------------------------------------------------- Plus various BGP instances at the end. If I check birdc, things seems to be good: -------------------------------------------------------------------------------- bird> show route Table master4: 185.203.114.0/23 unicast [server121_v6_v4 22:24:45.009] * (100) [AS213081i] via 2a0a:e5c0:32:4::1 on tun1 185.203.113.2/32 unicast [r2ge_v6_v4 22:35:40.181 from 2a0a:5480::2] * (100/10) [i] via fe80::20d:b9ff:fe46:3bd4 on eth0 185.203.113.0/24 unreachable [static2 22:12:35.949] * (200) unicast [r2ge_v6_v4 22:35:40.181 from 2a0a:5480::2] (100/10) [i] via fe80::20d:b9ff:fe46:3bd4 on eth0 148.222.248.1/32 unicast [server121_v6_v4 09:39:56.279] * (100) [AS209898i] via 2a0a:e5c0:32:4::1 on tun1 unicast [r2ge_v6_v4 09:39:57.048 from 2a0a:5480::2] (100/20) [AS209898i] via fe80::20d:b9ff:fe46:3bd4 on eth0 ... bird> show protocols Name Proto Table State Since Info device1 Device --- up 22:12:35.949 kernel_v4 Kernel master4 up 22:12:35.949 kernel_v6 Kernel master6 up 22:12:35.949 static1 Static master6 up 22:12:35.949 static2 Static master4 up 22:12:35.949 bfd1 BFD --- up 22:12:35.949 r2ge_v6_v4 BGP --- up 22:35:40.175 Established genauso_v6 BGP --- start 22:12:35.949 Passive server121_v6_v4 BGP --- up 22:24:15.183 Established radv1 RAdv master6 up 22:12:35.949 ospf6 OSPF master6 up 22:12:35.949 Running fiberstream Static master4 up 22:12:35.949 direct1 Direct --- up 22:12:35.949 genauso_1 BGP --- up 22:12:36.974 Established genauso_2 BGP --- up 22:12:36.979 Established genauso_3 BGP --- up 22:12:36.985 Established genauso_4 BGP --- start 22:14:01.848 Idle bird> bird> show protocols all kernel_v4 Name Proto Table State Since Info kernel_v4 Kernel master4 up 22:12:35.949 Channel ipv4 State: UP Table: master4 Preference: 10 Input filter: ACCEPT Output filter: ACCEPT Routes: 0 imported, 23 exported, 0 preferred Route change stats: received rejected filtered ignored accepted Import updates: 0 0 0 0 0 Import withdraws: 0 0 --- 0 0 Export updates: 265 0 0 --- 265 Export withdraws: 113 --- --- --- 113 bird> show protocols all kernel_v6 Name Proto Table State Since Info kernel_v6 Kernel master6 up 22:12:35.949 Channel ipv6 State: UP Table: master6 Preference: 10 Input filter: ACCEPT Output filter: ACCEPT Routes: 0 imported, 83 exported, 0 preferred Route change stats: received rejected filtered ignored accepted Import updates: 0 0 0 0 0 Import withdraws: 0 0 --- 0 0 Export updates: 2797 0 0 --- 2797 Export withdraws: 431 --- --- --- 431 bird> -------------------------------------------------------------------------------- However checking the route table in the kernel, there is not a single route injected by bird: -------------------------------------------------------------------------------- # ip r default via 192.168.1.254 dev eth1 proto dhcp src 192.168.1.159 metric 1003 192.168.1.0/24 dev eth1 proto dhcp scope link src 192.168.1.159 metric 1003 194.5.220.0/24 via 192.168.1.254 dev eth1 / # ip -6 r 2a0a:5480::/64 dev eth0 proto kernel metric 256 pref medium 2a0a:5480:0:a::b dev lo proto kernel metric 256 pref medium 2a0a:5480:3:1::/64 dev k8sbridge proto kernel metric 256 pref medium 2a0a:5480:3:3::3 dev lo proto kernel metric 256 pref medium 2a0a:5480:3:4::/64 dev tun0 proto kernel metric 256 pref medium 2a0a:e5c0:32:4::/64 dev tun1 proto kernel metric 256 pref medium fe80::/64 dev eth0 proto kernel metric 256 pref medium fe80::/64 dev eth1 proto kernel metric 256 pref medium fe80::/64 dev k8sbridge proto kernel metric 256 pref medium fe80::/64 dev veth99f0c958 proto kernel metric 256 pref medium fe80::/64 dev vethe20cee78 proto kernel metric 256 pref medium fe80::/64 dev veth8f504fac proto kernel metric 256 pref medium fe80::/64 dev vethc03bfec4 proto kernel metric 256 pref medium fe80::/64 dev veth046f7cf0 proto kernel metric 256 pref medium fe80::/64 dev veth434f4ff5 proto kernel metric 256 pref medium fe80::/64 dev vethd021bdfa proto kernel metric 256 pref medium fe80::/64 dev veth935a701b proto kernel metric 256 pref medium fe80::/64 dev veth473f9ed3 proto kernel metric 256 pref medium fe80::/64 dev veth931ba96a proto kernel metric 256 pref medium fe80::/64 dev vethdbaa705e proto kernel metric 256 pref medium fe80::/64 dev tun1 proto kernel metric 256 pref medium fe80::/64 dev tun0 proto kernel metric 256 pref medium / # -------------------------------------------------------------------------------- I think I saw some routes shortly being installed and then vanish within a second again, but I cannot even take a screenshot of it - so it might be that bird writes the routes and that they instantly disappear. I can reproduce the missing routes on 2 lab machines and I was even able to downgrade to 2.13.1 and reproduce it there, too. I have attached the log output of bird below. Does anyone have an idea on what might be going wrong? Best regards, Nico -------------------------------------------------------------------------------- 2023-12-25 22:12:35.949 <INFO> Started 2023-12-25 22:12:36.210 <WARN> Next hop address 2a0a:5480:2:4::2 resolvable through recursive route for ::/0 2023-12-25 22:12:36.216 <WARN> Next hop address 2a0a:e5c0:31:4::1 resolvable through recursive route for 2a0a:e5c0:31:4::/64 2023-12-25 22:12:36.216 <WARN> Next hop address 2a0a:5480:2:4::2 resolvable through recursive route for 2a0a:5480:2:4::/64 2023-12-25 22:12:36.218 <WARN> Next hop address 2a0a:5480:2:4::2 resolvable through recursive route for 2a0a:5480:2:4::/64 2023-12-25 22:12:36.218 <WARN> Next hop address 2a0a:e5c0:31:4::1 resolvable through recursive route for 2a0a:e5c0:31:4::/64 2023-12-25 22:12:36.909 <WARN> Next hop address 2a0a:e5c0:31:4::1 resolvable through recursive route for 2a0a:e5c0:31:4::/64 2023-12-25 22:12:36.909 <WARN> Next hop address 2a0a:5480:2:4::2 resolvable through recursive route for 2a0a:5480:2:4::/64 2023-12-25 22:12:36.909 <WARN> Next hop address 2a0a:5480:2:4::2 resolvable through recursive route for 2a0a:5480:2:4::/64 2023-12-25 22:12:36.909 <WARN> Next hop address 2a0a:e5c0:31:4::1 resolvable through recursive route for 2a0a:e5c0:31:4::/64 2023-12-25 22:12:38.723 <WARN> Next hop address 2a0a:e5c0:31:4::1 resolvable through recursive route for 2a0a:e5c0:31:4::/64 2023-12-25 22:12:38.723 <WARN> Next hop address 2a0a:5480:2:4::2 resolvable through recursive route for 2a0a:5480:2:4::/64 2023-12-25 22:12:38.723 <WARN> Next hop address 2a0a:5480:2:4::2 resolvable through recursive route for 2a0a:5480:2:4::/64 2023-12-25 22:12:38.723 <WARN> Next hop address 2a0a:e5c0:31:4::1 resolvable through recursive route for 2a0a:e5c0:31:4::/64 2023-12-25 22:16:45.534 <WARN> Netlink: No such device 2023-12-25 22:20:13.582 <WARN> Netlink: No such device 2023-12-25 22:23:11.536 <RMT> server121_v6_v4: Received: Administrative shutdown 2023-12-25 22:28:13.570 <WARN> Netlink: No such device 2023-12-25 22:29:40.051 <WARN> Next hop address 2a0a:e5c0:31:4::1 resolvable through recursive route for 2a0a:e5c0:31:4::/64 2023-12-25 22:29:40.051 <WARN> Next hop address 2a0a:5480:2:4::2 resolvable through recursive route for 2a0a:5480:2:4::/64 2023-12-25 22:29:40.051 <WARN> Next hop address 2a0a:5480:2:4::2 resolvable through recursive route for 2a0a:5480:2:4::/64 2023-12-25 22:29:40.051 <WARN> Next hop address 2a0a:e5c0:31:4::1 resolvable through recursive route for 2a0a:e5c0:31:4::/64 2023-12-25 22:29:40.059 <WARN> Next hop address 2a0a:e5c0:31:4::1 resolvable through recursive route for 2a0a:e5c0:31:4::/64 2023-12-25 22:29:40.059 <WARN> Next hop address 2a0a:5480:2:4::2 resolvable through recursive route for 2a0a:5480:2:4::/64 2023-12-25 22:29:40.059 <WARN> Next hop address 2a0a:5480:2:4::2 resolvable through recursive route for 2a0a:5480:2:4::/64 2023-12-25 22:29:40.059 <WARN> Next hop address 2a0a:e5c0:31:4::1 resolvable through recursive route for 2a0a:e5c0:31:4::/64 2023-12-25 22:29:40.091 <WARN> Next hop address 2a0a:e5c0:31:4::1 resolvable through recursive route for 2a0a:e5c0:31:4::/64 2023-12-25 22:29:40.091 <WARN> Next hop address 2a0a:5480:2:4::2 resolvable through recursive route for 2a0a:5480:2:4::/64 2023-12-25 22:29:40.091 <WARN> Next hop address 2a0a:5480:2:4::2 resolvable through recursive route for 2a0a:5480:2:4::/64 2023-12-25 22:29:40.091 <WARN> Next hop address 2a0a:e5c0:31:4::1 resolvable through recursive route for 2a0a:e5c0:31:4::/64 2023-12-25 22:30:02.584 <RMT> r2ge_v6_v4: Received: Administrative shutdown 2023-12-25 22:34:33.277 <WARN> Netlink: No such device 2023-12-25 22:49:44.311 <WARN> Netlink: No such device 2023-12-25 22:50:35.660 <WARN> Netlink: No such device 2023-12-25 22:50:43.548 <WARN> Netlink: No such device 2023-12-25 23:08:38.133 <WARN> Netlink: No such device 2023-12-25 23:28:39.044 <WARN> Netlink: No such device 2023-12-25 23:53:43.584 <WARN> Netlink: No such device 2023-12-26 00:02:43.576 <WARN> Netlink: No such device 2023-12-26 00:09:43.593 <WARN> Netlink: No such device 2023-12-26 00:17:44.840 <WARN> Netlink: No such device 2023-12-26 00:19:44.792 <WARN> Netlink: No such device 2023-12-26 00:24:48.079 <WARN> Netlink: No such device 2023-12-26 00:52:52.080 <WARN> Netlink: No such device 2023-12-26 01:04:44.532 <WARN> Netlink: No such device 2023-12-26 01:32:43.574 <WARN> Netlink: No such device 2023-12-26 02:17:43.583 <WARN> Netlink: No such device 2023-12-26 02:43:44.123 <WARN> Netlink: No such device 2023-12-26 03:07:06.367 <WARN> Netlink: No such device 2023-12-26 03:08:53.050 <WARN> Netlink: No such device 2023-12-26 03:39:10.264 <WARN> Netlink: No such device 2023-12-26 04:03:13.540 <WARN> Netlink: No such device 2023-12-26 04:03:43.591 <WARN> Netlink: No such device 2023-12-26 04:07:13.660 <WARN> Netlink: No such device 2023-12-26 04:22:44.732 <WARN> Netlink: No such device 2023-12-26 04:27:15.276 <WARN> Netlink: No such device 2023-12-26 04:39:43.578 <WARN> Netlink: No such device 2023-12-26 04:41:43.598 <WARN> Netlink: No such device 2023-12-26 05:09:18.230 <WARN> Netlink: No such device 2023-12-26 06:10:45.058 <WARN> Netlink: No such device 2023-12-26 06:15:27.087 <WARN> Netlink: No such device 2023-12-26 06:45:32.092 <WARN> Netlink: No such device 2023-12-26 06:55:33.326 <WARN> Netlink: No such device 2023-12-26 07:05:43.542 <WARN> Netlink: No such device 2023-12-26 07:17:35.427 <WARN> Netlink: No such device 2023-12-26 07:29:35.980 <WARN> Netlink: No such device 2023-12-26 08:01:39.077 <WARN> Netlink: No such device 2023-12-26 09:01:44.615 <WARN> Netlink: No such device 2023-12-26 09:02:43.566 <WARN> Netlink: No such device 2023-12-26 09:17:47.696 <WARN> Netlink: No such device 2023-12-26 09:23:48.668 <WARN> Netlink: No such device 2023-12-26 09:27:49.466 <WARN> Netlink: No such device 2023-12-26 09:29:43.564 <WARN> Netlink: No such device 2023-12-26 09:39:52.004 <WARN> Netlink: No such device 2023-12-26 09:44:58.208 <WARN> Netlink: No such device 2023-12-26 09:45:43.545 <WARN> Netlink: No such device 2023-12-26 09:55:53.271 <WARN> Netlink: No such device 2023-12-26 10:09:53.189 <WARN> Netlink: No such device -------------------------------------------------------------------------------- -- Sustainable and modern Infrastructures by ungleich.ch

3 4

Route filtering by route distinguisher
by Jon Langemak 29 Aug '24

29 Aug '24

Hi folks - I swear I’ve done this before but I can’t recall the syntax to filter routes based on the RD. I’m able to do it by RT quite easily by comparing to the bgp_ext_community but can’t figure out the comparison value for RDs. Thanks in advance!

2 3

[PATCH] configure.ac: properly evaluate ac_test_CFLAGS
by Fabrice Fontaine 27 Aug '24

27 Aug '24

Since autoconf 2.69 and https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=76754e04fce5f6a77… ac_test_CFLAGS is set to ${CFLAGS+y} instead of ${CFLAGS+set}. Just test that ac_test_CFLAGS is not empty, to support both cases. Signed-off-by: Fabrice Fontaine <fontaine.fabrice(a)gmail.com> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout(a)mind.be> --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 64181d29..b4b3fcfb 100644 --- a/configure.ac +++ b/configure.ac @@ -114,7 +114,7 @@ AC_SEARCH_LIBS([clock_gettime], [rt posix4], AC_CANONICAL_HOST # Store this value because ac_test_CFLAGS is overwritten by AC_PROG_CC -if test "$ac_test_CFLAGS" != set ; then +if ! test "$ac_test_CFLAGS" ; then bird_cflags_default=yes fi -- 2.33.0

2 1

Can't create timers longer than ~71 minutes
by Felix Friedlander 27 Aug '24

27 Aug '24

I encountered this issue when setting up the mrt protocol to periodically dump routing tables. Despite specifying "period 28800", which should log every 28,800 seconds = 8 hours, dumps were being saved every 50-ish minutes. It appears this is because timers (defined in lib/timer.h) currently store their interval ("recurrent") in microseconds as a uint - on most platforms, a 32-bit integer. Naturally, 28,800,000,000 µs taken mod 2^32 gives 3,030,196,224 µs, or ~50.5 minutes. As far as I can tell, this means bird's timers (on 32-bit and LP64 platforms) can't wait any longer than 2^32 µs, or ~71.6 minutes. I imagine for many uses this is fine, but for scheduling periodic events, it's not ideal - exporting or syncing some data a handful of times a day (or less!) seems like a sensible thing to want to do. Increasing this to 64 bits seems easy enough - does someone know otherwise? Or have a better idea? Thanks, - Felix

2 1

babel RTT metric false samples
by Stephanie Wilde-Hobbs 14 Aug '24

14 Aug '24

Hi, The babel RTT metric measurements provided by bird appears suspect for my setup. The metric through a tunnel with a latency of about 5ms is shown in babel as 150+ms. Can others replicate this issue? (should be easy to check for other babel users since RTT measurement is on by default in recent versions) First I suspected a problem with the tunnel, but I compared bird's babel RTT measurement against a long-running ping for the same time period and got ~160ms measured by bird's babel implementation, and 4.6ms with a 28ms maximum latency reported by pings in the same wireguard tunnel. Other machines across my network also report similarly inflated RTT metrics for all non-wired links. Debug logs show many RTT samples with approximately correct timestamps (4-6ms) then the occasional IHU with 800-1200ms calculated instead. Calculating the RTT metric by hand using babel packet logs shows that the calculations are correct. By correlating two packet dumps (the machines have <1ms NTP timekeeping) I can also see that the packets for which high RTT is calculated have similar transit times through the tunnel as other packets. Hence, I suspect the accuracy of the packet timestamps recorded by bird. Is the current packet timestamping system giving correct timestamps if the packet arrives while babel is processing another event? I can provide packet captures for anyone interested in debugging further. Thanks, Stephanie.

5 5

Debugging down BFD sessions - unknown session id
by Nico Schottelius 06 Aug '24

06 Aug '24

Good morning, we have one server on which all bfd sessions are down, however the associated BGP protocols are actually up: bird> show bfd sessions bfd1: IP address Interface State Since Interval Timeout 2a0a:e5c0:10:1::122 eth0 Down 11:49:53.211 2.000 0.000 2a0a:e5c0:31:12::1 oserver120 Down 10:54:30.465 1.000 0.000 2a0a:e5c0:10:1::123 eth0 Down 11:59:53.890 2.000 0.000 bfd2: IP address Interface State Since Interval Timeout bird> bird> show protocols outgoing_server120 Name Proto Table State Since Info outgoing_server120 BGP --- up 10:54:35.058 Established bird> bird> show protocols ibgp_server122 Name Proto Table State Since Info ibgp_server122 BGP --- up 11:54:09.411 Established bird> show protocols ibgp_server123 Name Proto Table State Since Info ibgp_server123 BGP --- up 11:59:55.306 Established bird> The log of bird says: 2024-06-18 12:18:30.095 <RMT> bfd2: Bad packet from 2a0a:e5c0:10:1::123 - unknown session id (4057542731) 2024-06-18 12:18:30.288 <RMT> bfd2: Bad packet from 2a0a:e5c0:31:12::1 - unknown session id (1148668725) 2024-06-18 12:18:30.434 <RMT> bfd2: Bad packet from 2a0a:e5c0:10:1::122 - unknown session id (635122417) 2024-06-18 12:18:30.912 <RMT> bfd2: Bad packet from 2a0a:e5c0:10:1::123 - unknown session id (4057542731) 2024-06-18 12:18:31.058 <RMT> bfd2: Bad packet from 2a0a:e5c0:31:12::1 - unknown session id (1148668725) 2024-06-18 12:18:31.230 <RMT> bfd2: Bad packet from 2a0a:e5c0:10:1::122 - unknown session id (635122417) It seems like declaring 2 bfd sections is causing this issue: -------------------------------------------------------------------------------- protocol bfd { interface "o*" { interval 500 ms; idle tx interval 2 s; }; interface "i*" { interval 500 ms; idle tx interval 2 s; }; } protocol bfd { # openvpn interface "tun*" { interval 500 ms; idle tx interval 2 s; }; # transfer interface "eth0" { interval 500 ms; idle tx interval 2 s; }; } -------------------------------------------------------------------------------- Changing the bfd definition to: -------------------------------------------------------------------------------- protocol bfd { } -------------------------------------------------------------------------------- Changes the status to all sessions are up: -------------------------------------------------------------------------------- bird> show bfd sessions bfd1: IP address Interface State Since Interval Timeout 2a0a:e5c0:10:1::122 eth0 Up 12:22:52.027 0.100 0.500 2a0a:e5c0:31:12::1 oserver120 Up 12:22:52.445 0.100 0.500 2a0a:e5c0:10:1::123 eth0 Up 12:22:51.658 0.100 0.500 bird> -------------------------------------------------------------------------------- So I wonder ... is this a) a bug b) working as expected? If it is working as expected, should we add a note in the documentation saying multiple bfd instances might lead to this state / error? Best regards, Nico -- Sustainable and modern Infrastructures by ungleich.ch

2 1

Best practice for route preference
by Nico Schottelius 06 Aug '24

06 Aug '24

Good morning, you might remember my confusion about non-exported routes some threads away [0] and while not completely bird specific, I think it might be a good topic to discuss for most bird users as well: How to deal with route preference when one has multiple sources? Problem statement: - Your ASN receives the same route multiple times from different upstreams - What is the best way of handling multiple routes in regards to a) best practice ("the next engineer understands the solution") b) efficiency ("how fast to failover") c) robustness ("simplicity" and "default behaviour") The setup will for almost anybody look something like that: -------- |Your ASN | -------- router1----------------- ASN A: sends route X | iBGP+IGP (babel, OSPF, etc.) - other-routers-of-the-asn | router2 |--------------------- ASN B: sends route X And let's assume that by default ASN A is the preferred path for route X. Solution 1: lower bgp_local pref on import from ASN B ----------------------------------------------- - Advantage: - very easy to configure - has the state local: "this upstream is not so interesting" - Disadvantage - router2 does not export route X into the ASN - Only if the ASN A route vanishes, it is being redistributed From a setup perspective, this looks very logical and coherent, besides the lack of knowledge of all other routers of the routes. Solution 2: lower bgp_local pref on import from router2 ------------------------------------------------- - Advantage: - route X will be propagated into the ASN - Should have almost zero failover time, only kernel needs to be updated on each router - Disadvantage - All routes from router2 will have a lower preference, if router2 handles other routes that should be treated normally, configuration can get complex From a setup perspective this looks more messy and complicated, but should achieve faster failover times and seems more transparent. Solution 3: Elongate the bgp_path ------------------------------------------------- router2 could prepend ASN B some times on import or export to iBGP. - Advantage: - route would be propagated (actually unclear, as it is not the best route) - Disadvantage - path is modified in an "incorrect" way Solution 4: other solutions ------------------------------------------------- Maybe something else is actually much smarter? If you solve the problem differently, I'm looking for feedback on that topic. Best regards, Nico [0] https://bird.network.cz/pipermail/bird-users/2024-July/017743.html -- Sustainable and modern Infrastructures by ungleich.ch

3 2