[j-nsp] __default_arp_policer__

[Bit Gossip]

This is a very valid point.
I have also verified that if no user-defined policer is applied and only
the internal __default_arp_policer__ is in place, this policer is a
global policer and drops arp-req from any interface if a single
interface is under ARP attack
Another point of having user-defined ARP-POLICER is that the default
thresholds for it may change between Junos releases and platforms and
therefore it is not safe to depend on those values.

Bit

On Tue, 2009-10-20 at 10:10 +0300, Pekka Savola wrote:
> On Fri, 16 Oct 2009, Bit Gossip wrote:
> > https://puck.nether.net/pipermail/juniper-nsp/2009-May/013325.html
> ...
> > and only ~40000 arp requests received a reply from M7i
> > which makes roughly ~222 arp-reply/sec
> ...
> > My conclusion is that the setting for __default_arp_policer__
> > are perfectly fine and there is no need to apply a custom arp policer to
> > any interface.
> >
> > What is the opinion of the experts over there?
> 
> There's a drawback to this.  __default_arp_policer__ is (AFAIK) 
> global, so an ARP storm on interface X will result in ARP timeouts on 
> interface Y.  It's also impossible to track via counters which 
> interface had an ARP storm.  Compare e.g.:
> 
> JUNIPER-FIREWALL-MIB::jnxFWCounterPacketCount."__default_arp_policer__"."__default_arp_policer__".policer = Counter64: 0
> JUNIPER-FIREWALL-MIB::jnxFWCounterPacketCount."ARP-POLICER-ge-1/0/0.0-inet-arp"."ARP-POLICER-ge-1/0/0.0-inet-arp".policer = Counter64: 0
> JUNIPER-FIREWALL-MIB::jnxFWCounterPacketCount."ARP-POLICER-ge-4/0/0.0-inet-arp"."ARP-POLICER-ge-4/0/0.0-inet-arp".policer = Counter64: 376
> 
> A bit tangential:
> 
> If there's an ARP storm, it is often due to an ethernet loop and is 
> actually a broadcast storm.  Then I suppose there's also other L2 
> broadcast traffic that's hitting the RE.  'Family any' L2 policer on 
> loopback would be interesting to test; I've been intending to do that 
> for a while but haven't gotten around to doing so.
>