23 | | Simular to ping, but works at layer-2. Hoever sudo access is requiresd and, typically you'll specify your physical interface. Arping is useful for : |
24 | | |
25 | | * detecting duplicate IP addresses. The Example below shows to hosts, deliniated by MAC, reporting the same IP address. |
| 23 | Similar to ping, but works at layer-2. However, sudo access is requires and, typically, you'll specify a single physical interface. Arping is useful for : |
| 24 | |
| 25 | * detecting duplicate IP addresses. The Example below shows to hosts, delineated by MAC, reporting the same IP address. |
57 | | == jperf == |
58 | | Jperf can be obtained from the following link: http://www.softpedia.com/progDownload/JPerf-Download-154326.html |
59 | | |
60 | | PS. Jperf is simply iperf with a GUI. |
| 57 | Iperf is a defacto traffic generation and analysis tool. Iperf works in a client-server model; the iperf server recieves the iperf traffic generated by the iperf client. the iperf client will gnerate traffic for a finite duration ('-t'). See PersistentTestHostRequirments. |
| 58 | |
| 59 | Iperf supports both TCP and UDP; TCP is the default UDP is specified with the '-u' option. |
| 60 | |
| 61 | In GENI, TCP mode is useful for testing Layer-2 backbone link performance, but will attempt to consume the entire available bandwidth per the usual TCP mechanisms (some iperf versions support the '-a' option to limit the consumed TCP bandwidth). This type of test is usually coordinated in advance and typically runs for a short duration. For longer-term link-availability testing, UDP mode is typically used with a small amount of data, s specified with the '-b' option. |
| 62 | |
| 63 | Some useful options follow, see iperf's man page for more details: |
| 64 | * -B: bind to a specific interface. Useful for test hosts with multiple interfaces, allows for a unique iperf instance per test providing finer control of test start/stop and logging. |
| 65 | * -o: specify an output file |
| 66 | * -i: specify the interval to ''display'' data, Note this does not have any influence on the generated data transmission. |
| 67 | * -p: specify send/receive software port. |
| 68 | * -D: run the server as a daemon. |
| 69 | * -b: UDP requested bandwidth per second. |
| 70 | * -a: ''if supported'', limit the amount of TCP data generated by the iperf client. |
| 71 | * -d: bi-directional test. |
| 72 | |
| 73 | * UDP example, also shows port specification. |
| 74 | * UDP server (on 10.37.11.101), binds to all available interfaces, use port 5002 instead of the default 5001: |
| 75 | {{{ |
| 76 | iperf -s -u -p 5002 |
| 77 | }}} |
| 78 | * UDP client. Send 1 Mbitps of UDP to the iperf server at 10.37.11.101 on port 5002 for 60 seconds: |
| 79 | {{{ |
| 80 | iperf -c 10.37.11.101 -u -i 1 -b 1M -t 60 -p 5002 |
| 81 | }}} |
| 82 | |
| 83 | * Sending UDP traffic bi-directionally (-d) Send 50Mbps of traffic to 10.37.11.101:5002 for 30 seconds and requests the server to also send 50Mbps of UDP traffic for 30 seconds to port 5050, the iperf client binds to the local interface 10.37.11.100. test status is displayed every 5 seconds. the server was ran the same as the example above. |
| 84 | {{{ |
| 85 | iperf -c 10.37.11.101 -p 5002 -u -B 10.37.11.100 -t 30 -b 50M -i 5 -d -L 5050 |
| 86 | }}} |
| 87 | |
| 88 | === jperf === |
| 89 | Jperf provides a GUI front-end for iperf. Jperf can be obtained from the following link: http://www.softpedia.com/progDownload/JPerf-Download-154326.html |
| 90 | |