EVPN-VXLAN: the control plane, one route type at a time
Five route types, in the order you meet them when a fabric misbehaves. No slide-deck diagrams, just BGP output.
Every explainer of EVPN starts with a diagram: spines at the top, leaves in the middle, servers at the bottom, arrows everywhere. The diagram is fine. The problem is that diagrams don't help when a MAC is missing from a remote VTEP's table and traffic is blackholing. BGP output helps.
EVPN is a BGP address family — specifically, L2VPN EVPN, address family 25/70. Like any BGP AFI/SAFI, it carries NLRI: in this case, the five EVPN route types. Each route type carries specific reachability information. When you understand what each type advertises, you can read a show bgp l2vpn evpn output and know immediately which piece of the forwarding chain is broken.
Route Type 3: the VTEP announces itself
Before anything else can work, VTEPs need to know about each other. RT-3 — Inclusive Multicast Ethernet Tag — is how a VTEP announces "I exist, I'm handling VNI X, and here's my underlay IP." When a VTEP comes up and joins an EVPN fabric, RT-3 routes propagate to every other VTEP. The result is an ingress replication list: the set of VTEPs to which BUM (broadcast, unknown unicast, multicast) traffic should be sent.
If a VTEP's RT-3 route isn't showing up on a remote leaf, BUM traffic won't reach it. That means ARP requests won't cross the fabric. Which means nothing can learn the remote MAC/IP. Start here when debugging.
leaf-1# show bgp l2vpn evpn route-type 3
BGP routing table information for VRF default
Router identifier 10.0.0.1, local AS number 65001
Route Distinguisher: 10.0.0.3:10100
10.0.0.3/32 from 10.0.0.101 (10.0.0.101)
Origin IGP, metric 0, localpref 100
Extended Community: RT:65001:10100 Encap:8
PMSI Tunnel: IngressReplication, 10.0.0.3
RT:65001:10100 is the route target matching VNI 10100. Encap:8 means VXLAN. PMSI IngressReplication means unicast BUM. This is what a healthy RT-3 looks like.
Route Type 2: MAC/IP reachability
RT-2 carries what the fabric is actually for: the MAC address of a host, optionally with its IP, bound to a VNI and a VTEP. When a host sends traffic, the local VTEP learns its MAC, generates an RT-2, and advertises it. Remote VTEPs install a forwarding entry: to reach MAC X, encapsulate in VXLAN with VNI Y and send to VTEP Z.
The IP in RT-2 is what enables ARP suppression — the local VTEP can answer ARP requests for remote hosts without flooding the fabric, because it learned the IP→MAC binding from BGP.
RT-2 routes present on the BGP control plane but not installed in the EVPN MAC table. Check whether the route target is configured correctly on both ends. A misconfigured import RT means the VTEP receives the prefix but doesn't know to install it.
Route Type 5: IP prefix routes
RT-5 carries IP prefixes rather than MAC/IP pairs. This is how inter-subnet routing works in an EVPN fabric: rather than stretching L2 across subnets, each leaf acts as a gateway for its local subnets and advertises RT-5 routes for them. Remote leaves route to the prefix via the advertising VTEP.
This is the route type you care about when inter-VLAN traffic is failing in a pure L3 design. If a host on VLAN 10 can't reach a host on VLAN 20, look for the RT-5 covering the destination prefix on the source leaf. If it's absent, the leaf either isn't receiving the advertisement or isn't importing it.
Reading the output cold
The practical skill is this: pull show bgp l2vpn evpn on both VTEPs, compare what's being advertised versus what's being received, check route targets, check that the VNI is correct in the NLRI. The fabric is transparent — every forwarding decision is visible in the BGP table if you know what you're reading.
When traffic is blackholing, the answer is almost always in one of three places: the RT-3 replication list (VTEP not known), the RT-2 table (MAC not learned), or the RT-5 table (prefix not installed). Knowing which route type maps to which failure cuts the debugging time in half.