- Bird-users - Mailing Lists

Detailed ASPA_INVALID logging? (responsible AS and ASPA object)
by Christoph 05 Jan '26

05 Jan '26

Hello, we started to validate (logging only) ASPA objects with this: if (aspa_check_downstream(at) = ASPA_INVALID) then { print "ASPA INVALID announcement (monitoring only): ", net, " AS path: ", bgp_path; } Example output: ASPA INVALID announcement: 91.223.183.0/24 AS path: (path 1764 5405 6830 206659 197477 215563) Then we manually investigate which AS along the path is responsible for the ASPA_INVALID result by asking routinator for the ASPA objects of all involved ASNs, example output for ASN6830 showing an AS0 ASPA: "aspas": [ { "customer": "AS6830", "providers": ["AS0"], "ta": "ripe" } ] Depending on the length of the AS path this is cumbersome. Is there a way to write the first responsible AS and ASPA object to the log that caused the ASPA_INVALID result? best regards, Christoph

1 0

Re: Strict Bind usability
by Maria Matejka 04 Jan '26

04 Jan '26

Hello Sebastian, >> Issue: 46, 340 On Sun, Jan 04, 2026 at 02:04:04PM +0100, Sebastian Hahn wrote: > just wanted to ask if there's any progress here. Added Maria because I've > seen you a lot on the mailing list. Many thanks! Well there is _some_ progress, yet probably not complete, see below. On Sun, Jan 14, 2024 at 10:50:18PM +0100, Sebastian Hahn wrote: > I've been using strict bind for bgp, but there might be a lack in my understanding or I have a proposal for a new feature. Strict bind seems to be a bit more restrictive than I'd like (and than I think it is necessary): > > I would like to use dynamic bgp (using a range for neighbour) with > auto-configured LL IPv6 adresses. This doesn't work, of course, if I > need to statically configure the source address, which I am forced to > with the strict bind option. [...] With BIRD 2.18, you should be able (and I may be wrong because I implemented it half a year ago) to have `strict bind` with dynamic link-local and `interface` set. I have no idea whether your needs would be met completely with this version but if you could check please … > I am wondering, is this restriction > really needed? There is only one IP address (the LL one) on the > interface in question (and the interface is specified in config). > I think this should mean that bird could just pick that IP address and > use it for both source as well as to bind to. If that is true, could a > "source address auto" option or so be added to allow such a > configuration? If it's ok that it would choose the source address kinda randomly from that interface, it's probably a feature worth adding. And because we did some BGP listening reworks, it should actually be trivial now, while for 2.17 and older it wasn't. > In addition, it would be great if a strict bind option could be added > for the babel protocol. Noted finally, sorry for missing that. Thanks for the heads-up, have a good new year! Maria -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

1 0

EPVN MPLS label parsing error
by William 26 Dec '25

26 Dec '25

