zebra: route EVPN FDB/neighbor reads through dplane

[rjarry]

When advertise-all-vni is enabled, zebra reads FDB and neighbor tables directly from the kernel via netlink, bypassing all dplane providers. A dplane provider has no way to supply its own FDB/neighbor state, making EVPN unusable with non-kernel dplane plugins (e.g. grout/DPDK).

This series adds two new dplane operations (DPLANE_OP_FDB_READ and DPLANE_OP_NEIGH_READ) and converts all FDB/neighbor read call sites to use the dplane enqueue path instead of calling netlink directly. The read results already flow through the dplane notification path, so only the read requests need to be rerouted.

The netlink-specific handling lives in rt_netlink.c (macfdb_read_ctx() / neigh_read_ctx()), with no-op stubs in rtread_sysctl.c for BSD, following the existing pattern for platform-specific read functions.

Fixes #21190

[greptile-apps]

Greptile Summary

This PR routes EVPN FDB (MAC forwarding database) and neighbor table reads through the zebra dataplane (dplane) infrastructure instead of invoking netlink directly from the main thread. Two new dplane operations — DPLANE_OP_FDB_READ and DPLANE_OP_NEIGH_READ — are introduced, along with corresponding context structures, accessor functions, enqueue helpers, and kernel-provider dispatch handlers. All seven call sites across zebra_vxlan.c, zebra_evpn.c, zebra_evpn_neigh.c, and zebra_ns.c are updated to use the new dplane_fdb_* / dplane_neigh_* APIs. The netlink-specific implementation is refactored into two new static-scoped dispatchers (kernel_read_macfdb / kernel_read_neigh in rt_netlink.c), and BSD stubs in rtread_sysctl.c are consolidated from seven no-op functions down to two.

• New dplane_macfdb_read_info and dplane_neigh_read_info structs added to the dplane context union, with full accessor coverage.
• Dispatch logic in kernel_read_macfdb uses a sentinel-based if-else chain (is_zero_mac, vni, ifindex) to multiplex four read variants; kernel_read_neigh uses a parallel ipa_type/ifindex pattern.
• All switched enums (kernel_socket.c, dplane_fpm_nl.c, zebra_script.c, zebra_rib.c) handle the two new ops with no-op / break clauses, consistent with the existing pattern for DPLANE_OP_VLAN_INSTALL.
• The filter_vlan global used in netlink MAC-table parsing is now set and cleared entirely within the dplane pthread; since the kernel dplane provider is single-threaded, this is safe.

Confidence Score: 5/5

Safe to merge; all functional and structural changes are correct and consistent with existing dplane patterns.

All 16 changed files are handled correctly: the dispatch logic in kernel_read_macfdb and kernel_read_neigh faithfully reproduces the four original read variants using sentinel-based multiplexing; the filter_vlan global is accessed safely within the single-threaded dplane provider; all switch statements covering dplane_op_e are updated; BSD stubs are properly consolidated; and all call sites are migrated. The two remaining P2 comments are observability/clarity issues with no effect on runtime correctness.

No files require special attention.

Vulnerabilities

No security concerns identified. The change is purely architectural — it reroutes read-only netlink queries through the dplane queue rather than calling them directly. No new data is exposed externally, no user input flows into the new path, and the netlink socket handling follows the same patterns as existing dplane operations.

Important Files Changed

Filename	Overview
zebra/zebra_dplane.c	Core of the change: adds context structs, accessors, enqueue helpers, and kernel-provider dispatch for DPLANE_OP_FDB_READ / DPLANE_OP_NEIGH_READ; logic is correct and consistent with existing patterns.
zebra/zebra_dplane.h	Adds two new enum values, accessor declarations, and public enqueue API; clean API surface mirroring existing EVPN dplane patterns.
zebra/rt_netlink.c	Refactors macfdb/neigh read functions to static, accepting nlsock+dp_info instead of zebra_ns; adds kernel_read_macfdb and kernel_read_neigh entry points called from the dplane pthread. Dispatch logic is correct.
zebra/rt_netlink.h	Removes now-static netlink_macfdb/neigh declarations; exposes kernel_read_macfdb and kernel_read_neigh as the two new entry points. Clean.
zebra/rt.h	Replaces nine old macfdb_/neigh_ extern declarations with two new ones (kernel_read_macfdb, kernel_read_neigh); clean reduction in public API surface.
zebra/rtread_netlink.c	Removes seven now-obsolete macfdb_/neigh_ wrapper stubs; only route_read and kernel_read_pbr_rules remain. Correct.
zebra/rtread_sysctl.c	BSD stubs consolidated from seven functions to two no-ops (kernel_read_macfdb / kernel_read_neigh); follows existing no-op pattern for platform-unsupported operations.

Sequence Diagram

