[j-nsp] Junos Arp Expiration Timer Behavior & Active Flows
arseniev at btinternet.com
Sat Jan 12 12:00:06 EST 2019
Few more ARP tidbits for You:
1/ JUNOS learns ARP not only from responses but from requests as well -
this is according to RFC 826 "Packet reception" chapter (ARP opcode is
examined AFTER the xlation table is updated). Therefore, You may see
that ARP entry for the remote node is regularly refreshed on local node
without any ARP requests being sent out from that local node. This could
happen if the ARP randomized aging timers or clocks are different - and
they normally are if only by a small amount.
2/ changing ARP aging-time does not take effect immediately, You need to
wait until current entry ages out or clear it with CLI command.
3/ if You configure a static /32 route to with destination == nexthop -
like set routing-options static route 203.0.113.1/32 next-hop
203.0.113.1, which is a valid route in JUNOS and 203.0.113.1 must be
directly connected - then the ARP entry for 203.0.113.1 is maintained by
JUNOS in accordance with configured (or default) ARP aging timers
without any traffic going to 203.0.113.1 as opposed to normal ARP
behaviour where ARP is only resolved where there is a packet going to
On 11/01/2019 16:50, Clarke Morledge wrote:
> According to KB19396, "the Address Resolution Protocol (ARP)
> expiration timer does not refresh even if there is an active traffic
> flow in the router. This is the default behavior of all routers
> running Junos OS." The default timer is 20 minutes. I have confirmed
> this behavior on the MX platform.
> This does not seem very intuitive, as it suggests that a Junos device
> at L3 would stop in the middle of an active flow, to send an ARP
> request to try to refresh its ARP cache, potentially causing some
> unnecessary queuing of traffic, while the Junos device waits for ARP
> resolution. For an active flow, the ARP response should come back
> quick, but still it seems unnecessary.
> I would have thought that the ARP cache would only start to decrement
> the expiration timer, when the device was not seeing any traffic
> to/from ARP entry host.
> KB19396 goes onto say, "When the ARP timer reaches 20 (+/- 25%)
> minutes, the router will initiate an ARP request for that entry to
> check that the host is still alive." I can see that when the ARP timer
> is started initially, that it starts the expiration countdown, at this
> (+/- 25%) value, and not exactly at, say, 20 minutes, which is the
> default timer value.
> A couple of questions:
> (a) Is this default behavior across all Junos platforms, including MX,
> SRX, and EX?
> (b) Is there any other caveat as to when the Junos device will send
> out the ARP request, at the end of expiration period?
> Clarke Morledge
> College of William and Mary
> Information Technology - Network Engineering
> Jones Hall (Room 18)
> 200 Ukrop Way
> Williamsburg VA 23187
> juniper-nsp mailing list juniper-nsp at puck.nether.net
More information about the juniper-nsp