EVPN Control-Plane Intro

Updated

September 4, 2026

EVPN Control-Plane Intro

EVPN (Ethernet VPN) is a BGP-based control plane for overlay reachability—most often paired with VXLAN data planes in modern fabrics. This chapter is an introduction to models and lab reality on free stacks (FRR EVPN/VXLAN where available, optional SR Linux community). Syntax shifts; objects do not.

Learning goals

By the end of this chapter you can:

  • Explain what EVPN advertises versus what VXLAN carries
  • Name core route types at a practical level (2, 3, 5—awareness)
  • Relate RD/RT-style membership ideas to “who joins which VNI”
  • Sketch an FRR EVPN + VXLAN lab and know how to verify BGP EVPN tables
  • Predict failure when underlay OK but EVPN session down

Why EVPN exists

Data-plane-only VXLAN:

  • Floods BUM to all peers
  • Learns MAC reactively
  • Scales poorly; slow on moves

EVPN:

  • Distributes MAC/IP bindings and VTEP locations via BGP
  • Reduces unknown flooding (in good designs)
  • Supports L2 and L3 (IRB) services in one framework
  BGP EVPN  (control)     VXLAN/GRE/...  (data)
       │                        │
       └──── same fabric intent─┘

Objects (vendor-agnostic)

Object Role
VTEP IP Underlay endpoint
VNI L2 segment id in data plane
MAC-VRF / EVI Service instance
RD Disambiguates routes
RT (route target) Import/export membership
Type-2 route MAC (/IP) advertisement
Type-3 route Inclusive multicast / flood tree membership ideas
Type-5 route IP prefix (L3 VPN style overlay)
IRB / L3 VNI Inter-subnet routing in fabric

You do not need full RFC memorization to operate: session up → EVPN routes present → data plane VNI up → hosts pass.

Control vs data verification split

Layer Healthy signs
Underlay VTEP loopbacks ping; ECMP present
BGP EVPN Neighbors Established; AFI/SAFI EVPN negotiated
EVPN RIB Type-2 for host MACs; correct next-hop VTEP
Data plane VXLAN encap; host ping; FDB consistent

Minimal design story — 2 leaf

   h1--leaf1----spine----leaf2--h2
         \      underlay     /
          BGP EVPN (often via spine route-reflector or eBGP unnumbered fabric)

Common free lab patterns:

  1. iBGP EVPN to a route reflector (spine or dedicated).
  2. eBGP EVPN unnumbered on fabric links (advanced; FRR supports variants).

Start with iBGP + RR mentally even if your first lab is two leaves peering directly.

FRR capability note (mid-2026)

FRR continues to expand EVPN/VXLAN integration. Treat the following as structural config—verify against your image’s vtysh help and docs:

# daemons: zebra, bgpd, staticd (and platform vxlan integration)
router bgp 65000
 bgp router-id 10.0.0.1
 neighbor 10.0.0.3 remote-as 65000
 neighbor 10.0.0.3 update-source lo
 !
 address-family l2vpn evpn
  neighbor 10.0.0.3 activate
  advertise-all-vni
 exit-address-family
!
# VNI / bridge mapping is platform-specific:
# Linux FRR may integrate with kernel bridge/vxlan via zebra

Always confirm with:

vtysh -c 'show bgp l2vpn evpn summary'
vtysh -c 'show bgp l2vpn evpn'
vtysh -c 'show evpn vni'
vtysh -c 'show evpn mac vni all'

If a command is missing, your build differs—fall back to kernel VXLAN static (previous chapter) and read FRR release notes.

Topology sketch (EVPN lab)

name: evpn-intro

topology:
  nodes:
    leaf1:
      kind: linux
      image: quay.io/frrouting/frr:10.2.1
      binds:
        - ./config/leaf1:/etc/frr
    leaf2:
      kind: linux
      image: quay.io/frrouting/frr:10.2.1
      binds:
        - ./config/leaf2:/etc/frr
    rr:
      kind: linux
      image: quay.io/frrouting/frr:10.2.1
      binds:
        - ./config/rr:/etc/frr
    h1:
      kind: linux
      image: alpine:3.20
      exec:
        - apk add --no-cache iproute2 iputils
    h2:
      kind: linux
      image: alpine:3.20
      exec:
        - apk add --no-cache iproute2 iputils

  links:
    - endpoints: ["leaf1:eth1", "rr:eth1"]
    - endpoints: ["leaf2:eth1", "rr:eth2"]
    - endpoints: ["h1:eth1", "leaf1:eth2"]
    - endpoints: ["h2:eth1", "leaf2:eth2"]

