MAC Addresses in VXLAN/EVPN: Which Layer Holds Layer-2 Identity

In the enterprise, a MAC address is almost the whole of layer 2: switches build their forwarding tables from it, flood unknown unicast with it, and locate a device on a port through the MAC address table. In the data center, that logic is wrapped inside an overlay. VXLAN uses MAC-in-UDP to carry a tenant's layer-2 frames inside IP packets across a routed Clos fabric; a host MAC is no longer learned directly by a physical switch but is learned by a tunnel endpoint (VTEP) on the host's behalf, or distributed outright by a BGP EVPN control plane. This article makes one thing clear: in a VXLAN/EVPN fabric, where the same MAC address appears at each layer, who learns it, and which table to inspect when something breaks.

How many copies of one MAC does a VXLAN packet carry

VXLAN encapsulation is usually described as MAC-in-UDP, but more precisely the inner Ethernet frame is nested inside UDP/IP, which is in turn nested inside an outer Ethernet header. A frame from host A to host B, after VTEP encapsulation, looks roughly like this:

• Outer Ethernet header (outer SMAC/DMAC) — the physical address between two devices on the underlay, rewritten at every routed hop, unrelated to the endpoints.
• Outer IP header — source is the source VTEP's IP (typically a dedicated loopback), destination is the destination VTEP's IP.
• UDP header — destination port fixed at 4789 (IANA-assigned to VXLAN, not configurable in vendor implementations).
• VXLAN header — the core is a 24-bit VNI (VXLAN Network Identifier), up to 16 million tenant segments, replacing the 4094 limit of VLAN IDs.
• Inner Ethernet header (inner SMAC/DMAC) — the tenant's actual layer-2 frame header, i.e. the MACs of host A and host B.

So a single packet carries two copies of a MAC: the outer MAC belongs to the physical network, the inner MAC to the tenant's virtual network. This is the premise for everything that follows — the underlay spine/leaf only looks at the outer headers when routing, and endpoint MACs are entirely invisible to them.

Flood and learn: how VXLAN originally learned MACs

VXLAN's native approach mirrors a classic layer-2 bridge: flood and learn. When a VTEP receives a frame whose destination it does not know (broadcast, unknown unicast, multicast — together abbreviated BUM), it sends it to every VTEP that is a member of that VNI — first via IP multicast, and more commonly these days via head-end replication (HER), unicasting a copy to each. This is the same idea as a classic switch learning a source MAC against an ingress port, except the port becomes a tunnel.

The receiving VTEP decapsulates, then does two things: forwards on the inner DMAC, and learns the inner SMAC against the outer source IP. In other words, the VTEP's forwarding table records "this MAC is behind that VTEP". Return traffic can then be unicast straight to that VTEP instead of flooded.

The weakness is scale. The layer-2 broadcast domain has grown from one switch to the entire fabric, and every BUM frame must be replicated to all member VTEPs. As hosts grow, the flooding cost becomes untenable. Cisco's configuration guide states it plainly: the inherent flooding of flood-and-learn "presents serious scale challenges especially as the number of end hosts go up".

BGP EVPN: moving MAC learning to the control plane

The fix is to move MAC learning off the data plane (flooding) and onto a routing protocol. That is BGP EVPN: EVPN was first defined by RFC 7432 (for MPLS), and RFC 8365 defined the VXLAN-based NVO (Network Virtualization Overlay) case, using MP-BGP NLRI to carry both layer-2 MAC and layer-3 IP reachability in one place.

Among the route types, the one tied directly to MACs is the Type 2 route (MAC/IP Advertisement Route). A VTEP advertises the MACs it learned locally (optionally with the host IP and VNI) to other VTEPs; the receiver installs the entry pointing at the originating VTEP's IP. The result is that flooding is no longer needed to learn MACs — the fundamental gain of an EVPN fabric over plain flood-and-learn, in both scale and convergence.

The "MAC address table" in a fabric therefore takes a new shape: local MACs (on your own ports) versus remote MACs pointing at a VTEP's IP. Vendor CLI distinguishes the two explicitly, and H3C's VXLAN guide even offers switches such as disabling remote-MAC learning and enabling local-MAC logging to bound this table.

MAC mobility: the most important operational semantic

MAC mobility is the most easily overlooked yet most troubleshooting-relevant piece of EVPN. When a MAC moves from behind one VTEP to behind another (VM migration, host drift, or simply a loop or spoof), the new VTEP emits a fresh Type 2 advertisement carrying an incrementing MAC Mobility Sequence Number. All VTEPs compare sequence numbers and the higher one wins, moving the flow's ownership to the new location.

