Check the EVPN Router MAC Before Blaming the Underlay

Two MAC addresses appear in the same VXLAN packet, and only one of them belongs to the destination host. In an EVPN VXLAN IP-VRF-to-IP-VRF design, the inner destination MAC is the egress router's advertised router MAC, while the outer destination MAC belongs to whatever delivers the packet on the next underlay link. Confusing the two sends people into the underlay looking for a fault that is not there. Work the checks in order.

Each step answers one question, and the first answer decides whether the later ones are relevant at all.

1. Read the prefix route and its communities

Start from the route rather than from the packet capture:

show bgp l2vpn evpn route type prefix 10.20.0.0/24

A Type 5 route advertises an IP prefix. In the interface-less IP-VRF model it also carries the L3 VNI and the router MAC extended community, and that community is what identifies the egress routing endpoint. Read the community instead of assuming the MAC is embedded in the prefix NLRI, because it is not. If the route is present and the community is attached, the control plane has already done its part.

2. Confirm which forwarding model is in use

Interface-less and overlay-index recursion are different supported arrangements. The interface-less model routes the packet, builds an inner frame for the remote routing endpoint, and encapsulates it toward the egress VTEP.

With overlay-index recursion, the ingress router needs an additional lookup to resolve the next hop before it can forward. Both models are valid, and the procedure that applies depends on which one your fabric uses. Applying the direct next-hop reasoning to a fabric built the other way produces a conclusion that looks correct in the capture and wrong in the design review.

3. Expect two different MAC roles

The inner destination MAC is the advertised router MAC of the egress router. The outer destination MAC is the local delivery next hop, which may be an underlay router and may change at every hop. Seeing them differ is normal, and seeing them equal is a coincidence rather than a requirement. A capture showing a chassis-looking address on the inside and a physical next-hop address on the outside is describing exactly the intended encapsulation.

4. Treat a chassis-derived value as an implementation choice

A platform may derive its advertised router MAC from a system or chassis identity, and that is an implementation decision rather than a protocol rule. Check the vendor's allocation and redundancy model before reading anything into the address format.

Two implementations that both comply can advertise different-looking router MACs, which is why comparing them across vendors proves very little.

5. Change nothing until the state disagrees

For a review, compare the selected prefix route, its extended communities, the BGP next hop, the L3 VNI and the resulting forwarding state. Then label the inner and outer headers in the capture.

If those five agree, the MAC that looks odd is doing its job, and changing it will break a routing endpoint rather than fix an addressing mistake. If they disagree, you now know which field is wrong, and the change is targeted instead of speculative. The EVPN IP-prefix specification is the reference to quote in that discussion, because it describes both the model and the community that carries the value.