Flamingo Raises $4.5M Seed Round · Led by Vertex Ventures, bringing total funding to $6.7M to build the open, AI-native layer for IT and security.
Aliaska Varieva
The ARP table is where a device keeps the IP-to-MAC pairs it has learned on its own segment, and it goes wrong in four recognizable ways. Here is how to read arp -a on each platform, which end to clear after a hardware swap, and why a static entry is not a fix.
A device can have the right IP address, the right gateway and a green link light, and still not get a single packet back. The reason is often sitting in a table nobody looks at until the third hour of the ticket. This guide explains what the ARP table is, how to read arp -a on each platform, and which entries to clear, set or leave alone.
Every packet on a wired or Wi-Fi segment is delivered to a hardware address, the MAC, not to an IP address. The Address Resolution Protocol is how a device learns which MAC owns an IP on its own segment: it broadcasts "who has 192.168.1.1" to everyone on the wire, the owner answers "I do, I'm 3c-ab-72-...", and the asker writes the pair down. That list of pairs is the ARP table, also called the ARP cache or neighbor cache. It exists on every IP device: laptops, servers, printers, phones, firewalls, the core switch.
Two limits shape every ticket in this post. ARP never crosses a router, so the table only ever holds devices on the same subnet plus the gateway; for anything further away, the only entry that matters is the gateway's. And ARP has no verification step at all. Whoever answers first, or answers unasked, is believed, which is why the table can be wrong and why the last section of this post exists.
It is not the same as the MAC address table on a switch. The switch's table maps a MAC to the physical port it was last seen on. The ARP table maps an IP to a MAC. Troubleshooting usually needs both: the ARP table tells you which MAC a host thinks owns the address, and the switch's table tells you which port that MAC is on, which is how you find the device in a rack. IPv6 does the same job with Neighbor Discovery, and on Windows both live in the same neighbor cache.
On Windows, arp -a prints one block per network interface, headed by the interface's own IP, then three columns: the IP, the MAC, and a type of dynamic or static. Microsoft's arp reference covers the switches. Three kinds of rows look alarming and are not. 255.255.255.255 and the subnet broadcast resolve to ff-ff-ff-ff-ff-ff, which is the broadcast address. Rows for 224.0.0.x and 239.x.x.x resolve to 01-00-5e-..., which is how IPv4 multicast groups are written as MACs. Both are static, both are normal, and neither is a device.
The rows that matter are the dynamic ones, and arp -a hides their state. Get-NetNeighbor in PowerShell shows it: Reachable means the entry was confirmed recently, Stale means it is still used but unconfirmed, Incomplete means a request went out and nothing answered, and Permanent is a static entry. Per Microsoft's ARP caching article, an unused entry stays Reachable for a random 15 to 45 seconds, then goes Stale and triggers a fresh request the next time anything is sent to it. Windows does not hold onto an old answer for long.
On Linux, ip neigh prints the same table with the state spelled out: REACHABLE, STALE, DELAY, PROBE, INCOMPLETE and FAILED, where FAILED means the probes ran out without a reply. On macOS, arp -a shows (incomplete) in place of a MAC for the same condition, and a permanent flag on static rows. An incomplete or FAILED row for an address that should be up is the single most useful line in the whole table: the host asked and nobody on the segment claimed the IP.
Two devices, one IP. The table flaps: the same IP shows one MAC, then another, and the user's connection comes and goes with it. On the gateway the log says the IP "moved" between two MACs. In an r/networking thread from September 2024 the core switch logged exactly that every few minutes, the poster cleared the table and pinged while Wireshark listened, and two different machines answered. The second one turned out to be a laptop's management firmware answering on a default IP from the BIOS, with the OS not even running. Wireshark's arp.duplicate-address-detected filter and Windows Event ID 4199 catch the same thing from the host side.
A replaced firewall or router. The new box has the old IP and a new MAC. Every host on the segment relearns within a minute, but the device upstream of the firewall, the ISP router or the core switch, may not. Cisco IOS keeps an ARP entry for 14,400 seconds by default, four hours, and an ASA uses the same figure globally. Until it expires, that device keeps sending traffic for your IP to a MAC that no longer exists, and the symptom is "the new firewall works from inside and nothing works from outside". The fix lives on the neighbour, not on the new box: clear the entry there, or have the new device send a gratuitous ARP, which is an unrequested "I have this IP" broadcast that most neighbours accept.
A cloned VM with a duplicate MAC. Clone a VM without regenerating its network adapter and two machines share a MAC. The ARP table on everything else looks fine, because the IP-to-MAC pairs are consistent; the switch's MAC table is the one that flaps between two ports. Both VMs drop in and out, and whichever one spoke last gets the traffic. The tell is the switch log, not arp -a.
A printer that moved VLANs. A silent device that moves subnet keeps its old IP and gateway, so the new VLAN's router never sees it speak and never learns it. The host side shows incomplete; the gateway side holds a stale entry pointing at the old segment until it times out. Reconfigure the device for its new subnet, then clear the entry on the gateway. The wider version of this diagnosis, where the first reply tells you which hop gave up, is in our guide to Destination Host Unreachable.
Clearing a host's table is safe and cheap; the host relearns everything it needs on the next packet. On Windows, arp -d * from an elevated prompt drops every entry, arp -d 192.168.1.1 drops one, and netsh interface ip delete arpcache does the whole cache. On Linux it is ip neigh flush dev eth0, or ip neigh del 192.168.1.1 dev eth0 for one address. On macOS, sudo arp -d -a. Then ping the gateway and read the table again.
The catch is that the host's table is rarely the one that is wrong, because Windows and Linux expire entries in under a minute. The device that keeps an old answer for hours is the router or firewall, and that is the one to clear. On Cisco gear it is clear arp-cache or clear ip arp 192.168.1.50 for one address; every firewall vendor has the equivalent in its diagnostics page. Which end to clear is the first question, and it has a rule: if the host can reach the gateway but the far side cannot reach the host, clear the gateway.
The r/sysadmin thread below is the hours-long version of that rule, from August 2026. Hosts in one subnet were unreachable from another until they pinged their own gateway, then fine for an hour or two, then unreachable again. A permanent ARP entry on the host for the gateway changed nothing, because the host's table was never the problem. The most-voted reply pointed at the gateway holding a wrong MAC for the hosts' addresses and relearning it only when the host happened to speak, which is the shape to recognize.
Static entries are the other half of the arp command, and they are a tool with a narrow use. arp -s 10.0.0.80 00-AA-00-4F-2A-9C pins an IP to a MAC until the TCP/IP stack restarts, so Microsoft's own advice for a permanent one is a batch file in a scheduled task. A static entry is right when a device cannot answer ARP, such as some embedded controllers, or when you need a pinned gateway on a kiosk. It is wrong as a fix for any of the four tickets above, because it does not change what the other devices believe, and it breaks silently the day the pinned device's NIC is replaced. Clear, relearn and fix the cause; pin only when the device itself cannot play the protocol.
The same trust that makes a gratuitous ARP useful for failover makes it an attack. Any device on the segment can broadcast "I have the gateway's IP" with its own MAC, every host writes it down, and from then on their traffic goes through the attacker's machine before reaching the real gateway. That is ARP spoofing, also called ARP poisoning, and it is the standard on-the-wire route to intercepting sessions on a flat office network. The signs are a gateway IP whose MAC changed to one your switch vendor did not make, or two MACs claiming the gateway in quick succession.
The textbook answer is a static entry for the gateway on every host. It stops the host accepting a poisoned reply, and it does not scale past a handful of machines, has to be redone on every NIC or firewall swap, and protects only the hosts you remembered. The switch-side answer is Dynamic ARP Inspection: the switch builds a table of legitimate IP-to-MAC leases from DHCP snooping, then drops any ARP packet on an untrusted port whose sender pair does not match a lease. It needs DHCP snooping on first, uplinks marked trusted before it is turned on, and manual bindings for anything with a static IP, and switching it on without those three steps takes the VLAN down, a lockout Cisco's own small-business forums describe. Segmentation shrinks the blast radius too: an attacker can only poison the subnet they are on, which is one more reason the VLAN guide puts guests and devices on their own segments.
Across a fleet, the useful habit is a baseline. Collect arp -a from every Windows machine at once and keep the gateway row; a gateway MAC that differs on one machine, or changes between runs, is either a swap you knew about or a poisoning you did not. If you run OpenFrame, that is one script run across a client's devices with the output collected in one place, which turns a per-machine command into a per-site answer.
Every network has run the four-hour version of this ticket at least once.
The ARP table is the list of IP-to-MAC pairs a device has learned on its own segment, and it is wrong in four recognizable ways: it flaps when two devices share an IP, it goes stale on the upstream router after a hardware swap, it shows incomplete when the device is not on the segment it thinks it is, and it points at a stranger when someone is poisoning it. Hosts forget in under a minute; routers remember for hours; so read the table at both ends and clear the end that is wrong. Pin an entry only for a device that cannot answer for itself, and let the switch do the policing.
If the gateway is fine and the problem is names rather than addresses, the next stop is DNS server not responding. For a map of which device sits on which port before the next swap, the network mapping guide covers how discovery tools build it.
Head of Platform
Hi! I’m Aliaska, and I’ve been working as a software engineer (mostly Java + a bit Kotlin) for over 8 years now. I mostly spend my time building backend services, integrating systems, fixing bugs (the fun part 🙃), and making sure things don’t fall apart behind the scenes.
Still deciding?
Ask Mingo answers from our docs and customer stories.
Still deciding?
Ask Mingo answers from our docs and customer stories.