EVPN Route Types: A Deep Dive From a Live Fabric

Every EVPN explainer shows you a Type-2 route, waves at Type-3, and calls it a day. Which is a shame, because a datacenter fabric runs on five core route types (extensions like RFC 9251 add more, but these five do the heavy lifting), and the two nobody demos (Type-1 and Type-4) are the ones doing the cleverest work. Most labs never show them for a simple reason: they only exist when you run EVPN multihoming, and most labs run MLAG instead, where the redundancy magic hides inside a proprietary peerlink.

My containerlab fabric runs real EVPN-MH: the servers dual-home to their leaf pairs through Ethernet Segments, no MLAG anywhere. Which means all five route types are alive in it right now. Every output below is captured from that running fabric. If you want the lab itself, the previous post shows how it builds itself from a git repo.

The cast, in one table

The config that creates all of this

Worth seeing how little configuration stands behind five route types. On each leaf: EVPN on, multihoming on, an Ethernet Segment ID per host bond, a shared segment MAC per leaf pair, and the spine uplinks marked for uplink tracking. The route distinguishers you will see below are auto-derived. The L2 route targets come straight from this config: each L2VNI is pinned to a fabric-wide 65000:VNI value, a deliberate convention that keeps imports deterministic and vendor-neutral in a fabric where every leaf pair runs its own ASN. The L3VNI target travels as the origin pair's ASN:VNI; FRR imports it by matching the VNI half.

One detail that pays off later: each leaf pair shares a segment MAC. This worker pair uses 44:38:39:be:ef:12; the master pair you will meet in the captures uses 44:38:39:be:ef:11. It doubles as the LACP system ID the host sees, so the server thinks there is a single switch on the other end of its bond. That MAC is about to show up inside three different route types.

Type-3 first: the fabric says hello

Before anyone can learn a MAC, unknown traffic has to flood somewhere. Type-3 is each VTEP raising its hand per L2VNI: flood to me. Every VTEP originates one IMET route per L2VNI it serves; the capture shows the master leaves, 10.0.0.11 and 10.0.0.12, advertising theirs. Each leaf collects the IMET routes that match its own VNIs, and that set becomes the VNI's ingress replication list. For my worker VNI 10120 that list is built from the pair leaf's IMET, which is exactly the single remote VTEP in the table below. No multicast underlay, no PIM, just BGP building the flood domain.

Read the prefix as [3]:[EthTag]:[IPlen]:[OrigIP]. The originator IP is the VTEP loopback, and that is the whole message. Note the VNI table below it: 10120 is a Layer 2 VNI with MACs and remote VTEPs; 50001 is the Layer 3 VNI: no flood list at all (remote VTEPs n/a), and the only MACs it tracks are the other leaves' router MACs, because it carries routed traffic between the leaves' copies of the same tenant VRF. Keep that split in mind for Type-5.

Type-2: the workhorse, in three stages

Type-2 is where most people stop, but even here the interesting part is what travels with the MAC. Watch the progression in one capture: the same leaf advertises a router MAC with nothing attached, then a server MAC tagged with its Ethernet Segment, then the full MAC plus IP carrying two route targets and a router MAC extended community.

The last entry is the fully loaded one. 50:00:00:0b:00:01 with 10.167.10.11 is my first Kubernetes master, learned on its bond. Three things ride along:

• The ESI. Because the MAC was learned on an Ethernet Segment, every remote VTEP knows this host is multihomed, and resolves it through the ESI rather than a single VTEP. That indirection is what makes failover a control-plane event.
• Two route targets. RT:65000:10110 imports into the L2VNI (bridging), RT:65111:50001 into the L3VNI (routing). One route feeds both tables. That is symmetric IRB in a single line of output.
• The Rmac. The advertising leaf's router MAC. When a remote leaf routes to this host over VNI 50001, it writes that MAC as the inner destination when it encapsulates. It is the glue between the routed and bridged worlds.

Types 4 and 1: the multihoming double act

