[yang] Add SONiC YANG model and frrcfgd plumbing for FIB route filtering by kalash-nexthop · Pull Request #27192 · sonic-net/sonic-buildimage

kalash-nexthop · 2026-05-06T02:35:06Z

Implements the HLD posted here: sonic-net/SONiC#2367

Add a new SONiC YANG module that models FIB route filtering — the policy that decides which routes from each routing protocol are installed into the FIB (and therefore APPL_DB and the hardware ASIC). Backed by FRR's ip|ipv6 protocol <PROTO> route-map <NAME> (see https://docs.frrouting.org/en/stable-7.5/zebra.html#zebra-route-filtering); a deny-match flows through nexthop_active_check -> rib_process and short-circuits rib_install_kernel, so fpmsyncd never sees the prefix and APPL_DB / hardware are never programmed for it. The route remains in zebra's RIB.

Each CONFIG_DB entry binds a route-map to a (vrf, addr_family, protocol) tuple; addr_family reuses sonic-types:ip-family (IPv4/IPv6); a must expression enforces AFI/protocol compatibility (ospf/rip/eigrp IPv4-only, ospf6/ripng IPv6-only); route_map is a mandatory leafref into ROUTE_MAP_SET.

Both modes are wired end-to-end, boot and runtime:

separated mode: boot rendering via dockers/docker-fpm-frr/frr/zebra/zebra.fib_route_filter.conf.j2 (included from zebra.conf.j2), plus runtime translation via a new FibRouteFilterMgr in bgpcfgd that subscribes to FIB_ROUTE_FILTER and pushes the matching FRR command through vtysh.
unified mode: same boot include from frr.conf.j2 (sonic-frr-mgmt-framework), plus runtime translation in frrcfgd.py (fib_route_filter_handler) routed via mgmtd because the FRR CLI is DEFPY_YANG.

The boot template is the source of truth for warm reboot / fresh boot; the managers are the runtime mutation hooks. Net effect: a sonic-db-cli write to FIB_ROUTE_FILTER takes effect immediately in either mode — no config_reload required.

Why I did it

SONiC has YANG coverage for route-maps, prefix-lists, community sets, etc., but no schema for "limit which routes from this protocol are programmed into the FIB / APPL_DB / hardware." Today the only way to configure ip protocol <proto> route-map <name> is to hand-edit zebra.conf (of frr.conf in unified mode). This PR adds a CONFIG_DB-driven schema so the feature can be configured through the standard SONiC flow, plus the conversion layer to render and runtime-update the corresponding FRR config.

The primary operator use case is reducing hardware route capacity pressure: routes from a chosen protocol can be selectively excluded from the FIB without affecting the BGP/OSPF/etc. control plane.

Work item tracking

Microsoft ADO (number only):

How I did it

New YANG module src/sonic-yang-models/yang-models/sonic-fib-route-filter.yang:

Table FIB_ROUTE_FILTER keyed on vrf_name | addr_family | protocol.
vrf_name: union of the literal default and a leafref into sonic-vrf.
addr_family: sonic-types:ip-family (IPv4 / IPv6); rendered into the FRR ip / ipv6 CLI keyword via the same {'IPv4':'ip','IPv6':'ipv6'} lookup the prefix-list and route-map templates already use.
protocol: enum (any, bgp, connected, eigrp, isis, kernel, nhrp, ospf, ospf6, rip, ripng, static, table) — same set as FRR's frr-route-types.
route_map: mandatory leafref into sonic-route-map:ROUTE_MAP_SET.

Conversion layer:

Separated mode boot rendering: new include dockers/docker-fpm-frr/frr/zebra/zebra.fib_route_filter.conf.j2, pulled into zebra.conf.j2 after zebra.interfaces.conf.j2. Renders empty when the table is missing; emits a single vrf <N> / ... / exit-vrf block per non-default VRF (rows for the same VRF grouped) and bare lines for the default VRF.
Separated mode runtime apply: new FibRouteFilterMgr in src/sonic-bgpcfgd/bgpcfgd/managers_fib_route_filter.py, registered in main.py next to the other route-policy managers. Subscribes to CONFIG_DB / FIB_ROUTE_FILTER; on SET pushes ip|ipv6 protocol <proto> route-map <name> (wrapped in vrf <N> / ... / exit-vrf for non-default VRFs) via cfg_mgr.push_list; on DEL pushes the matching no ... form using a per-key state cache so the prior route_map field is not needed. Idempotent re-sets short-circuit (no churn on ConfigDBConnector replay). del_handler checks the tracked-key fast-exit before the AFI guard so a DEL for an unsupported-AFI key (which set_handler would have rejected on the way in) is a quiet skip rather than a spurious error.
Unified mode: same boot include pulled into src/sonic-frr-mgmt-framework/templates/frr/frr.conf.j2, plus fib_route_filter_handler in frrcfgd.py that: (a) seeds fib_route_filter_state from CONFIG_DB at init, (b) translates SET / UPDATE / DELETE events into vtysh, (c) advances state only on __run_command success so failures are retryable, (d) is registered against mgmtd in TABLE_DAEMON because the FRR CLIs are DEFPY_YANG and unified mode dispatches them through mgmtd's northbound (going to ['zebra'] directly returns "Unknown command").