Hi BIRDians, Been tinkering with EPVN in (built from git on Debian 13.1) hooked into an Arista vEOS-LAB network, with an IPv6 underlay. Have all the BGP sessions up and running, pushing MACs and their next hops, receiving traffic on the VXLAN interface, all good. But I'm not seeing the traffic coming out of the linux bridge to the respective VLAN subinterface for processing. Digging round I see this in the bridge FDB: <snip> 00:50:00:00:12:01 dev vxlan100 vlan 40 extern_learn master br1 42:a5:d1:11:88:4b dev vxlan100 vlan 40 master br1 permanent 42:a5:d1:11:88:4b dev vxlan100 master br1 permanent 00:00:00:00:00:00 dev vxlan100 dst 2001:db8:ffff:1ad::403 vni 10040 self extern_learn permanent 00:50:00:00:12:01 dev vxlan100 dst 2001:db8:ffff:1ad::401 vni 627 self extern_learn permanent 627? the VNI is 10040. root@eve-deb:~# bridge vlan show port vlan-id br1 1 PVID Egress Untagged vxlan100 40 root@eve-deb:~# bridge vni show dev vni group/remote root@eve-deb:~# checking evpntab and etab: bird> sh route table evpntab Table evpntab: evpn mac 1004003:10040 0 fe:40:19:7e:2a:79 * unicast [SPINE1_EVPN 18:21:59.435 from 2001:db8:ffff:1aa::1] * (100/?) [AS4201004001i] via 2001:db8:ffff:1f3::8 on ens4 mpls 627 evpn imet 5001:10040 0 2001:db8:ffff:1ad::501 [evpn1 18:11:30.067] * (120) evpn imet 1004003:10040 0 2001:db8:ffff:1ad::401 [SPINE1_EVPN 18:07:31.985 from 2001:db8:ffff:1aa::1] * (100) [AS4201004001i] evpn imet 1004003:10040 0 2001:db8:ffff:1ad::403 [SPINE1_EVPN 18:07:31.987 from 2001:db8:ffff:1aa::1] * (100) [AS4201004003i] evpn mac 1004003:10040 0 00:50:00:00:12:01 * unicast [SPINE1_EVPN 18:21:43.590 from 2001:db8:ffff:1aa::1] * (100/?) [AS4201004001i] via 2001:db8:ffff:1f3::8 on ens4 mpls 627 bird> sh route table etab Table etab: 00:00:00:00:00:00 vlan 40 unicast [evpn1 18:11:30.067] * (80) via 2001:db8:ffff:1ad::403 on vxlan100 mpls 10040 42:a5:d1:11:88:4b unicast [bridge1 16:58:39.461] * L (0) dev vxlan100 fe:40:19:7e:2a:79 vlan 40 unicast [evpn1 18:21:59.434] * (80) via 2001:db8:ffff:1ad::401 on vxlan100 mpls 627 00:50:00:00:12:01 vlan 40 unicast [evpn1 18:21:43.590] * (80) via 2001:db8:ffff:1ad::401 on vxlan100 mpls 627 06:06:4f:2b:a5:e6 unicast [bridge1 16:54:40.358] * L (0) dev br1 bird> Where's it coming from? On the single (so far) attached Arista spine we see this: dc1-spine-1#sh bgp evpn BGP routing table information for VRF default Router identifier 192.168.1.10, local AS number 4201003001 Route status codes: * - valid, > - active, S - Stale, E - ECMP head, e - ECMP c - Contributing to ECMP, % - Pending best path selection Origin codes: i - IGP, e - EGP, ? - incomplete AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop Network Next Hop Metric LocPref Weight Path * > RD: 1004003:10040 mac-ip 0050.0000.1201 2001:db8:ffff:1ad::401 - 100 0 4201004001 i * > RD: 1004003:10040 imet 2001:db8:ffff:1ad::401 2001:db8:ffff:1ad::401 - 100 0 4201004001 i * > RD: 1004003:10040 imet 2001:db8:ffff:1ad::403 2001:db8:ffff:1ad::403 - 100 0 4201004003 i * > RD: 5001:10040 imet 2001:db8:ffff:1ad::501 2001:db8:ffff:1aa::501 - 100 0 4201005001 i dc1-spine-1# 2001:db8:ffff:1ad::501 is the loopback that the vxlan interface is using. Something going on weird with the RT processing. Having a look at a packet dump of an EVPN update on the wire: 18:21:59.434664 IP6 (class 0xc0, flowlabel 0x59dd9, hlim 3, next-header TCP (6) payload length: 151) 2001:db8:ffff:1aa::1.40949 > 2001:db8:ffff:1aa::501.179: Flags [P.], cksum 0x107d (correct), seq 4225498746:4225498865, ack 3651948816, win 498, options [nop,nop,TS val 3223710250 ecr 3856730090], length 119: BGP Update Message (2), length: 119 Origin (1), length: 1, Flags [T]: IGP 0x0000: 00 AS Path (2), length: 10, Flags [T]: 4201003001 4201004001 0x0000: 0202 fa66 37f9 fa66 3be1 Multi-Protocol Reach NLRI (14), length: 56, Flags [OE]: AFI: VPLS (25), SAFI: EVPN (70) no AFI 25 / SAFI 70 decoder 0x0000: 0019 4610 2001 0db8 ffff 01ad 0000 0000 0x0010: 0000 0401 0002 2100 0200 0f51 e327 3800 0x0020: 0000 0000 0000 0000 0000 0000 0030 fe40 0x0030: 197e 2a79 0000 2738 Extended Community (16), length: 16, Flags [OT]: target (0x0202), Flags [none]: 1004003:10040 encapsulation (0x030c), Flags [none]: Tunnel type: VXLAN 0x0000: 0202 000f 51e3 2738 030c 0000 0000 0008 The RT there is showing correctly. Hang on... 627 HEX is 273... looks like the 2 bytes of the latter half of the RT is being trimmed by 4 bits. I couldn't get a hang of the code to try and ID where it's playing up so sorry, no patch. Also, I'm not able to use 4-byte ASNs in the first part of the RT. The docs indicate that we should be able to, but the config barfs with out-of-range (was trying to use 1005001 - a subset of the ASNs being used). Config: filter SPINE_LO { if net.len = 128 then accept; reject; } evpn table evpntab; protocol bgp SPINE1_BGP { ipv6 { import all; export filter SPINE_LO; }; local 2001:db8:ffff:1f3::9 as 4201005001; neighbor 2001:db8:ffff:1f3::8 as 4201003001; } protocol bgp SPINE1_EVPN { evpn { import all; export all; }; local 2001:db8:ffff:1aa::501 as 4201005001; neighbor 2001:db8:ffff:1aa::1 as 4201003001; multihop; } eth table etab; protocol bridge { eth { table etab; export all; }; bridge device "br1"; debug all; }; protocol evpn { eth { table etab; }; evpn { }; rd 5001:10040; import target (rt, 1004001, 10040); import target (rt, 1004003, 10040); export target (rt, 5001, 10040); tunnel device "vxlan100"; router address 2001:db8:ffff:1ad::501; vni 10040; vid 40; debug all; }; Took a bit to work it all out based on a previous thread and the testing config, but got there in the end, then found this :( If you're able to spin up a patch I can re-compile with it and test. Regards, William -- This email has been checked for viruses by Avast antivirus software. www.avast.com

