[j-nsp] __default_arp_policer__

[Pekka Savola]

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.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings