4. Reacting to a network outage

When a user comes to the network staff with a complaint of a "massive" network outage, the first step is to stay calm. Most users are rarely aware of everything going on at their table and may be exaggerating the problem. Your next step is to get the basic information you'll need for troubleshooting such as:

Reason for the complaint - what behavior did they expect and what did they get Location of the seat / PC so that you can identify the table they're connected to Name / handle and other contact info so you can call them later if you have more questions

Begin the troubleshooting with the easy stuff, followed by the obvious PC stuff, and finally the "Oh crap we have major problems" stuff:

Easy Stuff

First check the switch at their table to make sure it's powered up and the uplink light is lit and showing activity (usually by blinking). Also ask others at the table if they are having trouble - the guy playing a 32-mac Battlefield game will usually give away that there's not a core connectivity problem. But ask just in case he's a looney and playing a bunch of bots.

Obvious PC Stuff

Check the user's PC to make sure the link light is lit. Then make sure they have a valid IP address assigned via DHCP (or manually if your LAN isn't using DHCP):

Ethernet adapter Local Area Connection:


Connection-specific DNS Suffix . : asylumlan.lan IP Address. . . . . . . . . . . . : 10.90.1.140 Subnet Mask . . . . . . . . . . . : 255.0.0.0 Default Gateway . . . . . . . . . : 10.10.1.241

If your LAN is using DHCP, ask another user who is "known working" to release and renew their IP address. If that user can re-establish his IP address fine, the problem is isolated to the user's PC. I'll cover this shortly.

"Oh crap we have major problems..."

If DHCP leases are failing to renew, go to a different table and try from there. If you still get get a DHCP lease, chances are the problem is with your DHCP server. Try restarting the service and perform standard troubleshooting there.

Try pinging various machines to see if you can hit server row, the core switch and another player at a different table. If any of these fail, you might want to check for problems using the management tools on your core switch.

If you're still stumped, try rebooting the table switch, but be sure to first inform users that connectivity will be lost for a few moments.

Acting in a coordinated and consistent manner will reassure users that you are not flying by the seat of your pants. Unannounced reboots of switches and critical servers are sure to result in unhappy players who may not return to your next party.