[j-nsp] Juniper "firewall policer" inner workings
Gabriel Blanchard
gabe at teksavvy.ca
Mon Apr 4 08:33:54 EDT 2011
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
More information about the juniper-nsp
mailing list