July 2026 - Bird-users - Mailing Lists

6VPE (VPNv6 over IPv4 MPLS): IPv6 route with IPv4 next-hop rejected by kernel — root cause found, patch attached
by Aleš Kopecký 13 Jul '26

13 Jul '26

Hello, While preparing a question about this symptom, I found the root cause and put together a working, tested patch against sysdep/linux/netlink.c. Posting the fix directly rather than just the question, since a patch is more actionable than a symptom report. Happy to open this as a GitLab MR if that's useful — wanted to get feedback from the list / maintainers first, since I'm not fully sure this is the right layer to fix it at. == Environment == BIRD: 3.3.1 (bird3 3.3.1-cznic.1~trixie, Debian 13 test box) Kernel: 6.12.86 (Debian test), production runs Gentoo Role: egress PE, seamless-MPLS BGP L3VPN (AS 197296), IPv4-only underlay (OSPFv2 + BGP-LU), adding IPv6 as 6VPE (RFC 4659) over the IPv4 transport, extended next hop capability enabled on the vpn6 channel, no IPv6 IGP / LDPv6 anywhere in the underlay. == Symptom (unchanged from the original report) == Control plane resolution is complete and correct — BIRD resolves the VPNv6 route recursively via the IPv4 labeled table and builds the correct double MPLS label stack: show route table vpntab6 all 2a02:d280:201::/64 mpls 1207 unicast [proto_bgp_rr] * (100/?) [?] via 172.21.1.1 on lan mpls 24482/16 hostentry: via 100.127.1.26 table master4_lu mpls 16 But kernel export fails for these routes: show route table table_vpn6_overlay 2a02:d280:201::/64 unicast [l3_overlay] ! (80/?) via 172.21.1.1 on lan mpls 24482/16 <bird>: Netlink: Invalid argument (repeated, once per scan cycle) == Root cause == Confirmed by manual reproduction outside BIRD: # ip -6 route add 2a02:d280:300::/40 encap mpls 24481/1033 via inet 172.21.1.1 dev lan table 20 Error: IPv6 does not support RTA_VIA attribute. net/ipv6/route.c in mainline Linux does not accept RTA_VIA (the netlink attribute for a cross-family nexthop) on an IPv6 route, full stop — regardless of whether the address is a raw IPv4 address or an IPv4-mapped IPv6 address. Since our underlay is IPv4-only, every VPNv6 route we import resolves (via the IPv4-labeled IGP table) to a physically IPv4-family adjacency, so every such route hits this kernel limitation. In sysdep/linux/netlink.c, nl_add_nexthop() is exactly where this happens: if (ipa_nonzero(nh->gw)) { if (af == (ipa_is_ip4(nh->gw) ? AF_INET : AF_INET6)) nl_add_attr_ipa(h, bufsize, RTA_GATEWAY, nh->gw); /* same family, OK */ else nl_add_attr_via(h, bufsize, nh->gw); /* cross-family -> rejected for v6 */ } The MPLS encap (nl_add_attr_mpls_encap(), a few lines above) is completely independent of this gateway-family branch — it's already correctly built from the hostentry-resolved label stack before the gateway is even considered. So fixing the gateway encoding does not touch the label stack at all. This looks like the mirror case of RFC 8950 (v4-via-v6, "IPv6 next hop for IPv4 NLRI", which the kernel does support): what we need here is the opposite direction, v6-via-v4, for which the kernel intentionally has no FIB representation. For an MPLS-encapsulated route, though, the gateway is only used to pick the L2 adjacency (the packet leaves as an MPLS frame, so the address family of the nexthop is otherwise irrelevant to forwarding), which means we don't actually need the kernel to support v6-via-v4 in general — we just need *some* valid on-link IPv6 address for that neighbor. == Two things I ruled out first (documenting so nobody re-treads this) == 1. Overriding gw in a kernel export filter (`if ifname = "lan" then gw = fe80::1;`): the route becomes installable, but overriding gw forces BIRD to recompute the nexthop as non-recursive/explicit, which drops the label stack from the hostentry resolution. Installable but non-forwarding. 2. BGP-side "next hop address" / extended-nexthop config changes: these only affect what *we* advertise for routes *we* originate. They have no effect on how imported routes (from the RR, next-hop = remote PE loopback) get resolved — that resolution goes through our IPv4-only IGP table (master4_lu) regardless of how our own next-hop attribute is encoded. Also, disabling extended-nexthop entirely makes BIRD reject the config outright ("Mismatched IGP table type") since it then requires the next-hop family to match the IGP table family. Verified both variants live against production traffic; neither changes the kernel-export outcome. == The patch == Confirmed the neighboring router already sends IPv6 Router Advertisements on the segment (independent of any IPv6 IGP — RA is link-scoped), so the kernel already keeps a working ND cache entry for it: ip -6 neigh show dev lan fe80::1 lladdr dc:68:0c:32:ed:b2 router STALE The attached patch adds a small on-link-router cache to netlink.c (mirrors the existing AF_BRIDGE FDB cache/parsing that's already in the file, just generalized to AF_INET6 neighbors flagged NTF_ROUTER), refreshed once per KRT scan cycle. In nl_add_nexthop(), when exporting an IPv6 route whose resolved gateway is IPv4-family, it looks up this cache by egress interface and substitutes the neighbor's real link-local address for RTA_GATEWAY instead of building the (rejected) RTA_VIA — the MPLS encap is untouched. No interface name or address is hardcoded anywhere; it's fully derived from what the kernel already knows via ND. If the cache has no entry yet for that interface, behavior is unchanged from today (route stays uninstalled, self-heals on the next scan) — no regression. Diff attached: 0001-netlink-ipv6-onlink-router-cache-for-6vpe-mpls-nexthop.diff (against v3.3.1, 4 hunks, all confined to sysdep/linux/netlink.c). == Test results (live, on a production-representative PE) == show route table table_vpn6_overlay -> routes now "*" (were "!") ip -6 route show table 20 2a02:d280:201::/64 encap mpls 24482/16 via fe80::1 dev lan proto bird ip -6 route get 2a02:d280:200::1 ... encap mpls 24481/1032 via fe80::1 dev lan ... (correct FIB lookup) ip -6 neigh show dev lan fe80::1 lladdr dc:68:0c:32:ed:b2 router REACHABLE journalctl -u bird -> no more "Netlink: Invalid argument" End-to-end ping from a live CPE through the fixed path: 171/171 received, 0% loss. == Questions for the list / maintainers == 1. Is this an acceptable place/approach to fix this, or would you rather see it handled differently (e.g. in rt-table.c nexthop resolution itself, or as an explicit config knob rather than automatic ND-based discovery)? 2. Known edge case: if a segment ever has more than one NTF_ROUTER neighbor on the same interface, the cache currently keeps whichever one was last seen in the dump (non-deterministic ordering). Not an issue in our topology (always exactly one router per segment), but worth flagging. 3. Cache refresh is tied to the existing KRT scan interval rather than the async netlink notification path, to avoid touching the shared AF_BRIDGE dispatch code. Happy to change this if an event-driven refresh is preferred upstream. Willing to open this as a merge request, test further, or provide more captures/config context — just let me know the preferred path. Thanks a lot for BIRD. Aleš Kopecký AS 197296 ales.kopecky(a)u-n.cz Attachments: 0001-netlink-ipv6-onlink-router-cache-for-6vpe-mpls-nexthop.diff

