SONiC

Module 4

EVPN/VXLAN in SONiC

Your EVPN/VXLAN knowledge, meet SONiC's implementation model.

~8 h2.5 h lecture5 h labs6 lessons6 labs8 check questions

Purpose

Combine the learner's existing EVPN/VXLAN knowledge with SONiC's implementation model.

This module is heavily lab-oriented: build an underlay, stand up VXLAN and EVPN, and trace and break it across layers.

Learning objectives

  • →Describe SONiC's EVPN/VXLAN architecture: underlay, overlay, VTEP/NVE, VNIs, VLAN-to-VNI mapping, and BGP EVPN.
  • →Design a routed underlay and reason about ECMP, MTU, and failure domains.
  • →Trace VXLAN forwarding from local host to remote decapsulation.
  • →Explain symmetric vs asymmetric IRB and confirm what the lab image supports before assuming a workflow.
  • →Troubleshoot EVPN/VXLAN across ten layers, from host attachment to ASIC programming and packet capture.

Lessons

  1. SONiC EVPN/VXLAN ArchitectureYou 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.40m
  2. Underlay DesignThe overlay is only as good as the road beneath it. This lesson covers eBGP vs iBGP underlays, loopback and point-to-point addressing, ECMP, the reachability the VTEPs actually require, the MTU math VXLAN forces on you, and how underlay design draws your failure domains.35m
  3. EVPN Route Types (SONiC View)A fast, CCNP+-level review of the route types that matter in a SONiC leaf-leaf fabric — type-2, type-3, and type-5 — focused entirely on how they appear in FRR, what SONiC does with them, and the failure signatures each one produces. No introductory definitions.35m
  4. VXLAN Forwarding BehaviorFollow one tenant packet end to end: local source host → ingress leaf FDB/routing decision → remote VTEP resolution → VXLAN encapsulation → underlay forwarding → remote decapsulation → destination delivery. Each step names the SONiC object that must be correct for the packet to advance.40m
  5. Symmetric and Asymmetric IRBBoth IRB models solved the same problem differently. This lesson contrasts them at the level a SONiC operator needs — what each requires on every VTEP, how the L3VNI does or does not appear, and the operational tradeoffs — with a hard caveat: identify what your specific lab image supports before assuming either workflow.35m
  6. EVPN Troubleshooting Across LayersA repeatable 10-layer ladder for overlay incidents: host attachment → local bridge → VNI mapping → VTEP reachability → EVPN control plane → remote MAC/IP state → tunnel object → ASIC programming → packet capture → counters. Each rung names the command that confirms or clears it, so you always know where to look next.40m

Labs

  1. Build the UnderlayStand up the routed fabric the overlay will depend on: point-to-point interfaces, loopbacks, BGP between the leaves, verified loopback-to-loopback reachability (ideally over ECMP), and a validated MTU that leaves room for VXLAN overhead. No overlay yet — this lab exists so later overlay failures are truly overlay failures.ConfigurationVirtualOpen-source60m
  2. Configure VXLAN and VNIsCreate the tenant VLAN, define the VXLAN tunnel sourced from Loopback0, map VLAN-to-VNI (L2VNI), and verify the tunnel object reaches an operational state on both leaves. This is data-plane plumbing only — EVPN comes in Lab 4.3.ConfigurationVirtualOpen-source60m
  3. Establish EVPNTurn on the control plane: bring up the loopback-to-loopback BGP session, activate the l2vpn evpn address family, advertise the relevant routes, and confirm the EVPN RIB and remote-VTEP information appear on both leaves. After this lab the directory exists — hosts can find each other.ConfigurationCorrelationVirtualOpen-source60m
  4. Trace a MAC Between LeavesCorrelation lab: generate traffic from Host1 and follow one MAC through the whole machine — local learning on Leaf1, type-2 advertisement, import and remote installation on Leaf2, down to the FDB/tunnel objects — then confirm VXLAN forwarding actually delivers the frame to Host2.CorrelationObservationVirtualOpen-source55m
  5. Packet CapturePacket-tracing lab: capture the VXLAN traffic on the underlay and dissect one packet layer by layer — original tenant Ethernet frame, then the outer Ethernet, outer IP, UDP, and the VXLAN header with its VNI — proving on the wire what the control plane claimed.Packet tracingObservationVirtualOpen-source50m
  6. Failure ScenariosFailure-injection lab: deliberately break the working fabric one way at a time — underlay route missing, VNI mismatch, MTU problem, EVPN session up but route absent, MAC learned locally but not advertised, remote route present but not programmed, tunnel present but forwarding fails — and drive each to root cause with the 10-layer ladder. Revert to a known-good snapshot between scenarios.Failure injectionTroubleshootingVirtualOpen-source75m

Module summary

  • EVPN is the control plane (who is where); VXLAN is the transport (how it is wrapped); the underlay is the road they ride on.
  • Most overlay failures are underlay or mapping failures wearing an overlay costume — verify reachability, MTU, and VNI mapping first.

Completion checklist

  • ☐ I built a routed underlay with BGP and validated reachability and MTU.
  • ☐ I mapped VLANs to VNIs, configured VTEPs, and verified tunnel state.
  • ☐ I enabled EVPN and validated remote VTEP and MAC/IP state.
  • ☐ I captured and decoded a VXLAN packet down to the inner frame.
  • ☐ I diagnosed at least three EVPN/VXLAN failure scenarios across layers.
Carry this forward

Finish the labs before moving on — later modules assume you can navigate the databases and containers hands-on, not just in theory.