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