2 2

HTML archive of bird-users not generating
by Lars Gierth 13 Jul '26

13 Jul '26

Hi, I noticed the HTML archive at https://bird.network.cz/pipermail/bird-users/2026-June/subject.html hasn't been regenerating since ~1 month ago. Last message there is from Thu Jun 11 17:43:35 CEST 2026 Cheers, Lars

2 1

Fwd: [Battlemesh] Battlemesh v18 Announcement
by Linus Lüssing 12 Jul '26

12 Jul '26

Hi, I hope it's not rude forwarding emails to this ML / advertising as a first post. But I thought maybe some people here could be interested in this event. Regards, Linus ----- Forwarded message from "Chester A. Unal via Battlemesh" <battlemesh(a)ml.ninux.org> ----- Date: Mon, 1 Jun 2026 06:51:02 +0000 (UTC) From: "Chester A. Unal via Battlemesh" <battlemesh(a)ml.ninux.org> To: battlemesh(a)ml.ninux.org Cc: "Chester A. Unal" <chester.a.unal(a)arinc9.com> Subject: [Battlemesh] Battlemesh v18 Announcement Hello everyone! We're announcing the 18th edition of the Wireless Battle of the Mesh! Date: 7-13 September 2026, 7 days Venue: Pueblo Escondido at Gornji Karin, Croatia Battlemesh features a variety of talks and workshops on technical and political issues related to mesh networking, wireless community networks and OpenWrt firmware development. The purpose of the event is to further topics such as right to connectivity, community-owned infrastructure and related free open source projects. The event is free of charge and open for all. Registering: Add yourself to the participants list. If you'd rather not have your name there, please send an email to the organisation team with the same information displayed on the participants list. https://www.battlemesh.org/BattleMeshV18/Participants Accomodation: The event space allows for camping on site either in your own tent or camper vans. The charge is 15 EUR per night per person. For those preferring indoor accommodation, numerous small hotels and/or privately owned apartments are available in the near vicinity. Booking can be arranged individually or via recommendation by the Karin team. More information: https://www.battlemesh.org/BattleMeshV18 Please help us spread the word by sharing this announcement. Battlemesh v18 Organisers _______________________________________________ Battlemesh mailing list Battlemesh(a)ml.ninux.org https://ml.ninux.org/mailman/listinfo/battlemesh ----- End forwarded message -----

1 0

And AI-based bug hunters have arrived at BIRD
by Douglas Fischer 10 Jul '26

10 Jul '26

This has become a common occurrence across various open-source projects. It seems like there’s a massive investment in tokens—a desperate scramble to find any opening to shoehorn a patch into the codebase, just to post about it on LinkedIn. I’ve seen a range of attitudes toward this: from code maintainers fully embracing it (which is actually a bit unsettling) to outright blocking anything AI-generated (sometimes discarding potentially interesting contributions in the process). I think the best suggestion I’ve seen is a middle-ground approach. Projects could build the necessary infrastructure internally to support AI-driven activities, treating them as native to the project rather than the work of an external entity simply scouring for opportunities. This would allow interested individuals to contribute their tokens to run whatever tests they deem appropriate. I don't believe the current volume justifies the effort. But once it starts to become excessive, that idea might be worth considering. -- Douglas Fernando Fischer Engº de Controle e Automação

2 1

BGP AGGREGATOR / AS4_AGGREGATOR with AS=0 is accepted and may be propagated
by xinzhe liu 09 Jul '26

09 Jul '26

