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

[Clarke Morledge]

On Fri, 1 Feb 2019, Saku Ytti wrote:

>> Am I missing something?
>
> I don't think you are. You have not described the practical problem
> you are facing, which may help people with proposing a solution. What
> practical consequences you have with the unnecessary ARP traffic?

Thanks, Ytti, Krasi, and others for the suggestions to explore (I have 
stayed away from subscriber access, up to this point, but will look at the 
other options first).

The practical problem I have is that we have some downstream devices that 
are very sensitive to being overwhelmed by even small spikes of ARP 
traffic.

For example, there is an ethernet switch on the market today (*cough*), 
with a chip made by a well-known manufacturer, that will try to process 
all of the ARPs coming in from every VLAN serviced by the switch, even 
when the switch is configured to only operate in L2 mode. In other words, 
the chip will suck in all of the ARP requests, coming from all VLANs, not 
just the management VLAN, where the switch's IP address is configured. The 
switch vendor admits that this is a hardware defect. All it takes is about 
200 ARP pkts/sec, across all of the VLANs, to overwhelm the switch, and 
render the mananagement interface unusable.

In an environment where we have 20 VLANs on an L2 switch, where a certain 
number of them have exposure to be scanned by nefarious hosts on the 
Interwebs, this effectively compromises our ability to manage this 
particular switch.

To make the problem even more annoying, our upstream MX router, with L3 
configured, does something I never expected. Let us imagine that I have a 
/20 IPv4 subnet, being serviced by DHCP, with exposure to the big-bad 
Internet-based scanners.

I realize that less than half of this address space is being used, so I am 
able to resize the DHCP ranges to split the subnet into two /21s. So, I 
pack all of my DHCP serviceable addresses into one of the /21s, and then 
blackhole the other /21.

I would have expected that this reconfiguration would eliminate perhaps a 
little less than half of my unnecessary ARP traffic, destined for 
not-in-use addresses. For example, I normally see 300 ARPs/sec being spit 
out by the MX RE, with the full /20 configure originally.  I would have 
expected the ARP rate to drop to somewhere between 150 and 200 ARPs/sec, 
by splitting my /20 in half, and blackholing one of the /21s.  Instead, 
the ARP rate only drops to about 280-290 ARPs/sec.

Apparently, the MX algorithm for trying to resolve ARPs shifts things 
around internally, on the RE I suppose, such that it keeps spitting out 
more ARP requests per second on that remaining /21, than it was spitting 
out before.

Anyway, the name of the game I am playing is unnecessary ARP elimination, 
and I am not winning.

I guess there is always IPv6 :-)

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