Most explanations of EVPN route types are a numbered list you memorise for an exam and forget. They become useful the moment you are staring at show bgp l2vpn evpn on a fabric that is not forwarding and have to work out which route type is missing. This walkthrough takes the control plane apart on a two-spine, two-leaf Nexus fabric with real routes on the table, assuming the underlay from the data center fabric guide is up. Types 2, 3 and 5 have captured output. Two more are explained without it, and this post says why.
One address family carrying everything
EVPN is not a new protocol. It is an address family, l2vpn evpn, carried in ordinary MP-BGP with ordinary mechanics: route distinguishers, route targets, extended communities and route reflection. If your fundamentals are solid, EVPN is mostly new NLRI formats on machinery the BGP guides already cover, and the network virtualization material covers why anyone wants a layer 2 service delivered this way at all.
What makes it different is that one address family carries MAC addresses, IP-to-MAC bindings, flood list membership, IP prefixes and multihoming state, and the route type is the first NLRI field telling you which. This fabric runs one autonomous system, 65001, spines as route reflectors, leaves as clients.
The spines are route reflectors, with one critical extra line
Here is SPINE1. SPINE2 is identical apart from its router ID.
feature bgp
feature nv overlay
nv overlay evpn
router bgp 65001
router-id 10.255.0.1
address-family l2vpn evpn
retain route-target all
neighbor 10.255.0.11
remote-as 65001
update-source loopback0
address-family l2vpn evpn
send-community
send-community extended
route-reflector-client
neighbor 10.255.0.12
remote-as 65001
update-source loopback0
address-family l2vpn evpn
send-community
send-community extended
route-reflector-clientMost of that is standard iBGP route reflection: peer to the leaf loopbacks, mark each client with route-reflector-client. The peering uses Loopback0, not the Loopback1 VTEP source, a separation that comes from the OSPF underlay build.
send-community and send-community extended are not optional decoration. EVPN carries its route targets, encapsulation type and router MAC as extended communities, so a peer not sending them sends routes stripped of what makes them usable. The symptom is routes present in the table with forwarding broken.
The line that catches people out is retain route-target all. Normal behaviour on a VPN address family is to drop any received route whose route targets you do not import into a local VRF, a sensible optimisation on a PE. On a spine it is a disaster: no VRFs, no imported route targets, so it would discard every EVPN route it receives before ever reflecting it. Sessions established, prefix counts at zero, fabric not forwarding. On a pure reflector this line is mandatory.
The leaf side is simpler, because a client does not need to know it is a client.
feature bgp
feature nv overlay
feature vn-segment-vlan-based
feature interface-vlan
nv overlay evpn
router bgp 65001
router-id 10.255.0.11
neighbor 10.255.0.1
remote-as 65001
update-source loopback0
address-family l2vpn evpn
send-community
send-community extended
neighbor 10.255.0.2
remote-as 65001
update-source loopback0
address-family l2vpn evpn
send-community
send-community extendedTwo sessions, one per spine, because a single reflector is a single point of failure for the whole overlay control plane. Note the absence of retain route-target all: a leaf imports route targets and should drop what it has no VRF for.
The summary output, and the table most people miss
show bgp l2vpn evpn summary
BGP summary information for VRF default, address family L2VPN EVPN
BGP router identifier 10.255.0.11, local AS number 65001
BGP table version is 4, L2VPN EVPN config peers 2, capable peers 2
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.255.0.1 4 65001 7 7 4 0 0 00:01:42 0
10.255.0.2 4 65001 7 7 4 0 0 00:01:31 0
Neighbor T AS Type-1 Type-2 Type-3 Type-4 Type-5 Type-6 Type-7 Type-8 Type-12
10.255.0.1 I 65001 0 0 0 0 0 0 0 0 0
10.255.0.2 I 65001 0 0 0 0 0 0 0 0 0The first table is the familiar BGP summary. Both sessions are established (a numeric value in State/PfxRcd rather than a word means up), capable peers 2 confirms both negotiated the EVPN address family, and the counts are zero because this was captured right after the sessions came up, before any VNI existed. Zero prefixes is normal on a fabric with nothing configured on top of it, and it is also exactly what a missing retain route-target all looks like. The difference is whether the leaves have anything to advertise yet.
The second table is the one to remember. NX-OS breaks the received count out per route type, per neighbour, so one command tells you whether you are missing MAC advertisements, flood list routes or prefix routes. Type-3 arriving but no Type-2 points at MAC learning. Nothing from one spine but everything from the other points at that spine's reflector config.
How to read an EVPN prefix
Learn the format once. Every EVPN NLRI prints as positional fields in square brackets, and what each position means depends on the first. Three prefixes from this fabric, decoded left to right:
[2]:[0]:[0]:[48]:[4e69.d07b.10f7]:[0]:[0.0.0.0]/216is route type 2, then the Ethernet Segment Identifier (all zeros, so the host is single-homed), the Ethernet Tag ID (0 for a VLAN-based service), the MAC length in bits and the MAC, then the IP length and the IP. An IP length of0means a MAC-only advertisement with no IP binding.[3]:[0]:[32]:[10.255.1.11]/88is route type 3, Ethernet Tag ID 0, then the originating router's IP length in bits and the address. No ESI and no MAC, because a Type 3 is not about a host.[5]:[0]:[0]:[24]:[10.10.10.0]/224is route type 5, ESI, Ethernet Tag ID, then the prefix length and the prefix. That length counts bits of subnet mask rather than the width of an address field, a small inconsistency worth knowing before it confuses you at 3am.
The trailing value after the slash is not a subnet mask. It is the NLRI length in bits, counting the route type byte, the length byte and every encoded field except the route distinguisher, which NX-OS prints in the section header instead. Count the Type 3 out and it lands exactly: 8 bits of type, 8 of length, 32 of Ethernet Tag ID, 8 for the IP length field and 32 for the address, total 88. Type 2 adds the 80-bit ESI, the MAC length byte, the 48-bit MAC and a 24-bit label to reach 216; Type 5 adds the ESI, the prefix, a 32-bit gateway IP and a label to reach 224.
That lets you spot variants by eye: a Type 2 carrying an IPv4 address as well as a MAC runs 32 bits longer than the MAC-only ones here, so a table of identical lengths says no IP bindings are being advertised.
Route Type 2: MAC/IP Advertisement
Type 2 is the workhorse. It advertises a MAC, optionally with an IP bound to it, plus the VNI and the VTEP that owns it, and it is what replaces flood-and-learn.
show bgp l2vpn evpn
Route Distinguisher: 10.255.0.11:32777 (L2VNI 10010)
*>i[2]:[0]:[0]:[48]:[4e69.d07b.10f7]:[0]:[0.0.0.0]/216
10.255.1.12 100 0 i
*>l[2]:[0]:[0]:[48]:[5254.0087.1ddf]:[0]:[0.0.0.0]/216
10.255.1.11 100 32768 i
*>l[3]:[0]:[32]:[10.255.1.11]/88
10.255.1.11 100 32768 i
*>i[3]:[0]:[32]:[10.255.1.12]/88
10.255.1.12 100 0 iThe first route advertises MAC 4e69.d07b.10f7 with no IP binding, and its next hop is 10.255.1.12, LEAF2's VTEP source rather than its router ID. That is the address the ingress leaf puts in the outer destination IP when it encapsulates a frame for this MAC, which is why the two loopbacks being different matters up here as well as in the underlay.
The route distinguisher 10.255.0.11:32777 is auto-derived and annotated by NX-OS with (L2VNI 10010). Being unique per leaf per VNI, two hosts with the same MAC in different VNIs never collide in the BGP table.
The status characters carry a lot. *> means valid and best, and the character after it is the origin marker: l for locally originated, i for internal, learned from the reflector. LEAF1 originated the Type-2 for 5254.0087.1ddf, a host on its own access port, and learned 4e69.d07b.10f7 from LEAF2 via a spine. Weight 32768 versus 0 repeats the point.
In the MAC address table these BGP-learned MACs appear with a C flag for control plane and a port of nve1(10.255.1.12), the remote VTEP rather than a physical interface. That output sits in the L2VNI build.
A Type 2 that carries an IP as well as a MAC doubles as the ARP/ND binding that makes ARP suppression possible, and it is how the distributed anycast gateway knows where a host lives. That side of it is covered in the L3VNI and anycast gateway build.
Route Type 3: Inclusive Multicast Ethernet Tag
Type 3 is in the same output and its job is narrow. *>l[3]:[0]:[32]:[10.255.1.11]/88 says "this VTEP participates in this VNI, include it in the flood list". Membership, not hosts.
On this fabric, which uses ingress replication rather than underlay multicast, the set of Type-3 routes a leaf holds for a VNI is its flood list. Add a leaf and its Type-3 appears everywhere with no config change elsewhere. They appear for VNIs with nothing learned yet too, which they must: the first thing a new host does is ARP. The replication side of that is in ingress replication versus PIM anycast RP.
Route Type 5: IP Prefix
Type 5 carries an IP prefix rather than a host MAC, and it is what makes routing between VNIs and out to the rest of the network work. The detail view is far more informative than the table view.
show bgp l2vpn evpn route-type 5
Route Distinguisher: 10.255.0.11:4 (L3VNI 50001)
BGP routing table entry for [5]:[0]:[0]:[24]:[10.10.10.0]/224, version 50
Paths: (2 available, best #2)
Path type: internal, path is valid, not best reason: Weight, no labeled nexthop
Imported from 10.255.0.12:4:[5]:[0]:[0]:[24]:[10.10.10.0]/224
Gateway IP: 0.0.0.0
10.255.1.12 (metric 81) from 10.255.0.1 (10.255.0.1)
Origin incomplete, MED 0, localpref 100, weight 0
Received label 50001
Extcommunity: RT:65001:50001 ENCAP:8 Router MAC:521f.ff1f.1b08
Originator: 10.255.0.12 Cluster list: 10.255.0.1
Advertised path-id 1
Path type: local, path is valid, is best path, no labeled nexthop
10.255.1.11 (metric 0) from 0.0.0.0 (10.255.0.11)
Origin incomplete, MED 0, localpref 100, weight 32768
Received label 50001
Extcommunity: RT:65001:50001 ENCAP:8 Router MAC:529a.2a3a.1b08
Path-id 1 advertised to peers:
10.255.0.1 10.255.0.2The RD is annotated (L3VNI 50001), so 10.10.10.0/24 belongs to the tenant VRF behind that L3VNI, not to an L2VNI. Four fields in the received path do the real work.
Received label 50001 is the L3VNI, called a label because EVPN inherited the MPLS VPN encoding. On a VXLAN fabric that value is the VNI the ingress leaf writes into the VXLAN header when it routes toward this prefix.
Extcommunity: RT:65001:50001 is the route target controlling which VRF imports the prefix, and ENCAP:8 is the BGP tunnel encapsulation attribute, where 8 means VXLAN. Together they are why the receiving leaf accepts the route into TENANT-A and knows how to encapsulate toward it.
Router MAC:521f.ff1f.1b08 is the remote leaf's router MAC, and it is the field people forget exists. In symmetric IRB the ingress leaf routes into the L3VNI and needs an inner destination MAC for the encapsulated frame. That MAC is the egress leaf's, learned right here. Missing or stale, and you get the classic symptom of a route that is present and correct in the VRF table while traffic silently disappears.
Two more fields describe the path rather than the forwarding. Originator: 10.255.0.12 is the leaf that originated the route and Cluster list: 10.255.0.1 is the reflector it passed through, so you read "LEAF2 originated this, SPINE1 reflected it" straight off the output. The next hop 10.255.1.12 (metric 81) is the VTEP address resolved through the underlay, at the same metric the OSPF build produced.
Compare the local path underneath: next hop 10.255.1.11 at metric 0, weight 32768, its own Router MAC, no Originator or Cluster list because it never went near a reflector. Same prefix, both leaves originating it because both have the subnet attached locally, which is precisely what a distributed anycast gateway means.
Types 1 and 4, and why there is no output for them
Two route types this lab cannot show you, because both belong to EVPN multihoming and this fabric has none.
Route Type 1, Ethernet Auto-Discovery is advertised per Ethernet Segment and handles fast convergence and split horizon when a host attaches to more than one leaf. Its best trick is mass withdrawal: when a multihomed link fails, one Type 1 withdrawal invalidates every MAC behind that segment at once, instead of thousands of individual Type 2 withdrawals.
Route Type 4, Ethernet Segment is advertised by every leaf on a shared segment so those leaves discover each other and elect a designated forwarder, the one allowed to send BUM traffic down to the multihomed host. Without it the host gets duplicate copies of every broadcast.
Both need an Ethernet Segment Identifier on the multihomed links, which is why the Type 2 routes above carry an all-zero ESI. This lab used vPC during its multihoming phase and single-homed servers after, so no ESI existed and no Type 1 or Type 4 routes were generated. Anything printed here as their output would be invented, so nothing is. Types 6, 7, 8 and 12 were likewise not exercised.
Reading the control plane in order
When a fabric is not forwarding, work top down: sessions and capable peers in the summary, then the per-type table for what is arriving, then the origin markers to separate what you originated from what you learned, then the detail view for the three extended communities. Almost every EVPN problem that is not an underlay problem shows up in one of those four steps. The layer this control plane feeds is VXLAN L2VNI configuration, and the full build order sits in the data center fabric pillar guide.
Key Takeaways
- EVPN is MP-BGP with new NLRI formats. The route type is the number in square brackets at the front, and the trailing slash value is an NLRI bit length, not a mask.
retain route-target allis mandatory on a spine acting as a pure route reflector, because a spine with no VRFs would otherwise discard every route it is supposed to reflect.- The second table in
show bgp l2vpn evpn summarybreaks received routes out per type per neighbour. It is the fastest triage command in the fabric. - Type 2 advertises MAC and MAC/IP bindings, Type 3 advertises VNI participation and builds the flood list, Type 5 carries IP prefixes for the tenant VRF.
- On a Type 5,
Received label,RT,ENCAP:8andRouter MACare what make symmetric IRB forward, and the first things to check when it does not.OriginatorandCluster listtell you which leaf sent it and which spine reflected it. - Type 1 and Type 4 exist for multihoming, mass withdrawal and designated forwarder election. This lab had no EVPN multihoming, so no output for them was captured.