Hello BIRD maintainers, I would like to report a possible issue in BIRD. ### Summary BIRD appears to accept a BGP UPDATE containing `AS4_AGGREGATOR` with AS number 0 from a non-AS4 peer. When the same UPDATE also contains `AGGREGATOR` with `AS_TRANS`, BIRD's AS4 transition processing converts the `AS4_AGGREGATOR` value into the effective `AGGREGATOR` attribute. In dynamic testing, BIRD installed the route with: ```text BGP.aggregator: 192.0.2.9 AS0 ``` and then exported the route to a downstream non-AS4 peer with: ```text AGGREGATOR flags=0xc0 as=0 addr=192.0.2.9 ``` I am reporting this as an RFC 7607 conformance / input-validation issue, not as a high-impact security vulnerability. ### Expected Behavior RFC 7607 Section 2 says that a BGP speaker MUST NOT originate or propagate a route with AS number zero in the `AS_PATH`, `AS4_PATH`, `AGGREGATOR`, or `AS4_AGGREGATOR` attributes. An UPDATE containing AS 0 in `AS4_AGGREGATOR` should cause the `AS4_AGGREGATOR` attribute to be considered malformed under RFC 7607 and handled according to RFC 6793. In other words, the attribute should be discarded and the UPDATE may continue to be processed. However, the `AS4_AGGREGATOR` value must not become the effective `AGGREGATOR` attribute, and BIRD must not install or export the route with `AGGREGATOR AS=0`. ### Actual Behavior BIRD continues processing the UPDATE, but the malformed `AS4_AGGREGATOR` value becomes the effective `AGGREGATOR` attribute. The route is installed with `BGP.aggregator: 192.0.2.9 AS0`, and BIRD exports an `AGGREGATOR` attribute whose AS field is 0. ### Steps to Reproduce 1. Start BIRD with a dynamic BGP listener: ```bird router id 127.0.0.1; protocol device { } protocol bgp as4agg_as0 { local 127.0.0.1 port 11918 as 65001; neighbor range 127.0.0.0/8 external; dynamic name "poc"; multihop; ipv4 { import all; export all; }; } ``` 2. Connect an upstream peer from `127.0.0.2`, AS 65002, without advertising AS4 capability. 3. Send an UPDATE for `203.0.113.0/24` containing: ```text ORIGIN = IGP AS_PATH = 65002 NEXT_HOP = 127.0.0.2 AGGREGATOR = AS_TRANS / 192.0.2.9 AS4_AGGREGATOR = AS 0 / 192.0.2.9 ``` 4. Query the local RIB: ```text birdc show route 203.0.113.0/24 all ``` 5. Connect a downstream peer from `127.0.0.3`, AS 65003, also without AS4 capability, and inspect the UPDATE exported by BIRD. ### Dynamic Verification This was reproduced against: ```text BIRD version 2.19.0+branch.master.880200b1f94c ``` Local RIB: ```text 203.0.113.0/24 unreachable [poc1 ... from 127.0.0.2] * (100) [AS65002i] Type: BGP univ BGP.origin: IGP BGP.as_path: 65002 BGP.next_hop: 127.0.0.2 BGP.local_pref: 100 BGP.aggregator: 192.0.2.9 AS0 ``` Downstream export: ```text [+] Exported AGGREGATOR flags=0xc0 as=0 addr=192.0.2.9 VERDICT: NON_COMPLIANT_REPRODUCED_ACCEPTED_AND_PROPAGATED ``` ### Source Analysis `AS4_AGGREGATOR` decoding checks whether the session is already AS4-capable and whether the attribute length is 8, but it does not check whether the AS field is 0: ```c static void bgp_decode_as4_aggregator(...) { if (s->as4_session) DISCARD(NEW_BGP, "AS4_AGGREGATOR"); if (len != 8) DISCARD(BAD_LENGTH, "AS4_AGGREGATOR", len); bgp_set_attr_data(to, s->pool, BA_AS4_AGGREGATOR, flags, data, len); } ``` During AS4 transition processing, if both `AGGREGATOR` and `AS4_AGGREGATOR` are present and `AGGREGATOR` has `AS_TRANS`, BIRD uses `AS4_AGGREGATOR` as the effective `AGGREGATOR`: ```c if (a2 && a4) { u32 a2_asn = get_u32(a2->u.ptr->data); if (a2_asn != AS_TRANS) return; /* Use AS4_AGGREGATOR instead of AGGREGATOR */ a2->u.ptr = a4->u.ptr; } ``` There appears to be no AS 0 validation on either `AGGREGATOR` or `AS4_AGGREGATOR`. ### Comparison FRR checks AS 0 for both `AGGREGATOR` and `AS4_AGGREGATOR`. If the AS is 0, FRR logs the condition and does not mark the attribute as present for propagation. ### Impact The practical impact is interoperability and malformed route propagation. BIRD may propagate a route with invalid AS 0 aggregator metadata, which can cause downstream implementations with stricter RFC 7607 handling to reject, withdraw, or otherwise handle the route inconsistently. This does not directly imply route hijacking. `AGGREGATOR` is not the primary AS loop detection input; `AS_PATH` and `AS4_PATH` are. ### Suggested Fix Direction Add AS 0 validation for `AGGREGATOR` and `AS4_AGGREGATOR` during decode or before AS4 transition reconstruction. In particular, an `AS4_AGGREGATOR` whose first four bytes decode to ASN 0 should not be allowed to become the effective `AGGREGATOR` attribute or be propagated downstream.

2 1

OSPFv2: PtP stub interface
by Lexi Winter 09 Jul '26

09 Jul '26

hello, i'm using BIRD 3.2.0 on FreeBSD 15.0. i have a PPPoE interface with a point-to-point IPv4 address configured: ng0: flags=10088d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500 options=0 inet 81.187.73.117 --> 81.187.81.187/32 inet6 2001:8b0:aab5:1::1/128 inet6 fe80::227c:14ff:fef3:d8f7%ng0/64 scopeid 0x12 groups: arpa nd6 options=1<PERFORMNUD> i would like to advertise this in OSPF as a passive interface, so i configured the OSPF protocol: define OSPF_V6_EXPORT = [ ]; define OSPF_V4_EXPORT = [ 0.0.0.0/0 ]; filter ospf_export { if (net ~ OSPF_V6_EXPORT) then accept; if (net ~ OSPF_V4_EXPORT) then accept; reject; }; protocol ospf v2 core4 { ipv4 { export filter ospf_export; import all; }; area 0 { interface "ng0" { stub yes; }; [... other config elided ...] }; } however, BIRD does not advertise 81.187.73.117/32 in OSPF. it *does* advertise 81.187.81.187/32, which is the remote side of the interface. the interface looks fine in BIRD: bird> show ospf interface "ng0" core6: core4: Interface ng0 (peer 81.187.81.187) Type: ptp Area: 0.0.0.0 (0) State: PtP (stub) Priority: 1 Cost: 10 ECMP weight: 1 Hello timer: 10 Wait timer: 40 Dead timer: 40 Retransmit timer: 5 the route: bird> show route for 81.187.73.117/32 Table master4: 0.0.0.0/0 unicast [kernel4 2026-07-04] ! (10) via 81.187.81.187 on ng0 81.187.73.117/32 unicast [kernel4 2026-07-04] ! (10) dev lo0 if i add 81.187.73.117/32 to OSPF_V4_EXPORT, then it is correctly advertised as an E2 route, which is fine as a workaround, but i would like to understand why the interface configuration doesn't work.

3 5

BGP: KEEPALIVE with length != 19 is accepted instead of rejected with Bad Message Length
by xinzhe liu 08 Jul '26

08 Jul '26

