Hi FRR developers, I wanted to bring a bug to the list's attention that I've filed on GitHub. I've fully isolated and confirmed the root cause and the fix is a one-line change. GitHub Issue: https://github.com/FRRouting/frr/issues/21882 --- SUMMARY A mismatch between the CLI definition and the YANG schema for 'match metric' causes bgpd and ospfd to crash with SIGABRT when a route-map contains 'match metric 0'. The value 0 is valid per RFC 4271 (BGP MED attribute) and is accepted by the CLI, but is excluded by the YANG schema, causing libyang2 to fail validation on read-back. AFFECTED VERSIONS - FRR 10.3.3, Ubuntu 24.04 (Noble), aarch64, libyang2 2.1.128-2~ubuntu24.04u2 - FRR 10.3.4, Ubuntu 24.04 (Noble), aarch64, libyang2 2.1.128-2~ubuntu24.04u2 - master branch as of May 2026 — bug is still present and unpatched ROOT CAUSE In yang/frr-route-map.yang, the metric leaf under case match-metric has range 1..4294967295, excluding 0: case match-metric { when "derived-from-or-self(../condition, 'match-metric')"; leaf metric { type uint32 { range "1..4294967295"; <-- BUG: excludes 0 } } } The CLI in lib/routemap_cli.c accepts range 0-4294967295: "match metric (0-4294967295)$metric" This mismatch means FRR accepts 'match metric 0' at the CLI and stores it, but libyang2 correctly rejects value 0 against the schema when vtysh attempts to render the config. This causes yang_dnode_get_string() to receive a null node, triggering an assertion failure and SIGABRT. CRASH PATH vtysh connects -> show running-config triggered -> route_map_condition_show() -> yang_dnode_get_string(dnode, "./rmap-match-condition/metric") -> libyang2 validates metric=0 against schema range 1..4294967295 -> validation fails, node not found -> assert() fires -> SIGABRT [SZNR8-V24R3][EC 100663326] yang_dnode_xpath_get_canon: couldn't find ./rmap-match-condition/metric CONFIRMED ISOLATION - Route-map with 'match metric 0' present -> bgpd and ospfd crash on every vtysh connection - Route-map with 'match metric 1' alone -> no crash, show running-config works normally - Removing 'match metric 0' and restarting FRR -> crash completely resolved REAL-WORLD IMPACT BGP MED value 0 is valid per RFC 4271 and commonly used in production. In our case a Cisco CSR peer sends MED 0 for the primary tunnel and MED 1 for the secondary tunnel. 'match metric 0' in a route-map is the correct and operationally required way to match this traffic. There is no workaround that preserves the required routing behavior. NOTABLE INCONSISTENCY IN THE SAME FILE Comparing similar leaves in frr-route-map.yang shows the inconsistency clearly: match-metric -> metric: range "1..4294967295" <- BUG match-tag -> tag: range "0..4294967295" <- correct set-metric -> value: range "0..4294967295" <- correct set-min-metric: range "0..4294967295" <- correct set-max-metric: range "0..4294967295" <- correct PROPOSED FIX One-line change in yang/frr-route-map.yang: - range "1..4294967295"; + range "0..4294967295"; This fix should be applied to master and backported to stable/10.3, stable/10.4, stable/10.5, and stable/10.6. Happy to test a patched build on our aarch64/Ubuntu 24.04 setup if that would help validation. Thank you for your time and for maintaining FRR. P.S. I used Claude Code to help troubleshoot and craft this email.