Example

Filter BGP-learned IPv4 routes and OSPFv3 IPv6 routes in the default VRF, and filter both static and BGP routes in Vrf_red:

CONFIG_DB:

{
    "FIB_ROUTE_FILTER": {
        "default|IPv4|bgp":    { "route_map": "RM_FROM_BGP" },
        "default|IPv6|ospf6":  { "route_map": "RM_FROM_OSPF6" },
        "Vrf_red|IPv4|static": { "route_map": "RM_STATIC_V4" },
        "Vrf_red|IPv4|bgp":    { "route_map": "RM_BGP_RED" }
    }
}

Corresponding FRR CLI (rendered into zebra.conf / frr.conf and pushed via vtysh):

ip protocol bgp route-map RM_FROM_BGP
ipv6 protocol ospf6 route-map RM_FROM_OSPF6
!
vrf Vrf_red
 ip protocol static route-map RM_STATIC_V4
 ip protocol bgp route-map RM_BGP_RED
exit-vrf
!

This maps onto FRR's own YANG list filter-protocol under /frr-vrf:lib/vrf[name=N]/frr-zebra:zebra/ (frr-zebra.yang). The SONiC schema flattens FRR's VRF-augmented tree into a single multi-key CONFIG_DB table and tightens the type system (enum protocol, IPv4/IPv6 AFI only, AFI/protocol must-guard).

How to verify it

The yang-models test harness (src/sonic-yang-models/tests/yang_model_tests/test_yang_model.py) globs yang-models/*.yang and every fixture under tests/yang_model_tests/tests/, so the new model + tests run automatically in CI. Expected outcomes:

Positive: FIB_ROUTE_FILTER_VALID, FIB_ROUTE_FILTER_VALID_NAMED_VRF load cleanly.
Negative: LeafRef (NON_EXIST_RT_MAP), InvalidValue x2 (NON_EXIST_VRF, INVALID_PROTOCOL), Mandatory (MISSING_RT_MAP), Must x5 (AFI_PROTO_MISMATCH_V4_OSPF6, V6_OSPF, V4_RIPNG, V6_RIP, V6_EIGRP).

frrcfgd unit tests run in src/sonic-frr-mgmt-framework; the CI builds the wheel and runs them. 17 FRF tests pass alongside the existing suite.

test_zebra_frr_fib_route_filter in src/sonic-config-engine/tests/test_frr.py verifies separated-mode template rendering against the committed sample output.

bgpcfgd unit tests run in src/sonic-bgpcfgd; CI builds the wheel and runs them. tests/test_fib_route_filter_mgr.py contributes 22 tests covering: the exact wire format of set / del commands (default and named VRFs, IPv4 / IPv6); set_handler over default-VRF v4 / v6, named-VRF wrapping, idempotent re-set, upsert with a different route-map, malformed-key and unknown-AFI rejection, tuple-key acceptance; del_handler over tracked / untracked / malformed / unknown-AFI cases; per-(vrf, afi, proto) tracking independence; and the set -> del -> re-set lifecycle (verifies _applied eviction-then-re-registration so a re-set after delete re-pushes rather than idempotent-skipping).

Which release branch to backport (provide reason below if selected)

Tested branch (Please provide the tested image version)

Description for the changelog

Add FIB_ROUTE_FILTER CONFIG_DB table and YANG schema, plus frrcfgd handler and zebra/frr.conf templates: bind a route-map to (vrf, addr_family, protocol) so chosen routes are filtered out before FIB / APPL_DB / hardware install. Renders to FRR's ip|ipv6 protocol <PROTO> route-map <NAME>.