Device Configuration Tool: Troubleshooting Slow Network Performance

Overview

Resolve slow network performance or collect the appropriate information to escalate the issue.

Slowness for workstations or on the network can be a challenging problem to diagnose or solve. There are several intial steps that need to be taken, however, to understand the scope of the issue and to collect information for escalation to higher tiers of support staff. This initial reconnaissance may lead to the resolution of the problem or expedite resolution efforts.

Information Gathering

The following pieces of information will need to be gathered and reviewed:

  1. What kind of connection are they using? Wired or wireless. Does the problem persist if the customer switches to the alternative, if available? Ie, using a wired connection instead of wireless.
  2. Is it all sites and services, or a specific site or service?
  3. For wired customers, does DCT show large numbers of Input or Output errors?
  4. Does the slow performance depend on time of day?
  5. Does the workstation display indications of being taxed?
  6. What protocols are being used? (eg. FTP, SFTP, HTTP, etc)

Understanding the Information

What kind of connection are they using? Wired or wireless?

The first step is to determine if they are using a wired connection or a wireless connection. Wireless connections are subject to many more sources of interference, but they eventually leave the building on a wired connection. Knowing if it is just wireless customers helps to reduce the number and types of devices that will be checked. Checking the alternative kind of connection, if available can be useful in determining the scope of the problem. For example, if a wireless connection shows poor performance, but the same machine performs well on a wired connection, it indicates a potential problem with the wireless network in that location. Likewise, if the wired connection performs poorly but wireless is good, it suggests a problem local to that jack or a particular access switch. If both are bad, it could indicate a problem with the building connection which is the common point between wired and wireless networks.

Is it all sites and services, or a specific site or service?

This step is important in determining if it's an application issue, or a more general network issue. For example, if a user is having issues entering their time in Wolverine Access, but can stream videos on YouTube, view other internal sites (such as www.umich.edu), and browse ServiceLink and use GMail without issue, this strongly suggests a problem specific to Wolverine Access. On the other hand, if all sites behave poorly, it indicates a more general problem for that users machine, building, or potentially the campus. When checking this, it's important to note all the sites checked in case the issue is escalated. If it is a specific service that is affected, it can be escalated to the appropriate application administration team via ServiceLink.

For wired customers, does DCT show large numbers of Input or Output errors?

Using a Fluke network diagnostic tool [insert link to FLUKE article] or NetDisco, determine the access layer switch and port that services the customer. Use DCT to see if that port shows a large number of Input or Output errors. Small numbers of errors (in the tens) are fine, but large numbers of errors indciate a potential switch port or cabling problem. Increasing numbers of errors indicate a port or wiring problem as well. The first step is to replace the patch cable, and if this does not help the incident should be referred to ITCom FSU to have the jack checked. Be sure to let them know the symptoms and information about port errors, especially if you are able to establish link. Collect the switch IP, port, and error count information in case the issue is escalated to another team.

Does the slow performance depend on the time of day?

Slow performance dependant on the time of day can be a clue to other external factors, such as a batch job for an application or link saturation for a building, are affecting the user.

Does the workstation display indications of being taxed?

Is there a virus scan, software updates, or other high intensity tasks slowing down the machine? If so, the problem is local and will need to be fixed at the local machine.

What protocols are being used?

Does the problem occur when the user is using a web browser? When using SFTP or FTP? Something else?

Escalation

If the problem is not resolved during the information gathering stage, it will need to be escalated to ITS Networking. The following information should be provided, and should already be available as part of the information gathering process:

  • Building/Room information
  • Connection type - wired or wireless
  • Affected user(s)
  • Machine IP address and MAC address [link to KB article]
  • Switch IP and port informaiton
  • Tests done to determine the scope of the problem, and a list of sites visited
  • When the problem occurs. The more specific, the better.
  • Any other information you think may be relative to solving the issue, or any other steps taken other than what is in this KB article
Last Updated: 
Wednesday, January 4, 2017 - 00:00