- Bird-users - Mailing Lists

Problem redistributing routes from iBGP to OSPF
by Pete Heist 11 Jul '25

11 Jul '25

Hi, I'm seeing a problem with route redistribution that I hope someone can help with... When redistributing a default route from iBGP to OSPF, other OSPF routers do not seem to respect the value of ospf_metric2 set on exported routes. If I define the default route in a static protocol instead of redistributing it, I do not see the problem. I *think* I see a clue in the output from "show ospf state" below in the two cases. When using a static protocol, there are different route distances for each default route- 0 and 10. When doing route redistribution, both routers show a distance of 65535. That seems odd, and I'm not sure why it is. Also note that all iBGP peerings are IPv6, so BGP-MP is in use. The topology is as follows: ^ ^ | | eBGP eBGP | | +------+ +------+ | gw1 |-----------------------------------------| gw2 | +--+---+ <-- 0.0.0.0/0 ---+---+--+ | | \ iBGP / | | | | \ / | | | | \ / | | | | \ / | | | 0.0.0.0/0 \ / 0.0.0.0/0 | | | iBGP \ \ / / iBGP | | | v v \ / v v | | \ / | | \ / | | \ / | | x | | / \ | | / \ | | / \ | | ^ ^ / \ ^ ^ | | | iBGP / / \ \ iBGP | | | A.B.C.D/X / \ A.B.C.D/X | | | / \ | | | | / \ | | | | / \ | | | | / \ | | +--+---+ +---+--+ | nat1 |-----------------------------------------| nat2 | +------+ +------+ | | OSPF OSPF E2 metric 10 E2 metric 100 0.0.0.0/0 0.0.0.0/0 | | v v * Four routers in an iBGP full mesh * gw1 and gw2 are the ASBRs, with full BGP tables * nat1 and nat2 are core routers doing NAT44 * NOTE: all iBGP peerings are IPv6 only, so BGP-MP is in use * Default route: * exported by gw1 and gw2 using iBGP * imported by nat1 and nat2 using iBGP * redistributed by nat1 and nat2 using OSPF into the LAN * Different metrics from nat1 and nat2 seem not to be respected * Problem occurs on both BIRD 2.0.12 and 2.17.1 ----------------------------------------------------------------------- STATIC PROTOCOL (what works) If I define default routes in a static protocol on nat1 and nat2, and set ospf_metric2 on an export filter, it works as expected. Routers on the LAN respect the metric and prefer the route from nat1. # # Routing table on another OSPF host running BIRD # # Regardless of which order nat1 and nat2 are started in, the # default route chosen is the one with the lower metric, as expected. # bird> show ospf state ospf4 area 0.0.0.0 router <gw1 IPv4 IP> distance 0 ... external 0.0.0.0/0 metric2 10 router <gw2 IPv4 IP> distance 10 ... external 0.0.0.0/0 metric2 100 bird> show route for 0.0.0.0/0 all Table master4: 0.0.0.0/0 unicast [ospf4 09:26:57.341] * E2 (150/65535/10) [<gw1 IPv4 IP>] via <gw1 IPv4 IP> on eth0 Type: OSPF-E2 univ OSPF.metric1: 65535 OSPF.metric2: 10 OSPF.tag: 0x00000000 OSPF.router_id: <gw1 IPv4 IP> # # Partial config from gw1/gw2... # # NO_KERNEL_EXPORT, if defined, flags a route for NOT exporting to the # kernel. attribute int NO_KERNEL_EXPORT; # IBGP_EXPORT, if defined, flags a route for export to iBGP peers. attribute int IBGP_EXPORT; ipv4 table Tibgp4; # default route injected on gw1/gw2 with static protocol into custom table protocol static Sibgp4 { ipv4 { table Tibgp4; import filter { IBGP_EXPORT = 1; NO_KERNEL_EXPORT = 1; accept; }; }; route 0.0.0.0/0 unreachable; } # pipe to master protocol pipe Pibgp4 { table master4; peer table Tibgp4; import where !defined(NO_KERNEL_EXPORT); export where defined(IBGP_EXPORT); } # sample peering for nat1, with a bunch of things left out protocol bgp nat1 from IBGP { ipv4 { ... table Tibgp4; export where defined(IBGP_EXPORT); }; ipv6 { ... table Tibgp6; export where defined(IBGP_EXPORT); }; # anonymized addresses below, but shows that IPv6 LLA is used interface "bond0.A"; source address fe80::A:1; neighbor fe80::A:2 internal; ... } # # Partial config for nat1/nat2... # # Default route added in a static protocol. This works. protocol static Sospf4 { ipv4 { table Tospf4; import filter { OSPF_EXPORT = 1; accept; }; }; route 0.0.0.0/0 unreachable; } # ospf_metric2 set on an export filter. protocol ospf v2 ospf4 { ipv4 { table Tospf4; import all; export filter { if !defined(OSPF_EXPORT) then reject; ospf_metric2 = 10; # for nat1, or 100 for nat2 accept; }; }; ... } ----------------------------------------------------------------------- ROUTE REDISTRIBUTION (what does not work) # # Routing table on another OSPF host running BIRD # # !!! Even though nat1 and nat2 are both running, and nat2 has a # lower value for OSPF.metric2, its default route is not chosen. # The default route in the OSPF database is from the router that # started first. bird> show ospf state ospf4 area 0.0.0.0 ... router <gw1 IPv4 IP> # !!! distance is 65535- with static protocol it's 0 distance 65535 ... # default route not present when started second router <gw2 IPv4 IP> # !!! distance is 65535- with static protocol it's 10 distance 65535 ... # external default route with higher metric 100 is used external 0.0.0.0/0 metric2 100 # The default route is gw2, which is unexpected when it has a # higher metric2. bird> show route for 0.0.0.0/0 all Table master4: 0.0.0.0/0 unicast [ospf4 08:37:10.342] * E2 (150/65535/100) [<gw2 IPv4 IP>] via <gw2 IPv4 IP> on eth0 Type: OSPF-E2 univ OSPF.metric1: 65535 OSPF.metric2: 100 OSPF.tag: 0x00000000 OSPF.router_id: <gw2 IPv4 IP> # # Config for gw1/gw2 is same as above, when using static protocol... # # # Partial config from nat1/nat2... # # OSPF_EXPORT, if defined, flags a route for export via OSPF. attribute int OSPF_EXPORT; ipv4 table Tibgp4; # ibgp_in_primary4 filters primary IPv4 routes imported via iBGP. filter ibgp_in_primary4 { if net = 0.0.0.0/0 then { OSPF_EXPORT = 1; } bgp_local_pref = 100; accept; } # pipe to master protocol pipe Pibgp4 { table master4; peer table Tibgp4; import all; export where defined(IBGP_EXPORT); } protocol bgp gw1 from IBGP { description "gw1 - VLAN 3313"; ipv4 { table Tibgp4; import filter ibgp_in_primary4; export where defined(IBGP_EXPORT); ... }; ipv6 { table Tibgp6; import filter ibgp_in_primary6; export where defined(IBGP_EXPORT); ... }; interface "bond0.A"; source address fe80::A:2; neighbor fe80::A:1 internal; ... } # ospf_metric2 set on an export filter the same as with the static # protocol case, but the metric seems to not be respected when # the route is redistributed from iBGP. protocol ospf v2 ospf4 { ipv4 { table Tospf4; import all; export filter { if !defined(OSPF_EXPORT) then reject; ospf_metric2 = 10; # 10 for nat1, 100 for nat2 accept; }; }; ... } Thanks in advance for any help... Pete

