Many modern enterprise and cloud data center networks have standardized on a combination of BGP, EVPN, and VXLAN to build scalable Layer 2 and Layer 3 fabrics. Whether the environment is only a few dozen switches or thousands of leaf and spine devices, EVPN has become the preferred control plane for distributing endpoint reachability information across the fabric.
An important concept to understand when first learning EVPN are the route types used within the EVPN address family. Unlike traditional BGP, which primarily exchanges IP prefixes, EVPN distributes a variety of information. Each route type serves a specific purpose and helps the fabric build a complete picture of where endpoints, gateways, and services exist.
Why EVPN Needs Multiple Route Types
Traditional networks (campus, legacy data center, etc) rely mostly on flooding and MAC learning. Switches learn MAC addresses by observing traffic and then flooding unknown unicast traffic throughout a Layer 2 domain, also known as flood-and-learn. That works well at a small scale, but it becomes very inefficient when we scale up to large data centers with hundreds or thousands of switches.
EVPN replaces many of these data-plane learning mechanisms with a control-plane approach. Instead of waiting for switches to discover information through flooding, endpoint information is distributed proactively through BGP EVPN, which is an extension of BGP.
To do this, EVPN uses several specialized route types that communicate different categories of information:
- MAC addresses
- IP addresses
- VXLAN tunnel endpoints (VTEPs)
- Gateway MAC/IP information
- Multicast and broadcast handling
- Layer 3 routing information
What we get is a network fabric that converges quickly, scales efficiently, and minimizes (or eliminates) unnecessary flooding. In most production VXLAN fabrics, we see five route types which you can see in the table below.
| Route Type | Purpose |
| Type 1 | Ethernet Auto-Discovery and multihoming support |
| Type 2 | MAC and IP endpoint advertisement |
| Type 3 | VTEP discovery and BUM replication |
| Type 4 | Ethernet Segment advertisement for multihoming |
| Type 5 | Layer 3 IP prefix advertisement |
Route Type 1
Route Type 1 is the Ethernet Auto-Discovery (A-D) Route. It’s how we advertise the existence of an Ethernet segment into the network. This route is most commonly associated with multihoming scenarios where a server, firewall, or some network appliance connects to multiple leaf switches at the same time.
For example, if HostA is connected to both Leaf1 and Leaf2 using LACP, both leaf switches need a mechanism to advertise that they’re participating in the same Ethernet segment. Route Type 1 provides this information.
Its primary functions include:
- Multihoming discovery
- Ethernet segment auto-discovery
- Fast convergence during failures
- Aliasing and backup path advertisement
This means that without Route Type 1, EVPN multihoming wouldn’t work correctly.
Route Type 2
Route Type 2 is the most common EVPN route and probably the one many engineers spend the most time troubleshooting. Type 2 routes tell the fabric where endpoints live. In other words, this is the MAC/IP advertisement route that advertises endpoint reachability information. It can contain a MAC address, IP address, VNI, and the originating VTEP. Type 2 routes also advertise gateway MAC/IP information used by distributed Anycast gateways.
Imagine a host connected to switch Leaf1. When Leaf1 learns this endpoint, it advertises a Type 2 route to the rest of the fabric. The advertisement contains information like the MAC address, IP, VNI, and the originating VTEP.
Remote leaf switches receive this route and install it into their own forwarding tables. Then, MAC learning becomes control-plane driven, unknown unicast flooding is reduced, we can support endpoint mobility, and convergence improves significantly.
If you’re a network engineer and you’ve ever run commands such as show bgp evpn route-type mac-ip or show bgp evpn in your network, you’ve probably been looking at Type 2 routes. Here’s an example from my home lab running cEOS switches:
leaf1#show bgp evpn route-type mac-ipBGP routing table information for VRF defaultRouter identifier 10.0.0.11, local AS number 65101Route status codes: * - valid, > - active, S - Stale, E - ECMP head, e - ECMP c - Contributing to ECMP, % - Pending best path selectionOrigin codes: i - IGP, e - EGP, ? - incompleteAS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop Network Next Hop Metric LocPref Weight Path * > RD: 10.0.0.11:10010 mac-ip aac1.ab6b.43fb - - - 0 i * > RD: 10.0.0.11:10010 mac-ip aac1.ab6b.43fb 10.10.10.11 - - - 0 i * >Ec RD: 10.0.0.12:10010 mac-ip aac1.aba0.1b3c 10.0.0.12 - 100 0 65000 65102 i * ec RD: 10.0.0.12:10010 mac-ip aac1.aba0.1b3c 10.0.0.12 - 100 0 65000 65102 i * >Ec RD: 10.0.0.13:10020 mac-ip aac1.abee.ae1d 10.0.0.13 - 100 0 65000 65103 i * ec RD: 10.0.0.13:10020 mac-ip aac1.abee.ae1d 10.0.0.13 - 100 0 65000 65103 i * >Ec RD: 10.0.0.13:10020 mac-ip aac1.abee.ae1d 10.20.20.13 10.0.0.13 - 100 0 65000 65103 i * ec RD: 10.0.0.13:10020 mac-ip aac1.abee.ae1d 10.20.20.13 10.0.0.13 - 100 0 65000 65103 i
The first entries show us the local route from Leaf1, which means that Leaf1 learned a local endpoint with MAC aac1.ab6b.43fb, IP address of 10.10.10.11, and VNI 10010. Then, Leaf1 advertises that into EVPN. As we go down the list of entries, we can see remote routes and endpoints behind remote VTEPs.
Route Type 3
Route Type 3 routes are Inclusive Multicast Ethernet Tag Routes. The purpose of an IMET route is pretty straightforward. They help establish the actual VXLAN flooding topology by informing the fabric that a particular VTEP is a member of a specific VXLAN segment (VNI), which is often mapped to a VLAN locally. In essence, they tell the fabric which VTEPs participate in a VNI and how the remote VTEPs can reach a VTEP participating in a specific VNI.
Typically, a VTEP advertises a Type 3 route for each VNI in which it participates. In my lab, I have four leaf switches:
- Leaf1 VTEP 10.0.0.11
- Leaf2 VTEP 10.0.0.12
- Leaf3 VTEP 10.0.0.13
- Leaf4 VTEP 10.0.0.14
Leaf1 and Leaf2 advertise a Type 3 route indicating they participate in VNI 10010, and Leaf3 and Leaf4 advertise they participate in VNI 10020. They also advertise the VTEP used as the next-hop address. Take a look at this output of show bgp evpn route-type imet from my lab:
leaf1#show bgp evpn route-type imet BGP routing table information for VRF defaultRouter identifier 10.0.0.11, local AS number 65101Route status codes: * - valid, > - active, S - Stale, E - ECMP head, e - ECMP c - Contributing to ECMP, % - Pending best path selectionOrigin codes: i - IGP, e - EGP, ? - incompleteAS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop Network Next Hop Metric LocPref Weight Path * > RD: 10.0.0.11:10010 imet 10.0.0.11 - - - 0 i * >Ec RD: 10.0.0.12:10010 imet 10.0.0.12 10.0.0.12 - 100 0 65000 65102 i * ec RD: 10.0.0.12:10010 imet 10.0.0.12 10.0.0.12 - 100 0 65000 65102 i * >Ec RD: 10.0.0.13:10020 imet 10.0.0.13 10.0.0.13 - 100 0 65000 65103 i * ec RD: 10.0.0.13:10020 imet 10.0.0.13 10.0.0.13 - 100 0 65000 65103 i * >Ec RD: 10.0.0.14:10020 imet 10.0.0.14 10.0.0.14 - 100 0 65000 65104 i * ec RD: 10.0.0.14:10020 imet 10.0.0.14 10.0.0.14 - 100 0 65000 65104 i
Notice the first in the list is the local IMET route (this is Leaf1’s own Type 3 route). And below that we can see advertisements from Leaf 3 and Leaf 4 for a different VNI, 10020. In this environment, Leaf1 and Leaf2 both advertise Type 3 routes for VNI 10010 because each VTEP participates in that VXLAN segment. These advertisements allow each VTEP to build a flooding list for that VXLAN segment, so when BUM traffic such as ARP requests need to be replicated, the originating VTEP knows exactly which remote VTEPs should receive the traffic.
Route Type 4
Route Type 4 routes are Ethernet Segment Routes and help EVPN multihoming work correctly. Route Type 4 works closely with Route Type 1 in multihoming environments, but while Type 1 routes advertise attachment to a specific Ethernet segment, Type 4 routes advertise reachability to the Ethernet Segment Identifier (ESI) itself (the ESI is a 10-byte identifier used to represent a group of switches as one logical unit).
The main purpose of Route Type 4 is to support Designated Forwarder (DF) elections and other EVPN multihoming functions. By advertising Ethernet Segment reachability information, Type 4 routes help participating VTEPs figure out forwarding decisions, improve convergence, and avoid forwarding loops.
Consider our earlier example of HostA connected to both Leaf1 and Leaf2. Both leaf switches advertise Type 4 routes associated with the same ESI. Then, remote VTEPs use these advertisements to learn reachability to the shared ESI and to support DF election and multihoming convergence procedures.
Most single-homed deployments never directly interact with Type 4 routes, but in large-scale data centers where dual-attached servers are very common, Type 4 routes are extremely important. In fact, many engineers deploying EVPN-MH for the first time quickly learn that Type 1 and Type 4 routes are the key building blocks behind the design.
Route Type 5
A Route Type 5 advertises routed IP reachability. It extends EVPN beyond Layer 2 and enables Layer 3 route advertisements instead of advertising MAC addresses. So while Type 2 routes advertise individual MAC/IP host reachability, Type 5 routes advertise routed IP prefixes associated with a tenant VRF.
These routes are commonly used for basic inter-subnet routing, tenant VRFs, data center interconnect, and also external route advertisements. However, in many fabrics they’ll also be used for VRF route redistribution, prefix summarization, and route leaking.
In a typical EVPN-VXLAN fabric, tenant VRFs can advertise prefixes using Type 5 routes when routed reachability needs to be distributed through EVPN. Look at the output below of show bgp evpn route-type ip-prefix.
leaf1#show bgp evpn route-type ip-prefixBGP routing table information for VRF defaultRouter identifier 10.0.0.11, local AS number 65101Route status codes: * - valid, > - active, S - Stale, E - ECMP head, e - ECMP c - Contributing to ECMP, % - Pending best path selectionOrigin codes: i - IGP, e - EGP, ? - incompleteAS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop Network Next Hop Metric LocPref Weight Path * > RD: 10.0.0.11:50001 ip-prefix 10.10.10.0/24 - - - 0 i * >Ec RD: 10.0.0.12:50001 ip-prefix 10.10.10.0/24 10.0.0.12 - 100 0 65000 65102 i * ec RD: 10.0.0.12:50001 ip-prefix 10.10.10.0/24 10.0.0.12 - 100 0 65000 65102 i * >Ec RD: 10.0.0.13:50002 ip-prefix 10.20.20.0/24 10.0.0.13 - 100 0 65000 65103 i * ec RD: 10.0.0.13:50002 ip-prefix 10.20.20.0/24 10.0.0.13 - 100 0 65000 65103 i * >Ec RD: 10.0.0.14:50002 ip-prefix 10.20.20.0/24 10.0.0.14 - 100 0 65000 65104 i * ec RD: 10.0.0.14:50002 ip-prefix 10.20.20.0/24 10.0.0.14 - 100 0 65000 65104 i
In my lab I have TENANT-A and TENANT-B represented by their own VRFs. In the output, the first entry tells us that Leaf1’s locally originated Type 5 route is IP prefix 10.10.10.0/24 from a tenant in VRF context 50001. Leaf2 is advertising the same because they’re both participating in the same tenant/VLAN/subnet, TENANT-A.
Further down we see Leaf3 and Leaf4 are advertising TENANT-B in VRF context 50002 with the prefix 10.20.20.0/24.
Putting It All Together
When you look at these route types individually, it might seem complicated, but I believe they become easier to understand when you view them as pieces of a complete system.
Generally speaking, you’ll most frequently see Type 2 and Type 3 routes because they’re fundamental to endpoint learning and VXLAN operation. But as you begin implementing Anycast Gateways, tenant VRFs, and inter-subnet routing, you’ll see more Type 5 routes as well. And if you later introduce EVPN multihoming, Type 1 and Type 4 routes come into play to provide the control-plane intelligence we need for dual-homed endpoints.
In other words, each route type solves a specific problem, but together they allow EVPN to replace traditional flood-and-learn behavior with a scalable control-plane-driven architecture. And the real beauty of EVPN is that all of these route types are exchanged through standard MP-BGP which means that rather than relying on flooding and data-plane learning, the fabric distributes endpoint, gateway, and service information through a familiar and scalable control plane.
Thanks,
Phil
{networkphil} 
Leave a comment