From jlewis at lewis.org  Thu Jun 25 11:53:55 2026
From: jlewis at lewis.org (Jon Lewis)
Date: Thu, 25 Jun 2026 11:53:55 -0400 (EDT)
Subject: [j-nsp] Junos ARP aging and refcnt
Message-ID: <f9959c4-1c1c-6541-fe38-6f64cb147ff@lewis.org>

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_________

From saku at ytti.fi  Thu Jun 25 12:10:34 2026
From: saku at ytti.fi (Saku Ytti)
Date: Thu, 25 Jun 2026 19:10:34 +0300
Subject: [j-nsp] Junos ARP aging and refcnt
In-Reply-To: <f9959c4-1c1c-6541-fe38-6f64cb147ff@lewis.org>
References: <f9959c4-1c1c-6541-fe38-6f64cb147ff@lewis.org>
Message-ID: <CAAeewD_E+t-Dzbt-xqZwEFO0O+tiMFKpi3umEybXtzmBdDR3-Q@mail.gmail.com>

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

From timamaryin at gmail.com  Thu Jun 25 17:08:36 2026
From: timamaryin at gmail.com (Tim Marin)
Date: Thu, 25 Jun 2026 23:08:36 +0200
Subject: [j-nsp] Junos ARP aging and refcnt
In-Reply-To: <f9959c4-1c1c-6541-fe38-6f64cb147ff@lewis.org>
References: <f9959c4-1c1c-6541-fe38-6f64cb147ff@lewis.org>
Message-ID: <CADxNKvW5uX9gHZ=O9kqXS12YZytgDw0UJY74MfeftmeLg9qJeQ@mail.gmail.com>

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
>