= 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 == 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 : * detecting duplicate IP addresses. The Example below shows to hosts, deliniated 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 == == jperf == Jperf can be obtained from the following link: http://www.softpedia.com/progDownload/JPerf-Download-154326.html PS. Jperf is simply iperf with a GUI. == 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)