[j-nsp] ARP resolution algorithm? Storage of MX transit packets?

[Clarke Morledge]

I am trying to wrap my head around how the MX handles ARP resolution, 
and how it stores packets waiting to be transmitted, while waiting for ARP 
to resolve.

If a transit packet comes into a router, on a PFE, and there is no 
corresponding entry in the ARP cache for the next hop, the routing engine 
gets involved in order to perform ARP resolution.

>From Junos 16.2, and moving forward, what should show up in rtsockmon -tn, 
to help locate the ARP query and next-hop programming, etc., once the 
reply is received?

In the event an ARP request is generated, and no response is received 
within x(???) seconds, it looks like another request is sent out, or more, 
perhaps? If no response ever comes back, after some period of time, I 
presume the router will drop the transit packet.

So, where is this transit packet being held, while it is waiting for the 
ARP reply to come back (if it even does come back)? How is the packet 
being stored? Are the packets stored via a hash in separate queues, of 
some sort, so that other transit traffic is not getting blocked?

What is strange is that if there is a string of transit packets coming in, 
that have no corresponding ARP entry in the cache available, the way the 
RE sends out ARP requests does not exactly correspond to the order of 
transmit packets, as they come into the PFE.  I would have expected a 
FIFO-like mechanism, but this does not seem to be the case.

Does anyone have an explanation for this behavior, or better, how the ARP 
resolution algorithm is supposed to work, at the packet buffering level?

Below is a half-second sample of what traffic comes into the router, that 
needs ARP resolution, followed by what ARP requests the RE actually sends 
out.

Clarke Morledge
College of William and Mary
Information Technology - Network Engineering
Jones Hall (Room 18)
200 Ukrop Way
Williamsburg VA 23187

--------------------

Off the Wire, Just Before Traffic Enters the MX:

21:51:16.158064 IP 185.254.123.12.46185 > 100.64.101.189.3588:
21:51:16.297351 IP 92.63.194.38.47423 > 100.64.101.25.55126:
21:51:16.301438 IP 185.53.91.24.55823 > 100.64.101.88.5038:
21:51:16.385521 IP 185.176.27.34.58908 > 100.64.101.215.1288:
21:51:16.449858 IP 92.53.90.143.44499 > 100.64.101.192.282:
21:51:16.462591 IP 92.53.90.143.44499 > 100.64.101.181.282:
21:51:16.470221 IP 185.143.221.106.58528 > 100.64.101.1.4040:
21:51:16.492806 IP 92.63.194.38.47423 > 100.64.101.35.55126:
21:51:16.500132 IP 92.63.194.38.47423 > 100.64.101.58.55126:

ARP Requests Coming Out of the RE:

21:51:16.158515 ARP, Request who-has 100.64.101.189 tell 100.64.101.3
21:51:16.227443 ARP, Request who-has 100.64.101.50 tell 100.64.101.3
21:51:16.227985 ARP, Request who-has 100.64.101.158 tell 100.64.101.3
21:51:16.297828 ARP, Request who-has 100.64.101.25 tell 100.64.101.3
21:51:16.327204 ARP, Request who-has 100.64.101.59 tell 100.64.101.3
21:51:16.327664 ARP, Request who-has 100.64.101.65 tell 100.64.101.3
21:51:16.427452 ARP, Request who-has 100.64.101.2 tell 100.64.101.3
21:51:16.428282 ARP, Request who-has 100.64.101.9 tell 100.64.101.3
21:51:16.473085 ARP, Request who-has 100.64.101.1 tell 100.64.101.3
21:51:16.527447 ARP, Request who-has 100.64.101.7 tell 100.64.101.3
21:51:16.528278 ARP, Request who-has 100.64.101.88 tell 100.64.101.3