EVPN Route Types in VXLAN Data Center Fabrics — A Complete Technical Guide
Data Center Networking | EVPN | VXLAN | BGP | Route Types
EVPN Route Types in VXLAN Data Center Fabrics — A Complete Technical Guide
Everything network engineers need to know about all EVPN BGP route types — how they work, what they carry, when they are used, and why they are the control plane backbone of modern VXLAN data center fabrics.
Ethernet VPN (EVPN) combined with VXLAN (Virtual Extensible LAN) has become the de facto standard control and data plane architecture for modern data center fabrics. Whether you are building a greenfield leaf-spine data center, migrating from traditional STP-based designs, or architecting multi-site DCI (Data Center Interconnect) solutions, understanding EVPN route types is not optional — it is foundational.
EVPN uses BGP as its control plane and defines a rich set of Network Layer Reachability Information (NLRI) types — called EVPN Route Types — each carrying specific information needed to build and maintain the distributed MAC, IP, and multicast forwarding tables that make VXLAN fabrics work. There are currently eleven defined EVPN route types (Type 1 through Type 11), though Types 1 through 5 are the most commonly deployed in data center environments.
This guide provides a thorough technical breakdown of every EVPN route type — what each carries, how it is generated and processed, real-world use cases, and how they interact within a VXLAN fabric. Whether you are preparing for a CCIE Data Center exam or designing a production data center, this is your complete reference.
📋 Table of Contents
- EVPN and VXLAN — Architecture Overview
- How BGP EVPN NLRI Works — The Route Type Framework
- Route Type 1 — Ethernet Auto-Discovery (A-D) Route
- Route Type 2 — MAC/IP Advertisement Route
- Route Type 3 — Inclusive Multicast Ethernet Tag (IMET) Route
- Route Type 4 — Ethernet Segment Route
- Route Type 5 — IP Prefix Route
- Route Types 6 through 11 — Extended and Emerging Types
- EVPN Route Type Comparison Table
- How Route Types Work Together — End-to-End VXLAN Flow
- EVPN Route Types on Key Vendor Platforms
- Troubleshooting EVPN Routes in VXLAN Fabrics
- Frequently Asked Questions (FAQ)
1. EVPN and VXLAN — Architecture Overview
Before diving into individual route types, it is essential to understand the architectural context in which EVPN route types operate.
🏗️ VXLAN Data Plane
VXLAN encapsulates original Layer 2 Ethernet frames in UDP/IP packets, enabling Layer 2 domains to be stretched over a Layer 3 IP underlay network. Each VXLAN segment is identified by a 24-bit VNI (VXLAN Network Identifier), which maps to a VLAN or Layer 3 VRF. The devices performing VXLAN encapsulation/decapsulation are called VTEPs (VXLAN Tunnel Endpoints) — typically leaf switches in a leaf-spine fabric.
🧠 EVPN Control Plane
EVPN (defined in RFC 7432 and extended by RFC 8365 for VXLAN) provides the BGP-based control plane for VXLAN. Instead of relying on data-plane MAC learning (flooding) to discover remote hosts, EVPN uses BGP to advertise MAC addresses, IP addresses, and reachability information between VTEPs. This eliminates BUM (Broadcast, Unknown unicast, Multicast) flooding for known hosts, dramatically improving scalability and enabling active-active multihoming.
📐 Key EVPN Terminology
| Term | Definition |
|---|---|
| VTEP | VXLAN Tunnel Endpoint — performs VXLAN encap/decap; typically a leaf switch |
| VNI | VXLAN Network Identifier — 24-bit segment ID (L2 VNI for bridging, L3 VNI for routing) |
| EVI | EVPN Instance — BGP routing instance representing a VXLAN segment or VRF |
| RT (Route Target) | BGP community controlling EVPN route import/export between VRFs and EVIs |
| RD (Route Distinguisher) | Makes EVPN prefixes unique in the BGP table across VTEPs |
| ESI | Ethernet Segment Identifier — 10-byte ID for multihomed segments (used in RT-1 and RT-4) |
| BUM Traffic | Broadcast, Unknown unicast, Multicast — handled via RT-3 IMET routes in EVPN |
2. How BGP EVPN NLRI Works — The Route Type Framework
EVPN uses BGP Address Family AFI 25 (L2VPN) / SAFI 70 (EVPN). Within this address family, EVPN defines a new type of NLRI — the EVPN NLRI — that begins with a Route Type field (1 byte) identifying what kind of information the route carries.
Each EVPN route type has a specific structure, carries specific fields, and serves a specific purpose in the VXLAN fabric control plane. All EVPN routes share a common BGP framework: they carry a Route Distinguisher (RD) to ensure global uniqueness, and use Route Target (RT) extended communities to control import/export between EVPN instances.
# BGP EVPN Address Family Configuration (Cisco NX-OS Example)
router bgp 65001
neighbor 10.0.0.2 remote-as 65001
address-family l2vpn evpn
send-community extended
route-reflector-client
evpn
vni 10010 l2
rd auto
route-target import auto
route-target export auto
💡 Key Concept: Route Type Field
The first byte of every EVPN NLRI is the Route Type field. This single byte tells the receiving BGP speaker exactly how to parse and process the rest of the NLRI. This extensible design allows EVPN to carry completely different types of information — MAC addresses, IP prefixes, multicast membership, multihoming data — all within the same BGP address family, simply by varying the Route Type value.
3. Route Type 1 — Ethernet Auto-Discovery (A-D) Route
| Route Type Number | Type 1 (RT-1) |
| RFC Reference | RFC 7432 |
| Primary Purpose | Multihoming — Fast convergence and split-horizon filtering for active-active/active-standby Ethernet Segment multihoming |
| Generated By | VTEPs that have a multihomed Ethernet Segment configured (non-zero ESI) |
The Ethernet Auto-Discovery (A-D) Route is generated by VTEPs that have devices multihomed (connected to multiple VTEPs) via an Ethernet Segment (ES). It exists in two sub-flavors, serving different functions:
RT-1 Per-ES Route (Ethernet Tag = 0xFFFFFFFF)
Purpose: Advertises that a VTEP is connected to a given Ethernet Segment (identified by its ESI). This route is used for aliasing — enabling remote VTEPs to load-balance traffic across all VTEPs connected to a multihomed CE (Customer Edge) device, even before they have learned a specific MAC/IP from all VTEPs on that segment.
Key Fields: RD, ESI (10 bytes), Ethernet Tag ID (0xFFFFFFFF), MPLS Label / VNI
RT-1 Per-EVI Route (Ethernet Tag = specific EVI tag)
Purpose: Used for mass withdrawal — when a VTEP loses connectivity to a multihomed segment, it sends a RT-1 withdrawal with specific Ethernet Tags, enabling remote VTEPs to rapidly withdraw all MAC/IP routes learned from that path without waiting for individual RT-2 withdrawals for each MAC address. This dramatically improves convergence time during link failures.
Key Fields: RD, ESI, Ethernet Tag ID (EVI-specific value), MPLS Label / VNI
RT-1 Route in BGP Table (NX-OS show output example):
show bgp l2vpn evpn route-type 1 BGP routing table entry for [1]:[0]:[0300.0000.0001.0000.0100]:[0]/23 Paths: (2 available, best #1) Path type: internal, path is valid, is best path AS-Path: NONE, path locally originated Nexthop: 10.1.1.1 (via default) Extended Community: RT:65001:10010 ENCAP:8
✅ When You Will See RT-1 Routes
RT-1 routes are only present when you have active-active or active-standby multihoming configured on your leaf switches (e.g., vPC with EVPN on Cisco NX-OS, MLAG with EVPN on Arista EOS, or MC-LAG on Juniper). In a simple single-homed VTEP environment, you will not see RT-1 routes being generated.
4. Route Type 2 — MAC/IP Advertisement Route
| Route Type Number | Type 2 (RT-2) |
| RFC Reference | RFC 7432 / RFC 8365 |
| Primary Purpose | THE most important route type — advertises MAC address reachability and optionally associated IP address (ARP/ND suppression) for hosts in an EVPN instance |
| Generated By | Any VTEP that learns a local host MAC/IP through data-plane learning or static configuration |
The MAC/IP Advertisement Route is the workhorse of EVPN. Every time a VTEP learns a host's MAC address (through normal data-plane flooding and learning), it generates an RT-2 route advertising that MAC — and optionally the host's IP address — to all other VTEPs in the fabric via BGP.
RT-2 comes in three important variants:
Variant A — MAC-Only Advertisement
Carries only the MAC address of the host. IP Length = 0. Used for Layer 2-only EVPN instances where no IP information is being distributed through EVPN.
NLRI Format: [2]:[ESI]:[Ethernet Tag]:[MAC Length]:[MAC Address]:[IP Length=0]:[Label1]
Variant B — MAC + IPv4 Advertisement
Carries both the MAC address and the host's IPv4 address. This enables ARP suppression — remote VTEPs can answer ARP requests locally using the distributed MAC/IP table, eliminating ARP flooding across the fabric. This is critical for scaling in large environments. Carries both an L2 VNI label (Label1) and optionally an L3 VNI label (Label2) for symmetric IRB routing.
NLRI Format: [2]:[ESI]:[Ethernet Tag]:[MAC Length]:[MAC Address]:[32]:[IPv4 Address]:[Label1]:[Label2]
Variant C — MAC + IPv6 Advertisement
Same as Variant B but carries an IPv6 address (128-bit) instead of IPv4. Used for IPv6 host reachability and Neighbor Discovery (ND) suppression in dual-stack or IPv6-only environments.
NLRI Format: [2]:[ESI]:[Ethernet Tag]:[MAC Length]:[MAC Address]:[128]:[IPv6 Address]:[Label1]:[Label2]
RT-2 Route Output Example (NX-OS):
show bgp l2vpn evpn route-type 2
BGP routing table entry for [2]:[0]:[0]:[48]:[0050.7966.6800]:[32]:[192.168.10.101]/272
Paths: (1 available, best #1)
Path type: internal, path is valid, is best path
AS-Path: NONE, path locally originated
Nexthop: 10.1.1.1 (vtep loopback)
Extended Community: RT:65001:10010 RT:65001:99999 ENCAP:8
Router MAC:5004.0000.1b08
VNI: 10010 (L2) 99999 (L3)
🔍 ARP Suppression — The Critical Role of RT-2 MAC+IP Routes
When RT-2 routes carry both MAC and IP information, every VTEP in the fabric builds a local ARP/ND suppression table. When a host sends an ARP request for an IP address that the VTEP already knows (from RT-2 learning), the VTEP answers the ARP locally on behalf of the remote host — preventing the ARP broadcast from being flooded across the entire VXLAN fabric. This is perhaps the single most impactful scalability feature in EVPN/VXLAN deployments.
✅ Symmetric vs. Asymmetric IRB and RT-2 Label2
In Symmetric IRB (the recommended approach for inter-VLAN routing in VXLAN), RT-2 routes carry TWO VNI labels: Label1 is the L2 VNI for the host's VLAN, and Label2 is the L3 VNI for the VRF. The remote VTEP uses Label2 to identify the correct routing table for inter-VLAN traffic. In Asymmetric IRB, only Label1 is present, and routing happens on the ingress VTEP only.
5. Route Type 3 — Inclusive Multicast Ethernet Tag (IMET) Route
| Route Type Number | Type 3 (RT-3) — IMET Route |
| RFC Reference | RFC 7432 / RFC 8365 |
| Primary Purpose | VTEP Discovery and BUM traffic handling — establishes the VXLAN tunnel mesh and identifies how each VTEP handles Broadcast, Unknown-unicast, Multicast traffic for each VNI |
| Generated By | Every VTEP, for every L2 VNI it participates in |
The IMET Route serves two critical purposes in a VXLAN fabric. It is arguably the first EVPN route type that gets exchanged when a VTEP comes online, and it establishes the foundation for all BUM traffic handling.
Purpose 1 — VTEP Auto-Discovery
When a VTEP is configured to participate in an L2 VNI, it generates and advertises an RT-3 IMET route for that VNI. Every other VTEP that imports RT-3 routes with the same Route Target discovers the advertising VTEP as a participant in the same L2 segment. This creates the logical VXLAN tunnel mesh — VTEPs learn about each other through RT-3 exchange rather than requiring manual peer configuration.
Purpose 2 — BUM Traffic Handling Advertisement
The RT-3 route carries a PMSI (Provider Multicast Service Interface) Tunnel Attribute that specifies how the advertising VTEP handles BUM traffic for the VNI. The two main options are:
- Ingress Replication (IR) / Headend Replication: PMSI Tunnel Type 6 — the ingress VTEP unicasts BUM packets to each remote VTEP individually. No underlay multicast required. The most common approach in data centers.
- PIM-based Multicast: PMSI Tunnel Type 2 (PIM-SM) or Type 3 (PIM-Bidir) — the underlay uses IP multicast to distribute BUM traffic. More efficient at scale but requires multicast in the underlay.
RT-3 IMET Route Output Example:
show bgp l2vpn evpn route-type 3
BGP routing table entry for [3]:[0]:[32]:[10.1.1.1]/88
Paths: (1 available, best #1)
Path type: internal, path is valid, is best path
Nexthop: 10.1.1.1
Extended Community: RT:65001:10010 ENCAP:8
PMSI: Flags: 0x00, Tunnel type: Ingress Replication
Label: 10010, Tunnel Id: 10.1.1.1
💡 RT-3 and the Flood-and-Learn Replacement
Without EVPN, VTEPs used multicast or flood-and-learn to discover each other. With RT-3, this discovery happens through BGP — providing a controlled, scalable, and auditable mechanism for VTEP membership tracking per VNI. When a new VTEP joins a VNI, it simply advertises its RT-3 route and is immediately discovered by all peers.
6. Route Type 4 — Ethernet Segment Route
| Route Type Number | Type 4 (RT-4) |
| RFC Reference | RFC 7432 |
| Primary Purpose | Ethernet Segment Discovery and Designated Forwarder (DF) Election for multihomed segments |
| Generated By | VTEPs participating in a multihomed Ethernet Segment (ESI != 0) |
The Ethernet Segment Route works hand-in-hand with RT-1 for multihoming scenarios. While RT-1 handles traffic aliasing and mass withdrawal, RT-4 handles the crucial task of Designated Forwarder (DF) election.
What Is the Designated Forwarder (DF)?
When multiple VTEPs are connected to the same multihomed Ethernet Segment (e.g., a server dual-homed to two leaf switches), only ONE of those VTEPs should forward BUM traffic toward the CE device on that segment at any given time. This prevents duplicate delivery of broadcast/multicast/unknown-unicast frames to the multihomed host. The VTEP elected as DF for a given VNI is the one responsible for forwarding BUM traffic to the CE.
RT-4 routes enable all VTEPs on a shared Ethernet Segment to discover each other and then run the DF election algorithm. The election is based on comparing VTEP IP addresses — typically the highest or lowest IP wins, depending on the election algorithm (modulo-based or preference-based methods are defined in RFC 8584).
RT-4 NLRI Fields
- RD: Route Distinguisher of the advertising VTEP
- ESI: 10-byte Ethernet Segment Identifier identifying the shared segment
- IP Address Length + Originating IP: The VTEP's IP address used in DF election comparison
# Verify DF Election Result (NX-OS)
show nve ethernet-segment
show bgp l2vpn evpn route-type 4
ESI: 0300.0000.0001.0000.0100
ES State: Up
DF Election Algorithm: Preference
DF Timeout: 3 seconds
Interfaces:
port-channel10 (oper up, primary)
VNI List:
VNI 10010 DF: This node is DF
🔑 RT-1 + RT-4 — The Multihoming Team
RT-1 and RT-4 always work together for multihoming. RT-4 handles DF election (who forwards BUM), while RT-1 handles aliasing (load-balancing known unicast) and mass withdrawal (fast convergence). In single-homed VTEP environments, neither RT-1 nor RT-4 is generated or needed.
7. Route Type 5 — IP Prefix Route
| Route Type Number | Type 5 (RT-5) — IP Prefix Route |
| RFC Reference | RFC 9136 (formerly draft-ietf-bess-evpn-prefix-advertisement) |
| Primary Purpose | IP prefix reachability — advertising external routes, subnet prefixes, and Layer 3 gateway information into the EVPN fabric. The key enabler for Symmetric IRB and DCI (Data Center Interconnect) |
| Generated By | Border leaf/spine VTEPs redistributing external routes; any VTEP in symmetric IRB for subnet routes |
The IP Prefix Route is the Layer 3 extension of EVPN. While RT-2 advertises individual host /32 (IPv4) or /128 (IPv6) routes with their associated MAC addresses, RT-5 advertises IP prefixes of any length — without requiring a MAC address binding. This makes RT-5 the mechanism for:
Key Use Cases for RT-5
- External Route Redistribution: Border leaf switches redistribute routes learned from external routers (OSPF, IS-IS, static, eBGP) into the EVPN fabric as RT-5 routes, making external destinations reachable from hosts within the fabric
- Data Center Interconnect (DCI): RT-5 routes carry subnet and aggregate prefixes between data centers, enabling multi-site VXLAN fabrics without requiring host-level MAC/IP routes to cross the DCI link
- Subnet Advertisement in Symmetric IRB: In symmetric IRB designs, the anycast gateway IP for each VLAN subnet can be advertised as an RT-5 prefix route, enabling remote VTEPs to perform proper L3 forwarding decisions
- Default Route Advertisement: A border gateway can advertise a default route (0.0.0.0/0) as an RT-5 route into the fabric, enabling internet-bound traffic from fabric hosts to be routed correctly
RT-5 NLRI Structure
Unlike RT-2, RT-5 does not carry a MAC address field. Its key fields are:
- RD: Route Distinguisher
- ESI: Always zero (no MAC binding)
- Ethernet Tag: Always zero for VXLAN
- IP Prefix Length: Length of the advertised prefix (1-32 for IPv4, 1-128 for IPv6)
- IP Prefix: The actual IP prefix being advertised
- GW IP Address: The IP address of the gateway for this prefix (next hop in the overlay)
- Label (VNI): The L3 VNI for the VRF this prefix belongs to
RT-5 Route Output Example:
show bgp l2vpn evpn route-type 5
BGP routing table entry for [5]:[0]:[0]:[24]:[10.100.0.0]/224
Paths: (1 available, best #1)
Path type: internal, path is valid, is best path
Nexthop: 10.1.1.5 (border-leaf VTEP)
Extended Community: RT:65001:99999 ENCAP:8
Router MAC:5004.0000.1b08
VNI: 99999 (L3 VRF VNI)
Gateway IP: 10.1.1.5
🔥 RT-5 and the Router MAC Extended Community
RT-5 routes for symmetric IRB carry a Router MAC Extended Community — the MAC address of the advertising VTEP's anycast or unique gateway MAC. This is essential for the receiving VTEP to correctly construct the inner Ethernet header when forwarding packets to remote VTEPs using the L3 VNI, ensuring the packet arrives at the correct overlay gateway for L3 processing.
8. Route Types 6 Through 11 — Extended and Emerging Types
While Route Types 1-5 are the foundation of every EVPN/VXLAN deployment, Route Types 6-11 address more specialized use cases. Their implementation varies significantly across vendors, and not all are supported in every platform or deployment scenario.
Route Type 6 — Selective Multicast Ethernet Tag (SMET) Route
Purpose: Optimizes multicast traffic delivery in EVPN fabrics. Instead of flooding all BUM traffic to all VTEPs in a VNI (as RT-3 ingress replication does), RT-6 enables VTEPs to signal which multicast groups they are interested in — enabling selective multicast delivery only to VTEPs with interested receivers.
RFC: draft-ietf-bess-evpn-optimized-ir | Use Case: Large fabrics with significant IP multicast traffic; reduces BUM flooding overhead significantly
Route Type 7 — IGMP Join Synch Route
Purpose: Synchronizes IGMP (Internet Group Management Protocol) membership information between VTEPs on the same multihomed Ethernet Segment. When a host on a multihomed segment joins a multicast group, RT-7 ensures all VTEPs on that segment have consistent IGMP group membership state — preventing packet loss during failover events.
RFC: draft-ietf-bess-evpn-igmp-mld-proxy | Use Case: EVPN multihoming environments with IP multicast receivers
Route Type 8 — IGMP Leave Synch Route
Purpose: The complement to RT-7 — synchronizes IGMP Leave messages between VTEPs on multihomed segments. When a host leaves a multicast group, RT-8 propagates this information to ensure all VTEPs on the segment remove the host from their multicast forwarding tables consistently.
RFC: draft-ietf-bess-evpn-igmp-mld-proxy | Use Case: Works alongside RT-7 for complete IGMP state synchronization in multihomed EVPN environments
Route Type 9 — Per-Region I-PMSI A-D Route
Purpose: Used in hierarchical EVPN deployments and inter-AS EVPN scenarios to advertise inclusive multicast service interface (I-PMSI) tunnel information at a regional or area level. Primarily relevant in very large-scale carrier and service provider EVPN deployments.
RFC: RFC 9251 | Use Case: Hierarchical EVPN / large-scale service provider deployments; rarely seen in data center VXLAN deployments
Route Type 10 — S-PMSI A-D Route
Purpose: Selective PMSI (S-PMSI) Auto-Discovery — used to signal the creation of selective multicast tunnels for specific (S,G) multicast groups when traffic rates justify moving from inclusive to selective delivery trees. Enables efficient multicast delivery at scale by avoiding unnecessary replication.
RFC: RFC 9251 | Use Case: Optimized multicast delivery in large EVPN deployments; service provider and large enterprise multicast scenarios
Route Type 11 — Multicast Leaf A-D Route
Purpose: Used by leaf nodes to join S-PMSI tunnels advertised by root nodes (via RT-10). A leaf node sends RT-11 to signal its interest in receiving traffic from a specific selective multicast tunnel, completing the selective multicast join mechanism in EVPN.
RFC: RFC 9251 | Use Case: Selective multicast tree joining; complements RT-10 in optimized multicast delivery scenarios
📌 Practical Note on Route Types 6-11
In the vast majority of enterprise data center VXLAN deployments, you will work primarily with Route Types 1-5. Types 6-11 become relevant when you are dealing with large-scale IP multicast optimization in EVPN fabrics, hierarchical EVPN designs, or service provider EVPN deployments. Always check your vendor's platform support matrix before planning deployments using these newer route types.
9. EVPN Route Type Comparison Table
The following table provides a concise reference for all EVPN route types, their purposes, key fields, and deployment frequency in VXLAN data center environments:
| RT # | Name | Primary Purpose | Carries MAC? | Carries IP? | DC Frequency |
|---|---|---|---|---|---|
| RT-1 | Ethernet A-D | Multihoming — Aliasing & Mass Withdrawal | ❌ | ❌ | Multihomed only |
| RT-2 | MAC/IP Advertisement | Host MAC/IP learning; ARP Suppression; Symmetric IRB | ✅ | ✅ (opt) | Universal |
| RT-3 | IMET | VTEP Discovery; BUM Traffic Handling (IR or Multicast) | ❌ | ❌ | Universal |
| RT-4 | Ethernet Segment | ES Discovery; Designated Forwarder Election | ❌ | VTEP IP | Multihomed only |
| RT-5 | IP Prefix | External route redistribution; DCI; Symmetric IRB subnet routes | ❌ | ✅ Prefix | L3 Fabrics |
| RT-6 | SMET | Selective Multicast — optimized IR | ❌ | Mcast Group | Specialized |
| RT-7 | IGMP Join Synch | IGMP group membership sync across multihomed segment VTEPs | ❌ | Mcast Group | Specialized |
| RT-8 | IGMP Leave Synch | IGMP leave sync across multihomed segment VTEPs | ❌ | Mcast Group | Specialized |
| RT-9 | Per-Region I-PMSI A-D | Hierarchical EVPN inclusive multicast signaling | ❌ | ❌ | SP / Rare |
| RT-10 | S-PMSI A-D | Selective multicast tunnel advertisement | ❌ | Mcast (S,G) | SP / Rare |
| RT-11 | Multicast Leaf A-D | S-PMSI tunnel join signaling from leaf to root | ❌ | Mcast (S,G) | SP / Rare |
10. How Route Types Work Together — End-to-End VXLAN Flow
Understanding each route type in isolation is valuable — but understanding how they work together in a real VXLAN fabric is essential. Here is the complete sequence of events for a typical data center fabric scenario:
Scenario: Host A (VLAN 10) on Leaf-1 communicates with Host B (VLAN 20) on Leaf-2
Phase 1 — Fabric Bootstrap (RT-3)
When Leaf-1 and Leaf-2 come online, each advertises RT-3 IMET routes for every L2 VNI they participate in. Leaf-1 discovers Leaf-2 as a VNI participant (and vice versa) through BGP RT-3 exchange via the Route Reflector. VXLAN tunnels are dynamically established. BUM traffic method (ingress replication) is communicated via the PMSI attribute.
Phase 2 — Host MAC/IP Learning (RT-2)
Host A sends its first packet. Leaf-1 learns Host A's MAC address through data-plane learning. Leaf-1 also learns Host A's IP address from ARP. Leaf-1 generates an RT-2 MAC+IP Advertisement route and advertises it to all peers. Leaf-2 receives this RT-2 and installs Host A's MAC and IP in its local EVPN table, populating its ARP suppression cache.
Phase 3 — ARP Suppression (RT-2 Utilized)
Host B on Leaf-2 sends an ARP request for Host A's IP. Because Leaf-2 already has Host A's MAC+IP in its EVPN table (learned from the RT-2 route above), Leaf-2 answers the ARP locally — the ARP request is never flooded across the VXLAN fabric. This eliminates BUM traffic for known hosts.
Phase 4 — Inter-VLAN Routing (RT-5 + RT-2 L3 VNI)
Host B is in VLAN 20 — a different subnet from Host A's VLAN 10. In symmetric IRB, traffic is routed at both the ingress and egress VTEP using the L3 VNI. RT-5 routes carry the subnet prefixes for both VLANs, and the L3 VNI in RT-2 Label2 enables correct VRF routing at each VTEP. The Router MAC extended community ensures correct inner Ethernet header construction for the routed packet.
Phase 5 — Multihoming Failover (RT-1 + RT-4, if applicable)
If Host A is dual-homed to Leaf-1 and Leaf-3, RT-4 routes have already established which leaf is the DF for BUM traffic. RT-1 per-ES routes have enabled Leaf-2 to load-balance known unicast traffic across both Leaf-1 and Leaf-3. If Leaf-1's link to Host A fails, a RT-1 mass withdrawal instantly signals Leaf-2 to remove all routes via Leaf-1 — convergence is measured in seconds rather than minutes.
11. EVPN Route Types on Key Vendor Platforms
All major data center networking vendors support EVPN/VXLAN with the core route types. Here are the key verification commands for each platform:
Cisco NX-OS (Nexus 9000 / Catalyst 9000)
show bgp l2vpn evpn summary show bgp l2vpn evpn route-type 1 show bgp l2vpn evpn route-type 2 show bgp l2vpn evpn route-type 3 show bgp l2vpn evpn route-type 4 show bgp l2vpn evpn route-type 5 show nve peers show nve vni show l2route evpn mac all show ip arp suppression-cache detail
Arista EOS
show bgp evpn summary show bgp evpn route-type auto-discovery show bgp evpn route-type mac-ip show bgp evpn route-type imet show bgp evpn route-type ethernet-segment show bgp evpn route-type ip-prefix show vxlan address-table show vxlan vni show arp vrf TENANT suppressed
Juniper Junos (QFX / EX Series)
show bgp summary show route table bgp.evpn.0 show evpn database show evpn instance show evpn l2-domain show route table evpn-vxlan.evpn.0 detail show ethernet-switching vxlan-tunnel-end-point remote
Nokia SR Linux / SROS
show network-instance default protocols bgp routes evpn route-type 1 summary show network-instance default protocols bgp routes evpn route-type 2 summary show network-instance default protocols bgp routes evpn route-type 3 summary show network-instance default protocols bgp routes evpn route-type 5 summary info from state network-instance MAC-VRF-10 bridge-table mac-table
12. Troubleshooting EVPN Routes in VXLAN Fabrics
| Problem Symptom | Likely Cause (Route Type) | Diagnostic Command |
|---|---|---|
| VXLAN tunnel not forming between VTEPs | RT-3 IMET routes not being exchanged; BGP l2vpn evpn session issue | show bgp l2vpn evpn route-type 3 |
| Remote host not reachable (L2) | RT-2 MAC route missing or not imported (RT mismatch) | show bgp l2vpn evpn route-type 2 |
| ARP flooding not being suppressed | RT-2 MAC+IP routes not being advertised; ARP suppression not enabled | show ip arp suppression-cache detail |
| Inter-VLAN routing failing | RT-5 IP prefix routes missing; L3 VNI not configured; Router MAC issue | show bgp l2vpn evpn route-type 5 |
| Duplicate frames in multihomed setup | RT-4 DF election not working; split-horizon filtering issue | show nve ethernet-segment |
| Slow convergence after link failure | RT-1 mass withdrawal not working; BGP timer too slow | show bgp l2vpn evpn route-type 1 |
| External routes not visible in fabric | RT-5 routes not being redistributed at border leaf; RT import/export mismatch | show bgp l2vpn evpn route-type 5 |
🔧 Golden Troubleshooting Rule for EVPN
When troubleshooting EVPN issues, always follow this order: (1) Verify BGP session is up → (2) Confirm Route Target import/export alignment → (3) Check that expected route types are being generated → (4) Verify routes are being received and imported correctly → (5) Confirm hardware/forwarding table is populated. Most EVPN issues are RT mismatch, VNI misconfiguration, or underlay reachability problems.
13. Frequently Asked Questions (FAQ)
Q: Which EVPN route types are absolutely mandatory for a basic VXLAN fabric?
A: For a basic L2 VXLAN fabric with BGP EVPN control plane, you need RT-2 (MAC/IP learning) and RT-3 (VTEP discovery and BUM handling). These are the two foundational route types without which VXLAN EVPN simply does not function. If you add Layer 3 routing, RT-5 becomes essential. If you add multihoming, RT-1 and RT-4 are required.
Q: What is the difference between asymmetric IRB and symmetric IRB in terms of EVPN routes?
A: In asymmetric IRB, routing happens only on the ingress VTEP, and only RT-2 routes are needed (with L2 VNI label only). In symmetric IRB, routing happens at both ingress and egress VTEPs using an L3 VNI. RT-2 routes carry both L2 VNI (Label1) and L3 VNI (Label2), and RT-5 IP prefix routes are also used. Symmetric IRB is the recommended approach for scalable multi-tenant environments as it distributes the routing workload and eliminates the need for all VNIs to be configured on every VTEP.
Q: Can RT-2 and RT-5 both be used simultaneously in the same fabric?
A: Yes — in fact, in a properly designed symmetric IRB fabric, both are always present simultaneously. RT-2 routes advertise individual host /32 routes with MAC+IP binding (critical for ARP suppression and direct host routing), while RT-5 routes advertise subnet prefixes and external routes. Remote VTEPs prefer the more specific RT-2 /32 route for known hosts and fall back to the RT-5 subnet/prefix route for unknown destinations.
Q: What is a Route Reflector (RR) and do I need one for EVPN?
A: A BGP Route Reflector is used to avoid the need for full mesh iBGP peering between all VTEPs. In a data center EVPN fabric, the spine switches typically act as Route Reflectors for the L2VPN EVPN address family — leaf VTEPs peer only with the spine RRs, which reflect EVPN routes between all leaf peers. This is the standard and recommended design for scaling EVPN fabrics beyond a handful of VTEPs.
Q: How does EVPN handle MAC mobility (when a host moves between VTEPs)?
A: EVPN uses a MAC Mobility Extended Community carried in RT-2 routes. When a MAC address is detected on a new VTEP (after a host VM migration, for example), the new VTEP advertises an RT-2 for that MAC with a higher sequence number in the MAC Mobility extended community. All receiving VTEPs replace the old RT-2 (from the previous VTEP) with the new one, updating their forwarding tables. This enables seamless VM mobility without traffic disruption.
Q: What is the ESI (Ethernet Segment Identifier) and how is it formatted?
A: The ESI is a 10-byte (80-bit) identifier that uniquely identifies a multihomed Ethernet Segment across the fabric. The first byte indicates the ESI Type (0 = manually configured, 1 = based on LACP system MAC and port key, 2 = based on bridge MAC, 3 = based on MAC address of CE device, 4 = based on router ID). On Cisco NX-OS with vPC, the ESI is automatically derived from the vPC domain and port-channel configuration. On Arista with MLAG, it is derived from the MLAG peer configuration. A non-zero ESI signals that RT-1 and RT-4 processing is required for the connected segment.
📌 Quick Reference
EVPN Route Types — Engineer's Cheat Sheet
EVPN ROUTE TYPES — VXLAN DATA CENTER REFERENCE
══════════════════════════════════════════════════════════
RT-1 Ethernet A-D │ Multihoming: Aliasing + Mass Withdrawal
│ Per-ES: ESI + Tag=0xFFFFFFFF → Aliasing
│ Per-EVI: ESI + EVI Tag → Fast Convergence
RT-2 MAC/IP Advert. │ ★ THE CORE ROUTE — All fabrics need this
│ MAC Only: L2-only environments
│ MAC+IPv4: ARP Suppression + Symmetric IRB
│ MAC+IPv6: ND Suppression + IPv6 fabrics
│ Label1=L2 VNI, Label2=L3 VNI (sym. IRB)
RT-3 IMET │ ★ VTEP Discovery — All fabrics need this
│ PMSI Type 6 = Ingress Replication (common)
│ PMSI Type 2/3 = Underlay Multicast
│ One RT-3 per VNI per VTEP
RT-4 Ethernet Segment │ Multihoming only — DF Election
│ Carries: ESI + Originating VTEP IP
│ Enables: split-horizon + DF role
RT-5 IP Prefix │ Layer 3 / External routes
│ No MAC! Carries IP prefix + GW IP
│ L3 VNI label + Router MAC community
│ Used for: DCI, external redistribution,
│ symmetric IRB subnet routes
RT-6 SMET │ Selective Multicast optimization
RT-7 IGMP Join Synch │ Multicast group sync (multihomed ES)
RT-8 IGMP Leave Synch │ Multicast leave sync (multihomed ES)
RT-9 Per-Region I-PMSI│ Hierarchical EVPN (SP use)
RT-10 S-PMSI A-D │ Selective multicast trees (SP use)
RT-11 Multicast Leaf │ S-PMSI join from leaf (SP use)
══════════════════════════════════════════════════════════
MINIMUM REQUIRED: RT-2 + RT-3 (L2 fabric)
ADD FOR L3: RT-5 + RT-2 Label2 (L3 VNI)
ADD FOR MHOMING: RT-1 + RT-4 (ESI multihoming)
🔵 Conclusion — Mastering EVPN Route Types
EVPN route types are the language through which VXLAN fabric VTEPs communicate — sharing MAC addresses, IP reachability, multicast membership, multihoming state, and external route information through a single, elegant BGP address family extension.
For any network engineer working with modern data center infrastructure, fluency in EVPN route types is non-negotiable. Understanding when each route type is generated, what it carries, and how receiving VTEPs process it is the difference between being able to design, deploy, and troubleshoot EVPN/VXLAN fabrics confidently versus being dependent on vendor wizards and hoping for the best.
Start with RT-2 and RT-3 as your foundation — master the MAC/IP advertisement and VTEP discovery mechanics thoroughly. Add RT-5 when you introduce Layer 3 routing. Add RT-1 and RT-4 when you design multihomed topologies. The rest will follow naturally as your EVPN expertise grows.
Tags: EVPN Route Types | VXLAN Data Center | BGP EVPN | Route Type 1 | Route Type 2 MAC/IP | Route Type 3 IMET | Route Type 4 Ethernet Segment | Route Type 5 IP Prefix | VXLAN Fabric | ARP Suppression | Symmetric IRB | Asymmetric IRB | VTEP | VNI | Data Center Networking | CCIE Data Center | NX-OS EVPN | Arista EVPN | Juniper EVPN | Leaf Spine Architecture
