[j-nsp] Junos ARP aging and refcnt

[Tim Marin]

Hey Jon,

Also worth mentioning , as expiring ARP can be a ticking bomb to several
things
at some point there was per interface huge timers implemented:

# set system arp interfaces xe-0/0/4 aging-timer ?
Possible completions:
  <aging-timer>        Change the ARP aging time value (1..600000 minutes)




On Thu, Jun 25, 2026 at 5:54 PM Jon Lewis via juniper-nsp <
juniper-nsp at puck.nether.net> wrote:

> I've had some issues recently with ARP and am getting conflicting answers
> from JTAC, from google searching (and Google AI answers I can't
> substantiate) and emperical evidence.
>
> We have the arp aging-timer set to 5[minutes]. Junos adds a random jitter
> to that value for each ARP entry to stagger ARP timeouts...so I see
> ARP table entries refresh and get TTE's of 5-6 minutes.
>
> Where we've run into issues, and things get murky is exactly what the
> behavior should be when an ARP entry expires (and how refcnt might alter
> that behavior).  When doing FBF / policy routing utilizing next-ip, the
> behavior we've seen recently is that the next-ip's ARP entry expires and
> then the volume of traffic hitting the next-ip rule causes a resolve
> ucast-v4 ddos-protection protocol violation.  When the ddos-protection
> policer kicks in, sometimes the violation is brief and unnoticed.
> Sometimes it will persist indefinitely (until traffic stops hitting the
> FBF next-ip rule) causing policy routed traffic to blackhole.
>
> I can't find detailed documentation on this from Juniper, but according to
> Google AI, Junos treats ARP entries with refcnt > 0 differently than
> refcnt = 0.  In practice, I've not been able to find an ARP entry with
> refcnt = 0.  It seems more like 1 is as low as refcnt can be, and an ARP
> entry that's next-hop for a route increments that entry's refcnt for each
> such active route.
>
> What I've seen watching the ARP table is entries with refcnt > 1 can have
> their TTE reach 0, but they are not immediately removed.  Instead, they
> seem to be retained while an ARP is sent, and if a reply is received, the
> TTE is reset.
>
> I can't find this behavior documented anywhere, but it's what I'm seeing.
> So, I'm wondering if, when using next-ip in FBF, if it's best practice /
> required to have at least one route with that next-ip as next-hop (or just
> resort to a static ARP entry for the next-ip)?
>
> ----------------------------------------------------------------------
>   Jon Lewis, MCP :)              |  I route
>   Blue Stream Fiber, Sr. Neteng  |  therefore you are
> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>