Connectivity Test Software


Below are a few network tools currently supported by the GPO Lab for testing purposes. Should your campus decide to test with the GPO, please note the tool, and its respective configurations (NB. These configurations were tested on Ubuntu 10.04). The statistics obtained will be available to the public via our monitoring web-server and will prove effective in determining the operational status of GENI connections.

For a template for informing a campus of requirements of a test host to support this testing see PersistentTestHostRequirments.


For GENI, this is used to verify that the route configuration is correct over a GENI backbone connection, which should be a single broadcast domain. I.E., a single hope should be displayed. For example, the GPO's connection to Rutgers via I2's ION service only has one hop.

[jwilliams@argos ~]$ traceroute
traceroute to (, 30 hops max, 40 byte packets
 1 (  32.200 ms  32.250 ms  32.287 ms
[jwilliams@argos ~]$


Useful for capturing and analogizing network traffic. Documentation and download from


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 :

  • detecting duplicate IP addresses. The Example below shows to hosts, delineated by MAC, reporting the same IP address.
    [jwilliams@carthage ~]$ sudo /sbin/arping -I eth7
    ARPING from eth7
    Unicast reply from [00:0C:29:9D:65:D7]  0.900ms
    Unicast reply from [00:16:B9:CF:FC:40]  30.330ms
  • generating layer-2 traffic to a given IP address. This allows for switches's MAC-port tables to be inspected for your known path to identify a problem.


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.

Iperf supports both TCP and UDP; TCP is the default UDP is specified with the '-u' option.

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.

Some useful options follow, see iperf's man page for more details:

  • -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.
  • -o: specify an output file
  • -i: specify the interval to display data, Note this does not have any influence on the generated data transmission.
  • -p: specify send/receive software port.
  • -D: run the server as a daemon.
  • -b: UDP requested bandwidth per second.
  • -a: if supported, limit the amount of TCP data generated by the iperf client.
  • -d: bi-directional test.
  • UDP example, also shows port specification.
    • UDP server (on, binds to all available interfaces, use port 5002 instead of the default 5001:
      iperf -s -u -p 5002
    • UDP client. Send 1 Mbitps of UDP to the iperf server at on port 5002 for 60 seconds:
      iperf -c -u -i 1 -b 1M -t 60 -p 5002
  • Sending UDP traffic bi-directionally (-d) Send 50Mbps of traffic to 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 test status is displayed every 5 seconds. the server was ran the same as the example above.
    iperf -c -p 5002 -u -B -t 30 -b 50M -i 5 -d -L 5050


Jperf provides a GUI front-end for iperf. Jperf can be obtained from the following link:


  • packETH is a packet generator and can be used to generate traffic such as LLDP packets. On Debian distributions (like Ubuntu), packETH can be installed from the package manager. This test simply verifies LLDP connectivity between OpenFlow switches

  • The source computer installs packETH and generates these packets to the destination host. packETH has a self explanatory interface at the receiving end, the host simply runs tcpdump to collect the statistics.


Note: We have installed the monitoring server in the GPO lab, and unless you intend to run your own server, you need only install the ganglia client (See section below: On the system(or systems) which runs the Ganglia client)

On the system which runs the Ganglia server, do the following:

  1. Install gmetad, ganglia-monitor (from package manager)
  2. Create folder /var/www/ganglia
  3. Copy folder "ganglia-webfrontend" from /usr/share to /var/www/ganglia
  4. Modify/add the following lines as necessary, in the configuration file /etc/gmetad.conf:
       data_source "ganglia_server" localhost
       data_source "ganglia_client_1" ganglia_client_1_ip
       data_source "ganglia_client_2 " ganglia_client_2_ip
       gridname "GPO Lab"
       setuid_username "ganglia"

Where ganglia_server is the hostname of your ganglia server, and ganglia_client_x and ganglia_client_x_ip are the respective names and IP addresses of your ganglia clients (i.e. the systems which will run the ganglia client daemon).

  1. Modify configuration file /etc/gmond.conf
    cluster {
    	name ="OpenFlow Integration"
    	owner ="ganglia_server"
    	latlong = "unspecified"
    	url = "unspecified"

  1. Start apache
    /etc/init.d/apache2 restart
  1. Start gmond
  1. Start gmetad
    service gmetad restart

On the system(or systems) which runs the Ganglia client, do the following:

  1. Install ganglia-monitor (from package manager)
  2. Modify /etc/ganglia/gmond.conf on all client systems:
    cluster {
    	name ="OpenFlow Integration"
    	owner ="ganglia_client_x"
    	latlong = "unspecified"
    	url = "unspecified"


For all tests, we assume a client/server paradigm, and that VLC is installed

Generating traffic with VLC

For this test, the video server streams UDP packets to the client who stores the stream in a file (Perhaps for later viewing). This test primarily analyzes performance statistics (using tcpdump) rather than viewing the stream on the client side.


The command below assumes that the server terminal is currently pointing to a directory with file "" This file will be streamed to the given destination IP address and port address with the specified time-to-live of 7.

vlc -vvv --sout '#std{access=udp{ttl=7},mux=ts,dst=a.b.c.d,port=abcd}'

The client receives contents of the stream (from port abcd) and stores it in a file named

vlc -vvv udp://@:abcd --sout file/ 


vlc -vvv udp://@:abcd 

If you would simply like to use vlc to view the stream, use tcpdump to save all packets destined to a given IP address, via a given port number, in a file named "statistics."

/usr/sbin/tcpdump -nnvvS src a.b.c.d and dst port abcd > statistics

Viewing the VLC stream via the GUI

This test is strictly for decorative purposes. For this reason, the received stream will be displayed at the host's terminal. Please note that, due to latency constraints on the streamed frames, DO NOT be disappointed if the resulting video is not HD quality.

  • Select Media > streaming
  • Add streams to play-list
  • Select stream > Next > check Display locally (should you choose to view stream locally) > "File=UDP" > Add
  • Specify destination IP address and destination port, and ensure "activate transcoding" is unchecked
  • Select next > stream
  • Select file > open network stream > check UDP/RTP > Port=abcd
  • Optional "Customize=udp://@:abcd" > OK
  • NB. Ensure your firewall does not block access to UDP traffic on port abcd

Viewing the VLC stream via the CLI

This test is strictly for decorative purposes. For this reason, the received stream will be displayed at the host's terminal. Please note that, due to latency constraints on the streamed frames, DO NOT be disappointed if the resulting video is not HD quality.

vlc -vvv --sout '#std{access=udp{ttl=7},mux=ts,dst=a.b.c.d,port=abcd}'

The line above assumes the file "" is to be streamed from the server to the host with an IP address of a.b.c.d, via port abcd

vlc -vvv udp://@:abcd

NB. If Xserver fails, try

vlc --no-x11-shm --no-xvideo-shm --no-glx-shm vlc -vvv udp://@:abcd 


vlc --no-x11-shm -vvv udp://@:abcd

VLC teleconferencing using a webcam

  • Install ffmpeg
  • Ensure webcam is disconnected and check to see the audio and video drivers in use (if any)
    ls -s /dev/audio*
    ls -s /dev/video*
  • Plug the webcam and run the two commands above to see the new video and audio drivers in use
  • In vlc, you will need to know the card and device number
  • In vlc, go to media > streaming and select "capture device"
  • video name = /dev/video0 (this is the value obtained from running the ls -s /dev/video* cmd)
  • audio name = hw:1,0 (where hw:x, y st x is the card number and y is the device number)
  • You can do UDP streaming only with TS type codec
  • Below "Transcoding options" Video - H.264 + AAC (TS) gives best resolution but you have to install "mpeg aac audio" for the audio to work
  • I used mpeg-2 + mpga (TS), but the video quality is not close to HD quality
vlc -vvv udp://@:abcd

NB. TO RUN SMOOTHLY specify RTP protocol > activate transcoding > video H.264 + AAC (TS)

Last modified 9 years ago Last modified on 07/02/15 16:46:39