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

[Ben Dale]

Without "filter-specific", applying a single policer to multiple interfaces will usually result in the policer aggregating throughput from all interfaces it has been applied to in order to determine whether your bandwidth-limit has been met.  

On 04/04/2011, at 10:29 PM, Martin T 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
>>> 
>> 
>> 
>