July 2026 - Bird-users - Mailing Lists

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

BIRD 3.3.1 persist option (proto kernel) not working
by artem＠bonzo.me 07 Jul '26

07 Jul '26

After upgrade 3.2.2 -> 3.3.1 the ability to leave routes is broken. When stop Bird, all routes are removed from the linux kernel. Conf sample: protocol static { ipv4; route 172.16.0.0/12 blackhole; } protocol kernel { persist; scan time 5; learn off; ipv4 { import none; export all; }; }

2 1

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

[Bug]: AS_PATH containing AS 0 is accepted, missing RFC 7607 validation
by xinzhe liu 05 Jul '26

05 Jul '26

Hello BIRD maintainers, I would like to report a possible RFC 7607 compliance issue in BIRD's BGP UPDATE validation: routes whose AS_PATH contains AS number 0 appear to be accepted into the BGP table instead of being treated as malformed. Summary BIRD appears not to reject AS 0 when it appears inside the AS_PATH path attribute. I tested this with an eBGP session where the peer sent a valid UPDATE whose AS_PATH was: 65002 0 BIRD accepted the route and displayed the AS_PATH with the reserved AS 0 still present. RFC 7607 Section 2 states that a BGP speaker must not originate or propagate a route with AS number 0 in AS_PATH, and that an UPDATE containing AS number 0 in AS_PATH must be considered malformed and handled according to RFC 7606. For a malformed AS_PATH attribute with parseable NLRI, RFC 7606 handling should be treat-as-withdraw: the route should not be installed, while the BGP session should remain established. Affected Version I reproduced this on: BIRD version 2.19.0+branch.master.880200b1f94c commit 880200b1 Observed Behavior After establishing an eBGP session, the peer sent an UPDATE for 192.0.2.0/24 with: ORIGIN: IGP AS_PATH: 65002 0 NEXT_HOP: 10.0.0.2 NLRI: 192.0.2.0/24 BIRD accepted the UPDATE. birdc show route 192.0.2.0/24 all showed: Table master4:192.0.2.0/24 unreachable [as0_test ... from 10.100.0.2] * (100) [AS0i] Type: BGP univ BGP.origin: IGP BGP.as_path: 65002 0 BGP.next_hop: 10.0.0.2 BGP.local_pref: 100 The route was marked unreachable because of next-hop resolution in the local test setup, but the important point is that the route was accepted into the BGP table with: BGP.as_path: 65002 0 I did not observe an error, warning, or treat-as-withdraw behavior for the reserved AS 0. The BIRD log showed the UPDATE being accepted: as0_test: BGP session established as0_test: Got UPDATE as0_test.ipv4 > added [best] 192.0.2.0/24 ... Expected Behavior BIRD should detect AS 0 in AS_PATH and treat the UPDATE as malformed. Since the UPDATE contains reachable NLRI and the NLRI is parseable, the expected behavior is: - do not install the route, - keep the BGP session established, - handle the route using treat-as-withdraw, consistent with RFC 7606 error handling for malformed AS_PATH attributes. Source-Level Analysis The AS_PATH decoder validates AS_PATH structure but does not appear to validate individual AS numbers against the reserved AS 0 value. In proto/bgp/attrs.c, bgp_decode_as_path() calls as_path_valid() and then stores the attribute: if (!as_path_valid(data, len, as_length, as_sets, as_confed, err, sizeof(err))) WITHDRAW("Malformed AS_PATH attribute - %s", err); ... bgp_set_attr_data(to, s->pool, BA_AS_PATH, flags, data, len); The later post-decode checks in bgp_decode_attrs() cover mandatory attribute presence, local-AS loop detection, confederation loop detection, ORIGINATOR_ID loop detection, and CLUSTER_LIST loop detection, but I could not find a check for AS 0: if (bgp_as_path_loopy(p, attrs, p->local_as)) goto loop; if ((p->public_as != p->local_as) && bgp_as_path_loopy(p, attrs, p->public_as)) goto loop; In nest/a-path.c, as_path_valid() checks segment framing, segment type, whether AS_SET / AS_CONFED_* are allowed, and zero-length segments: switch (type) { case AS_PATH_SET: if (!sets) BAD("AS_SET segment", type); break; case AS_PATH_SEQUENCE: break; case AS_PATH_CONFED_SEQUENCE: if (!confed) BAD("AS_CONFED_SEQUENCE segment", type); break; case AS_PATH_CONFED_SET: if (!sets || !confed) BAD("AS_CONFED_SET segment", type); break; default: BAD("unknown segment", type); } if (pos[1] == 0) BAD("zero-length segment", type); I did not find an equivalent validation pass that iterates through the AS numbers in the path and rejects asn == 0. Suggested Fix Add AS 0 validation during AS_PATH parsing or immediately after AS_PATH decoding. Conceptually: /* RFC 7607: AS 0 is reserved and must not appear in AS_PATH */ if (as_path_contains_as_zero(...)) WITHDRAW("Malformed AS_PATH attribute - AS 0 is reserved"); A similar validation may also be relevant for AS4_PATH, AGGREGATOR, and AS4_AGGREGATOR, since RFC 7607 also covers those attributes. However, this report only describes the AS_PATH case that I reproduced dynamically. Impact Accepting AS 0 in AS_PATH can cause interoperability and policy issues: - routes accepted by BIRD may later be rejected by stricter BGP speakers, - AS_PATH-based filters may behave unexpectedly, - reserved-AS input is allowed into routing policy and best-path processing, - this appears inconsistent with RFC 7607's reserved-AS handling. This does not require tearing down the BGP session. Treat-as-withdraw should be sufficient and would match the usual RFC 7606 approach for malformed AS_PATH attributes. Please let me know if you would like a minimal reproducer or packet capture. Best regards, Xinzhe Liu