Hello BIRD maintainers, I would like to report a possible issue in BIRD. ### Summary BIRD appears to accept BGP KEEPALIVE messages whose BGP message length is greater than 19 bytes. RFC 4271 defines KEEPALIVE as only the fixed BGP message header, so a valid KEEPALIVE has length 19 and no body. In dynamic testing, a BGP peer established a session with BIRD and then sent a KEEPALIVE with length 23 and a 4-byte payload. BIRD treated the malformed message as a normal KEEPALIVE, refreshed the session, and kept the BGP state Established. I am reporting this as a low-severity RFC conformance / input validation issue, not as a high-impact security vulnerability. ### Expected Behavior When BIRD receives a KEEPALIVE message whose BGP message length is not exactly 19 bytes, it should reject the message with: ```text Error Code: Message Header Error Error Subcode: Bad Message Length ``` That is, an oversized KEEPALIVE should not be accepted as a valid KEEPALIVE. ### Actual Behavior BIRD accepts a KEEPALIVE with a 4-byte payload: ```text BGP message type: KEEPALIVE BGP message length: 23 Payload length: 4 bytes Payload bytes: 41 42 43 44 ``` After the malformed KEEPALIVE is sent, `birdc show protocols all` still reports the BGP session as Established: ```text keepalive_len_test BGP --- up ... Established BGP state: Established ``` The BIRD log records the malformed message as a normal KEEPALIVE: ```text keepalive_len_test: Got KEEPALIVE ``` No Header Error / Bad Message Length NOTIFICATION was observed. ### Steps to Reproduce 1. Configure a BGP peer, for example: ```bird router id 127.0.0.1; protocol device { } protocol bgp keepalive_len_test { local 127.0.0.1 port 11879 as 65001; neighbor 127.0.0.2 as 65002; multihop; passive on; ipv4 { import all; export none; }; } ``` 2. Establish the BGP session with normal OPEN and KEEPALIVE messages. 3. Send the malformed KEEPALIVE: ```text ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00 17 04 41 42 43 44 ``` This is a BGP KEEPALIVE (`type=4`) with total length `0x0017` (23) and a 4-byte body. ### Dynamic Verification This was reproduced against: ```text BIRD version 2.19.0+branch.master.880200b1f94c ``` PoC output: ```text === BIRD oversized KEEPALIVE length PoC === [+] TCP connected: ('127.0.0.2', ...) -> ('127.0.0.1', 11879) [*] Sent BGP OPEN [*] Received pre-test message: type=1 body_len=34 [*] Sent normal KEEPALIVE [*] Received pre-test message: type=4 body_len=0 [*] Sending malformed KEEPALIVE: length=23, payload_len=4 [*] Received post-test message: type=2 body=00000000 ... keepalive_len_test BGP --- up ... Established [+] Socket still writable after malformed KEEPALIVE [!] BIRD accepted an oversized KEEPALIVE and kept the session Established VERDICT: NON_COMPLIANT_REPRODUCED ``` The post-test `type=2 body=00000000` message is an UPDATE carrying an IPv4 End-of-RIB marker. It is not a Header Error NOTIFICATION. ### Source Analysis The generic receive loop checks only that the BGP message length is within the global BGP message bounds: ```c if ((len < BGP_HEADER_LENGTH) || (len > bgp_max_packet_length(conn))) { bgp_error(conn, 1, 2, pkt_start+16, 2); break; } ``` Then `bgp_rx_packet()` dispatches KEEPALIVE messages without passing the packet length to `bgp_rx_keepalive()`: ```c case PKT_KEEPALIVE: return bgp_rx_keepalive(conn); ``` `bgp_rx_keepalive()` therefore cannot reject a KEEPALIVE whose length is greater than 19 bytes: ```c static void bgp_rx_keepalive(struct bgp_conn *conn) { ... bgp_start_timer(conn->hold_timer, conn->hold_time); ... } ``` ### Comparison For comparison, FRR 10.6.1 rejects the same malformed KEEPALIVE with NOTIFICATION `1/2` (`Message Header Error / Bad Message Length`). FRR has an explicit check that KEEPALIVE length must equal 19: ```c type == BGP_MSG_KEEPALIVE && size != BGP_MSG_KEEPALIVE_MIN_SIZE ``` where `BGP_MSG_KEEPALIVE_MIN_SIZE` is `BGP_HEADER_SIZE + 0`. ### Impact The practical impact appears low. A malformed KEEPALIVE is accepted and refreshes the hold timer instead of being rejected as a protocol error. This does not appear to create parser desynchronization, because the extra bytes are consumed as part of the same BGP message. The sender also needs to be an established BGP peer or an on-path attacker capable of injecting/modifying BGP traffic. The issue is best described as an RFC 4271 conformance and malformed input validation bug. ### Suggested Fix Direction Add a KEEPALIVE-specific length check in `bgp_rx_packet()` before dispatching to `bgp_rx_keepalive()`. That avoids changing the `bgp_rx_keepalive()` function signature: ```c static void bgp_rx_packet(struct bgp_conn *conn, byte *pkt, uint len) { byte type = pkt[18]; if ((type == PKT_KEEPALIVE) && (len != BGP_HEADER_LENGTH)) { bgp_error(conn, 1, 2, pkt + 16, 2); return; } ... } ``` The `pkt + 16` data field points to the erroneous Length field, matching the usual Bad Message Length NOTIFICATION data. Best regards.

1 0

BGP merge paths uses AS_PATH length, not AS_PATH equality or same remote-AS, for ECMP equivalence
by xinzhe liu 07 Jul '26

07 Jul '26

