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 <[email protected]> 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 [email protected] > https://puck.nether.net/mailman/listinfo/juniper-nsp > _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