Alongside it sits duplicate MAC detection: if the same MAC appears at two VTEPs with the same sequence number, EVPN flags a duplicate, raises an alert and applies protection. This is the overlay counterpart of classic layer-2 MAC flapping, and the diagnostic approach carries over directly from MAC address flapping troubleshooting and duplicate MAC address troubleshooting — with one extra check: is a VM doing a live migration, which legitimately triggers MAC mobility?

ARP/ND suppression: a neighbour table beyond the MAC table

A data-center fabric adds one more MAC-coupled optimisation: ARP/ND suppression. VTEPs exchange not only MACs but IP-MAC bindings (a Type 2 route can already carry the IP). A VTEP can then answer ARP on behalf of its hosts, so requests never need to flood the whole fabric. H3C lists it as a basic VXLAN feature, "ARP and ND flood suppression".

This has an operational consequence: ARP often cannot be captured in a VXLAN network, because the VTEP answers it. Verifying whether a host is up may mean checking the VTEP's neighbour/ARP sync table rather than waiting for an ARP reply. The classic ARP protocol observation method and ARP spoofing defence techniques both need adjusting to this premise, or you will misread a working network as broken.

Reading it in a capture

If you capture on a fabric edge or beside a server and get encapsulated packets, Wireshark can decode the VXLAN layer. Key points:

• Filter for tunnel traffic first with vxlan or udp.port==4789, then filter by MAC on the decoded inner frame. The outer MAC is the physical next hop; the inner MAC is the endpoint.
• The VNI identifies the tenant segment, the VXLAN equivalent of a VLAN. For where a VLAN tag sits in a capture and what it means, see VLAN tags in packet captures.
• A VM's adapter MAC usually comes from a virtualisation platform's registered OUI (VMware, Xen, Hyper-V). Entering it on the lookup page reveals the platform, the same subject as MAC addresses of virtual machines.

Concrete filter syntax is in filtering captures by MAC address in Wireshark.

Practical guidance

For network engineers.

1. Keep the two tables apart: the underlay routing table (outer IP) and the VTEP MAC/IP table (inner MAC → VTEP). Looking up "where is this MAC" means the latter, not a physical switch.
2. Use EVPN Type 2 route counts to spot anomalies: a burst of remote MACs under one VNI usually means flooding or a loop, not genuinely more devices.
3. Watch how fast the MAC Mobility Sequence Number increments; it signals VM drift and address spoofing alike.
4. No ARP replies does not mean no traffic — suspect VTEP proxy suppression first.
5. Never conflate the underlay's physical MAC with tenant MACs; the outer MAC is rewritten at every hop and has no stable identity.

For asset and operations teams. VXLAN lets one VM's MAC appear in different physical locations while behaving perfectly normally, so the physical-switch-based method of locating a MAC breaks inside a fabric. Asset inventory should shift to upper-layer platform identifiers — see using MAC addresses for network inventory.

For this site's users. If you capture a MAC in a fabric that returns no vendor, identify the layer first. An outer MAC is a physical device and normally resolves; an inner one may be a VM or container, so a failed lookup — or a cloud-vendor prefix — is expected rather than a database problem.

In one sentence

VXLAN wrapped layer 2 inside layer 3, and EVPN moved MAC learning from flooding to BGP. The result is that one MAC address has three identities on the same network: the outer physical next hop, a remote entry in a VTEP's table pointing at a tunnel, and a movable route carrying a sequence number in the control plane. Miss the layering and you will hunt for a device in a table that never held it.

References

• IETF draft-ietf-nvo3-rfc7348bis-08, VXLAN (published 2026-09-11, obsoletes RFC 7348): https://www.ietf.org/archive/id/draft-ietf-nvo3-rfc7348bis-08.html
• RFC 7432, BGP MPLS-Based Ethernet VPN: https://www.rfc-editor.org/rfc/rfc7432.html
• RFC 8365, A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN): https://www.rfc-editor.org/rfc/rfc8365.html
• Cisco, Configuring VXLAN BGP EVPN (Catalyst 9500): https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9500/software/release/16-9/configuration_guide/lyr2/b_169_lyr2_9500_cg/configuring_vxlan_bgp_evpn.pdf
• Cisco, BGP EVPN VXLAN Overview (Catalyst 9600): https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9600/software/release/17-8/configuration_guide/vxlan/b_178_bgp_evpn_vxlan_9600_cg/bgp_evpn_vxlan_overview.pdf
• H3C, Basic VXLAN configuration: https://www.h3c.com/en/d_202310/1955938_294551_0.htm
• This site: How the switch MAC address table works
• This site: MAC address flapping troubleshooting
• This site: Duplicate MAC address troubleshooting
• This site: MAC addresses of virtual machines