= Connectivity Test Software = [[PageOutline]] '''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. == 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)[[BR]] 2. Create folder /var/www/ganglia[[BR]] 3. Copy folder "ganglia-webfrontend" from /usr/share to /var/www/ganglia[[BR]] 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). 5. Modify configuration file /etc/gmond.conf {{{ cluster { name ="OpenFlow Integration" owner ="ganglia_server" latlong = "unspecified" url = "unspecified" } }}} 6. Start apache {{{ /etc/init.d/apache2 restart }}} 7. Start gmond {{{ gmond }}} 8. 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)