Skip to main content
Validate the ARP table for ExpressRoute peering to troubleshoot Layer‑2 reachability between your on‑premises network and Azure. ExpressRoute peering depends on ARP (Address Resolution Protocol) to map Layer‑3 IPs to Layer‑2 MACs so peers can exchange traffic on the same VLAN/L2 segment. See ExpressRoute overview: https://learn.microsoft.com/en-us/azure/expressroute/overview ARP is a Layer‑2 protocol defined in RFC 826 that resolves IP addresses to MAC addresses, enabling proper packet delivery within a broadcast domain. If ARP fails or contains stale/missing entries for ExpressRoute peers, traffic can be blackholed at L2 even if routing (L3) looks correct. Below is a simple diagram illustrating an ARP request/response exchange where a host asks for the MAC address of IP 34.40.21.20 and the router replies with the corresponding MAC.
Diagram of the Address Resolution Protocol (ARP). A host requests the MAC address for IP 34.40.21.20 and the router replies with MAC A5:22:98:5C:24:93, with other hosts (34.40.21.18 and 34.40.21.19) shown.
Why ARP matters for ExpressRoute
  • ARP operates at Layer 2 and is required for local delivery of packets on the same subnet/VLAN used by ExpressRoute peering.
  • Both the on‑prem peer and the Azure (Microsoft) peer must be able to resolve each other’s MAC addresses for traffic to pass.
  • Missing or stale ARP entries typically indicate Layer‑2 issues: cabling, VLAN/tag mismatch, switch MAC learning problems, or security features blocking ARP.
A presentation slide titled "Address Resolution Protocol (ARP)" with three blue panels stating that ARP is a Layer‑2 protocol (RFC 826), translates IP addresses to MAC addresses, and is critical for proper communication across network layers.
Validation checklist (recommended order)
  1. Verify the ARP table on your on‑prem router for the Azure peer IP and confirm it maps to the expected Microsoft/Azure MAC.
  2. Verify the ARP table on the Azure-facing device (on‑prem edge or virtual network gateway) resolves your on‑prem router IP to the expected on‑prem MAC.
  3. Confirm both sides can ARP for each other — that ARP requests are sent and ARP replies are received.
  4. Look for stale entries, missing Microsoft/Azure router entries, or duplicate MACs that could indicate L2 problems.
Command reference
PlatformCommand
Windowsarp -a
Linuxip neigh show or arp -n
Cisco IOSshow ip arp (or show arp | include <ip-address>)
Junosshow arp
Examples (copy/execute on the appropriate device)
  • Windows:
arp -a
  • Linux:
ip neigh show
# or
arp -n
  • Cisco IOS:
show ip arp
# or for interface-specific entries:
show arp | include <ip-address>
  • Junos:
show arp
A slide titled "ARP Table Validations" showing two gradient boxes labeled "On-Prem to Azure Mapping" and "Azure to On-Prem Mapping." Each box has a short note about confirming IP-to-MAC address mappings and ensuring ExpressRoute router interfaces resolve properly to MAC addresses.
Common issues, what they mean, and next steps
SymptomLikely causeRecommended action
Incomplete MAC resolution for on‑prem router IPsVLAN mismatch, incorrect interface, or switch learning issueVerify VLAN tags, check interface configuration, inspect switch MAC table
Missing Microsoft/Azure router entries in your ARP tableAzure side not reachable at L2 or ARP responses blockedConfirm peering VLAN, check ACLs/port security, verify Azure peer is up
Duplicate or rapidly changing MACsMultiple devices using same MAC, VM migration, bridging/loopInspect for bridging loops, check virtualization/migration events, validate MAC address consistency
If ARP mappings are missing or stale, investigate:
  • Physical link state and cabling between the on‑prem edge and the provider/switch.
  • VLAN and trunk configuration — ensure the peering VLAN/tag matches on both sides (provider and customer).
  • Switch MAC address table to confirm the port where the MAC is learned.
  • Port security, MAC limiting, or ACLs that might restrict or drop ARP/broadcast traffic.
  • ARP cache issues — clear ARP carefully to force re-resolution from endpoints.
  • Virtual routers or firewalls that might block broadcast/ARP traffic in the path.
Helpful device and switch checks
  • Find which switch port learned a MAC (Cisco example):
show mac address-table dynamic | include <mac-address>
  • Clear ARP entries (use caution in production):
    • Cisco IOS: 
      clear ip arp <ip-address>
    • Linux: 
      sudo ip neigh flush <ip-address>
The slide titled "Common ARP Errors" shows two rounded boxes listing issues: "Incomplete MAC address resolution for on-prem router IPs" and "Missing Microsoft router entries in your ARP table." A small copyright notice for KodeKloud appears in the corner.
References and further reading
When validating ARP for ExpressRoute, always check both sides (on‑prem and Azure) and verify the MACs correspond to the expected peer interfaces. Confirming IP-to-MAC mappings quickly distinguishes L2 issues from L3/routing problems.
Clearing ARP entries or flushing neighbor caches can temporarily disrupt traffic. Perform these actions during maintenance windows when possible or on a single test device before making broader changes.

Watch Video