- Bird-users - Mailing Lists

<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

Bird 2.14 Starts but Won't Bind to Port 179
by Eric Robinson 01 Aug '24

01 Aug '24

Bird starts, and claims that it is waiting for the upstream routers to become neighbors... 2024-07-31 06:25:25.774 isp1: Initializing 2024-07-31 06:25:25.774 isp2: Initializing 2024-07-31 06:25:25.774 isp1: Starting 2024-07-31 06:25:25.774 isp1: State changed to start 2024-07-31 06:25:25.774 isp2: Starting 2024-07-31 06:25:25.774 isp2: State changed to start 2024-07-31 06:25:25.774 Started 2024-07-31 06:25:25.775 isp2: Waiting for 4.4.92.131 to become my neighbor 2024-07-31 06:25:25.775 isp1: Waiting for 4.4.92.130 to become my neighbor ...however, I can see in tcpdump that bird is refusing BGP connections... 08:50:31.055601 IP 4.4.92.130.34302 > 4.4.92.140.179: Flags [S], seq 733565924, win 16384, options [mss 1424,wscale 0,nop,sackOK,eol], length 0 08:50:31.056685 IP 4.4.92.140.179 > 4.4.92.130.34302: Flags [R.], seq 0, ack 733565925, win 0, length 0 ...and that's because bird is not listening... [root@fw9b log]# netstat -ant Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:8953 0.0.0.0:* LISTEN tcp6 0 0 :::1013 :::* LISTEN tcp6 0 0 :::444 :::* LISTEN tcp6 0 0 :::81 :::* LISTEN Bird is running... [root@fw9b log]# ps ax|grep bird 20738 pts/0 S+ 0:00 grep bird 29732 ? Ss 0:00 /usr/sbin/bird Strace shows that it is not binding to the port. I read a full thread about this exact symptom here: https://bird.network.cz/pipermail/bird-users/2020-September/014824.html Unfortunately, I'm brand new to bird and I was unable to follow some of it. -Eric Disclaimer : This email and any files transmitted with it are confidential and intended solely for intended recipients. If you are not the named addressee you should not disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author and might not represent those of Physician Select Management. Warning: Although Physician Select Management has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments.

2 7