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

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

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

On 5 April 2017 at 16:45, Nitzan Tzelniker wrote: Hey, > Did someone test if ddos-protraction for protocol resolve with > flow-detection detect the source IP and drop its requests I'm sure it works, but you only have about 5k policers for all of ddos-protection, so

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

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 wrote: > Hello, > > If You have control over Your L3 space assignments, have You tried >

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

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

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

Hey Clarke, > (a) Get a request from an incoming packet that would trigger an ARP request > to go out. This is packet hitting route of 'rslv' type. Packets hitting this route are punted to software. > (b) If the router does not get a response back after X number of tries in Y > number of

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

Thank you, Eduardo, I should have mentioned, that I was also trying to avoid dropping possibly legit ARP requests due to overaggressive policing. Clarke On Mon, 3 Apr 2017, Eduardo Schoedler wrote: Hi Clarke, Maybe arp policer problem? https://lists.gt.net/nsp/juniper/18201#18201

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

Last I knew this was an architecture problem and was not yet addressed. I can't recommend Juniper right now for any platform that might get internet scanned and having a large connected subnet as a result. - Jared > On Apr 3, 2017, at 1:11 PM, Eduardo Schoedler wrote: > >

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

Hi Clarke, Maybe arp policer problem? https://lists.gt.net/nsp/juniper/18201#18201 Regards, 2017-04-03 14:07 GMT-03:00 Clarke Morledge : > I would like to revisit a question that has come up several times on the > list: > > https://lists.gt.net/nsp/juniper/57670 >

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

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