Network Troubleshooting

Revision as of 11:39, 5 November 2009 by Christopher Hunt (talk | contribs) (Added GPUPDATE /FORCE; reorganized "Information to get in ticket")

See also

General steps & Important Questions

  • Has user checked and unplugged / reseated the network cable?
  • Find out the user's IP address. See cheatsheet below to see what various IP addresses mean.

INFORMATION TO GET IN TICKET. If you don't get this information, we probably can't fix the person's problem.

  • IP address
  • Name and location (building, room #).
  • Make sure we have their extension or cell # so we can call back.
  • Jack ID (it’s on a silver or white tag on the jack, something like "A-0-12").

Other information that can also help:

  • Is just one person having a problem, or are multiple people losing connectivity? Is a whole building down?
  • MAC address, and the result of running the "arp -a" command.

Re-map network drives on a PC

Sometimes faculty or staff computers' network drives get disconnected.

Run the command gpupdate /force and reboot the computer. The network drives will be there after restarting.

Multiple computers having connection issues


  • If any of the computers sharing a hub connection is not registered on the network, it's possible that all of the computers under that hub will be kicked back into registration. Register all computers on the network at the same time.
  • The hub itself must also be registered, or the computers under it won't be able to get valid IPs. If computers under a hub are getting 169 IP addresses, check whether the hub is registered.

==> How to register a hub?

Rogue Servers and/or entire building losing connectivity

  1. Note that one person calling with connection issues doesn’t mean the whole building is down. Ask the customer if anyone else is having the same issue. Generally we need a few calls to consider the issue to be building wide. Check arp -a in cmd, routers usually have an ip similar to
  2. Talk to someone in SR immediately. Also make a ticket assigned to SR.
  3. If this happens after 5pm, check “SNS After Hours” (it’s a Public Folder/Calendar in Outlook) and call the person listed there. Be prepared to give all the information you would put in a ticket. Still make a ticket and indicate whether you have contacted someone about the problem.

Decoding IP addresses

We can get a little information about the computer's network status by looking at the first two sections of its IP address.

  • 140.233... Computer should have a normal connection.
  • 172.17 is the registration subnet. 172.19 is the penalty subnet; 172.18 is the quarantine subnet; 172.16 is connected to midd_secure; 172.20 is midd_unplugged.
  • 169... Computer can’t find our DHCP server. See specific OS steps to clear any static-IP settings and flush DNS.
  • 192... or 10… (BAD addresses for on-campus, may be OK for off-campus, see footnote [1]). May indicate a manual IP address or rogue DHCP server. Create a new location, reboot. If it still gets a 192… or 10… IP address, there may be a rogue DHCP server in that subnet/area. See above.
  • Other messages or unclear symptoms - Invite the customer to LIB202 to see if the problems persist in another location.

Using the Fluke NetTool

The Fluke NetTool is a small automated device that can easily test network jacks and cables. For details see: Using the Fluke NetTool

  1. <sup>Some off-campus college houses are supposed to have 192 or 10 addresses. Knowledgebase has a list of off-campus locations.</sup>
Powered by MediaWiki