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

[Chris Tracy]

Martin,

> It might also be an idea to measure using different values of burst size.
> I personally find the Juniper manuals to be somewhat lacking here...

You may want to try a perf testing application which is less bursty.  iperf UDP traffic is very bursty -- it does not go out of its way to evenly space packets.  You can easily see this by capturing the perf traffic, then processing it with something like tcpdump -ttt -r file.pcap |  awk '{print $1}' | sed -e 's/00:00:00.//' | sort -n | uniq -c > deltas.  In the 'deltas' histogram that results you should see the overwhelming majority of the packets in your flow are spaced extremely close together (e.g., near the 0 end).

Your interface speed appears to be GigE, so you are bursting out at line rate and relying on the buffers in the router to accommodate these line-rate bursts.  You should have different results if you connected the host at FastE vs GigE.

nuttcp is a perf testing tool which, by default, is much less bursty -- you can control whether it bursts or not.  Go to www.nuttcp.org or grab the latest rev from http://lcp.nrl.navy.mil/nuttcp/beta/nuttcp-7.1.3.c.

Use the -Ri10M option for a non-bursty 10Mbps flow.  You can add /# to make it burst # number of packets.  (This can be useful for seeing how "much" bursty traffic a device can take before it exhausts its buffers when there is a speed transition, for example..)

        -Ri#[/#] instantaneous rate limit with optional packet burst

If you look closely at the CPU usage of iperf vs nuttcp, you will find nuttcp (unlike iperf) consumes 100% of the sender's CPU when running in UDP mode because it puts itself into a very tight loop to get the most precise timing.

-Chris

--
Chris Tracy <ctracy at es.net>
Energy Sciences Network (ESnet)
Lawrence Berkeley National Laboratory