Hello BIRD maintainers, I would like to ask for clarification about BIRD's BGP `merge paths` equivalence rules. BIRD 2.19.0+ appears to use an AS_PATH-length-based equivalence check for BGP routes when kernel `merge paths` is enabled. In the reproduced cases, BIRD exported one ECMP route from two BGP paths even though: 1. The two eBGP paths came from different neighboring ASes, and their AS_PATH contents were different. 2. The two iBGP paths had different AS_PATH contents. The common condition was that both paths had the same AS_PATH length and otherwise equal attributes. This looks similar to AS-path multipath-relax behavior in implementations such as FRR, but in FRR this relaxed behavior is enabled by an explicit `bgp bestpath as-path multipath-relax` option. FRR's default multipath behavior is stricter: eBGP multipath requires the same remote AS, and iBGP multipath requires matching AS_PATH contents. I am reporting this as a route-merging behavior / correctness concern and documentation clarification request, not as a security vulnerability or a strict RFC 4271 violation. ## Version Tested I reproduced this on: ```text BIRD version 2.19.0+branch.master.880200b1f94c ``` The PoC intentionally refuses to run against versions older than 2.19.0. ## Background BIRD's documentation for the kernel protocol says that `merge paths` merges best routes and "equivalent non-best routes" to generate one ECMP route: ```text With path merging enabled, both best routes and equivalent non-best routes are merged during export to generate one ECMP (equal-cost multipath) route for each network. ``` The question is what counts as BGP-equivalent for this purpose. The current documentation does not appear to make clear that equivalence can mean equal AS_PATH length rather than equal AS_PATH contents or same eBGP neighboring AS. For comparison, FRR's default behavior is: - iBGP paths are multipath-equivalent only when AS_PATH contents match. - eBGP paths are multipath-equivalent only when the remote AS is the same. - Different AS_PATHs of equal length are allowed only when the explicit `bgp bestpath as-path multipath-relax` knob is enabled. ## Expected Behavior / Documentation I expected BIRD either to avoid merging such paths by default, or to document that `merge paths` intentionally uses an AS_PATH-length-based relaxed equivalence rule. For example, I did not expect these two eBGP routes to be treated as ECMP-equivalent unless this relaxed rule is intentional and documented: ```text Route A: remote AS 65100, AS_PATH 65100 65200 Route B: remote AS 65300, AS_PATH 65300 65400 ``` Likewise, I did not expect these two iBGP routes to be treated as ECMP-equivalent unless AS_PATH-length-based equivalence is the intended behavior: ```text Route A: AS_PATH 65010 65020 Route B: AS_PATH 65030 65040 ``` If this relaxed behavior is intentional, it may be helpful to document it explicitly or expose a configuration knob similar to FRR's AS-path multipath relax option. ## Actual Behavior With `merge paths yes` enabled, BIRD exported a merged ECMP route in both cases. ### Case 1: eBGP paths from different neighboring ASes The PoC announced the same prefix from two synthetic eBGP peers: ```text Peer A: source: 127.0.0.11 remote AS: 65100 AS_PATH: 65100 65200 next-hop: 10.10.0.11 Peer B: source: 127.0.0.12 remote AS: 65300 AS_PATH: 65300 65400 next-hop: 10.10.0.12 ``` BIRD showed both BGP routes: ```text 203.0.113.0/24 unicast [poc_peer1 ... from 127.0.0.11] ! (100/?) [AS65200i] via 192.0.2.11 on lo onlink BGP.origin: IGP BGP.as_path: 65100 65200 BGP.next_hop: 10.10.0.11 BGP.local_pref: 100 unicast [poc_peer2 ... from 127.0.0.12] (100/?) [AS65400i] via 192.0.2.12 on lo onlink BGP.origin: IGP BGP.as_path: 65300 65400 BGP.next_hop: 10.10.0.12 BGP.local_pref: 100 ``` The merged export view for the kernel protocol contained both nexthops: ```text 203.0.113.0/24 unicast [poc_peer1 ... from 127.0.0.11] ! (100/?) [AS65200i] via 192.0.2.11 on lo onlink weight 1 via 192.0.2.12 on lo onlink weight 1 BGP.origin: IGP BGP.as_path: 65100 65200 BGP.next_hop: 10.10.0.11 BGP.local_pref: 100 ``` ### Case 2: iBGP paths with different AS_PATH contents The PoC also reproduced the behavior with two iBGP peers: ```text Peer A: source: 127.0.0.11 AS_PATH: 65010 65020 next-hop: 10.10.0.11 Peer B: source: 127.0.0.12 AS_PATH: 65030 65040 next-hop: 10.10.0.12 ``` BIRD again exported one merged route: ```text 203.0.113.0/24 unicast [poc_peer1 ... from 127.0.0.11] ! (100/?) [AS65020i] via 192.0.2.11 on lo onlink weight 1 via 192.0.2.12 on lo onlink weight 1 BGP.origin: IGP BGP.as_path: 65010 65020 BGP.next_hop: 10.10.0.11 BGP.local_pref: 100 ``` ## Steps to Reproduce The attached PoC starts a private BIRD instance, creates two synthetic BGP peers, advertises the same IPv4 prefix twice, and enables kernel `merge paths`. Run the eBGP case: ```sh python3 poc_bird_bgp_multipath_aspath.py --keep-workdir ``` Run the iBGP case: ```sh python3 poc_bird_bgp_multipath_aspath.py --case ibgp --keep-workdir ``` Expected reproduced signal: ```text RESULT: BIRD treated the routes as merge-paths equivalent and produced ECMP export view. ``` The script exits with status `2` when the behavior is reproduced. On an unprivileged account, BIRD may log netlink permission errors and the Linux kernel table may remain empty. The important evidence is the `birdc show route export krt_poc 203.0.113.0/24 all` output, because BIRD's CLI uses the same `rt_export_merged()` path to construct the merged export route. ## Source-Level Analysis BIRD's BGP merge predicate checks AS_PATH length but not full AS_PATH equality or same eBGP neighboring AS. In `proto/bgp/attrs.c`, `bgp_rte_mergable()` checks local preference, resolvability, LLGR stale state, AS_PATH length, origin, MED, peer type, and IGP metric: ```c /* RFC 4271 9.1.2.2. a) Use AS path lengths */ if (pri_bgp->cf->compare_path_lengths || sec_bgp->cf->compare_path_lengths) { x = ea_find(pri->attrs->eattrs, EA_CODE(PROTOCOL_BGP, BA_AS_PATH)); y = ea_find(sec->attrs->eattrs, EA_CODE(PROTOCOL_BGP, BA_AS_PATH)); p = x ? as_path_getlen(x->u.ptr) : AS_PATH_MAXLEN; s = y ? as_path_getlen(y->u.ptr) : AS_PATH_MAXLEN; if (p != s) return 0; } ``` It prevents mixing iBGP and eBGP paths: ```c /* RFC 4271 9.1.2.2. d) Prefer external peers */ if (pri_bgp->is_interior != sec_bgp->is_interior) return 0; ``` But after checking IGP metric, the remaining criteria are ignored: ```c /* Remaining criteria are ignored */ return 1; ``` I did not find a check equivalent to: - for iBGP: full AS_PATH contents must match, or - for eBGP: neighboring AS must match. ## Comparison with FRR FRR explicitly distinguishes relaxed and non-relaxed multipath behavior. In its default mode: ```c } else if (peer_new->sort == BGP_PEER_IBGP) { if (aspath_cmp(new->attr->aspath, exist->attr->aspath)) { *paths_eq = 1; } } else if (peer_new->as == peer_exist->as) { *paths_eq = 1; } ``` FRR only allows different AS_PATH contents of the same length when the explicit AS-path multipath relax flag is configured: ```c } else if (CHECK_FLAG(bgp->flags, BGP_FLAG_ASPATH_MULTIPATH_RELAX)) { *paths_eq = 1; } ``` This makes the relaxed behavior visible to operators as an intentional configuration choice. ## Impact When `merge paths` is enabled, BIRD may export ECMP routes whose contributing BGP paths would not be considered multipath-equivalent by implementations such as FRR unless an explicit AS-path multipath-relax option is enabled. Potential consequences include: 1. Traffic sharing across different upstream ASes when the operator expected same-AS eBGP multipath only. 2. Traffic sharing across iBGP paths that have different AS_PATH contents. 3. Policy surprises when one AS_PATH would normally be considered non-equivalent to another even though their lengths match. 4. Interoperability differences compared with implementations such as FRR that require explicit AS-path multipath relaxation. This impact is configuration-dependent. It requires `merge paths` or equivalent multipath export behavior to be enabled. It is not a session-reset issue and is not being reported as a security vulnerability. ## Suggested Fix or Clarification If the current behavior is unintentional, BIRD could make `bgp_rte_mergable()` stricter by default: 1. For iBGP routes, require full AS_PATH equality before merging. 2. For eBGP routes, require the same neighboring AS before merging. 3. Optionally add a configuration knob to allow the current relaxed behavior explicitly, similar to FRR's `bgp bestpath as-path multipath-relax`. If the current behavior is intentional, documenting that `merge paths` may merge BGP routes with different AS_PATH contents or different eBGP neighboring ASes when AS_PATH lengths are equal would help operators understand the policy impact. In other words, this may simply be intentional relaxed multipath behavior. I am reporting it because the documentation says "equivalent non-best routes" but does not appear to define that equivalence as AS_PATH-length-based rather than AS_PATH-content-based or same-neighboring-AS-based. Best regards.