2 6

BIRD 3.1.5 weird crashes - followup
by Łukasz Jarosz 19 Dec '25

19 Dec '25

Hello everyone, I guess this one is on me (I blame severe sleep deprivation ;) ). Turns out VPP was the culprit. Somewhere inbetween config generation my statseg definition went MIA. Still, I find fact that BIRD was constantly crashing very surprising and sole reason why I went on wild goose chase after "which route crashes my BIRD" instead of looking into flapping issue first. Pozdrawiam, Łukasz Jarosz

2 1

BIRD 3.1.5 weird crashes
by Łukasz Jarosz 18 Dec '25

18 Dec '25

Hello, I am coming to you with a weird one. I have simple iBGP setup between two routers which are interconnect through VLAN on IPv4 (/30) PtP link. For now RTR1 has all of the BGP feeds. I wanted to pass it to RTR2. Config on RTR2 is pretty simple: filter bgp_in { preference = bgp_local_pref; accept; } filter bgp_out { if proto = "CORE" then accept; reject; } protocol bgp RTR1 { local xx.xx.xx.xx as PUBLICAS; neighbor xx.xx.xx.xx as PUBLICAS; ipv4 { table master4; next hop self; import filter bgp_in; export filter bgp_out; }; } As soon as session starts up it loads routes, then unloads them and resets bird process. And it happens again and again and again... Logs doesn't seem very helpful: Dec 18 12:36:14 RTR2 bird[2009]: Started Dec 18 12:37:20 RTR2 systemd-journald[474]: [🡕] Suppressed 110623 messages from dataplane-bird.service Dec 18 12:37:20 RTR2 bird[2009]: RTR1.ipv4: Export state changed from DOWN to FEEDING Dec 18 12:37:20 RTR2 bird[2009]: RTR1.ipv4: Export state changed from FEEDING to PARTIAL Dec 18 12:37:20 RTR2 bird[2009]: RTR1: State changed to up Dec 18 12:37:20 RTR2 bird[2009]: RTR1.ipv4: Export state changed from PARTIAL to READY Dec 18 12:37:20 RTR2 bird[2009]: RTR1.ipv4: Fed up Dec 18 12:37:23 RTR2 bird[2009]: Netlink: Network is unreachable Dec 18 12:37:23 RTR2 bird[2009]: Netlink: Network is unreachable Dec 18 12:37:23 RTR2 bird[2009]: Netlink: Network is unreachable Dec 18 12:37:23 RTR2 bird[2009]: Netlink: Network is unreachable Dec 18 12:37:23 RTR2 bird[2009]: Netlink: Network is unreachable Dec 18 12:37:23 RTR2 bird[2009]: ... Dec 18 12:37:23 RTR2 bird[2009]: Kernel dropped some netlink messages, will resync on next scan. Dec 18 12:37:23 RTR2 bird[2009]: Shutting down Dec 18 12:37:23 RTR2 systemd[1]: Stopping dataplane-bird.service - BIRD Internet Routing Daemon... Dec 18 12:37:23 RTR2 bird[2009]: RTR1: Shutting down Dec 18 12:37:23 RTR2 bird[2009]: RTR1.ipv4: Export state changed from READY to DOWN Dec 18 12:37:23 RTR2 bird[2009]: RTR1.ipv4: stop import: rr 2 set 0 valid 0 pruning 0 pruned 0 Dec 18 12:37:23 RTR2 bird[2009]: RTR1: State changed to stop Dec 18 12:37:23 RTR2 bird[2009]: RTR1: State changed to flush Dec 18 12:37:24 RTR2 bird[2009]: RTR1: State changed to down Dec 18 12:37:24 RTR2 bird[2009]: Shutdown completed I also tried running the same config, but by starting BIRD processes manually as a root in foreground. It was able to load the routes, but only if pointed ipv4 channel of bgp protocol to custom separate table. As soon as I passed it into my master4 table process crashed with segfault. Unfortunately without meaningful traceback. I don't know if is important, but I use VPP as my dataplane. Pozdrawiam, Łukasz Jarosz

