This file is a compilation of the few various AppLabs text files found in the tarball. These are made as one text file for quick and easy online viewing. The text files which come with the testing programs themselves are in separate folders in the tarball. The various text files are separated with lines like: >>> BEGIN WAN WORKSHEET <<< >>> END WAN WORKSHEET <<< >>> BEGIN TTCP TEST TOOL TEXT FILE <<< >>> END TTCP TEST TOOL TEXT FILE <<< The text files included in this file are: wan_cert.txt - worksheet and testing instructions for RAID tests ttcp_test.txt tcpdump_test.txt If you have questions you can direct them to linux@applabs.com. >>> BEGIN WAN WORKSHEET TEXT <<< Linux WAN Certification Worksheet AppLabs WAN Certification Test, Revision 1.5 - JCW Tester's Name _____________________________________________ Date ______________ Section 1: Product Information Manufacturer:: ________________________________________________________________ Product Name and Model Number: ________________________________________________ Product Description: __________________________________________________________ Driver: ___________________ File size: _______________ File date: _____________ Manufacturer supplied driver: Yes No Driver found on the Internet: Yes No URL: ___________________________________ Included with Linux Distribution: Yes No Kernel: ______________________________ Loadable Module: Yes No Overall Result: Pass Fail Details: ______________________________________________________________________ Section 2: Product Setup and Installation Distributions Tested: Version: []Caldera ______________________ Pass Fail []Pacific High Tech ______________________ Pass Fail []S.u.S.E. ______________________ Pass Fail []Redhat ______________________ Pass Fail Describe Test System Hardware: ________________________________________________ Product requires modification out of the box? Yes No Notes: ________________________________________________________________________ Can the unit be modified as suggested by manufacturer? Yes No Does the unit install as suggested by the manufacturer? Yes No Connect the test unit and document what is connected: Notes: ________________________________________________________________________ Does the unit connect as suggested by the manufacturer: Yes No Notes: ________________________________________________________________________ Is a driver install script or program provided? Yes No Driver installs as suggested by manufacturer? Yes No Notes: ________________________________________________________________________ Are any additional steps required for setup? Yes No Notes: ________________________________________________________________________ Section 3: Tests Ping Functionality Ping to own address Pass Fail Ping to specific host Pass Fail Ping flood Pass Fail Traceroute Ping Functionality Pass Fail TCP Dump Functionality Pass Fail Loopbacks Functionality On-board loopback at loopback plug Pass Fail Loopback near end DSU digital Pass Fail Loopback at near end DSU analog Pass Fail Loopback at far end DSU digital Pass Fail FTP Functionality Small file from local host to remote host. Pass Fail Small file from remote host to local host. Pass Fail Large simultaneous transfers between hosts. Pass Fail TTCP Functionality Pass Fail HTTP Functionality Use http to read HTML, on remote Web Server. Pass Fail Telnet Functionality Pass Fail Cisco HDLC Functionality Pass Fail N/A Card-to-Card Functionality Pass Fail Performance Test Functionality Pass Fail Network Functionality (IP) Pass Fail Routing IP Functionality Pass Fail SECTION 4: Testing Procedures Ping Functionality Procedure: Tester conducts the following pings: Ping to own address ping localhost _or_ ping
Ping to specific host ping
Ping flood ping -f
Determination: All ping tests must be successful, otherwise, fail. If fail, check connections/settings. Traceroute Ping Functionality Procedure: Tester uses traceroute to ping as in the Ping Functionality test above. Determination: Traceroute must accurately show the route of the pings. TCP Dump Functionality Procedure: Tester calls tcpdump and redirects output into a file, then examines the file for proper information as per the tcpdump man page. Determination: the tcpdump file must contain accurate information as suggested by the tcpdump man page. FTP Functionality Procedure: Tester establishes an ftp connection between two machines and does the following: Sends a small file from local host to remote host. Sends small file from remote host to local host. Conducts large simultaneous transfers between the two hosts. Determination: All file transfers must be completed successfully. TTCP Functionality Procedure: Tester uses ttcp between the test system and a client to alternately send and receive, using various size packets and various size files. Determination: File transfer rate must be within ten percent of the manufacturer's suggested high-end transfer rate. HTTP Functionality Procedure: Tester sets up a machine as an Apache web server, a second machine as a remote client, then: Uses http to read an HTML file on the Apache server from the remote client. Determination: Html page must display properly on the client machine. Telnet Functionality Procedure: Tester makes two telnet connections between two machines: Local Host login to remote host Remote host to local host Determination: Connections must be complete in both directions. Cisco HDLC Functionality Procedure: Tester verifies the connectivity of the unit via the manufacturer's software/hardware or via a third-party piece of software. The operation of such software will vary, thus the tester must follow the instructions to: Keep-alive turned on on Cisco and it interoperates and link status is UP as reported by software. Keep-alive turned off on Cisco and it interoperates and link status is UP as reported by software. Keep-alive turned on on Cisco and interval configured to 30 seconds an link status is UP as reported by software. Determination: See the above listing for results expected according to switch status. Card -to-Card routing Functionality Procedure: Tester uses ttcp between two client systems to send data through the test system (containing two NIC cards) and with each client attached to a different NIC. Tester uses the test systems to route data between the two clients. Tester should use the same packet sizes and data configuration as from the TTCP test. Determination: Transfer rates should be similar to the ttcp results in the ttcp test above. Performance Test Functionality Procedure: Tester measures the transfer rate of packets. Rate should be at least 95% of Line Rate at packet size >= 512bytes as measured by netperf. No other applications running. Determination: If transfer rate is less than 95% of manufacturer's suggested line rate at the suggested, then the test is a fail; otherwise, pass. >>> END WAN WORKSHEET TEXT <<< >>> BEGIN TTCP TEST TEXT <<< ttcp_test.txt file for AppLabs Test Packages About the test -------------- The ttcp test shoots a file across a network connection while providing some feedback in the form of statistics. This information can be used to compare with performance statistics provided by manufacturers of network components to ensure the numbers are in the same ballpark. The test uses the ttcp program and two script files which operate the ttcp program. The scripts require ttcp to be installed and in the path and assume you are running the same version of ttcp on both ends -- some versions might use different ports. This test must be conducted between two different machines. Steps: 1. Copy the ttcp program into the path. 2. Put the ttcp script files into a directory on each machine. 3. Set the LABMACHINE environmental variable. (see below) 4. Make the testfile on the transmitting machine. 5. Run ttcp-receiver on the receiving machine. 6. Run the ttcp-transmit script on the transmitting machine. Steps Explained --------------- 1. Put a copy of the ttcp program into the path on each machine being used in the test. The ttcp program must be the same version on both machines. 2. Put the script files ttcp-receive and ttcp-transmit into their own directories on each machine. Check them for executability. 3. You must set up the LABMACHINE environment variable. To do so, execute the following command, substituting the address of the system running the reciever for the 10.10.10.1 address: export LABMACHINE=10.10.10.1 4. Create a file "testfile" to be sent during the test. The easiest way to do this is with dd and /dev/zero where "count" is however many megabytes you wish to use. This shouldn't be too large since it's better if it can fit in the cache. dd if=/dev/zero of=testfile bs=1048576 count=10 5. On the machine receiving the file, run the ttcp-receive program. It will wait a bit for a connection. 6. On the machine transmitting the file, run the ttcp-transmit program and the testfile will be sent. Monitoring the Test ------------------- Each time the file is transmitted, the ttcp program will return a set of statistics on each machine. >>> END TTCP TEST TEXT <<< >>> BEGIN TCPDUMP TEST TEXT <<< tcpdump_test.txt file for AppLabs Test Packages The tcpdump program is used to monitor packets in an IP connection. There is no true test involved other than sending output to a file and examining the data. The user is encouraged to read through the documentation for this program before using it. You'll need to get the libpcap as mentioned in the tcpdump README file before you'll be able to compile and use this program. The URLs for this and other useful programs are included in the tcpdump README file. >>> END TCPDUMP TEST TEXT <<<