2 1

[Bug]: BGP: OPEN with peer AS 0 may be accepted in external accept-any mode, missing RFC 7607 validation
by xinzhe liu 05 Jul '26

05 Jul '26

Hello BIRD maintainers, ### Summary BIRD appears to miss the mandatory RFC 7607 validation for AS 0 in received BGP OPEN messages when the peer is configured in accept-any external-AS mode, including dynamic BGP peers created from a `neighbor range ... external` configuration. RFC 7607 Section 2 says that AS 0 is reserved, must not be used by a BGP speaker, and must not be accepted in a BGP OPEN message. When a BGP speaker receives an OPEN whose peer AS is 0, it must abort the connection and send an OPEN Message Error with subcode Bad Peer AS. In the tested BIRD configuration, a dynamic external peer was able to complete session establishment while claiming peer AS 0. ### Affected Configuration This issue is relevant when BIRD is configured to accept any external AS, for example: ```bird protocol bgp as0_open_test { local as 65001; neighbor 10.0.0.2 external; ipv4 { import all; export none; }; } ``` or with dynamic BGP peers: ```bird protocol bgp dyn_as0_test { local as 65001; neighbor range 10.100.0.0/24 external; ipv4 { import all; export none; }; } ``` The dynamic-peer case was tested locally. ### Expected Behavior If a peer sends a BGP OPEN with My Autonomous System set to 0, BIRD should reject the OPEN, abort the connection, and send: ```text Error Code: OPEN Message Error Error Subcode: Bad Peer AS ``` That is, BIRD should send NOTIFICATION 2/2 rather than allowing the BGP FSM to reach Established. ### Actual Behavior With a dynamic external peer configuration, BIRD accepted an incoming OPEN with peer AS 0 and established the session. `birdc show protocols all` showed the spawned dynamic BGP instance in Established state: ```text as0_dyn_1 BGP --- up ... Established BGP state: Established Neighbor address: 10.100.0.2 Neighbor AS: 0 Local AS: 65001 Neighbor ID: 10.0.0.2 ``` The BIRD log also showed the AS 0 OPEN being accepted and the session becoming established: ```text as0_dyn_1: Got OPEN(as=0,hold=180,id=10.0.0.2) as0_dyn_1: Sending OPEN(ver=4,as=65001,hold=240,id=0a000001) as0_dyn_1: Sending KEEPALIVE as0_dyn_1: Got KEEPALIVE as0_dyn_1: BGP session established ``` For comparison, FRR rejects the same OPEN with NOTIFICATION 2/2. ### Root Cause The relevant validation is in `bgp_rx_open()` in `proto/bgp/packets.c`. For accept-any external-AS mode, where the configured remote AS is unspecified, the current check rejects a peer only when the effective peer AS equals the local AS. There does not appear to be a separate check for the reserved value 0. The effective logic is: ```c if (caps->as4_support) { u32 as4 = caps->as4_number; if (p->remote_as ? (as4 != p->remote_as) : (as4 == p->local_as)) bgp_error(conn, 2, 2, ...); conn->received_as = as4; } else { if (p->remote_as ? (asn != p->remote_as) : (asn == p->local_as)) bgp_error(conn, 2, 2, ...); conn->received_as = asn; } ``` In accept-any external mode, `asn == 0` is not equal to the non-zero local AS, so it can pass this validation and become `conn->received_as`. ### AS4 Capability Case The AS4 Capability path should also be considered. If the OPEN carries AS4 Capability and the AS4 number is 0, that effective peer AS should also be rejected. A fix should therefore reject both cases: ```c if (asn == 0) reject with OPEN Message Error / Bad Peer AS; if (caps->as4_support && caps->as4_number == 0) reject with OPEN Message Error / Bad Peer AS; ``` ### Impact This is best described as an RFC 7607 compliance bug in BGP OPEN validation for accept-any external and dynamic peers. Practical impact depends on deployments using accept-any external-AS or dynamic BGP peering, but the observed behavior can: 1. Allow an external peer to establish a session while claiming the reserved AS number 0. 2. Violate RFC 7607's mandatory OPEN handling. 3. Create inconsistent peer-AS state for logging, policy, and later route processing. 4. Cause interoperability issues with implementations that correctly reject AS 0. The issue does not require a configured neighbor AS of 0. It occurs in accept-any external-AS mode, where BIRD accepts an external peer AS dynamically. ### Version Tested This was reproduced against: ```text BIRD version 2.19.0+branch.master.880200b1f94c ``` Best regards, Xinzhe Liu

1 0