1 0

Writing filters that detect intersection between a prefix and a prefix set
by zx＠zxinc.org 16 Dec '25

16 Dec '25

Hello, I have a prefix set like [ 192.168.1.0/24+, 192.168.2.0/24+ ] and I want to write a filter that filters all prefixes intersects with the prefix set and accepts all others, that is, accepts 192.168.0.0/24, 192.168.3.0/24, 10.0.0.0/8, rejects 192.168.1.1/32, 192.168.1.0/24, 192.168.2.0/24, 192.168.2.0/23, 192.168.0.0/16, 192.0.0.0/8, Anyone who knows how to write such a filter? Is it possible? Thanks. ---- zx

2 2

BIRD 3.1.5 and 2.17.3 released
by Maria Matejka 11 Dec '25

11 Dec '25

Dear BIRD users, we are releasing BIRD versions 3.1.5 and 2.17.3. In 2.17.3, we have fixed a bug in RAdv prefix deprecation and a crash in BMP. In 3.1.5, we have fixed the same bug in RAdv, several crashes in MRT, some filter misbehavior, a reconfiguration crash in Babel, OSPF and RIP, included a thread group configuration and a fix for a very stupid bug causing the BSD kernel export to reject everything. Big thanks to all of you who helped us find and fix these issues! Packages are available on our website <https://bird.nic.cz/get-bird>. Debian and Ubuntu packages are available in our repository at <https://pkg.labs.nic.cz/doc?project=bird>. We are working on upstream RPM repositories as well. Happy routing! Maria and the BIRD Team -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

1 0

BGP Add-path multiplication
by Jon Langemak 11 Dec '25

11 Dec '25

