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

Mon Apr 4 12:00:30 EDT 2011

iperf counts payload, not total L3.  The policer is counting total L3.

10Mbit bits/sec of total L3 is 9.8Mbit of payload in this case.

There is _always_ noise in the system.

Unless you are using a calibrated test device doing the work in hardware
(or well written software in a RealTime scheduling loop), consider all
flow values to be "average" over some small window.  Generally there is
some packing up and bursting of some level, even if the flow averages
10Mbit over a 500ms window, it may be running over/under on a 50ms window.

There is also granularity in the policer.  When it drops, it cannot drop
a fractional packet....

9.77 v.s. 9.8 is dead on and as expected.

For example:  A single packet that is 10% over is 100% drop.  4 packets
a second that are 10% overlimit are are dropped account for the .77 v.s.
.8 right there.

On 4/4/11 4:48 AM, Martin T wrote:
> Gabriel,
> the question is, what does JUNOS "bandwidth-limit 10m" count into this
> "10m". Only they application payload? L4 header as well? Or even the
> IP header? If I send UDP traffic with 10Mbps and router policer
> "bandwidth-limit 10m" drops ~2.5% of this traffic, then I don't find
> this normal..
> 
> 
> regards,
> martin
> 
> 
> 2011/4/4 Gabriel Blanchard <gabe at teksavvy.ca>:
>> The policer is dropping packets in order to slow down your connection to 10mbps. In my opinion this is working perfectly.
>>
>>
>>
>> On 2011-04-04, at 8:30 AM, "Martin T" <m4rtntns at gmail.com> wrote:
>>
>>> With such configuration: http://img135.imageshack.us/img135/3162/iperftest.png
>>>
>>> ..there is still packet loss present:
>>>
>>> [root@ ~]# iperf -c 192.168.2.1 -u -fm -t60 -d -b 10m
>>> ------------------------------------------------------------
>>> Server listening on UDP port 5001
>>> Receiving 1470 byte datagrams
>>> UDP buffer size: 0.04 MByte (default)
>>> ------------------------------------------------------------
>>> ------------------------------------------------------------
>>> Client connecting to 192.168.2.1, UDP port 5001
>>> Sending 1470 byte datagrams
>>> UDP buffer size: 0.01 MByte (default)
>>> ------------------------------------------------------------
>>> [  4] local 192.168.1.1 port 59580 connected with 192.168.2.1 port 5001
>>> [  3] local 192.168.1.1 port 5001 connected with 192.168.2.1 port 44050
>>> [ ID] Interval       Transfer     Bandwidth
>>> [  4]  0.0-60.0 sec  71.5 MBytes  10.0 Mbits/sec
>>> [  4] Sent 51019 datagrams
>>> [  3]  0.0-60.0 sec  69.9 MBytes  9.77 Mbits/sec   0.022 ms 1180/51021 (2.3%)
>>> [  3]  0.0-60.0 sec  1 datagrams received out-of-order
>>> [  4] Server Report:
>>> [  4]  0.0-60.0 sec  69.9 MBytes  9.77 Mbits/sec   0.150 ms 1180/51018 (2.3%)
>>> [  4]  0.0-60.0 sec  1 datagrams received out-of-order
>>> [root@ ~]#
>>>
>>>
>>> What should this "filter-specific" do? According to documentation,
>>> "Filter-specific policers allow you to configure policers and counters
>>> for a specific filter name. If the filter-specific statement is not
>>> configured, then the policer defaults to a term-specific policer", but
>>> it's rather difficult to understand without examples..
>>>
>>> regards,
>>> martin
>>>
>>>
>>> 2011/4/4 Ben Dale <bdale at comlinx.com.au>:
>>>> Hi Martin,
>>>>
>>>> Your policer bandwidth (10Mbps) is being counted on both ingress and egress and will be stacking - try adding:
>>>>
>>>> set firewall policer bw-10Mbps filter-specific
>>>>
>>>> and you should see the loss go away.
>>>>
>>>> Cheers,
>>>>
>>>> Ben
>>>>
>>>> On 04/04/2011, at 7:41 PM, Martin T wrote:
>>>>
>>>>> I made a following setup:
>>>>>
>>>>> http://img690.imageshack.us/img690/3162/iperftest.png
>>>>>
>>>>> In a laptop, an Iperf server is listening like this: "iperf -s -u -fm".
>>>>> In a workstation, an Iperf client is executed like this: "iperf -c
>>>>> 192.168.2.1 -u -fm -t60 -d -b 10m". This will execute simultaneous
>>>>> 10Mbps UDP traffic flood between 192.168.1.1 and 192.168.2.1 for 1
>>>>> minute. Results are always like this:
>>>>>
>>>>> [root@ ~]# iperf -c 192.168.2.1 -u -fm -t60 -d -b 10m
>>>>> ------------------------------------------------------------
>>>>> Server listening on UDP port 5001
>>>>> Receiving 1470 byte datagrams
>>>>> UDP buffer size: 0.04 MByte (default)
>>>>> ------------------------------------------------------------
>>>>> ------------------------------------------------------------
>>>>> Client connecting to 192.168.2.1, UDP port 5001
>>>>> Sending 1470 byte datagrams
>>>>> UDP buffer size: 0.01 MByte (default)
>>>>> ------------------------------------------------------------
>>>>> [  4] local 192.168.1.1 port 32284 connected with 192.168.2.1 port 5001
>>>>> [  3] local 192.168.1.1 port 5001 connected with 192.168.2.1 port 52428
>>>>> [ ID] Interval       Transfer     Bandwidth
>>>>> [  4]  0.0-60.0 sec  71.5 MBytes  10.0 Mbits/sec
>>>>> [  4] Sent 51021 datagrams
>>>>> [  4] Server Report:
>>>>> [  4]  0.0-59.9 sec  69.8 MBytes  9.77 Mbits/sec   0.112 ms 1259/51020 (2.5%)
>>>>> [  4]  0.0-59.9 sec  1 datagrams received out-of-order
>>>>> [  3]  0.0-60.0 sec  69.8 MBytes  9.77 Mbits/sec   0.030 ms 1200/51021 (2.4%)
>>>>> [  3]  0.0-60.0 sec  1 datagrams received out-of-order
>>>>> [root@ ~]#
>>>>>
>>>>> As you can see, there is a ~2.5% packet loss. This packet loss is due
>>>>> to the fact, that router "bw-10Mbps" policer drops small percentage of
>>>>> packages in "input" direction(I can check the amount of dropped
>>>>> packets with "show policer" command). For example if I increase the
>>>>> policer "bandwidth-limit" to "11m", there will be no packet loss.
>>>>>
>>>>> In both machines(192.168.1.1 and 192.168.2.1) Iperf sends packets with
>>>>> 1470 byte payload. In addition, there is a 8 byte UDP header and 20
>>>>> byte IPv4 header. So according to tcpdump the whole IPv4 packet is
>>>>> 1498 bytes:
>>>>>
>>>>>
>>>>> [root@ ~]# tcpdump -i fxp0 -c 4 -v
>>>>> tcpdump: listening on fxp0, link-type EN10MB (Ethernet), capture size 96 bytes
>>>>> 11:49:18.961405 IP (tos 0x0, ttl 63, id 44836, offset 0, flags [DF],
>>>>> proto UDP (17), length 1498)
>>>>>    192.168.2.1.52428 > 192.168.1.1.commplex-link: UDP, length 1470
>>>>> 11:49:18.961459 IP (tos 0x0, ttl 64, id 37052, offset 0, flags [none],
>>>>> proto UDP (17), length 1498)
>>>>>    192.168.1.1.32284 > 192.168.2.1.commplex-link: UDP, length 1470
>>>>> 11:49:18.961473 IP (tos 0x0, ttl 64, id 37053, offset 0, flags [none],
>>>>> proto UDP (17), length 1498)
>>>>>    192.168.1.1.32284 > 192.168.2.1.commplex-link: UDP, length 1470
>>>>> 11:49:18.961485 IP (tos 0x0, ttl 64, id 37054, offset 0, flags [none],
>>>>> proto UDP (17), length 1498)
>>>>>    192.168.1.1.32284 > 192.168.2.1.commplex-link: UDP, length 1470
>>>>> 4 packets captured
>>>>> 284 packets received by filter
>>>>> 0 packets dropped by kernel
>>>>> [root@ ~]#
>>>>>
>>>>> Whole frame size is 1512 bytes.
>>>>>
>>>>> Does JUNOS include UDP(or L3 header in general) header to this
>>>>> "bandwidth-limit 10m"? If it does, shouldn't there be 0.5% packet loss
>>>>> instead of 2.5%? Or if "bandwidth-limit 10m" includes IPv4 header as
>>>>> well, the packet loss for Iperf should be
>>>>>
>>>>> 1498 - 100%
>>>>>  28 - x%
>>>>>
>>>>> ..1.9% not ~2.5%. Are my calculations wrong or how does JUNOS policer
>>>>> "bandwidth-limit" calculate this 10m bits?
>>>>>
>>>>>
>>>>> regards,
>>>>> martin
>>>>> _______________________________________________
>>>>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp