BGP EVPN control-plane integration for the VPP dataplane (VXLAN today, without precluding MPLS transport)

Type: Feature Request

Summary

VyOS 1.5 supports VXLAN and bridge-domain interfaces natively in the VPP dataplane (interfaces vpp vxlan, interfaces vpp bridge), and the LCP plugin synchronizes L3 routes between kernel/FRR and VPP. The existing BGP L2VPN/EVPN control plane (protocols bgp address-family l2vpn-evpn), however, only programs the kernel dataplane's VXLAN/bridge FDB via Zebra netlink. There is no equivalent path feeding EVPN Type-2 (MAC/IP) and Type-3 (IMET) route state into VPP's bridge-domain forwarding tables. Today, interfaces vpp vxlan only supports static tunnel-remote + vni (head-end replication style) — no dynamic VTEP discovery, no MAC learning via BGP.

It's worth noting up front that EVPN (RFC 7432) was originally defined with MPLS as the transport/encapsulation, with VXLAN (RFC 8365) added later as an alternative for datacenter fabrics. VyOS currently only wires EVPN to VXLAN at all — MPLS (via LDP, protocols mpls) exists in VyOS as a fully separate feature with no EVPN tie-in, on either the kernel or VPP dataplane. This request focuses on the VXLAN case because that's where the existing gap is most concrete and most requested, but the design should be chosen so it doesn't foreclose MPLS-encapsulated EVPN later (see "Transport independence" below) — otherwise we'd be trading one dead end for a different one.

Current behavior (kernel dataplane, works today)

set protocols bgp address-family l2vpn-evpn advertise ipv4 unicast
set protocols bgp address-family l2vpn-evpn advertise-all-vni
set protocols bgp system-as '100'
set protocols bgp peer-group ibgp address-family l2vpn-evpn

set interfaces vxlan vxlan2000 parameters nolearning
set interfaces vxlan vxlan2000 source-address '172.29.255.1'
set interfaces vxlan vxlan2000 vni '2000'

set vrf name blue protocols bgp address-family l2vpn-evpn advertise ipv4 unicast
set vrf name blue vni '2000'

set interfaces bridge br2000 member interface vxlan2000
set interfaces bridge br2000 vrf 'blue'

FRR's zebra learns remote VTEPs and MACs via BGP EVPN routes and installs them straight into the kernel VXLAN device's FDB (see docs/configexamples/autotest/L3VPN_EVPN).

Current behavior (VPP dataplane, the gap)

set interfaces vpp vxlan vppvxlan0 source-address '172.29.255.1'
set interfaces vpp vxlan vppvxlan0 tunnel-remote '172.29.255.2'
set interfaces vpp vxlan vppvxlan0 vni '2000'

tunnel-remote is fixed and singular — no way to hand VPP's bridge-domain a dynamic set of remote VTEPs/MACs learned from protocols bgp address-family l2vpn-evpn. VPP-based VXLAN is limited to static point-to-point or manually-enumerated head-end-replication overlays.

Desired behavior

set interfaces vpp vxlan vppvxlan2000 vni '2000'
set interfaces vpp vxlan vppvxlan2000 source-address '172.29.255.1'
set interfaces vpp bridge vppbr2000 member interface vppvxlan2000
set interfaces vpp bridge vppbr2000 vrf 'blue'

set protocols bgp address-family l2vpn-evpn advertise-all-vni

...where tunnel-remote becomes unnecessary because remote VTEPs/MACs arrive dynamically via EVPN, same as the kernel case.

Use cases this would unblock

1. Multi-tenant hosting / DC fabric at high port density — the existing L3VPN_EVPN example (VRF-per-tenant, VNI-per-tenant, asymmetric IRB) is CPU-bound on the kernel dataplane once tenant count/pps scale up. Operators wanting >10G aggregate throughput per PE currently must choose EVPN (kernel-only) *or* VPP (static-only), never both.
2. Inter-DC L2 stretch for anycast/VM mobility — stretching a VLAN between sites for VM/anycast mobility needs both throughput (VPP) and dynamic VTEP/MAC learning (EVPN) once it carries real production traffic between more than a handful of sites; static tunnel-remote doesn't scale or survive VTEP renumbering.
3. Access/broadband aggregation with per-subscriber/per-customer VNI — BNG/ISP access designs mapping many customer VLANs 1:1 to VNIs generate the highest interface/FDB churn, which is exactly where kernel forwarding hits its ceiling first — and exactly where static VPP config is least practical.
4. (Forward-looking) Service-provider core L2VPN/L3VPN over MPLS — many SP networks (including ones already running MPLS/LDP on VyOS today) prefer EVPN-over-MPLS for core services precisely because it avoids VXLAN's UDP/IP encapsulation overhead and reuses existing MPLS TE/FRR mechanisms. This isn't asked for here, but it's the reason the underlying integration shouldn't be designed as VXLAN-specific plumbing.

In all three near-term cases: EVPN control-plane learning and VPP-dataplane forwarding are currently mutually exclusive in VyOS.

Transport independence / future-proofing

The integration point this request targets — FRR zebra's EVPN route processing feeding a VPP dataplane — should be designed around "EVPN NLRI → forwarding intent," not around VXLAN FDB semantics specifically. Two things support that this is achievable without extra cost:

