wiki:ConnectivityTesting

Version 11 (modified by jwilliams@bbn.com, 14 years ago) (diff)

added iperf examples

Connectivity Test Software

DRAFT NETWORK TOOLS AND CONFIGURATION FOR TESTS BETWEEN GPO LAB AND CAMPUSES

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.

traceroute

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 10.37.33.101
traceroute to 10.37.33.101 (10.37.33.101), 30 hops max, 40 byte packets
 1  probe1-vlan3733.rutgers.dataplane.geni.net (10.37.33.101)  32.200 ms  32.250 ms  32.287 ms
[jwilliams@argos ~]$

tcpdump

Useful for capturing and analogizing network traffic. Documentation and download from http://www.tcpdump.org/.

arping

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 10.37.5.101 -I eth7
    ARPING 10.37.5.101 from 10.37.5.100 eth7
    Unicast reply from 10.37.5.101 [00:0C:29:9D:65:D7]  0.900ms
    Unicast reply from 10.37.5.101 [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. the example below shows the GPO's MAC showing up in the NLR's Boston switch but not NLR's Seattle switch, which helped diagnose the problem.
    # display our MAC
    [jwilliams@wyverley ~]$ /sbin/ifconfig eth3 | grep HWaddr
    eth3      Link encap:Ethernet  HWaddr 00:0C:29:40:45:1D  
    
    #generate layer-2 traffic from this MAC
    [jwilliams@wyverley ~]$ sudo /sbin/arping -I eth3 10.37.16.90
    ARPING 10.37.16.90 from 10.37.16.100 eth3
    
    #NLR's Boston switch - shows our MAC:
      vlan   mac address     type    learn     age              ports
    ------+----------------+--------+-----+----------+--------------------------
    * 3716  000c.2940.451d   dynamic  Yes          0   Gi9/2
    * 3716  001b.902e.f4ca   dynamic  Yes         60   Te1/2
    
    #NLR's Seattle switch - does NOT show our MAC:
      vlan   mac address     type    learn     age              ports
    ------+----------------+--------+-----+----------+--------------------------
    * 3716  3333.0000.0016    static  Yes          -   Switch,Stby-Switch
    

iperf

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 10.37.11.101), 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 10.37.11.101 on port 5002 for 60 seconds:
      iperf -c 10.37.11.101 -u -i 1 -b 1M -t 60 -p 5002
      
  • 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.
    iperf -c 10.37.11.101 -p 5002 -u -B 10.37.11.100 -t 30 -b 50M -i 5 -d -L 5050
    

jperf

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

packETH

  • 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.

Ganglia

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
    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"
            }
    

VLC

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.

FROM STREAMING SERVER (CLI)

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

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

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

vlc -vvv udp://@:abcd --sout file/ts:GpENI.mov 

OR

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.

FROM STREAMING SERVER (GUI)
  • 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
FROM CLIENT
  • 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.

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

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

FROM CLIENT
vlc -vvv udp://@:abcd

NB. If Xserver fails, try

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

OR

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

VLC teleconferencing using a webcam

FROM STREAMING SERVER
  • 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
FROM CLIENT
vlc -vvv udp://@:abcd

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