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

[Alexander Arseniev]

Actually, if the L2 switch supports E-OAM, it can be done as well.

Basically, on router side use 1 subinterface/VLAN per endpoint with CFM 
running between the router and switchport connected to that endpoint.

When the endpoint goes down, switchport will go down too, CFM will 
signal RDI to the router, and the router will mark the subinterface 
down. The associated static /32 will sink/disappear.

JUNOS automation would help with repetitive subinterface configs.

HTH

Thanks

Alex


On 05/04/2017 14:27, Alexander Arseniev 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/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 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