EVPN Type 2 vs Type 5: why one IP address means two routes

Two routes on the same box can point at 198.51.100.77 and still answer different questions. One describes where a MAC address is reachable and, optionally, which IP is bound to it. The other describes a prefix that resolves through a next hop, even when that prefix is a single host. Mixing them up produces a ticket that looks like a routing bug but is really a misread route type.

The fastest way to tell them apart is to read the key the NLRI is built around, not the mask at the end of it.

The route key tells you what the route claims

A type 2 is the MAC/IP Advertisement route from RFC 7432, and its key is the 48-bit MAC address inside the NLRI. Behind that key sits an IP address field whose length field can be 0, 32 or 128 bits, so a MAC-only advertisement is a complete route rather than a host entry with pieces missing. The label stack that follows points at the bridging context where that MAC lives.

Whether the IP field is filled in changes what the route states, not what kind of route it is. With a 32-bit or 128-bit length, the sender also claims that this IP belongs to that MAC inside one EVPN instance. With a zero length, the sender makes no IP claim at all. Neither version says a prefix is reachable through a router.

A type 5 is the IP Prefix route from RFC 9136, and its key is a prefix written as a length plus that many bits. The length runs from 0 to 32 for IPv4 and from 0 to 128 for IPv6.

Both ends of that range are legal, and neither implies a MAC. A zero-length prefix claims reachability without naming a host, while a /32 names exactly one address. The NLRI also carries a gateway IP address that the egress side uses to build the overlay index, plus a label for the forwarding context. There is no MAC field to switch on, which is why a receiver treats a type 5 as a routed destination.

A /32 prefix route is not a relabelled type 2

Host-sized prefixes are ordinary type 5 routes. A /32 prefix route and a type 2 for the same address can both exist in one EVPN instance, and they carry different forwarding information.

Take 198.51.100.77 in an EVPN instance using VNI 10100. A type 2 might pair it with MAC 02:00:00:00:00:77 and a label identifying the bridge domain where that MAC was learned. A type 5 might advertise 198.51.100.0/24 for the whole subnet, or 198.51.100.77/32 for just that address, with a gateway address pointing at the egress VTEP. The addresses overlap on purpose because the routes are answering different questions.

One route says an endpoint binding exists and is reachable through a particular bridge. The other says a prefix is reachable through a particular router, whether or not any endpoint inside it has ever been learned.

That difference decides where you look first when traffic fails. If a single host is unreachable while its subnet route looks fine, the type 5 was never supposed to carry that host; look for the missing type 2. If the host route exists but the whole subnet is unreachable, check whether the type 5 was originated at all. Reading the fields in order beats guessing from the mask length.

Reading both routes without guessing

On NX-OS, show bgp l2vpn evpn route type 2 and show bgp l2vpn evpn route type 5 split the table along exactly this line, and show l2route evpn mac ip shows the local MAC-to-IP bindings behind the type 2 routes. On Junos, show evpn database lists learned MAC and IP bindings while show route table bgp.evpn.0 shows what was advertised and received.

Filter by route distinguisher and Ethernet tag before drawing conclusions. The same MAC or prefix can appear in several EVPN instances, and a route that looks wrong in one instance may be correct in another.

Then read the NLRI in order: route type, key, gateway or label fields, then the route targets on the attributes. A type 2 carrying a non-zero ESI is telling you the MAC is multi-homed, and that value is what ties the advertisements from different PE routers together. A type 5 carrying a gateway address is telling you which egress VTEP should receive the traffic.

If a route is missing, check origination before encoding. Confirm the source has the binding or the prefix locally, then confirm that the route target attached to it is imported on this box. Most reports of a broken type 5 end at an import policy, not at the NLRI format.

Record the context, not just the route type

Write down the route type, the EVPN instance, the route distinguisher, the imported and exported route targets, and the resolved next hop together. A type 2 without its instance is ambiguous, and a next hop without the route family invites the wrong conclusion.

Both are EVPN routes even when the payload is an IPv4 address. The address family inside the NLRI and the address family of the route itself are separate properties, and a type 5 does not become an IPv4-unicast or VPN-IPv4 route because it carries an IPv4 prefix.

That distinction shows up at the boundary between an EVPN control plane and an IP-VRF. The route target decides which VRF imports the prefix, while the gateway address and label decide how the packet is encapsulated toward the egress. Read those together and the forwarding decision stops looking arbitrary.

Next time a /32 appears in the EVPN table, check the key before the mask. A MAC key with an optional IP is a type 2 binding; a prefix key is a type 5 route whatever its length. Write the route target and next hop beside it, and the next engineer will not have to re-derive the whole story.