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@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp