Overview
I’ve read EVPN blogs that walk through Type 2 and Type 3, then stop. The BGP update looks clean, but then the fabric dies under load and you’re staring at BGP tables that look perfectly healthy.
The reason is simple: they skipped the underlay.
This post explains how BGP carries EVPN routes (Type 2 and Type 3), and why none of that matters without a reliable underlay.
Before we look at Type 2 and Type 3 routes, we need one BGP idea. BGP doesn’t carry only IP prefixes - it carries many kinds of reachability information.
Part 1: BGP fundamentals - what you already know
BGP’s job is simple: distribute reachability facts.
One router says: “I can reach 10.1.1.0/24” and BGP carries that fact to everyone else. The fact is called an NLRI - Network Layer Reachability Information. The metadata describing how to reach it (next hop, AS path, communities) is carried in the Path Attributes.
That’s BGP’s core. NLRI + Path Attributes = reachability.
BGP was extended to carry multiple types of NLRIs on the same session: IPv4 unicast, IPv6, VPNv4, MPLS labels. All on one TCP connection, all at the same time.
That’s what AFI/SAFI is - Address Family Identifier / Subsequent Address Family Identifier. It’s just a field in the BGP update that says: “This NLRI is an IPv4 prefix” or “This NLRI is a MAC address”.
BGP already had the mechanism. EVPN just added a new AFI/SAFI pair: AFI 25 (L2VPN) / SAFI 70 (EVPN).
No new protocol. Same BGP session. Just a different type of fact.
Two new concepts EVPN brings
EVPN introduces two things you need to understand before we talk about Type 2 and Type 3.
Route Distinguisher (RD)
Every EVPN route needs a unique identifier, even if two different tenants have the same MAC address. The RD is a 64-bit value that prefixes the NLRI, making it unique within the BGP table.
It’s like a serial number. Two tenants can both have MAC aa:bb:cc:dd:ee:ff. But Tenant A’s route has RD 65001:100. Tenant B’s route has RD 65002:100. BGP treats them as completely different routes.
Route Target (RT)
The RT is a BGP extended community used for route import and export. In most deployments, each VNI (VXLAN Network Identifier) maps to its own RT, so the RT effectively identifies which VXLAN segment a route belongs to.
When a VTEP advertises a MAC, it attaches an RT. Other VTEPs are configured with import policies that look for specific RT values; they only install the route if the attached RT matches one they care about. In other words, the RT says: “This route belongs in VNI 10000”, and the receiving VTEP’s import policy decides, “I care about VNI 10000, so I’ll accept it”.
One common point of confusion: RD and RT are not the same thing. They’re often set to the same value (e.g., 65001:10000 for both), which makes people think they’re interchangeable. They’re not. The RD makes the route unique within the BGP table. The RT tags the route so that import policies can control which VTEPs accept it.
That’s the foundation. EVPN reuses RD for uniqueness, RT for route import/export, and defines a new EVPN address family for MAC addresses.
Now let’s look at what actually travels inside those updates.
Part 2: EVPN routes - Type 2 and Type 3
For basic L2 VXLAN, you only need two route types: Type 2 and Type 3. Type 1 (Ethernet Auto-Discovery) and Type 4 (Ethernet Segment) handle multihoming. Type 5 (IP Prefix) handles inter-subnet routing.
These two route types carry the whole story of how a fabric comes up and learns hosts.
Type 3: the “I exist” route
Before learning about any hosts, a VTEP first announces itself. That’s Type 3 - the Inclusive Multicast Ethernet Tag route.
When leaf2 activates VNI 10000, it sends a Type 3 route that says, roughly: “I’m VTEP 10.0.0.2. I host VNI 10000. If you have broadcast, unknown-unicast, or multicast traffic for this VNI, send it to me.”
The “Oh, that’s all it is?” moment:
Type 3 is just a membership list. It doesn’t carry MACs or IPs. It tells everyone: “I’m in this VNI. Flood to me.” That’s it.
The result is a list of every VTEP participating in that VNI. That list is what usually replaces multicast in the underlay: instead of joining a multicast group, a VTEP consults its Type 3 list and replicates BUM traffic as unicast, one copy per peer.
Eventually, a host sends that first frame.
Type 2: the “this host lives here” route
Once VTEPs know about each other, they still don’t know where any individual MAC lives. That’s Type 2 - the MAC/IP Advertisement route.
A host sends a frame. Its VTEP learns the MAC on a local port - normal L2 learning, nothing new.
Local learning tells only the local leaf where the MAC lives. The Type 2 route tells every other VTEP.
Next, the VTEP announces it. leaf2 sends a Type 2 route: “MAC aa:bb:cc:00:00:01 lives behind me, VTEP 10.0.0.2, VNI 10000.”
Every VTEP whose import policy matches the Route Target attached to that route installs the entry in its forwarding table.
The “Oh, that’s all it is?” moment:
Type 2 is just a MAC-to-VTEP mapping. Once learned, traffic to that MAC goes directly - no BUM replication needed.
Type 3 gets VTEPs talking to each other. Type 2 gets hosts found. In a simple L2 VXLAN deployment, these two routes are the entire control plane.
In a small diagram you can imagine every VTEP talking directly. Production fabrics usually use route reflectors (the spines) to distribute these routes. The end result is the same: every VTEP learns the same Type 2 and Type 3 information.
By now, every VTEP knows where every MAC lives. The control plane is working perfectly.
But none of that matters if packets can’t reach the destination VTEP.
Part 3: Underlay design - why it matters
BGP (the overlay) gives you the address book. The underlay is the road.
EVPN solved the learning problem. It tells every VTEP where every MAC lives.
But knowing where the destination is isn’t enough. The encapsulated packets still have to get there.
That’s the underlay’s job.
The underlay has exactly three responsibilities:
- Reach the remote VTEP.
- Use all available paths.
- Recover quickly when one fails.
Route reflectors, iBGP vs. eBGP, ECMP, and BFD are ways of meeting those three goals.
That’s the next part of the story.