[j-nsp] Junos ARP aging and refcnt

[Saku Ytti]

This was before we had a specific DDoS 'resolve' policer, like we have
today, but it may bring some clarity to the ARP resolution design.

http://blog.ip.fi/2014/02/junos-and-arp-glean.html


For a very long time after DDoS protection was implemented, and before
'resolve' policer was implemented, resolve packets would be classified
as any punted traffic would. So say you're sending 5000pps of BGP to
an unresolvable next-hop, now all your BGP is dead, because you
congest BGP policer, and lo0 filter won't help you, as these are not
true punts. This lasted years, maybe decade.


On Thu, 25 Jun 2026 at 18:54, 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



-- 
  ++ytti