Underlay: give leaf1/leaf2/rr loopbacks 10.0.0.1/32, .2, .3 and point-to-point links with static or OSPF so loopbacks mesh. EVPN BGP between leaves and rr using loopbacks.

RR config idea

router bgp 65000
 bgp router-id 10.0.0.3
 neighbor 10.0.0.1 remote-as 65000
 neighbor 10.0.0.1 update-source lo
 neighbor 10.0.0.2 remote-as 65000
 neighbor 10.0.0.2 update-source lo
 address-family l2vpn evpn
  neighbor 10.0.0.1 activate
  neighbor 10.0.0.1 route-reflector-client
  neighbor 10.0.0.2 activate
  neighbor 10.0.0.2 route-reflector-client
 exit-address-family

Predict → observe → fix drills

Drill 1 — Session before service

docker exec clab-evpn-intro-leaf1 vtysh -c 'show bgp l2vpn evpn summary'

Predict: Established to RR.
If Idle: underlay loopback ping, update-source, firewall, daemons.

Drill 2 — Host MAC appears as EVPN route

docker exec clab-evpn-intro-h1 ping -c 2 10.10.10.20
docker exec clab-evpn-intro-leaf1 vtysh -c 'show bgp l2vpn evpn'
docker exec clab-evpn-intro-leaf2 vtysh -c 'show evpn mac vni all'

Predict: Type-2-like entries; next-hop remote VTEP.
Fix: VNI advertise config, bridge binding, host traffic to trigger learning if required.

Drill 3 — Kill EVPN, keep underlay

docker exec clab-evpn-intro-leaf1 vtysh -c 'conf t' -c 'router bgp 65000' -c 'neighbor 10.0.0.3 shutdown'
docker exec clab-evpn-intro-h1 ping -c 5 10.10.10.20

Predict: underlay pings between leaves still work; overlay host traffic fails or relies on stale/f flood only.
Observe: BGP down, EVPN table ages out.
Fix: no neighbor … shutdown.

Drill 4 — RT mismatch (concept)

If export/import RTs do not match, routes exist on one leaf but are not imported on the other.

Predict: show bgp l2vpn evpn has routes locally originated but remote missing or not installed.
Fix: align VRF/VNI RT policy.

L2 VNI vs L3 VNI (awareness)

Service Host experience EVPN idea
L2 VNI Same subnet two leaves MAC routes (type-2)
L3 VNI / IRB Different subnets routed in fabric Type-5 prefixes + symmetric/asymmetric IRB models

Do not implement every IRB mode on day one. Get same-subnet across two leaves solid first.

Optional SR Linux community path

Nokia SR Linux is a common Containerlab free/community kind for EVPN-VXLAN labs. Workflow:

  1. Underlay eBGP or OSPF
  2. Overlay BGP EVPN
  3. mac-vrf / vxlan-interface style objects

Map to the same verification split. Use SR Linux documentation for exact CLI; journal the object mapping:

VNI ↔ vxlan-interface
MAC-VRF ↔ bridge table
bgp-evpn ↔ advertisement

Security / isolation checklist

  • VNI allocation authority
  • RT import discipline (no accidental cross-tenant)
  • Underlay ACL optional for UDP/4789 between VTEPs only
  • Control-plane protection on BGP

What this intro deliberately skips

  • Full multihoming Ethernet segments (ESI) deep dive
  • Complex IRB interop matrices
  • Multicast optimized BUM underlays
  • DCI stretch best practices

Those are fabric/scale topics once the skeleton works.

Common mistakes

Mistake Symptom
EVPN before underlay Endless BGP down
Wrong AFI/SAFI Session up but no EVPN
Data plane VNI ≠ advertised Control OK, ping fail
Treating EVPN as L2 switch only Miss L3 service models later
No RR scaling plan Full mesh pain

Summary

  • EVPN is BGP control for overlay membership and MAC/IP reachability
  • VXLAN (or similar) remains the data plane
  • Verify underlay → BGP EVPN → EVPN RIB → host data in order
  • FRR and SR Linux are free-ish paths to practice; check your image’s feature set
  • Master two-leaf same-subnet before IRB gymnastics

Next: overlay lab—a single integrated workout combining underlay, VXLAN, and (if available) EVPN verification.