1 1

Relaxed handling of OTC attribute
by André Grüneberg 26 Jun '25

26 Jun '25

Hi Bird team, We are currently evaluating the implementation of RFC9234 for our IXP route servers. Looking at it naively, one just needs to set local role rs_server in the protocol. And indeed, routes from peers will be rejected and this is logged. Instead of just logging, we would really like to apply our "blame and shame" policy, i.e. make the invalid routes (in our case, anything with an OTC set) visible in our looking glass (similar to RPKI invalids). To do so, we'd need the "ineligible" routes to be imported into the main table, tagged in a sensible way. I understand that RFC9234 section 5 mandates that the behaviour wrt OTC attribute handling shall not be configurable by the operator. But ineligible does not require the route to be invisible (see section 3). Would it be possible to implement a more relaxed behaviour by allowing the import of ineligible routes (but never export)? Our current alternative is to avoid using BGP roles capability, but only implement OTC handling in filters. Thanks and best wishes, André -- André Grüneberg, Managing Director andre.grueneberg(a)bcix.de +49 30 2332195 42 BCIX Management GmbH Albrechtstr. 110 12103 Berlin Germany Geschäftsführer/Managing Directors: Jens Lietzmann, André Grüneberg Handelsregister: Amtsgericht Charlottenburg, HRB 143581 B

7 16

Set src address of the route
by Max Tulyev 19 Jun '25

19 Jun '25

Hello, is it possible for bird (v 2.x) to manually set in the routing table in Linux the source address of the route came via BGP? i.e. I got the route 192.168.0.0/16 with nexthop 10.1.1.1, and need to export to the kernel something like this: "ip ro add 192.168.0.0/16 via 10.1.1.1 dev eth0.5 proto bird SRC 172.16.0.1" The real life example: the bird router connected to Internet Exchange point, learned the route from the peer or the route server. When something from this router wants to connect to something within this route, the source address of this connection will be the address of the Internet Exchange interface, which is not globally routed, and connection will fail. Any ideas? Thank you! -- WBR, Max Tulyev MT6561-RIPE - Jabber maxtul(a)netassi.st - Phone +447441953543 - Telegram @mt6561