sequenceDiagram
    participant ZMain as Zebra Main Thread
    participant DQ as Dplane Queue
    participant DProv as Kernel Dplane Provider
    participant NL as rt_netlink.c
    participant Kernel as Linux Kernel (netlink)
    participant CB as FDB/Neigh Callbacks

    note over ZMain: advertise-all-vni enabled / EVPN VNI event
    ZMain->>DQ: dplane_fdb_read / dplane_neigh_read / dplane_fdb_read_for_bridge etc.
    DQ-->>ZMain: ZEBRA_DPLANE_REQUEST_QUEUED

    DProv->>DQ: dequeue ctx
    alt DPLANE_OP_FDB_READ
        DProv->>NL: kernel_read_macfdb(ctx)
        NL->>NL: dispatch: specific_mac / mcast_vni / for_bridge / full
        NL->>Kernel: netlink_request_macs() RTM_GETNEIGH
        Kernel-->>NL: netlink response
        NL->>CB: netlink_parse_info netlink_macfdb_table
        NL-->>DProv: return
    else DPLANE_OP_NEIGH_READ
        DProv->>NL: kernel_read_neigh(ctx)
        NL->>NL: dispatch: specific_ip / for_vlan / full
        NL->>Kernel: netlink_request_neigh() RTM_GETNEIGH
        Kernel-->>NL: netlink response
        NL->>CB: netlink_parse_info netlink_neigh_table
        NL-->>DProv: return
    end
    DProv->>DQ: dplane_provider_enqueue_out_ctx(ctx)
    DQ->>ZMain: rib_process_dplane_results break no-op for read ops

Loading

Prompt To Fix All With AI

This is a comment left during a code review.
Path: zebra/rt_netlink.c
Line: 4375-4395

Comment:
**Return values from netlink read functions silently discarded**

In `kernel_read_macfdb`, the return values of all four netlink helper calls (`netlink_macfdb_read_specific_mac`, `netlink_macfdb_read_mcast_for_vni`, `netlink_macfdb_read_for_bridge`, `netlink_macfdb_read`) are discarded, and `ZEBRA_DPLANE_REQUEST_SUCCESS` is set unconditionally at the end regardless of whether any of them actually succeeded. The same pattern appears in `kernel_read_neigh` (which does check `ret >= 0` before parsing, but still always ends with SUCCESS).

Since none of the consumers — `kernel_dplane_handle_result` and `rib_process_dplane_results` — check the result status for `DPLANE_OP_FDB_READ` / `DPLANE_OP_NEIGH_READ` (they both just `break`), this is not a runtime bug today. However, silently swallowing errors means any netlink failure during a read (e.g., socket error, message truncation) will go completely unnoticed. Consider at least logging a warning when a negative return is received:

```c
if (!is_zero_mac(mac))
    ret = netlink_macfdb_read_specific_mac(nl, dp_info, br_ifindex, mac, vid, vlan_aware);
else if (vni)
    ret = netlink_macfdb_read_mcast_for_vni(nl, dp_info, ifindex, vni, is_vxlan);
else if (ifindex)
    ret = netlink_macfdb_read_for_bridge(nl, dp_info, br_ifindex, vlan_aware, vid);
else
    ret = netlink_macfdb_read(nl, dp_info);

if (ret < 0)
    zlog_warn("%s: macfdb read failed: %d", __func__, ret);
dplane_ctx_set_status(ctx, ZEBRA_DPLANE_REQUEST_SUCCESS);
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: zebra/zebra_dplane.c
Line: 6479-6497

Comment:
**`dplane_fdb_read_mcast_for_vni` returns `SUCCESS` instead of `QUEUED` on early-exit path**

When `IS_ZEBRA_VXLAN_IF_VNI(zif)` is true the function returns `ZEBRA_DPLANE_REQUEST_SUCCESS` rather than enqueuing anything. All callers currently discard the return value so there is no observable bug, but semantically this path has done no work. If callers are ever added that inspect this value, the distinction between "queued" and "skipped" will matter. A brief comment noting the intentional early-exit would clarify intent:

```c
if (IS_ZEBRA_VXLAN_IF_VNI(zif))
    /* Per-VNI VxLAN interfaces don't need mcast FDB reads */
    return ZEBRA_DPLANE_REQUEST_SUCCESS;
```

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (3): Last reviewed commit: "zebra: route neighbor reads through the ..." | Re-trigger Greptile}

[mjstapp]

we'll need to adjust this in order to avoid having the dplane pthread access unsafe data structs

[mjstapp]

no - if this is run in the dplane pthread, no zebra objects can be accessed at all.

[rjarry]

I have updated the code accordingly. Let me know if that is better.

[rjarry]

The CI is failing but I fail to understand what the errors actually are. They don't see related to my changes.

[rjarry]

Hi there, @mjstapp is there anything blocking this pull request? Let me know if I need to change anything else. Thanks!

[mjstapp]

@greptileai review

[mjstapp]

Thanks, this looks good to me now - I'm getting one more pass with the greptile, just to see if there's anything it spots.

[mjstapp]

trying to clear the red flag

[mjstapp]

if the greptile comment about dead functions is correct, would you please clean those up?

[mjstapp]

the comment is in the third paragraph after "score", before the "vulnerability" section

if the greptile comment about dead functions is correct, would you please clean those up?

[rjarry]

Will do, thanks for the review!

[rjarry]

It should be OK now. @greptileai was correct. I rebased on the latest master branch and removed the unused functions from rt_netlink.*

[rjarry]

@mjstapp could you have a look?