• FRR's own dataplane abstraction (zebra/dplane) already treats IP routes, MPLS LSPs, and EVPN VTEP programming as peer object types in the same framework (the same layer FPM and netlink dataplane plugins sit on). The control-plane side of EVPN — "this MAC/IP belongs behind this remote PE" — is inherently encapsulation-independent; only the last-mile dataplane programming (VXLAN header vs. MPLS label swap) differs.
• VPP itself already has native MPLS forwarding support (independent of this request — see Pim van Pelt's "MPLS in VPP," GRNOG16 2024), so the dataplane side isn't a blocker either, even though vyos-1x has no interfaces vpp mpls yet.

Concretely: whichever of the two directions below is chosen, the interface between "zebra's EVPN route state" and "VPP programming" should be kept generic enough that a later MPLS-encapsulated EVPN effort could plug into the same seam instead of needing a parallel, VXLAN-shaped mechanism rebuilt from scratch.

Prior art / reference

Closest analog — FRR-native, in production elsewhere: SONiC (the switch NOS used by hyperscalers) already solves the VXLAN case of this problem, built on FRR, not Bird:

"For control plane, MP-BGP with EVPN extension support is leveraged from FRR with changes in Zebra and Fpmsyncd to interact with SONiC SwSS." — SONiC EVPN/VXLAN HLD

Architecture: FRR (BGP + Zebra) → sync daemons (fpmsyncd, fdbsyncd, neighsyncd) → SwSS orchestration agents (VxlanOrch, FdbOrch, VrfOrch, RouteOrch) → SAI (hardware/dataplane abstraction) → ASIC or, in sonic-net/sonic-platform-vpp (Apache-2.0), VPP standing in as the SAI-compatible dataplane. That repo's own notes describe VXLAN BGP EVPN support as ongoing/in-progress, not finished — but the layered architecture (FRR unmodified, VPP behind a SAI-like shim) is proven at production scale today and worth following, precisely because SAI's object model is transport-abstracted rather than VXLAN-hardwired — a useful reference for keeping our own integration encapsulation-agnostic.

The seam already exists inside FRR itself: zebra's pluggable dataplane (dplane) framework already carries EVPN VTEP programming internally — see zebra: move EVPN VTEP programming to dataplane (FRR 7.2) and the regression it caused, FRRouting/frr#5431 (remote-VTEP forwarding through L3VNI broke when this moved to the dplane abstraction, later fixed). Confirms EVPN VTEP/MAC state is architecturally reachable through the same dataplane-plugin layer FRR already uses for netlink, FPM, and MPLS LSP programming — a VPP dataplane plugin at that layer is the intended extension point, not a hack, though it has had rough edges historically.

A concrete, already-documented seam for exactly this: FRR's FPM (Forwarding Plane Manager) — a zebra module streaming FIB state to an external process over TCP, encoded as Netlink or Protobuf (FRR dev-guide: FPM). SONiC's fpmsyncd is exactly this pattern in production. Public docs describe route-level data primarily; whether/how EVPN MAC/VTEP state rides the same channel today (vs. needing a sibling mechanism) needs confirming against zebra/dplane_fpm_nl.c directly rather than docs alone.

Unconfirmed lead: a "Proposal: VxLAN/eVPN" thread exists on the fd.io vpp-dev mailing list (native VPP community). Could not be fetched (login/paywall-gated groups.io archive) — worth someone with fd.io/groups.io access checking directly before citing it as settled prior art.

Bird2-based alternative (not directly reusable, VXLAN-only, no MPLS angle): ipng.ch's "VPP and eVPN/VxLAN" series (2025–2026) — part 1, part 2, part 3, part 4. Part 1 explicitly weighs FRR vs. Bird2 and floats "Linux CP Netlink messages" as an option:

"For the controlplane parts, FRRouting has a working implementation for L2 (MAC-VRF) and L3 (IP-VRF)."
"What's a good way to tie in a controlplane like FRRouting or Bird2 into the dataplane (perhaps using a sidecar controller, or perhaps using Linux CP Netlink messages)?"

...but parts 2–4 build the actual system, [vpp-evpn](https://git.ipng.ch/ipng/vpp-evpn) (Apache-2.0, Go — evpnd/evpnr/evpnc/evpnf), against Bird2 with a custom vppevpn protocol patch, not FRR, and is VXLAN-only throughout. Useful as a reference for bridge-domain/BVI lifecycle management and anycast-GW failover design, but not portable to VyOS's FRR-only stack, and doesn't inform the MPLS question either. VyOS's own LCP plugin (python/vyos/vpp/control_vpp.py) already does the netlink-resync style integration the author floated but didn't pursue for FRR.

License compatibility note: both vpp-evpn and sonic-platform-vpp are Apache-2.0; vyos-1x source carries a "GPL-2.0 or (at your option) any later version" header. Apache-2.0 is incompatible with GPLv2-only per FSF guidance but compatible with GPLv3, so reusing code/logic (not just architecture) would require treating the resulting VyOS work as GPLv3-or-later. Attribution should be given regardless of whether code or just architecture is reused.

Scope note

Two concrete technical directions, in order of how "native" they are to FRR — both should be evaluated against the transport-independence goal above, not just against the VXLAN case:

1. FPM-based: implement a VPP-side FPM client (à la SONiC's fpmsyncd) that consumes zebra's existing FIB/dataplane stream and programs VPP's tables. Needs verification of whether EVPN MAC/VTEP state (and, longer-term, MPLS LSP state) actually rides the FPM channel today, or needs a sibling path.
2. LCP-netlink extension: extend VyOS's existing LCP netlink-resync mechanism to also mirror AF_BRIDGE FDB/neighbor entries (which zebra already writes to the kernel for EVPN Type-2 routes today). This is more VXLAN/kernel-FDB-shaped by nature, so if chosen, it's worth explicitly checking whether it can be generalized later rather than assuming it can.

Either way, this is a substantial change and warrants a design discussion before a concrete implementation task is opened.