2 1

L3VPN route may resolve over IP-only recursive NEXT_HOP and produce VPN-label-only nexthop
by xinzhe liu 07 Jul '26

07 Jul '26

Hello BIRD maintainers, I would like to ask for clarification about BIRD's MPLS L3VPN/VPNv4 nexthop validation behavior. I am reporting this as a forwarding-correctness and documentation concern, not as a security vulnerability or a strict RFC 4364 violation. ## Summary With BIRD 2.19.0+, I can reproduce a case where a VPNv4 route with a VPN service label is accepted as a unicast route when its BGP NEXT_HOP is resolved only by an ordinary IP route. The resolved nexthop contains the VPN service label, but no transport label for reaching the remote PE. In the reproduced setup: ```text VPN prefix: 65000:100 203.0.113.0/24 BGP NEXT_HOP: 10.10.0.1 Underlay route: 10.10.0.1/32 via 192.0.2.1 dev lo onlink VPN service label: 100 Transport label: none ``` BIRD reports the route as reachable: ```text 65000:100 203.0.113.0/24 mpls 1000 unicast [vpn_peer1 ... from 127.0.0.11] * (100/?) [AS65100i] via 192.0.2.1 on lo mpls 100 onlink BGP.next_hop: 10.10.0.1 BGP.mpls_label_stack: 100 ``` The important part is: ```text via 192.0.2.1 on lo mpls 100 onlink ``` This appears to mean that the L3VPN route can resolve over an IP-only recursive NEXT_HOP and produce a nexthop carrying only the VPN service label. ## Version Tested Reproduced against: ```text BIRD version 2.19.0+branch.master.880200b1f94c ``` The PoC intentionally refuses to run against versions older than 2.19.0. ## Why I am asking I understand that a single-label L3VPN packet is not always wrong. For example, it may be valid when the remote PE is directly adjacent, when PHP removes the transport label before the final hop, or when another explicitly configured tunnel or encapsulation mechanism is used. The case I am concerned about is a multi-hop MPLS L3VPN topology where the BGP NEXT_HOP is not the directly attached IGP next hop and no GRE/SR/static-tunnel exception is configured. In such a topology, an IP-only recursive route to the remote PE can cause BIRD to install/export a VPN-label-only nexthop. An ordinary P router would not know how to forward a packet that carries only the remote VPN service label. ## Expected Behavior or Documentation For MPLS L3VPN deployments that require a label-switched transport path to the remote PE, I expected BIRD either to verify that recursive NEXT_HOP resolution provides a transport label, or to clearly document that IP-only recursive resolution is accepted and operators must ensure the required transport/tunnel by other means. In other words, if the current behavior is intentional, it would be helpful for the documentation to say that `vpn4 mpls` routes may be considered reachable through an unlabeled recursive IP nexthop, and that BIRD may emit only the VPN service label unless the underlay route itself provides transport labels. ## Control-Plane Reproduction The attached PoC starts a private BIRD instance, installs an unlabeled underlay route to a remote PE address, and injects a VPNv4/MPLS route. Run: ```sh python3 poc_bird_l3vpn_labeled_nexthop.py --keep-workdir ``` Reproduced signal: ```text RESULT: BIRD accepted the VPN route as unicast using only the VPN service label. ``` The script exits with status `2` when the behavior is reproduced. ## Dataplane Verification I also verified the dataplane consequence by reproducing the resulting Linux route shape in an isolated user/network namespace: ```text 203.0.113.0/24 encap mpls 100 via 192.0.2.1 dev v0 ``` The dataplane helper creates a veth pair, installs the MPLS route above, sends one packet to `203.0.113.1`, and parses the Ethernet/MPLS frame observed on the peer veth. Run: ```sh python3 dataplane_linux_mpls_label_stack.py ``` Observed output: ```text ===== dataplane route ===== 203.0.113.0/24 encap mpls 100 via 192.0.2.1 dev v0 ===== captured frame ===== ETH_TYPE: 0x8847 LABEL_STACK: [{'label': 100, 'exp': 0, 'bos': 1, 'ttl': 64}] RESULT: reproduced VPN-label-only dataplane frame with a single MPLS label 100. ``` This confirms that a kernel route equivalent to BIRD's resolved nexthop emits a VPN-label-only MPLS frame on the dataplane. ## Source-Level Analysis BIRD correctly parses the VPN label from the VPNv4 NLRI and applies it to the route nexthop. In `proto/bgp/packets.c`, `bgp_decode_mpls_labels()` attaches the MPLS label stack and then calls `bgp_apply_mpls_labels()`: ```c bgp_set_attr_ptr(&(a->eattrs), s->pool, BA_MPLS_LABEL_STACK, 0, s-> mpls_labels); ... bgp_apply_mpls_labels(s, a, labels, lnum); ``` For recursive BGP NEXT_HOPs, `bgp_apply_next_hop()` gets a hostentry from the IGP table: ```c s->hostentry = rt_get_hostentry(tab, gw, lla, c->c.table); if (!s->mpls) rta_apply_hostentry(a, s->hostentry, NULL); /* With MPLS, hostentry is applied later in bgp_apply_mpls_labels() */ ``` Then `bgp_apply_mpls_labels()` combines the recursive hostentry nexthop with the VPN label: ```c mpls_label_stack ms; ms.len = lnum; memcpy(ms.stack, labels, 4*lnum); rta_apply_hostentry(a, s->hostentry, &ms); ``` In `nest/rt-table.c`, `rta_apply_hostentry()` prepends any labels from the recursive underlay nexthop and appends the VPN labels: ```c nhp->labels = nh->labels + mls->len; nhp->labels_orig = mls->len; memcpy(nhp->label, nh->label, nh->labels * sizeof(u32)); memcpy(&(nhp->label[nh->labels]), mls->stack, mls->len * sizeof(u32)); ``` This works when the recursive underlay route has transport labels. If `nh->labels == 0`, the resulting nexthop still contains the VPN label only. BIRD's generic BGP route resolvability check appears broader: ```c static inline int rte_resolvable(rte *rt) { return rt->attrs->dest != RTD_UNREACHABLE; } ``` I did not find an L3VPN-specific check that requires a labeled recursive nexthop before treating a VPN route as forwardable in deployments that depend on MPLS transport labels. ## Comparison with FRR FRR appears to distinguish ordinary IP reachability from labeled-nexthop reachability for L3VPN. In `bgpd/bgp_nht.c`, FRR documents the condition: ```c /* * In case of unicast routes that were imported from vpn * and that have labels, they are valid only if there are * nexthops with labels */ ``` The L3VPN nexthop check requires one of the accepted MPLS-forwarding conditions: ```c return (bnc && (bnc->nexthop_num > 0 && (CHECK_FLAG(path->flags, BGP_PATH_ACCEPT_OWN) || CHECK_FLAG(bnc->flags, BGP_NEXTHOP_LABELED_VALID) || bgp_isvalid_nexthop_for_ebgp(bnc, path) || bgp_isvalid_nexthop_for_mplsovergre(bnc, path)))); ``` `BGP_NEXTHOP_LABELED_VALID` is set only when the recursive nexthop received from zebra contains labels: ```c if (nexthop->nh_label && nexthop->nh_label->num_labels) { SET_FLAG(bnc->flags, BGP_NEXTHOP_LABELED_VALID); } ``` I am not suggesting that BIRD must copy FRR's behavior exactly. I am using this as a comparison point because FRR makes the transport-label requirement explicit for VPN-imported labeled routes, with documented exceptions. ## Impact In a multi-hop MPLS L3VPN topology where the BGP NEXT_HOP is not the directly attached IGP next hop and no GRE/SR/static-tunnel exception is configured, BIRD may install or export an L3VPN route whose outgoing label stack contains only the VPN service label. Potential consequences: 1. VPN traffic may be blackholed in the MPLS underlay. 2. Operators may see the route as installed and reachable even though MPLS forwarding cannot deliver it correctly in that topology. 3. BIRD behavior may surprise operators coming from implementations that explicitly require a labeled transport path for MPLS VPN routes. The impact is configuration-dependent. It may not apply to directly adjacent L3VPN deployments, PHP-at-final-hop cases, or deployments that explicitly use another encapsulation model. ## Suggested Fix or Clarification If this behavior is unintentional, BIRD could add an L3VPN-specific forwardability check before treating VPN routes as resolvable in recursive MPLS-underlay deployments: 1. When a VPN route has a service label and recursive NEXT_HOP resolution is used, verify that the resolved underlay nexthop carries at least one transport label. 2. If the recursive underlay route is IP-only and no accepted exception applies, mark the VPN route unreachable or avoid exporting/installing it as an MPLS-forwardable L3VPN route. 3. Consider explicit exceptions for directly connected L3VPN, GRE/tunnel forwarding, SR, PHP-sensitive cases, or other documented encapsulation modes. If the current behavior is intentional, documenting it would help operators understand that BIRD may resolve VPN routes over unlabeled IP underlay routes and emit only the VPN service label unless they ensure the transport path separately. Thank you for taking a look.

