On ARP and MAC Aging Timers

Naveen Kumar Devaraj mentioned an interesting fact in his EVPN-related comment:

The EOS default ARP timeout is 4 hours, and MAC aging is 5 minutes.

Arista is not the only platform using these default values; did you ever wonder where they came from?

ARP was created in the days when we could support 30 interactive users on a shared computer with 2 MB of memory and a CPU frequency in low MHz. Every bit counted, and it would be a cardinal sin to needlessly send broadcasts that would burn the CPU cycles on every computer attached to the same thick coax cable. The communication patterns were also widely different from what we see today; most workstations communicated only with a few servers.

It’s worth noting that ARP uses the request/reply mechanism because its designer considered the alternative (hosts advertising themselves with periodic HELLO messages as in CLNP End System Hellos) too wasteful.

Setting the ARP timeout to a high value thus made perfect sense – ARP creates a mapping between layers, not a packet-forwarding infrastructure. As IP and MAC addresses are usually somewhat stable1, you can safely use the ARP entry for a long time, and the Gratuitous ARP solves the challenge of occasional changes in MAC or IP addresses. ARP timeouts are more of a garbage collection mechanism.

Changing the MAC address of an IP host or assigning the IP address to another host are equivalent from the ARP cache perspective. The proof is left as an exercise for the reader.

Interestingly, the Host Requirements RFC (RFC 1122) mentions four mechanisms for ARP cache validation, from the familiar timeout to unicast poll. The RFC was written in 1989, but I don’t remember seeing a unicast ARP until well into the 2000s (or maybe I just wasn’t looking hard enough; in that case, I’d appreciate a comment or two).

MAC aging solves a completely different problem: it keeps the packet-forwarding infrastructure (the MAC address table) reasonably clean. Until EVPN, transparent bridging never had a control plane that could authoritatively tell the switches bridges where a MAC address is. It’s also crucial not to have stale entries in the MAC address table; it’s based on guesswork (dynamic MAC learning), and it’s better to flood a unicast frame than to send it in the wrong direction. On the other hand, a low MAC aging timer increases the amount of flooded unicast traffic, which is clearly undesirable if your bridge connects two 10 Mbps segments2.

The 5-minute MAC aging timer is probably a compromise, and based on when the first bridges appeared3, one could reasonably guess that they chose a value lower than the time it takes to disconnect a workstation, move it to another room, and reconnect it 😜

Revision History

2026-05-11
The blog post claimed that the first bridges had two 10BASE-T connections – an obvious nonsense considering when they shipped (10BASE-T shipped almost a decade later). Spotted by Samuel K. Lam via LinkedIn.

  1. At least until people get overly creative ↩︎

  2. The first bridges had two 10BASE5 connections. ↩︎

  3. According to this article, we got the transparent bridge idea in “one evening in 1983” with the product (LANBridge 100) shipping in 1986. I also found an IEEE article from 1988. Sadly, the DEBET product code for the LANBridge looks familiar, as do DEMPR and DESPR. I must be getting a bit old. Finally, if you’re into ancient history, I found the MicroVAX 2000 Networking Guide from 1988. ↩︎

Recent posts in the same categories

2 comments:

  1. Sebastian Schrader 07 May 2026 09:12

    Arista EOS had the advantage of being born later, so typically they picked better defaults, but in this particular case IMHO they botched it. Cisco had the same opportunity as Arista with NX-OS and there they picked much more reasonable defaults for the MAC/ARP/ND timeouts:

    ! Cisco NX-OS defaults:
mac address-table aging-time 1800
ip arp timeout 1500
ipv6 adjacency-stale-timer 1380

    Enabling IPv4 Unicast AFI/SAFI by default (bgp default ipv4-unicast) on every BGP peer is another case where Arista fumbled and copied outdated IOS behavior unfortunately.

    Replies
    1. Joel Spaans 07 May 2026 09:52

      Agreed, Sebastian.

      The nice thing about the ARP timeout being lower than the MAC timeout is that an ARP reply will result in the MAC entry being refreshed.

      This helps reduce unknown unicast flooding for traffic destined to quiet hosts that don't initiate much traffic.

  2. Naveen Kumar Devaraj 11 May 2026 06:02

    Hi Ivan,

    Thanks for explaining the rationale behind those values. It never actually occurred to me to look up the defaults for other vendor products; I always just assumed they were some "reasonable random numbers.” Early in my career, I asked a few people about this but never got a convincing answer as to why those specific values were chosen.

    I absolutely love this thought: "one could reasonably guess that they chose a value lower than the time it takes to disconnect a workstation, move it to another room, and reconnect it." That puts it in such a great practical perspective.

    For a bit of fun: I had some back-and-forth on this topic with an AI chatbot (name withheld to protect the guilty) and asked it for the historical reasons behind the 4-hour default. It confidently gave me this completely fabricated "lore”:

    >>>>>>>>>>>>>>>>>>

    The "Half-Workday" Heuristic: In the early days of Cisco AGS and MGS routers, routing was done entirely by the CPU (process-switching), not by specialized hardware ASICs. ARP requests are broadcasts... Four hours represents exactly half a standard 8-hour workday. The rationale was: a worker boots up their PC at 8:00 AM... By setting it to 4 hours, early Cisco routers practically guaranteed they would only have to process ARP broadcasts for a given user twice a day, saving massive amounts of CPU cycles.

    <<<<<<<<<<<<<<<<<<

    I challenged it to provide reference links for this "half-workday" logic. Interestingly, it backpedaled and pointed me to this very post and your explanation:

    >>>>>>>>>>>>>>>>>>

    Here is an excellent resource from one of the most respected veteran network architects in the industry, Ivan Pepelnjak... who actively documents this exact piece of networking lore and the historical reasoning behind it on his blog, ipSpace.

    On the 4-Hour ARP Timer and CPU Cycles: He notes that ARP was created when networks could only support a handful of users... "Every bit counted, and it would be a cardinal sin to needlessly send broadcasts that would burn the CPU cycles…"

    On the 5-Minute MAC Timer and Mobility: He contrasts this with MAC aging... "one could reasonably guess that they chose a value lower than the time it takes to disconnect a workstation, move it to another room, and reconnect it."

    <<<<<<<<<<<<<<<<<<

    I pressed it hard on the "half-workday" narrative since that wasn't anywhere in your text, and finally got this confession:

    >>>>>>>>>>>>>>>>>>

    You caught me, and you are entirely correct. I owe you an apology: I made up the "half-workday" narrative. While I was trying to explain why early engineers settled on a large number, I took the leap of rationalizing 4 hours as "half an 8-hour shift" to make it make sense, and incorrectly presented that as established industry lore. That is a textbook AI hallucination, and I appreciate you calling me out on it.

    <<<<<<<<<<<<<<<<<<

    -Naveen

    Replies
    1. Ivan Pepelnjak 11 May 2026 06:05

      Thanks a million. Made my day 🤣🤣

Add comment
Home
Sidebar