[j-nsp] Negative ARP caching, on an MX router (again)

[Nitzan Tzelniker]

Did someone test if ddos-protraction for protocol resolve with
flow-detection detect the source IP and drop its requests

Nitzan

On Wed, Apr 5, 2017 at 4:27 PM, Alexander Arseniev <arseniev at btinternet.com>
wrote:

> Hello,
>
> If You have control over Your L3 space assignments, have You tried
> point-to-point Ethernet interfaces with static /32 routes?
>
> Assuming 203.0.113.0/24 subnet, Your router IP is 203.0.113.1, and there
> are 2 hosts 203.0.113.2 + 203.0.113.3 directly connected to ge-0/0/0 and
> ge-0/0/1 respectively, then the following example should help:
> (from memory)
>
> set interfaces ge-0/0/0.0 family inet unnumbered-address lo0.0
> preferred-source-address 203.0.113.1
> set interfaces ge-0/0/1.0 family inet unnumbered-address lo0.0
> preferred-source-address 203.0.113.1
> set routing-options static route 203.0.113.0/24 discard
> set routing-options static route 203.0.113.2/32 qualified-next-hop
> ge-0/0/0.0
> set routing-options static route 203.0.113.3/32 qualified-next-hop
> ge-0/0/1.0
>
> JUNOS scripting/Automation could help with large number of  used IPs.
> Packets towards unused IPs that have no corresponding /32 static route
> would get dropped by 203.0.113.0/24 static discard route.
> Disclaimer - this method does not solve the issue when used IPs are behind
> a switch connected to the router, and endpoints that utilize said IPs can
> go up & down without notice.
> HTH
> Thx
> Alex
>
>
> On 03/04/2017 18:07, Clarke Morledge wrote:
>
>> I would like to revisit a question that has come up several times on the
>> list:
>>
>> https://lists.gt.net/nsp/juniper/57670
>> https://lists.gt.net/nsp/juniper/60797
>>
>> I am trying to figure out a way to cut down on unnecessary ARP requests,
>> being generated by MX routers, when someone comes sweeping across my L3
>> space, and triggering these unnecessary ARP broadcasts, for unused
>> addresses.
>>
>> There is a possible solution of ARP sponging, but it would be really,
>> really nice if there was something on-board with JUNOS to handle this,
>> instead a rolling out a special purpose box:
>>
>> https://ams-ix.net/technical/specifications-descriptions/con
>> trolling-arp-traffic-on-ams-ix-platform
>>
>> Ideally, if JUNOS could do something like this:
>>
>> (a) Get a request from an incoming packet that would trigger an ARP
>> request to go out.
>>
>> (b) If the router does not get a response back after X number of tries in
>> Y number of seconds, put some type of dummy MAC address in the ARP cache
>> that can be easily sinkholed.
>>
>> (c) Stay in this state for Z number of seconds, before flushing that
>> dummy MAC address out of the cache, and then re-enabling ARP for that
>> particular address.
>>
>> (d) In addition, the router would passively listen for packets coming
>> into the L3 interface that would overwrite the dummy MAC address in the ARP
>> cache with a (hopefully) legitimate MAC address, which would allow the
>> process to exit out of the above state, without waiting for the above "Z"
>> timer to expire.
>>
>> Is there any way that JUNOS on an MX could configured to do this?
>> Enhancement request anyone?
>>
>>
>> Clarke Morledge
>> College of William and Mary
>> Information Technology - Network Engineering
>> Jones Hall (Room 18)
>> Williamsburg VA 23187
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>