3 2

Bird from Debian/Ubuntu repo or from sources?
by Mike Neo 16 Jun '25

16 Jun '25

Hi, for simple BGP routing with two peers (Global + IX). What is better to choose? Bird from Debian/Ubuntu repositories or from sources? Kind regards, Mike

2 2

[3.1.2 and older] birdc doesn't output the possible command expansions list
by Артём Варакса 16 Jun '25

16 Jun '25

Hello, I've observed an issue with `bird` 3.1.2 that is also reproducible in 2.17.1, but not with 2.15.1 (i. e. a regression somewhere between 2.15.1 and 2.17.1). After starting the `bird` service, on 2.17.1 and newer: > # birdc > bird> show stat > Ambiguous command, possible expansions are: On 2.15.1, the output is correct: > # birdc > bird> show stat > Ambiguous command, possible expansions are: > show status Show router status > show static [<name>] Show details of static protocol > bird> This was tested on ALT Linux (downstream issue: https://bugzilla.altlinux.org/54787) Per the maintainer, it's likely an issue in `bind` itself rather than the package, hence reporting here. Thanks!

4 4

prefer ipv6 examples in the documentation
by Alexander Zubkov 06 Jun '25

06 Jun '25

Hi everybody! In spite or recent Maria's activity, I decided to checked the BIRD documentation and found many examples where legacy :) IPv4 addresses are used. My proposal is to preferably use IPv6 examples in the documentation. I tried to spot the places where IPv4 examples can be replaced or complemented by IPv6 examples, and prepared a patch with possible changes. Regards, Alexander Zubkov

4 4

[3.1.2] Queuing an already queued event to another queue is not supported.
by Matt Corallo 03 Jun '25

03 Jun '25

Tried to test 3.1.2 and it mostly seems to work okay, but after some runtime I got the above error and crash. Sadly don't have a lot more to help debug this, though it may have been during a reload. Thanks, Matt

4 8

Correct replacement for 'birdc reload in all' in BIRD 3.1?
by Robert Scheck 02 Jun '25

02 Jun '25

Hello, I'm currently running the following commands in a systemd.service as part of a systemd.timer: - rpki-client -B -c -j -m -o - bird -p -c /var/lib/rpki-client/bird - birdc configure soft - birdc reload in all Since upgrading from BIRD 2.16 to 3.1, the last command fails. However, https://gitlab.nic.cz/labs/bird/-/blob/stable-v3.1/doc/migration-bird3.md mentions just: > "Reload of filters is now done by reload filters command, contrary to > just reload in BIRD 2. Am I overlooking something? What's the correct replacement command for BIRD 3.1? Regards, Robert

2 1

[3.1.1 on EL8] CPU 100% with NetworkManager
by zx＠zxinc.org 02 Jun '25

02 Jun '25

Hi there, When I upgrade bird from 2.16.2 to 3.1.1 today, it became unstable that it often causes CPU usage to 100% for bird, and later also for NetworkManager, and there are some notable syslogs: 6月 02 16:04:28 zx-router bird[2197971]: I/O loop cycle took 14046.255 ms for 43 events 6月 02 16:04:48 zx-router bird[2197971]: I/O loop cycle took 15307.277 ms for 42 events 6月 02 16:04:57 zx-router bird[2197971]: I/O loop cycle took 8562.921 ms for 43 events 6月 02 16:05:16 zx-router bird[2197971]: I/O loop cycle took 9799.271 ms for 85 events 6月 02 16:05:25 zx-router bird[2197971]: I/O loop cycle took 9330.265 ms for 80 events 6月 02 16:05:30 zx-router bird[2197971]: I/O loop cycle took 5004.867 ms for 44 events 6月 02 16:06:09 zx-router bird[2197971]: I/O loop cycle took 38759.438 ms for 84 events 6月 02 16:06:17 zx-router bird[2197971]: I/O loop cycle took 5465.396 ms for 6 events 6月 02 16:06:23 zx-router bird[2197971]: I/O loop cycle took 5906.858 ms for 44 events 6月 02 16:06:37 zx-router bird[2197971]: I/O loop cycle took 12896.032 ms for 9 events 6月 02 16:06:56 zx-router bird[2197971]: I/O loop cycle took 8217.969 ms for 81 events 6月 02 16:07:08 zx-router bird[2197971]: I/O loop cycle took 9012.775 ms for 25 events 6月 02 16:07:26 zx-router bird[2197971]: I/O loop cycle took 11506.570 ms for 45 events 6月 02 16:07:56 zx-router bird[2197971]: I/O loop cycle took 30014.580 ms for 85 events 6月 02 16:08:05 zx-router bird[2197971]: I/O loop cycle took 6333.289 ms for 6 events 6月 02 16:08:14 zx-router bird[2197971]: I/O loop cycle took 8751.816 ms for 42 events 6月 02 16:08:29 zx-router bird[2197971]: I/O loop cycle took 13017.064 ms for 46 events 6月 02 16:08:51 zx-router bird[2197971]: I/O loop cycle took 13223.357 ms for 80 events 6月 02 16:09:44 zx-router bird[2197971]: I/O loop cycle took 17730.328 ms for 5 events 6月 02 16:10:37 zx-router bird[2197971]: I/O loop cycle took 8061.950 ms for 8 events 6月 02 16:10:46 zx-router bird[2197971]: I/O loop cycle took 9008.065 ms for 65 events 6月 02 16:10:54 zx-router bird[2197971]: I/O loop cycle took 6035.965 ms for 4 events 6月 02 16:11:03 zx-router bird[2197971]: I/O loop cycle took 9959.243 ms for 67 events I'm exporting full table to kernel with NetworkManager running on RHEL8 related systems (CentOS/Alma/Rocky 8). There is no problem before upgrading.

