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

[Krasimir Avramski]

Hi,

If you use the MX as subscriber access dhcp server/relay it will populate
the host routes(access-internal) and arp entries automatically upon dhcp
negotiation. In that setup usually the ethernet interface(segment) is
unnumbered and only /32 host routes to subscribers are installed - no
network route with rsvl next-hop in PFE. Traffic to unused IP address space
would be silently dropped.

Best Regards,
Krasi

On Fri, 1 Feb 2019 at 01:32, Clarke Morledge <chmorl at wm.edu> wrote:

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