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

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Reply via email to