4 4

Crash width Assertion '!rejected || !accepted' failed at nest/rt-table.c:1192
by Alexey Boldyrev 02 Jun '25

02 Jun '25

Backtrace: Apr 26 18:05:26 router bird[751]: Netlink: Invalid argument Apr 26 18:05:26 router bird[751]: Netlink: Invalid argument Apr 26 18:05:26 router bird[751]: ... Apr 27 02:09:23 router bird[751]: AS4200220008: Error: Hold timer expired Apr 27 02:10:59 router bird[751]: AS4200220008: Error: Hold timer expired Apr 27 13:14:03 router bird[751]: Assertion '!rejected || !accepted' failed at nest/rt-table.c:1192 Apr 27 13:14:03 router systemd-coredump[1345547]: [🡕] Process 751 (bird) of user 967 dumped core. Stack trace of thread 824: #0 0x0000777b9f380624 n/a (libc.so.6 + 0x97624) #1 0x0000777b9f326ba0 raise (libc.so.6 + 0x3dba0) #2 0x0000777b9f30e582 abort (libc.so.6 + 0x25582) #3 0x000065083a2cb01f n/a (/usr/bin/bird + 0xe001f) #4 0x000065083a248712 n/a (/usr/bin/bird + 0x5d712) #5 0x000065083a249117 n/a (/usr/bin/bird + 0x5e117) #6 0x000065083a21d0cf n/a (/usr/bin/bird + 0x320cf) #7 0x000065083a2cf838 n/a (/usr/bin/bird + 0xe4838) #8 0x000065083a21d0cf n/a (/usr/bin/bird + 0x320cf) #9 0x000065083a2d1ee7 n/a (/usr/bin/bird + 0xe6ee7) #10 0x0000777b9f37e708 n/a (libc.so.6 + 0x95708) #11 0x0000777b9f402aac n/a (libc.so.6 + 0x119aac) Stack trace of thread 751: #0 0x0000777b9f386be2 n/a (libc.so.6 + 0x9dbe2) #1 0x0000777b9f37ae33 n/a (libc.so.6 + 0x91e33) #2 0x0000777b9f37ae74 n/a (libc.so.6 + 0x91e74) #3 0x0000777b9f3f553e __poll (libc.so.6 + 0x10c53e) #4 0x000065083a1f1a14 n/a (/usr/bin/bird + 0x6a14) #5 0x0000777b9f310488 n/a (libc.so.6 + 0x27488) #6 0x0000777b9f31054c __libc_start_main (libc.so.6 + 0x2754c) #7 0x000065083a1f2565 n/a (/usr/bin/bird + 0x7565) Stack trace of thread 826: #0 0x0000777b9f386be2 n/a (libc.so.6 + 0x9dbe2) #1 0x0000777b9f37ae33 n/a (libc.so.6 + 0x91e33) #2 0x0000777b9f37ae74 n/a (libc.so.6 + 0x91e74) #3 0x0000777b9f3f553e __poll (libc.so.6 + 0x10c53e) #4 0x000065083a2d2020 n/a (/usr/bin/bird + 0xe7020) #5 0x0000777b9f37e708 n/a (libc.so.6 + 0x95708) #6 0x0000777b9f402aac n/a (libc.so.6 + 0x119aac) ELF object binary architecture: AMD x86-64 Apr 27 13:14:03 router systemd[1]: bird.service: Main process exited, code=dumped, status=6/ABRT Apr 27 13:14:03 router systemd[1]: bird.service: Failed with result 'core-dump'. Apr 27 13:14:03 router systemd[1]: bird.service: Consumed 3min 7.732s CPU time, 6.1M memory peak. Version: 3.1.0

4 3