[j-nsp] Juniper "firewall policer" inner workings

sthaug at nethelp.no sthaug at nethelp.no
Thu Apr 7 06:05:03 EDT 2011


> I see. If policer counts in the IPv4 header as well, it would do
> (51021*28)/(1024*1024)=1.4MB which is rather close to 71.5-69.8=1.7MB.
> Could you please explain this "larger buffer to smooth things out"
> argument? As I understand, in simple terms, larger buffer is able to
> hold larger amount of received data in memory so in case of a burst,
> more data is held in the memory buffer and processed bit later. If the
> buffer is very small, buffer memory would be filled fast and even a
> short burst would be noticed as a packet loss. Right?

A policer will never delay packets, and will never change the interval
between packets - to do this you need shaping not policing.

The policer burst size will change the measurement interval used - thus
a bigger burst size means you will measure (average) the traffic over a
longer interval - you can potentially get more bps through the policer.

Steinar Haug, Nethelp consulting, sthaug at nethelp.no


More information about the juniper-nsp mailing list