March 2025 - Bird-users - Mailing Lists

BGP, "Invalid NEXT_HOP attribute"
by Lexi Winter 15 Mar '25

15 Mar '25

hello, recently i noticed some entries in syslog like this: Mar 15 11:03:22 uk-myb-2 bird[60388]: nl-myb-1: Invalid NEXT_HOP attribute - neighbor address fd5b:a83:b06b:500::1 Mar 15 11:03:22 uk-myb-2 bird[60388]: nl-myb-1: Invalid route 172.20.212.0/26 withdrawn Mar 15 11:03:22 uk-myb-2 bird[60388]: nl-myb-1: Invalid NEXT_HOP attribute - neighbor address fd5b:a83:b06b:500::1 Mar 15 11:03:22 uk-myb-2 bird[60388]: nl-myb-1: Invalid route 172.20.212.0/26 withdrawn Mar 15 11:03:22 uk-myb-2 bird[60388]: nl-myb-1: Invalid NEXT_HOP attribute - neighbor address fd5b:a83:b06b:500::1 Mar 15 11:03:22 uk-myb-2 bird[60388]: nl-myb-1: Invalid route 172.20.212.0/26 withdrawn Mar 15 11:03:22 uk-myb-2 bird[60388]: nl-myb-1: Invalid NEXT_HOP attribute - neighbor address fd5b:a83:b06b:500::1 Mar 15 11:03:22 uk-myb-2 bird[60388]: nl-myb-1: Invalid route 172.20.212.0/26 withdrawn i am not sure how to understand this log message. i still have the route (including via nl-myb-1): root@uk-myb-2:~ # birdc show route 172.20.212.0/26 BIRD 2.16.1 ready. Table master4: 172.20.212.0/26 unicast [uk-jmp-2 11:03:22.032 from fd5b:a83:b06b:400::1] * (100/61) [AS4242422622i] via fe80::e0e3:b1bf:8d1d:abcd on wg.nl-myb-1 unicast [nl-myb-1 11:03:20.704 from fd5b:a83:b06b:500::1] (100/61) [AS4242422622i] via fe80::e0e3:b1bf:8d1d:abcd on wg.nl-myb-1 unicast [ny-czy-1 11:03:20.589 from fd5b:a83:b06b:200::1] (100/694) [AS4242422622i] via fe80::bc1b:dbed:690a:6840 on wg.uk-jmp-2 unicast [mia-czy-1 11:03:20.680 from fd5b:a83:b06b:900::1] (100/694) [AS4242422622i] via fe80::bc1b:dbed:690a:6840 on wg.uk-jmp-2 and it's in the FIB as well: root@uk-myb-2:~ # route -n get -inet 172.20.212.0/26 route to: 172.20.212.0 destination: 172.20.212.0 mask: 255.255.255.192 gateway: fe80::e0e3:b1bf:8d1d:abcd%wg.nl-myb-1 fib: 0 interface: wg.nl-myb-1 flags: <UP,GATEWAY,DONE> recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1420 1 0 so everything seems fine. what is BIRD trying to indicate with this log message?

2 5

IGP metric attribute semantic dichotomy
by Maria Matejka 15 Mar '25

15 Mar '25