Now the two routes MLAG never shows you. When both leaves configure the same ESI on a host bond, each advertises a Type-4 Ethernet Segment route. The import is filtered by a special route target derived from the ES MAC (ES-Import-Rt:44:38:39:be:ef:11, there is the master pair's segment MAC again), so only leaves on the same segment import and act on them; the routes still land in every BGP table, which is why this worker leaf can display the master pair's. From that membership, they elect a Designated Forwarder, the one switch allowed to send flooded traffic onto the bond. Without a DF, every broadcast would hit the server twice.

Type-1 comes in two flavors, and the capture shows both. The per-EVI flavor (EthTag 0) says: this ESI is reachable through my VTEP in this VNI. Remote leaves use it for aliasing: they load-balance to every VTEP advertising the segment, even before learning a single MAC from one of them. The per-ES flavor (EthTag 4294967295, the reserved MAX-ET) exists mainly for one job: mass withdraw. When a leaf loses its segment, it pulls this one route and every remote VTEP instantly reroutes all MACs behind that ESI to the surviving leaf. One update instead of thousands.

The local view ties it together. The leaf knows each segment as Local and Remote, knows its peer VTEP, and knows whether it won the DF election:

I have watched this machinery earn its living. Pull both spine uplinks on a leaf and uplink tracking protodowns its Ethernet Segment bonds: the hosts fail over on LACP to the peer leaf while the fabric converges on the torn-down sessions, and my anycast probe lost a single second of traffic. Mass withdraw is the complementary insurance, for the day a segment fails while BGP survives: one per-ES withdrawal replaces thousands of per-MAC ones.

Type-5: leaving Layer 2 behind

Everything so far existed to move or protect MACs. Type-5 does not care about them. It advertises a bare IP prefix into the L3VNI, which is how routes with no bridge-domain presence at all cross the fabric. The best example in my lab: the Kubernetes anycast VIP.

Look at the AS path on 192.168.202.0/32: 65100 65111 65010. That last hop is not a switch. It is Cilium's BGP control plane on a Kubernetes node, advertising a LoadBalancer VIP to its leaf pair. The leaf translates a plain BGP route into an EVPN Type-5, attaches the L3VNI route target and its Rmac, and suddenly a container service IP is a first-class citizen of the fabric, reachable from the other datacenter through the backbone. The 10.167.10.0/24 route above it takes the same export path, fed by redistribution of the connected SVI subnet instead of a BGP peer; note its origin code, ? instead of i.

Decoding one line of it: [5]:[0]:[32]:[192.168.202.0] is type, Ethernet tag, prefix length, prefix. RT:65111:50001 targets the tenant L3VNI, and the Rmac tells the ingress leaf which inner MAC to use after VXLAN encapsulation. No ARP, no flooding, no MAC table entry anywhere.

How to read any EVPN output after today

Three decoding habits cover almost everything you will meet:

• The RD locates the origin. 10.0.0.11:2 is the advertising VTEP's loopback plus an instance number FRR assigns per VNI, per Ethernet Segment, or per VRF; the captures showed all three flavors. Same route from two spines, same RD: that is one origin, two BGP paths.
• The RTs decide who imports. L2VNI targets bridge, L3VNI targets route, ES-Import targets find your redundancy peers. A route with two RTs is feeding two tables.
• The extras carry the intent. ESI means multihomed, Rmac means routable, DF preference means an election happened. The type number tells you far less than the communities do.

Five route types, one BGP address family doing bridging, routing, redundancy and flood control at once. That is the actual pitch for EVPN, and it is much easier to believe once you have watched all five working in the same output buffer.

Sources

• RFC 7432: BGP MPLS-Based Ethernet VPN (route types 1 to 4, DF election, mass withdraw)
• RFC 9136: IP Prefix Advertisement in EVPN (Type-5)
• RFC 8584: Framework for EVPN Designated Forwarder Election Extensibility (the alg registry; the preference algorithm in the captures comes from the BESS preference-DF extension)
• RFC 8365: Network Virtualization Overlay Using EVPN (VXLAN encapsulation specifics)
• Cumulus Linux EVPN documentation (multihoming and symmetric IRB)
• FRRouting EVPN documentation (the show commands used throughout)