Network Switch Testing

Introduction

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 in 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:

• Pings the server to make sure it can be contacted over the network,
• Downloads (wget) the TESTFILE.ZIP from the server through it's network card (to /ramdisk),
• Checks the TESTFILE.ZIP against the file's known MD5 checksum,
• Spits out a message whether the test completed successfully or failed.

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 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 hubs offered to the public. Thus, we will ensure devices will also work at the 10BaseT rate with this hub.

Recycle Criteria

Devices to be recycled without testing

• DSL and cable modems (and DSL filters, phone cables, etc, if the store already has a few)
• DSL and cable modems with built in hub, 'internet router', or wireless
• 10BaseT hubs
• Cheap-looking little no-name-brand hubs if they are piling up at the testing station
• Cheap-looking little no-name-brand hubs if a matching power adapter can't be quickly found
• Devices with noisy or bad fans, or that appear physically damaged

Devices to leave for advanced testing

• Consumer-grade internet routers (with WAN ethernet port, not with DSL or Cable ports)
• Consumer-grade wireless access points and wireless routers
• Managed 10/100 switches with a console port that do not seem to pass testing
• Professional-looking rack mount routers, firewalls, and other network devices

Testing Procedures

Before Testing

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.

Testing a hub or switch (hereafter just called 'switch')

• Verify that the device is not to be immediately recycled by consulting the list above
• Connect power to the switch and verify it starts up (some advanced switches may take up to a minute to start up
• 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.
• Verify that the link lights illuminate on the switch for the appropriate ports.
• On the client computer run the hub test script (just type ht and press enter)
• Watch the screen as the file is transferred through the network switch
• If successful, switch both cables to other ports on the switch and repeat the test. You should test all ports (note: it may take several seconds after connecting to different ports for communications to work again. On switches, the ARP cache in the switch may still remember the computer MAC address as being at the old port location...)

Verifying a 100baseT hub operates with 10baseT devices

Note: this test is not needed on 10/100 switches, just hubs

Note: you can do this procedure before you test the remaining ports on the hub

• Connect the orange crossover network cable from the testing station's 10BaseT hub to a third port on the network hub you are testing. Verify that the port's link light illuminates on both the hub you are testing and on the testing station's 10BaseT hub. If the testing station's hub has a red link light for the port (partitioned), the hub being tested should be recycled.
• 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)
• Unplug the client computer's network cable from the hub being tested and plug it into a port on the testing station's hub. Now the network data connection will be through both hubs back to the server. Run the hub test script again. The speed should not have dropped below 750KB/s.

Background: hub vs switch

Hubs can be 10BaseT, 100BaseT, or 10/100BaseT. A hub retransmits all data it receives back out to all ports. A computer will receive the network traffic addressed to it and ignore all other traffic.

Switches understand which computers are on the network, and forward network traffic only to the appropriate port. Switches will only be 100BaseT devices.

Switches have several advantages over hubs:

• Whereas all network traffic slows down on a hub when the network is under heavy use, a switch makes direct connection between two network devices, leaving other ports free for communication. All traffic on a hub is in the same collision domain, and collisions slow down the network when multiple computers use the network at once.
• Hubs send all traffic to all ports, making it possible to intercept communications meant for another computer. Since switches send data directly between the two ports, switches are more secure.
• Switches can downgrade to slower 10BaseT speeds on some ports without affecting the speed of other ports. For example, five computers with 10BaseT connections could all access a server on a 100BaseT connection, and all could receive data at full 10BaseT speed. This strategy is also used to connect switches together using faster ports such as 1000BaseT between switches.