Thank you for the input thus far, folks.
Let me explain just a bit more about what I am dealing with. Because we
get so much garbage scanning, if the scanner tries to hit an IP address,
that does not have an ARP resolution, it really clutters up traffic
unnecessarily. A simple case from my lab illustrates some of the
difficulty.
Here I am sending a single transit packet, passing through my MX, destined
to an IP that will not resolve. Since the MX has nowhere immediately to
send the packet, the RE spits out a bunch of ARP requests:
17:30:35.095861 ARP, Request who-has 192.168.10.21 tell 192.168.10.8,
length 46
17:30:35.713821 ARP, Request who-has 192.168.10.21 tell 192.168.10.8,
length 46
17:30:36.613849 ARP, Request who-has 192.168.10.21 tell 192.168.10.8,
length 46
17:30:37.513831 ARP, Request who-has 192.168.10.21 tell 192.168.10.8,
length 46
17:30:38.313831 ARP, Request who-has 192.168.10.21 tell 192.168.10.8,
length 46
Correspondingly, rtsockmon -tn logs this:
[17:30:35:099.939] kernel P route add inet 192.168.10.21
tid=36 plen=32 type=dest flags=0x180 nh=hold nhflags=0x1 nhidx=1290
rt_nhiflist = 0 altfwdnhidx=0 filtidx=0 lr_id = 0 featureid=0
rt_mcast_nhiflist=-1610628420
[17:30:35:101.376] kernel P nexthop add inet nh=hold
flags=0x1 uflags=0x0 idx=1290 ifidx=421 filteridx=0 lr_id =0
[17:30:39:013.595] kernel P route delete inet 192.168.10.21
tid=36 plen=32 type=dest flags=0x180 nh=hold nhflags=0x1 nhidx=1290
rt_nhiflist = 0 altfwdnhidx=0 filtidx=0 lr_id = 0 featureid=0
rt_mcast_nhiflist=-1610628420
[17:30:39:013.710] kernel P nexthop delete inet nh=hold
flags=0x5 uflags=0x0 idx=1290 ifidx=421 filteridx=0 lr_id =0
In a real world case, we have generally observed a fairly even
distribution of scanning attempts on non-resolving IPs, across an entire
subnet, over time. So, let's say you have an unused class C, being scanned
at the rate of 4 IPs per second, such that every address gets scanned once
a minute. Assuming that each incoming transit packet kicks off 5 ARP
requests (1 initial, plus 4 retries), as I saw above, that would trigger
somewhere over 1200 ARP requests a minute, or about 20 ARP packets a
second.
That is a fairly moderate amplification type of attack.
In a DHCP-serviced subnet, like a /20 with some 4000 available host IPs,
we might have only 3000 being used at any one time, but we want to give
enough headroom to accommodate fluctuations in DHCP usage. But that leaves
those 1000 remaining, unused IPs unintentionally triggering lots of
unnecessary ARP traffic.
Specifically, what would be nice, is if there was a way to manipulate that
ARP retry mechanism, from 4 retries, down to 2, to cut down on the noise.
So far, I have not found a knob in Junos on the MX to do this.
Am I missing something?
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@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
