Difference between revisions of "Network Switch Testing"

From FreekiWiki
Jump to navigation Jump to search
(changed to redirect)
 
(18 intermediate revisions by 4 users not shown)
Line 1: Line 1:
== Introduction ==
+
#REDIRECT [[Network Testing]]
The network device testing station currently consists of two computers: A server and a client PC. These machines are not connected to the Free Geek network, and boot from their internal hard drives. They both run Linux.
 
 
 
The '''server''' runs httpd as a web server and has an IP address at 10.10.10.10. It has a dumb index.html homepage. The important part of this web server is it hosts a file called TESTFILE.ZIP. This is just an arbitrary file about 32MB in size. This machine boots to init 2 (command line) and doesn't need a login for operation (although if you are nice you will log into it to shut it down.) This machine is currently a Compaq mini-tower.
 
 
 
The '''client''' computer is a small-form-factor Dell desktop, which also boots to a command-line login. It's IP address is 10.10.10.11. It has a script called /bin/ht (hub test...). The script does these things:
 
<ul>
 
<li>Pings the server to make sure it can be contacted over the network,</li>
 
<li>Downloads (wget) the TESTFILE.ZIP from the server through it's network card (to /ramdisk), </li>
 
<li>Checks the TESTFILE.ZIP against the file's known MD5 checksum,</li>
 
<li>Spits out a message whether the test completed successfully or failed.</li>
 
</ul>
 
 
 
The testing station has both of these computers connected through a KVM (Keyboard-Video-Mouse switch). The client computer is on port 1, and the switch should stay set to port 1 unless diagnosing the server.
 
 
 
The network device testing station also has a 10baseT hub (3com). This is also used for testing - we want any 100baseT hubs tested and sold in the store to downgrade gracefully if a 10baseT device is connected. Many first-generation 100baseT hubs do not work with 10baseT devices at all, and this will cause problems and confusion in a mixed network. 10baseT devices such as network printers and DSL modems are still commonly used and should work on any devices offered to the public.
 
 
 
== Recycle Criteria ==
 
 
 
<h4>Devices to be recycled without testing</h4>
 
<ul>
 
<li> DSL and Cable modems (and DSL filters, phone cables, etc, if the store already has a few)</li>
 
<li>DSL and Cable modems with built in hub, 'internet router', or wireless</li>
 
<li>10baseT hubs</li>
 
<li>100baseT hubs that do not work with 10baseT (testing required)</li>
 
<li>cheap-looking little no-name-brand hubs if they are piling up at the testing station</li>
 
<li>cheap-looking little no-name-brand hubs if a matching power adapter can't be quickly found</li>
 
<li>devices with noisy or bad fans, or that appear physically damaged</li>
 
</ul>
 
 
 
<h4>Devices to leave for advanced testing:</h4>
 
<ul>
 
<li>Consumer-grade internet routers (with WAN ethernet port, not with DSL or Cable ports)</li>
 
<li>Consumer-grade wireless access points and wireless routers</li>
 
<li>Managed 10/100 switches with a console port that do not seem to pass testing</li>
 
<li>Professional-looking rack mount routers, firewalls, and other network devices</li>
 
</ul>
 
 
 
 
 
 
 
== Testing Procedures ==
 
<h4>Before Testing</h4>
 
At the beginning of the day, verify the server and client computer are on, along with the monitor. If either is not on, power it up. Check that the keyboard switch is set to port 1.
 
 
 
Log on to the client computer using Login: guest and Password: freegeek
 
 
 
The client computer should display some instructions.
 
 
 
<h4>Testing a hub or switch (hereafter just called 'switch')</h4>
 
<ul>
 
<li>Verify that the device is not to be immediately recycled by consulting the list above</li>
 
<li>Connect power to the switch and verify it starts up (some advanced switches may take up to a minute to start up</li>
 
<li>Connect the network cable coming from the server to a network port on the switch. Connect the network cable coming from the client to another network port on the switch. For right now, avoid any ''crossover'' or ''uplink'' ports.</li>
 
<li>Verify that the link lights illuminate on the switch for the appropriate ports.</li>
 
<li>On the client computer run the hub test script (just type ht and press enter)</li>
 
<li>Watch the screen as the file is transferred through the network switch</li>
 
<li>If successful, switch both cables to other ports on the switch and repeat the test. You should test all ports (note: it may take many seconds after re-connecting for the ports to communicate again on switches, the ARP cache in the switch still remembers the MAC address of the computers was on the other ports...)</li>
 
</ul>
 
 
 
<h4>Verifying a 100baseT hub interoperates with 10baseT</h4>
 
''Note: this test is not needed on 10/100 switches, just hubs''
 
''Note: you can do this before you test all the other ports on the hub''
 
<ul>
 
<li>Connect the network cable from the testing station's 10baseT hub to a third port on the network device you are testing. Verify that a link light comes on for the port on the device to be tested and the testing station's hub. If the testing station's hub has a red light for the port (partitioned), the device being tested should be recycled.</li>
 
<li>Without disconnecting the client or server cables from the hub being tested, run the hub test script again. The speed should not have dropped below 750KB/s (the hub downgrades to 10baseT)</li>
 
<li>Unplug the client computer's network cable from the hub being tested and plug it into the testing station's hub. Now the connection will be through both hubs. Run the hub test script again. The speed should not have dropped below 750KB/s</li>
 
</ul>
 

Latest revision as of 18:11, 16 September 2008

Redirect to: