EVPN Route Types (SONiC View)
A fast, CCNP+-level review of the route types that matter in a SONiC leaf-leaf fabric — type-2, type-3, and type-5 — focused entirely on how they appear in FRR, what SONiC does with them, and the failure signatures each one produces. No introductory definitions.
Prerequisites: Lesson 4.1 · CCNP+ EVPN route-type knowledge
Learning objectives
- →Recognize type-2, type-3, and type-5 routes in the FRR EVPN RIB and read their key fields.
- →State what SONiC installs (FDB entry, flood list, route) in response to each type.
- →Map each route type to the failure signature you see when it is missing or unprogrammed.
You do not need the definitions; you need to know which route type to look for when a specific symptom appears — unicast between known hosts vs BUM vs inter-subnet routing each implicate a different type.
The FRR EVPN RIB is where you confirm the control plane; reading it fluently is half of overlay troubleshooting.
| In the analogy | In SONiC |
|---|---|
| A parcel-level entry: this exact item is at this terminal | Type-2 (MAC/IP) |
| A terminal's membership card for a tenant's broadcast list | Type-3 (inclusive multicast) |
| A whole ZIP code reachable via this terminal | Type-5 (IP prefix) |
Where the analogy stops working
A directory is passive lookup; EVPN routes actively *drive* hardware programming, and the programming can fail even when the 'entry' is perfect. The analogy also flattens the type-2 MAC-only vs MAC+IP distinction, which matters for ARP suppression and IRB.
The three route types you will actually chase
| Type | Carries | SONiC installs | Missing/unprogrammed signature |
|---|---|---|---|
| 2 (MAC) | Remote MAC + VNI + VTEP | Remote FDB entry via tunnel | Unicast to a specific host fails; flooding may still 'work' |
| 2 (MAC+IP) | Remote MAC + IP + VNI | FDB + ARP/ND (suppression), IRB host route | ARP not suppressed; IRB host reachability gaps |
| 3 (IMET) | VTEP membership in a VNI | Head-end replication / flood list | BUM (ARP, DHCP discover) never reaches peer VTEP |
| 5 (IP prefix) | Routed prefix + L3VNI + RT | Route + tunnel next hop | Inter-subnet/routed reachability fails; same-subnet may work |
Reading the EVPN RIB in FRR
# Inside the bgp container / vtysh
show bgp l2vpn evpn summary # are EVPN sessions established?
show bgp l2vpn evpn # full EVPN table (all types)
show bgp l2vpn evpn route type macip # type-2 MAC/IP routes
show bgp l2vpn evpn route type multicast # type-3
show bgp l2vpn evpn route type prefix # type-5
show evpn vni # locally known VNIs and their kind (L2/L3)
show evpn mac vni <vni> # MACs learned in a given VNIYou confirm the control plane in vtysh, not in SONiC's show layer. These are the workhorse commands; field layout varies slightly by FRR version.
Illustrative type-2 entry (annotated)
Route Distinguisher: 10.0.0.1:5
*> [2]:[0]:[48]:[00:11:22:33:44:55]:[32]:[10.10.10.11]
10.0.0.1 (VTEP / next hop = remote loopback)
Extended Community: RT:65001:10010 ET:8
Label1 10010 (L2VNI) Label2 50010 (L3VNI, if IRB)
# Read: MAC 00:11:22:33:44:55 (+host 10.10.10.11) lives behind VTEP 10.0.0.1,
# in L2VNI 10010. The far leaf should install a remote FDB entry to that VTEP.What a MAC+IP route looks like and the fields that matter when correlating to hardware.
A perfectly formed type-2 route can sit in the EVPN RIB while the corresponding remote FDB entry never appears in ASIC_DB — SAI error, resource exhaustion, or a tunnel that is administratively present but not up. Lesson 4.6 turns this into a layered check; for now, treat RIB presence as step one, never the finish line.
Route targets and import
Whether a route even enters a leaf's EVPN RIB depends on route-target import. An RT mismatch means the advertising side is perfect and the receiving side simply never imports the route — a common, quietly self-inflicted failure. When a route is 'missing' on the receiver but present on the sender, suspect RT/import before suspecting the network.
- Match the symptom to the route type before opening any capture.
- Check both sides: advertised on the origin, and imported (RT match) on the receiver.
- Confirm RIB presence, then confirm hardware programming — they are separate checks.
Key takeaways
- ✓type-2 = remote MAC/IP unicast; type-3 = BUM membership; type-5 = routed prefixes.
- ✓Symptom class points at the route type; use vtysh to confirm the control plane.
- ✓RT/import mismatch is a top cause of 'route present on sender, missing on receiver'.
- ✓RIB presence never proves ASIC programming.
Tested against: SONiC 202305 / 202311 lineage · Upstream (community) unless noted · SONiC-VS (virtual) baseline · last reviewed 2026-07. Exact commands and behavior can vary by SONiC release, image, hardware platform, and enterprise distribution.
Knowledge check
Host A cannot resolve ARP for Host B in the same subnet across the fabric, even though once you statically prime the ARP entry, unicast works. Which EVPN route type is most likely at fault?