Dear BIRD users, we'd like to do a public survey about naming things. In short, there are two different route attributes in BIRD 2: - The whole route's total metric from here to the destination, if set explicitly by `igp_metric = N` in filters. I.e., a generic alternative to protocol-specific IGP metrics like `ospf_metric1` or `babel_metric`. - Metric of the route's part between here and `bgp_next_hop`, determined by recursive next hop resolution. I.e., from that route which resolved the recursive next hop, the value in the first meaning of `igp_metric` is taken and stored here. **Both of these two attributes are internally named `igp_metric` in BIRD 2.** However, only the first one is accessible by filters. When rewriting the attribute handling code for BIRD 3, I merged them together. This is technically not a bug per se and for now, yet it behaves weirdly in corner cases and confuses people. We plan to split these attributes back in BIRD 3, but we don't want (and technically also can't) use the same name any more. **How to name these two attributes better?** Looking forward to your suggestions and opinions. Happy routing! Maria and the BIRD Team -------------------------- Follows longer explanation on IGP metric, feel free to skip that. What's the IGP metric? Let's consider an iBGP route, received from a BGP peer in the same AS, via a multihop session. This route's next hop is often not locally known and has to be resolved by finding a matching route (let's call that route an IGP route) and using that route's nexthop, as expected by RFC 4271, section 5.1.3. We call such a situation "recursive nexthop". Such a route pair then may look like follows (shortened): 2001:db8:2::/48 unicast [ibgp3 <removed> from 10.1.4.1] * (100/40) [AS65532i] via fe80::386c:8fff:feb8:206c on ve1 hostentry: via 2001:db8:1:13::2 fe80::585b:d3ff:febd:1dd9 table master6 bgp_next_hop: 2001:db8:1:13::2 fe80::585b:d3ff:febd:1dd9 igp_metric: 40 source: BGP 2001:db8:1:13::/64 unicast [ospf6 <removed>] * I (150/40) [10.0.1.4] via fe80::386c:8fff:feb8:206c on ve1 ospf_metric1: 40 source: OSPF The `bgp_next_hop` attribute is non-local, and there is another route able to resolve that attribute to the local next hop. That route's metric is transferred to the BGP route as `igp_metric`. In BIRD 2, that's just an internal value, displayed on the first line as (100/40), which is preference (100) and the IGP metric (40). But you may also have a static route instead of the OSPF one: protocol static { ipv6; route 2001:db8:1:13::/64 via fe80::386c:8fff:feb8:206c dev ve1 { igp_metric = 40; }; } Here the `igp_metric` semantics is the whole route's metric. This metric can then be used in next hop resolution and applied to the BGP route. And in the BGP route, there will be this `igp_metric` attribute copied, representing only the metric from here to `bgp_next_hop`. -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

3 2

Add exceed merge path on limit
by Saklak, Marcin 13 Mar '25

13 Mar '25

Hi All, I’m wondering if it’s possible to add a log entry whenever the merged path limit is exceeded. For example, a route can have 64 next hops, but BIRD export to the kernel up to merge limit and skip rest of next hops. I’d like to be able to detect when this happens. Below is a potential solution for that: --- nest/rt-attr.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/nest/rt-attr.c b/nest/rt-attr.c index c8ef8e08..ef118cb0 100644 --- a/nest/rt-attr.c +++ b/nest/rt-attr.c @@ -323,6 +323,8 @@ nexthop_merge(struct nexthop *x, struct nexthop *y, int rx, int ry, int max, lin n = &((*n)->next); } *n = NULL; + if (max == -1) + log(L_ERR "Exceeded merge paths on limit!"); return root; } -- 2.34.1 If you have any suggestions or a better approach, please let me know! Best regards, Marcin Sakłak

2 2

OSPF type 5 LSA forward address change non zero to zero vice versa
by Bala Sajja 06 Mar '25

06 Mar '25

Hi Ondrej, If OSPF topology changes as part of interface addition/deletion to ospf area on router, that causes the forward address of type 5 lsa change to nonzero to zero or vice versa, Router should generate updated type 5 LSAs right with the updated forward address. Bird software seems not generating updated LSA's in this case. Regards, Bala.

1 0

Segment routing over IPv6 and OSPFv3
by Matyáš Kroupa 05 Mar '25

05 Mar '25

Hi, I recently decided that I would want to implement SRv6 extensions for OSPFv3 in Bird as my diploma theses. I study at the Faculty of Informatics, Masaryk University in Brno. As segment routing is a huge topic, I would start from the ground. That would mean implementing extended LSAs that use TLVs, then TLVs for Segment Routing with IPv6 dataplane. Since that would not be enough for a diploma thesis, I would also add definitions for Flex-algo. I already started with adding constants and data structures for extended LSAs. I read the contribution guide and worked on branch thread-next. I hope that my contribution will be welcomed and I am looking forward for hearing any comments from the maintainers. Best regards, Matyáš Kroupa

2 1

python library for generating bird configuration files
by Hendrik Wolff 03 Mar '25

03 Mar '25

Hey, I wrote a tiny library to generate bird configurations with python classes. It has no external dependencies and the repository includes some examples. It's in no way perfect or complete and I don't plan to extend it. But maybe it can serve as a base for your own needs. Extending it to support more protocols and options should be fairly easy. My personal favorite feature is that you can mark any Protocol class instance as a bird template by passing the is_template=True parameter. This template can be reused by passing the name of the template (e.g. "my_template") to the from_template="my_template" parameter of another Protocol class instance. https://github.com/hw0lff/bird-config-py Have fun! Cheers -- Hendrik

2 2

Interface specific RA DNSSL option behaviour
by Daniel Gröber 03 Mar '25

03 Mar '25

Hi BIRDies, I was playing with RA and DNSSL options today. I found the order of DNSSL options generated unhelpful. My config looks something like this: ``` protocol radv { dnssl { domain "global1.example"; domain "global2.example"; }; interface "enp2s0" { dnssl { domain "interface.example"; }; }; } ``` and I see the following RA options being generated (as shown by rdisc6): DNS search list : global1.example global2.example DNS search list lifetime: 1800 (0x00000708) seconds DNS search list : interface.example DNS search list lifetime: 1800 (0x00000708) seconds I tested with dhcpcd and rdnssd and saw problems with both: 1) dhcpcd outright doesn't support multiple DNSSL options so I only got the first one in /etc/resolv.conf (working on reporting) and 2) rdnssd supports this but the list in /etc/resolv.conf ends up being: search global1.example global2.example interface.example While rdnssd's behaviour seems in-line with RFC 8106 it's not what I wanted to achive overall. See section 6.3. "Synchronization between DNS Search List and Resolver Repository", https://datatracker.ietf.org/doc/html/rfc8106#section-6.3. > [...] it stores the DNSSL domain names (in order) [...] My goal was to have interface.example be the LAN domain (i.e the first in the search list) and the rest of the domains last in the search list. Admittedly this is a weird use-case and global dnssl was probably just intended for the simple case of all interfaces having the same search domain. If I had multiple LANs and corresponding domains I would not be able to share the list in the global dnssl option anyway, this really only works with LAN domains and network-wide search domain in the global list. I know I can fix this using the `dnssl local` switch (I tried and it works as expected), but perhaps a new option to give the order I want would be useful for others? Thanks, --Daniel

1 0