Hi folks, I was doing some testing with BIRD in a hierarchical route reflector configuration. Something that looks like this... +--------+ +--------+ +--------+ +--------+ | Left | | Left | | Right | | Right | | Tier 2 | | Tier 1 | | Tier 1 | | Tier 2 | | RR | | RR | | RR | | RR | +-----------+ | | | | | | | | | | +--------+ +--------+ +--------+ +--------+ +------------+ | | | | | Sending | | Receiving | | PE Router | | PE Router | | | | | +-----------+ +--------+ +--------+ +--------+ +--------+ +------------+ | Left | | Left | | Right | | Right | | Tier 2 | | Tier 1 | | Tier 1 | | Tier 2 | | RR | | RR | | RR | | RR | | | | | | | | | +--------+ +--------+ +--------+ +--------+ Basically we have two PEs that are connected to local tier 2 RRs which then connect to the tier 1 RRs to form a mesh. I couldn't get the lines to not look a mess on the diagram but the peering looks as follows... * PE routers peer to both local tier 2 RRs (left or right side) * Tier 2 RRs peer to both tier 1 RRs (within left or right) * Tier 1 RRs peer to both tier 1 RRs (between left and right) The only peering exception in terms of a full mesh peering is that RRs of the same type do not peer together in the same area (left or right). In terms of the diagram that means that vertical peering between nodes does not exist. What I'm seeing is that in a peering configuration with BGP add-path BIRD is sending all of the paths it is aware of to all of its peers. For instance... * A prefix originated from the PE on the left side of the diagram shows up as one path in each left side tier 2 RR it is peered with (1 path in each left side tier 2 RR) * The left side tier 2 RRs both peer to each left side tier 1 RRs so they each send a path to each of the left side tier 1 RRs (2 paths in each left side tier 1 RR) * The left side tier 1 RRs both peer to each of the right side tier 1 RRs so they send both paths they are aware of to each right side tier 1 RR (4 paths in each right side tier 1 RR) * The right side tier 1 RRs both peer to each of the right side tier 2 RRs so they send their 4 paths to each right side tier 2 RR (8 paths in each right side tier 2 RR) * The right side (receiving) PE ends up getting 8 paths from each right side tier 2 RR meaning it has a total of 16 paths for one prefix. Put more simply - a single path originating in the left side ends up getting multiplied by a factor of two at each route reflector "layer". >From my basic understanding of the code I believe this happens because BIRD considers paths unique on a per neighbor basis. Because of this - identical paths learned from unique neighbors can get assigned unique path IDs and therefore be propagated through the topology. From my understanding of RFC 7911 - this sort of topology was not discussed so there is no defined means for how to handle add-path and the deduplication of these paths in this kind of hierarchical route reflector setup. However I believe that in some other BGP implementations you can configure the route reflectors to only send paths with unique next-hops which would effectively deduplicate the paths in this kind of topology. I was curious if other folks had run into this before and if there has been any talk about possible solutions for BIRD to work with add-path in a hierarchical route reflector model without the path multiplication occurring. Thanks! - Jon

1 1

RFC 4684 implementation in Bird
by Jerome Tollet (jtollet) 10 Dec '25

10 Dec '25

Hello Bird community, I was wondering if someone already considered the implementation of RFC 4684 in Bird. It's rather old but still helpful for some highly multi-tenant environments. Any advice on this would be much appreciated. Regards, Jerome

2 2

LLGR De-Preferencing
by Matt Corallo 01 Dec '25

01 Dec '25

It appears bird (2.17.1) doesn't implement the required LLGR de-preferencing logic, eg in a simple test environment with LLGR and one (otherwise-preferred) session down, bird shows it as still selected even though it has the stale flag (see below). Is there any way to do the required de-preferencing with filters or would a patch to implement this be simple? Thanks. bird> show route for 69.59.18.0 all Table master4: 69.59.18.0/24 unicast [localsyncb 17:06:58.262 from 10.242.243.12] * (101s) [AS397444i] Type: BGP univ BGP.origin: IGP BGP.as_path: 397444 BGP.next_hop: .... BGP.local_pref: 101 BGP.community: (65535,6) unicast [localsync 2025-11-30 from 10.242.242.12] (100) [AS397444i] Type: BGP univ BGP.origin: IGP BGP.as_path: 397444 BGP.next_hop: .... BGP.local_pref: 100

3 3