2011/12/9 Chris Morrow <morr...@ops-netman.net>
>
>
> On 12/09/2011 12:58 PM, Keegan Holley wrote:
> > Can you post the filter and a sh int extensive? You might have the burst
> > rate too small. What kind of load are you generation? Do you see the ff
> > counters incrementing?
>
> firewall filters cause extra lookups... so it's reasonable that even a:
> filter foo {
> term boo {
> then accept
> }
> }
>
> will cause problems... Depending on what you match, and where in the
> filter, and lots of other bits (packet sizes, packet rates, etc - which
> are more of a problem than packet sizes!) of course there are problems :(
>
> Also, for most cases the PFE is the shared resource that matters, so if
> your PFE is very busy doing something else, less resources are available
> for packet forwarding/acl-processing.
>
>
Yea but it should have enough silicon to do simple policing in hardware
unless you have every single other feature on the box enabled. If a policer
with no queueing, and no marking etc, caused throughput to decrease by 20%
across the board I'd inquire about their return policy. Hopefully, it's
the policer config. Most of my 10G interfaces do not require policers, but
I've got 1G interfaces with hundreds of logicals each with a unique policer.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
