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