EVPN Type-5 IP Prefix Routes and Symmetric IRB

Type-2 routes tell an EVPN fabric about MAC and IP bindings; they say nothing about subnets that have no hosts on them yet. Type-5 IP prefix routes, added in RFC 9136, fill that gap: they advertise an IP prefix into the overlay, so a leaf can reach a remote subnet before any host has spoken on it. They also happen to be the mechanism that makes symmetric IRB scale. This article covers what a type-5 route carries, how it is generated, and how to find the reason when it is missing.

What a type-5 route contains

• Route Distinguisher, Ethernet Tag ID
• IP prefix and prefix length
• Gateway IP address — the address hosts use to reach this VRF
• MPLS/VXLAN label field carrying the L3VNI (the transit or routing VNI)
• Route Targets inherited from the originating VRF

Where a type-2 route carries a MAC VRF VNI, a type-5 route carries the L3VNI. That single difference is what makes the forwarding decision at the egress leaf: match the L3VNI, remove the VXLAN header, then route into the destination L2VNI locally.

Symmetric vs asymmetric IRB, in one paragraph each

Asymmetric IRB: the ingress VTEP routes into the destination L2VNI's VNI and the egress VTEP only bridges. It works without a transit VNI, but every VTEP must have every L2VNI configured locally — including subnets with no local hosts — which does not scale.

Symmetric IRB: the ingress VTEP routes from the source L2VNI into a shared L3VNI; the egress VTEP routes out of the L3VNI into the destination L2VNI. Both ends route, each VTEP only needs its local L2VNIs plus one L3VNI per VRF, and type-5 routes provide reachability for subnets with no local presence.

Generating type-5 routes on an Arista leaf

vrf instance Blue
!
interface Vlan10
 vrf Blue
 ip address 10.10.10.1/24
!
interface Vxlan1
 vxlan vrf Blue vni 10000
!
router bgp 65002
 vrf Blue
  rd 10.1.255.1:10000
  route-target import evpn 10000:10000
  route-target export evpn 10000:10000
  redistribute connected
 !
 address-family evpn
  neighbor LEAF_EVPN activate
 address-family ipv4
  no neighbor LEAF_EVPN activate

redistribute connected inside the tenant VRF is what originates the internal type-5 routes — the connected subnet of VLAN 10 is turned into an IP prefix route carrying L3VNI 10000. On other platforms the equivalent is explicit: Juniper uses vlan-aware-bundle plus advertise-svi-ip, and Cisco NX-OS uses advertise l2vpn evpn under the VRF address family.

Verification

show bgp evpn route-type ip-prefix ipv4
! Network            Next Hop        Metric LocPref Weight Path
! * > RD: 10.1.255.1:10000 ip-prefix 10.1.10.0/24  10.1.254.1  - 100 0 65101 i
! * > RD: 10.1.255.2:10000 ip-prefix 10.1.10.0/24  10.1.254.2  - 100 0 65102 i

show bgp evpn route-type mac-ip
show ip route vrf Blue bgp
show vxlan vni 10000
show interfaces Vxlan1

The Next Hop on a type-5 route is the VTEP address of the advertising leaf, not the gateway address. If a prefix is present in the EVPN table but not in the VRF routing table, the usual causes are a Route Target mismatch between the importing VRF and the advertising VRF, or a missing L3VNI/VXLAN mapping on the local leaf.

Multihoming considerations

Type-5 routes are not subject to the designated forwarder election that governs type-1/type-4 for multihomed segments; a prefix is reachable via whichever VTEP advertises it. On an MLAG pair, both leaves typically advertise the same prefix with the same or different route distinguishers, and the fabric's ECMP hashing decides. That makes route-target hygiene more important than DF state when debugging a type-5 problem.

Frequent failure modes

• No type-5 routes at all — the tenant VRF is missing redistribute connected (or the platform equivalent), or the VRF has no RTs configured.
• Prefixes received but not installed — RT import/export mismatch, or the prefix is filtered by an inbound route policy.
• Traffic reaches the egress leaf but stops — the L3VNI is not mapped in the VXLAN interface, or the destination L2VNI is absent on that leaf.
• Asymmetric behaviour between two prefixes in the same VRF — one is being learned by type-2 host routes and the other by type-5; both are valid, and the more specific wins.

Related reading: EVPN multihoming vs MLAG for the ESI and DF election side, and symmetric IRB on Arista EOS for the full fabric configuration.

原文链接：https://baud9600.com/pages/articles/evpn-vxlan-architecture