1 0

RFC 8538 Graceful Notification / N-bit / Hard Reset support
by xinzhe liu 07 Jul '26

07 Jul '26

Hello BIRD maintainers, I would like to report that BIRD does not currently implement RFC 8538 (Notification Message Support for BGP Graceful Restart). This is not a protocol violation — RFC 8538 is an optional extension that a speaker may choose not to implement. However, the lack of N-bit advertisement and Hard Reset handling limits interoperability with implementations that do support RFC 8538 (e.g., FRR, Cisco IOS-XR, Junos). ## Summary RFC 8538 extends RFC 4724 Graceful Restart with three mechanisms: 1. **N-bit** (Notification bit, 0x4000 in the 16-bit Restart Flags + Time field, i.e., 0x40 in the first byte): A speaker that is willing to send and receive NOTIFICATION messages under RFC 8538 semantics MUST advertise this bit. Only when both peers have advertised the N-bit is RFC 8538 behavior active. 2. **Hard Reset** (CEASE/subcode=9): When N-bit is mutually negotiated and a session teardown is intended to be unconditional (routes must be flushed immediately), the sender wraps applicable CEASE notifications inside a Hard Reset outer envelope (code=6, subcode=9, data=original notification). 3. **Soft notification handling**: When N-bit is negotiated and a non-CEASE notification is sent/received, routes are retained in stale state (GR hold) to allow a GR-style recovery, instead of being immediately withdrawn. BIRD 2.x implements RFC 4724 base Graceful Restart but has no code for any of the above RFC 8538 behaviors. ## Affected Version ```text BIRD version 2.0.7 ``` Static code analysis also confirms the absence in the current development tree. ## Observed Behavior ### Test 1 — N-bit not advertised in OPEN A Python BGP peer connected to BIRD 2.0.7 with `graceful restart yes; graceful restart time 120;` and captured BIRD's OPEN message. The Graceful Restart capability (type=64) contained: ```text Raw GR capability data: 0x007800010100 16-bit Restart Flags + Time field: 0x0078 Restart Flags nibble (bits 15-12): 0x0 R-bit (0x8000 / bit 15): False N-bit (0x4000 / bit 14, RFC 8538): False ← not set Restart Time (bits 11-0): 120s Per-AF: IPv4 unicast, F-bit=0 ``` The N-bit (0x4000 in the 16-bit field, 0x40 in the first byte) is not set. BIRD's only defined GR restart flag is `BGP_GRF_RESTART` (0x80, the R-bit). There is no definition or code path for the RFC 8538 N-bit. ### Test 2 — CEASE not wrapped as Hard Reset After session establishment, `birdc disable gr_test` triggered an admin shutdown. BIRD sent: ```text NOTIFICATION: code=6 (CEASE), subcode=2 (Administrative Shutdown) Data: (none) ``` This is a raw CEASE/AdminShutdown. RFC 8538 recommends that, when the N-bit has been exchanged, CEASE subcodes such as Administrative Shutdown be wrapped as Hard Reset (code=6, subcode=9) so the peer immediately flushes preserved routes. ## Expected Behavior RFC 8538 is an optional extension, so BIRD is not required to implement it. However, if BIRD intends to support RFC 8538, the expected behavior would be: 1. Provide a configuration knob to advertise the N-bit (0x4000) in the GR capability when the operator enables RFC 8538 notification mode. 2. When the N-bit has been mutually negotiated and an admin shutdown occurs, use Hard Reset encapsulation: ```text NOTIFICATION: code=6 (CEASE), subcode=9 (Hard Reset) Data: [original code=6][original subcode=2] ``` 3. When receiving a non-CEASE notification from a peer that negotiated the N-bit, retain the peer's routes in stale state instead of immediately withdrawing them, enabling GR-style recovery from notification-triggered session drops. ## Source-Level Analysis In `proto/bgp/packets.c`, `bgp_write_capabilities()` builds the GR capability: ```c if (caps->gr_aware) { *buf++ = 64; /* Capability 64: Support for graceful restart */ *buf++ = 0; /* length, filled later */ data = buf; put_u16(buf, caps->gr_time); buf[0] |= caps->gr_flags; /* only BGP_GRF_RESTART (0x80) defined */ buf += 2; ... } ``` `caps->gr_flags` is set in `bgp_prepare_capabilities()`: ```c caps->gr_flags = p->p.gr_recovery ? BGP_GRF_RESTART : 0; ``` `BGP_GRF_RESTART` is defined as `0x80` (R-bit). The N-bit (`0x40` in the first byte, `0x4000` in the 16-bit field) is not defined anywhere in BIRD's source. `bgp_create_notification()` writes NOTIFICATION messages directly: ```c buf[0] = conn->notify_code; buf[1] = conn->notify_subcode; memcpy(buf+2, conn->notify_data, conn->notify_size); return buf + 2 + conn->notify_size; ``` There is no Hard Reset wrapping, no N-bit negotiation check, and no soft-notification route-retention logic anywhere in the BIRD source. ## Comparison with FRR FRR bgpd fully implements RFC 8538 (`bgp_open.h`): ```c #define GRACEFUL_RESTART_R_BIT 0x8000 #define GRACEFUL_RESTART_N_BIT 0x4000 /* RFC 8538 */ ``` In OPEN construction: ```c SET_FLAG(gr_restart_time, GRACEFUL_RESTART_N_BIT); SET_FLAG(peer->cap, PEER_CAP_GRACEFUL_RESTART_N_BIT_ADV); ``` Negotiation check: ```c bool bgp_has_graceful_restart_notification(struct peer *peer) { return CHECK_FLAG(peer->cap, PEER_CAP_GRACEFUL_RESTART_N_BIT_RCV) && CHECK_FLAG(peer->cap, PEER_CAP_GRACEFUL_RESTART_N_BIT_ADV); } ``` Because BIRD never advertises the N-bit, `bgp_has_graceful_restart_notification()` always returns false on the FRR side for BIRD peers. Both implementations correctly fall back to RFC 4724 base GR behavior: this is an interoperability limitation, not a negotiated RFC 8538 failure. ## Dynamic Verification Verified against BIRD 2.0.7 using a Python BGP peer that: - Advertised the N-bit (0x4000) in its own OPEN to offer RFC 8538 to BIRD - Parsed BIRD's OPEN response for the N-bit - Triggered admin shutdown via `birdc` and captured BIRD's outgoing NOTIFICATION ```text TEST 1 (N-bit in OPEN) : N_BIT_NOT_SET GR data 0x0078... → Restart Flags nibble = 0x0 → N-bit absent TEST 2 (Hard Reset on CEASE) : CEASE_RAW NOTIFICATION code=6/sub=2 (AdminShutdown) — not wrapped as Hard Reset RESULT: BIRD does NOT implement RFC 8538 ``` ## Impact There is no current security or operational impact in BIRD-only or BIRD-FRR deployments, because the N-bit is never mutually negotiated and both sides fall back to standard RFC 4724 GR behavior. The forward-looking concern is: if BIRD adds N-bit advertisement in the future without also implementing Hard Reset and soft-notification semantics, sessions with RFC 8538-capable peers could exhibit asymmetric teardown. Specifically: - BIRD sends a raw CEASE/AdminShutdown (no Hard Reset envelope) - The RFC 8538 peer interprets this as a soft GR event and retains stale routes for the full restart timer window, instead of flushing them immediately This would be a behavioral surprise for operators who configure BIRD as an RFC 8538 peer in a mixed-vendor network. ## Suggested Fix If RFC 8538 support is planned: 1. Define the N-bit flag: ```c #define BGP_GRF_NOTIFICATION 0x40 /* RFC 8538 N-bit, 0x4000 in 16-bit field */ ``` 2. Add a configuration knob and set the bit in `bgp_prepare_capabilities()` when the operator enables GR notification mode. 3. Implement Hard Reset wrapping in the NOTIFICATION send path when N-bit is active. 4. On NOTIFICATION receive, when N-bit has been negotiated and the notification is not a Hard Reset, retain peer routes (stale hold) instead of immediate withdrawal. Best regards.

2 1