SONiC EVPN/VXLAN Architecture
You already know EVPN control plane vs VXLAN data plane. This lesson maps those concepts onto SONiC's concrete objects: the VXLAN tunnel (NVE), VLAN-to-VNI maps in CONFIG_DB, the BGP EVPN address family in FRR, and the STATE_DB/ASIC_DB objects that prove intent reached hardware.
Prerequisites: Modules 1–3 complete (SONiC system model, containers/Redis, BGP in FRR). · CCNP+ EVPN/VXLAN: route types, VTEP, VNI, control- vs data-plane separation.
Learning objectives
- →Name the SONiC objects that implement each EVPN/VXLAN concept: VTEP, NVE/tunnel, VLAN-VNI map, EVPN address family, remote VTEP.
- →Trace where each object lives across CONFIG_DB, APPL_DB, STATE_DB, and ASIC_DB.
- →Explain how MAC (type-2) and IP (type-2/type-5) advertisement produce remote forwarding state on a peer leaf.
- →Distinguish 'configured' from 'programmed' for a VXLAN tunnel and a remote MAC.
In a traditional NOS, 'show nve vni' answers almost every question. In SONiC the same truth is spread across FRR, several Redis databases, and the ASIC — so you must know which object to read for which question.
Most EVPN/VXLAN incidents in SONiC are not protocol bugs; they are state that stalled between layers. Knowing the object map is what lets you find the stall.
What your CCNP already gives you
- • EVPN route types and the control-plane/data-plane split.
- • VXLAN encapsulation format and the idea of a VTEP and a VNI.
- • BGP session establishment, route reflection, and address-family concepts.
What is new in SONiC
- • The VTEP is a VXLAN tunnel object plus a source loopback, configured in CONFIG_DB — not a single 'nve' interface command.
- • VLAN-to-VNI mapping is an explicit map object; L2VNI and L3VNI are configured differently.
- • 'Is it programmed?' is answered in STATE_DB and ASIC_DB, not by the CLI that accepted the config.
- • EVPN runs in FRR's bgpd inside the bgp container; you inspect it with vtysh, separately from SONiC's
showlayer.
| In the analogy | In SONiC |
|---|---|
| The directory & tracking system that says which terminal a parcel lives behind | EVPN control plane (BGP) |
| The shipping container that packages a tenant frame for transit | VXLAN encapsulation |
| The road network the containers travel over | The underlay (routed fabric) |
| A shipping terminal that loads/unloads containers | VTEP (local tunnel endpoint) |
| A partner terminal you ship containers to | Remote VTEP |
| The tenant/cargo label that keeps each customer's goods separate | VNI |
Where the analogy stops working
A real shipping directory is one central system; SONiC's 'directory' (FRR/BGP) and its 'loading dock' (the ASIC) are separate subsystems that can disagree — a parcel can be listed in the directory (remote MAC in the EVPN RIB) yet never loaded onto a truck (not programmed in ASIC_DB). Also, whether the terminal can do routing between tenant labels (IRB) — symmetric vs asymmetric — is image-dependent in SONiC; confirm what your lab image supports before assuming a workflow.
The object map (what implements what)
Keep this mapping in your head for the whole module. Every EVPN/VXLAN concept you already know corresponds to a named, inspectable object in SONiC:
VTEP / NVE → a VXLAN tunnel object (VXLAN_TUNNEL) whose source IP is a loopback. VLAN-to-VNI → a VXLAN_TUNNEL_MAP (L2VNI) and, for routing, a per-VRF L3VNI. Control plane → the l2vpn evpn address family in FRR/bgpd. Remote VTEP + remote MAC → learned as EVPN routes, then reflected into APPL_DB/STATE_DB and programmed into ASIC_DB.
Concept → SONiC object → where its truth lives
| EVPN/VXLAN concept | SONiC object | Configured in | Programmed/observed in |
|---|---|---|---|
| VTEP source | Loopback0 IP | CONFIG_DB (LOOPBACK_INTERFACE) | APPL_DB / kernel / ASIC_DB |
| VTEP / NVE | VXLAN_TUNNEL (src_ip) | CONFIG_DB | STATE_DB (VXLAN_TUNNEL_TABLE), ASIC_DB |
| L2VNI (VLAN↔VNI) | VXLAN_TUNNEL_MAP | CONFIG_DB | APPL_DB, ASIC_DB (tunnel map, bridgeport) |
| L3VNI (per-VRF routing) | VRF + VLAN + VNI binding | CONFIG_DB / FRR | FRR RIB, ASIC_DB |
| Control plane | BGP l2vpn evpn AF | FRR (bgpd) | vtysh: BGP EVPN RIB |
| Remote MAC (type-2) | EVPN route → FDB entry | learned via BGP | APPL_DB (VXLAN_FDB), STATE_DB, ASIC_DB (FDB) |
| Remote prefix (type-5) | EVPN route → route | learned via BGP | FRR RIB, kernel, ASIC_DB (route/nexthop) |
MAC and IP advertisement, concretely
When Host1's frame reaches Leaf1, Leaf1 learns the source MAC locally (bridge FDB) and, because the VLAN is EVPN-enabled, originates a type-2 route carrying that MAC (and, if it has the ARP/ND binding, the MAC+IP). Leaf2 imports the route into its EVPN RIB and installs a remote FDB entry pointing at Leaf1's VTEP.
type-3 (inclusive multicast) routes tell each VTEP who else is in a VNI so BUM traffic can be head-end replicated. type-5 (IP prefix) routes carry routed prefixes for inter-subnet/L3VNI forwarding — relevant to the symmetric-IRB discussion in Lesson 4.5.
For every overlay symptom, ask two questions in order: (1) does the control plane know? (EVPN RIB on the far leaf) and (2) did it get programmed? (STATE_DB tunnel + ASIC_DB FDB/route). 'Remote MAC present but not programmed' and 'tunnel present but forwarding fails' are real, distinct states — not contradictions.
Common misconceptions
Myth: If the EVPN route is in the RIB, forwarding works.
Reality: The route can be present in FRR yet not programmed into ASIC_DB (SAI failure, resource limit, tunnel not up). Control-plane presence is necessary, not sufficient.
Myth: The VTEP is one interface I turn on.
Reality: In SONiC a VTEP is a VXLAN tunnel object sourced from a loopback, plus VLAN-VNI maps. Several objects must all be present and consistent.
Myth: SONiC EVPN behaves like the vendor NOS I trained on.
Reality: CLI, defaults, and especially IRB support vary by image and distribution. Confirm your image's capabilities before assuming a workflow.
Key takeaways
- ✓Each EVPN/VXLAN concept maps to a named SONiC object; know which database holds its truth.
- ✓'Configured' (CONFIG_DB) and 'programmed' (STATE_DB/ASIC_DB) are different claims — verify both.
- ✓EVPN lives in FRR; VXLAN tunnel/maps live in SONiC's DBs; the ASIC is the final arbiter.
- ✓IRB capability is image-dependent — confirm before designing a workflow around it.
Tested against: SONiC 202305 / 202311 lineage · Upstream (community) unless noted · SONiC-VS (virtual) baseline · last reviewed 2026-07. Exact commands and behavior can vary by SONiC release, image, hardware platform, and enterprise distribution.
Knowledge check
In an EVPN/VXLAN fabric, which component distributes remote MAC/IP-to-VTEP reachability?
Match each SONiC object to the EVPN/VXLAN role it implements.