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

Mon Apr 4 08:29:23 EDT 2011

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
>>
>
>