bit.gossip at chello.nl
Tue Oct 20 07:52:26 EDT 2009
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.
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.
More information about the juniper-nsp