[j-nsp] Junos Arp Expiration Timer Behavior & Active Flows

[Alexander Arseniev]

Hello,

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 
203.0.113.1.

HTH

Thx
Alex

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
> https://puck.nether.net/mailman/listinfo/juniper-nsp