Understanding Network Infrastructure · Part 2 · How does data reach nearby devices?
When my PC sends data, whose MAC address does it use?
The destination on a local network, the gateway for a remote one—from ARP and switching to each hop's new frame
Even when a PC knows the destination IP, sending an Ethernet frame requires knowing who will receive it on this link—specifically, that device's MAC address. For a local destination, it resolves the destination's MAC address; for a remote one, it resolves the gateway's MAC address through ARP. A router first looks up the route, then resolves either the directly connected destination or the next hop to a MAC address and creates a new frame. A switch uses its MAC address table to forward that frame.
Local or remote? That determines which ARP target IP to query↑
When endpoint 192.0.2.10/24 sends to its own subnet's 192.0.2.80, it resolves that host's MAC address. When sending to Internet server 203.0.113.80, it resolves not the server but its default gateway 192.0.2.1 to a MAC address.
'Directly' does not mean one cable with nothing between the devices. One or more switches may lie along the path. As long as the destination is on the same link-layer network without crossing a router, the sending endpoint uses the final recipient's MAC address in the frame.
The local-or-remote decision made earlier determines which IP to query. ARP is not a worldwide IPv4-to-MAC directory. Within the current broadcast domain, it finds the next-hop interface's MAC address.
An endpoint first consults its route table to choose the ARP target. From 192.0.2.10/24, destination 192.0.2.80 matches the connected route, so the query asks for 192.0.2.80. Destination 203.0.113.80 matches the default route, so the chosen route's next hop, 192.0.2.1, is queried. ARP does not choose the route. The route lookup determines which ARP target IP to resolve.
A more-specific static route or multiple interfaces can change the selected next hop and the ARP egress interface for the same destination. With proxy ARP, a router can answer a query for a remote IP with its own MAC, hiding a mistaken on-link decision. During troubleshooting, inspect not just the ARP entry, but also the route and interface that caused it to be created.
An ARP request stays within the current broadcast domain. When a router sends a packet onto the next Ethernet link, it checks that link's next-hop MAC address and creates a new frame. During troubleshooting, record both the IP destination and the frame's destination MAC. This makes it clear why a remote server-bound packet normally leaves with the gateway MAC as its frame destination.
Sources for this section IETF RFC 1122 §3.3.1 · IETF RFC 826
What to look for in the diagram Compare the MAC and EtherType fields in the Ethernet header with the Layer 3 payload carrying the IP packet. Locate the destination MAC field used for the Layer 2 switch's forwarding decision.
↔ Scroll horizontally to explore the diagram.
A gateway removes the incoming frame, looks up the route, and builds a new frame↑
Suppose PC 192.0.2.10/24 sends to server 203.0.113.80 on another network. The IP destination is 203.0.113.80 from the start, but the PC's ARP query asks for gateway 192.0.2.1. The first frame's source MAC belongs to the PC; its destination MAC belongs to the gateway. An intermediate switch does not resolve the remote server's MAC address. It uses the frame's destination MAC to forward it toward the gateway.
The gateway accepts the destination MAC as its receiving interface's address, takes in the frame, and performs decapsulation. It uses the inner IP destination for a route lookup. The key distinction is that a router does not switch traffic using only its ARP cache. The routing table first determines the outgoing interface and next recipient. The device then checks its ARP cache or neighbor information. If no resolved MAC address is available, it sends an ARP request on the selected outgoing link.
If the route lookup matches 203.0.113.0/24 as a connected route, the router resolves the final server, 203.0.113.80, through ARP. The new frame's source MAC is the router's outgoing interface address, and its destination MAC is the server's address. A downstream switch then uses its MAC address table—mapping the MAC address together with the VLAN to a device port—to choose the actual outgoing device port. The ARP cache's IP-to-MAC mapping and the MAC address table's MAC-to-device port mapping serve different steps.
The logical order is the same when gateway and switching functions share one Layer 3 switch. A route lookup selects the outgoing path, and neighbor information is checked. If Layer 2 switching is needed in the outgoing VLAN, the new frame leaves according to the MAC address table. Hardware may perform these operations together, but the route, ARP cache, and MAC address table still answer different questions.
If the route points to another router, 198.51.100.2, as the next hop, this ARP query does not target the final server. It targets that next-hop IP. The new frame's source MAC belongs to the current router's outgoing interface; its destination MAC belongs to the next router. That router repeats the process. The sending PC therefore does not need the remote server's MAC address—only its first gateway's address.
Across a router, ordinary IP forwarding preserves the source IP and destination IP, while the source MAC and destination MAC change on each link. TTL decreases at each router, and the IPv4 header checksum is recalculated. NAT and tunnels are separate boundaries that may change IP values or add or alter an outer header. Keep those cases separate from this basic forwarding sequence.
| Sending device | Route lookup result | ARP Target | Destination MAC |
|---|---|---|---|
| PC | Local connected route | 192.0.2.80 | Destination host |
| PC | Default route to another network | 192.0.2.1 | Default Gateway |
| Router | Connected route to the destination network | 203.0.113.80 | Destination server |
| Router | The route's next hop | 198.51.100.2 | Next-hop router |
Sources for this section IETF RFC 1812 §5.2.1.2 · IETF RFC 826
What to look for in the diagram The upper path uses the local destination's destination MAC. The lower path goes to another network: the first router, then the next-hop router, and finally the connected route's destination server. Compare how the ARP target and each new frame's destination change along the way.
↔ Scroll horizontally to explore the diagram.
MAC unknown? Ask everyone; the reply usually returns to the requesting host↑
If an endpoint has no entry in its ARP cache, it sends a request to destination MAC ff:ff:ff:ff:ff:ff. Inside the frame are the queried target IP and the sender's IP and MAC addresses.
Devices on the same VLAN receive the request, but the target IP owner's interface replies with its own MAC address. The requester stores this IP-to-MAC mapping in its ARP cache temporarily and sends subsequent data frames by unicast.
The request's Ethernet destination is broadcast, but its sender MAC, sender IP, and target IP have specific values. It asks, for example, 'Who has 192.0.2.80? Tell 192.0.2.10.' The target MAC field is present, but its value has no meaning in an address-resolution request. The reply's destination MAC is normally the requester's MAC, allowing a unicast response. The requester saves the mapping in its cache.
An ARP reply need not immediately follow a request. A device can announce a new IP-to-MAC mapping or check for conflicts using gratuitous ARP or an ARP probe. A highly available gateway also uses announcements during an active-device change to update the virtual IP's MAC location. In a capture, read the opcode, sender and target IP, and MAC fields to distinguish a query, a reply, and a self-announcement.
Whether replies always use unicast, or a request alone updates the cache, depends on the operating system and security configuration. Compare request and reply opcodes, sender/target IP, and MAC fields to confirm that both messages belong to the same address-resolution exchange.
Sources for this section IETF RFC 826
What to look for in the diagram Compare the ARP request broadcast with the reply unicast. Check the destination MAC on each arrow—FF:FF:FF:FF:FF:FF for the request and the receiving host's MAC for the reply—and the note about recording the address mapping in the ARP cache.
↔ Scroll horizontally to explore the diagram.
Switch learning: why learn the source MAC rather than the destination?↑
When a switch receives a frame, it records the source MAC, incoming port, and VLAN in its MAC address table. It does not need to interpret ARP to learn an address. Observing the Ethernet frame's source MAC is enough to learn where the sender is.
If the destination MAC is in the table, the switch forwards the frame to that port. If the destination port found by the lookup is the incoming port, the switch filters the frame instead of forwarding it to other ports. If the destination MAC is unknown, it floods the frame to forwarding-enabled ports in the same VLAN as unknown unicast traffic, excluding the incoming port.
| Record | Question answered | Typical location |
|---|---|---|
| ARP Cache | For this IPv4 next hop, what is the MAC address? | Host or router |
| MAC address table | Where is this MAC in the current VLAN—which port? | Layer 2 switch |
When a PC's ARP request arrives on port 5, the switch handles the broadcast by first learning its source MAC on VLAN 10, port 5. When the gateway's reply arrives on the uplink, it learns the gateway MAC on VLAN 10's uplink. Now unicast frames in both directions can use the MAC address table to reach only the required port. The ARP exchange has effectively taught the switch where both ends are.
An unknown destination MAC causes unknown unicast flooding. Its reach may look like broadcast, but the cause is different: the destination MAC is unicast, and the frame is copied within the VLAN because the table lacks its location. A returning frame supplies that location through source learning. Persistent flooding calls for checking asymmetric traffic, aging, MAC learning limits, or a one-sided capture. A correct ARP cache does not prove that the MAC address table is also correct.
A switch does not learn a location from the destination address. The destination is the lookup key for this forwarding decision; the source provides evidence for updating location. When only one direction's frames have arrived, the opposite MAC may still be unknown and require flooding. Once replies teach both source locations, forwarding settles into unicast. Lookups also include the VLAN context, distinguishing the same MAC in different domains.
Sources for this section IEEE 802.1Q
What to look for in the diagram Distinguish source MAC learning from the destination CAM lookup and its hit and miss outcomes. Compare the address learned on Port 1, forwarding to Port 24 or filtering when the destination is on the ingress port, and flooding within the same VLAN when no entry matches.
↔ Scroll horizontally to explore the diagram.
When hosts move, how do the ARP cache and MAC address table find their new locations?↑
An ARP cache entry and a dynamic MAC entry both age out. Trusting stale entries too long delays recognition of moves or replacements; removing them too quickly increases broadcast and unknown unicast traffic. Exact timers depend on the operating system and switch implementation.
When a redundant gateway transfers a virtual IP to another device, or a server NIC is replaced, gratuitous ARP can announce the new MAC relationship. Still verify that intermediate-device caches and security policies accept the change.
A host's ARP cache and a switch's MAC address table live on different devices and use different timers. An ARP entry can remain after its corresponding MAC entry expires. The host then skips a new ARP exchange and uses the existing destination MAC in its frame. The switch may flood the first few frames as unknown unicast, then relearn the location from the reply frame's source MAC. The two timers need not match; do not assume that they do.
A virtual machine moving to another hypervisor or a gateway failover can make the same MAC appear on a new port. A normal move may produce a brief MAC move log and gratuitous ARP. Repeated alternation between two locations, however, may indicate a loop or two active owners. Compare the change time, MAC move frequency, and topology to distinguish a normal move from MAC flapping. Clearing the cache indiscriminately may hide the symptom briefly without explaining the cause.
The tables do not share one lifetime or update schedule. A switch may learn a new port while another host's ARP cache still points to an old MAC. Conversely, ARP may be correct while an empty switch table causes brief flooding. For a move-related outage, inspect IP → MAC and VLAN + MAC → Port at the same time. Correlate those results with MAC flapping logs and gratuitous ARP.
Sources for this section IETF RFC 826 · IETF RFC 5227 · IEEE 802.1Q
What to look for in the diagram Read the distinction between an ARP probe and a gratuitous ARP announcement, then compare the three boxes in the VRRP/HSRP failover example. Distinguish the announcement with Sender IP and Target IP both set to 192.0.2.1, the host's handling of the ARP address mapping and the switch's learning of a new port, and address-conflict detection.
↔ Scroll horizontally to explore the diagram.
Trusting unauthenticated ARP: spoofing and duplicate IP risks↑
Basic ARP has no strong authentication. An attacker can send a false reply associating the gateway IP with the attacker's MAC. Features such as Dynamic ARP Inspection reduce spoofing by comparing trusted DHCP bindings or policy with the ARP message.
If two devices use the same IP, an ARP cache may alternate between them and cause intermittent connectivity. Enabling a protection feature alone is not enough. Verify which address-to-MAC records it checks and which ports it trusts.
An attacker may claim, 'The gateway IP belongs to my MAC,' in an ARP reply. If a client saves that claim in its cache, later frames may head to the attacker's port. Dynamic ARP Inspection can compare the DHCP snooping binding's IP, MAC, VLAN, and port with the ARP message. But a static IP device has no DHCP binding. Inspecting everything without a suitable ACL or trust policy can drop legitimate packets too.
Duplicate IP addresses can cause the same symptoms without malicious intent. If two hosts take turns replying, different clients may retain different MAC addresses in their caches. The switch may correctly know both MAC locations while IP traffic intermittently reaches the wrong host. Compare ARP inspection drop counters, DHCP bindings, static asset records, and captured sender MAC addresses. Protection depends on trustworthy address records: inaccurate DHCP and IPAM operations undermine security policy too.
Using DHCP snooping bindings to validate ARP with Dynamic ARP Inspection, alongside static bindings, port security, and network authentication, can reduce risk. Missing static-address or relay details in the bindings can still cause legitimate packets to be dropped. Plan trusted ports, validation fields, rate limits, and rejection logs, then test normal gateway failover.
Sources for this section IETF RFC 5227 · Cisco Dynamic ARP Inspection
What to look for in the diagram Follow the Dynamic ARP Inspection path that uses DHCP snooping bindings and ARP ACLs for static addresses as validation sources. Check how a false IP-to-MAC mapping arriving on an untrusted port is inspected and dropped. Per-VLAN configuration values are not shown in this diagram.
↔ Scroll horizontally to explore the diagram.
ARP request, reply, and MAC learning: trace where the exchange stops↑
Scenario: An endpoint attempts a gateway ping, but its ARP entry remains Incomplete.
- In the endpoint capture, check for a gateway IP query in an outgoing ARP request.
- On the switch, verify that the VLAN is present on the access port and uplink.
- Capture the gateway interface to see the request arrive and the reply leave.
- If the reply does not return, check the VLAN, port security, DAI, and MAC address table move logs.
- After the fix, compare the ARP cache, MAC address table, and actual unicast frames again.
Trace the same ARP exchange at three points. Does the client access port send the request? Does the gateway port receive it in the same VLAN? Does the gateway reply head back toward the client? Record the VLAN ID and source MAC at each point, then check the switch's MAC address table for that MAC's learned port. If it is absent from only one uplink capture, narrow the investigation to allowed VLANs or STP state.
After the fix, do more than confirm a complete ARP entry: check that real data frames travel both ways by unicast. Once the gateway ping succeeds, test the same VLAN's other hosts and a remote prefix to verify the local and remote ARP targets. Use cache clearing as a test condition for observing relearning, not as the documented root-cause fix. Put the request, reply, MAC learning, and following IP packet on one timeline to explain why service recovered.
If the request never reaches the target port, investigate the VLAN or Layer 2 forwarding domain. If no reply is created, check the target host. If a reply disappears in transit, prioritize the MAC address table and security policy. Finding the first missing step helps prevent temporary actions, such as clearing the ARP cache, from obscuring the cause.
Sources for this section IETF RFC 826 · IEEE 802.1Q
Glossary↑
Sources and verification
- IETF RFC 1122 §3.3.1 — local/remote IP destination decisions and gateway selection
- IETF RFC 826 — basic IPv4 ARP operation
- IETF RFC 1812 §5.2.1.2 — router next-hop selection, TTL decrement, and new link-layer frames
- IETF RFC 5227 — IPv4 address conflict detection and ARP announcements
- IEEE 802.1Q — standards for bridge and VLAN operation
- Cisco Dynamic ARP Inspection — a vendor implementation example
MAC aging, ARP cache timers, and DAI configuration vary by platform. This article distinguishes standard principles from representative switch behavior.