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 < [email protected]> 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 [email protected] > https://puck.nether.net/mailman/listinfo/juniper-nsp > _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
