Cisco's eight-step troubleshooting method to fix your network

Even if you don't use Cisco equipment on your network, Cisco's eight-step troubleshooting
method can help solve your system's connectivity issues. Warren Heaton explains the method
and shares an additional tip for preventing recurrences. One of the skills a network administrator
must have is the ability to effectively troubleshoot network problems. To emphasize the
importance of network troubleshooting, Cisco has dedicated an entire exam to the topic as part of
the Cisco Certified Network Professional (CCNP) certification. Additionally, the Cisco
Internetwork Troubleshooting (CIT) course is recommended curriculum for anyone pursuing the
much-coveted CCIE certification. Although the CIT material presents Cisco’s troubleshooting
model, the same steps can be applied to just about any type of network or system failure you will
encounter.

The eight steps

The most important part of troubleshooting any problem is to divide the tasks of problem
resolution into a systematic process of elimination. Cisco has broken this process into eight
steps:
1. Define the problem.
2. Gather detailed information.
3. Consider probable cause for the failure.
4. Devise a plan to solve the problem.
5. Implement the plan.
6. Observe the results of the implementation.
7. Repeat the process if the plan does not resolve the problem.
8. Document the changes made to solve the problem.

Define the problem and gather facts

How many times have you heard this: “My computer does not work”? Which leads us to the
network administrator’s response: “Could you please be more vague?”
Often the user reporting the problem is frustrated and only knows that the computer is preventing
the completion of a task. It is the responsibility of the network administrator to find out what
aspect of the user’s machine is not working.
Handling such situations goes more smoothly when you have a good rapport with your support
personnel and users. A good network administrator can explain that more information is required
to diagnose the problem and more information must be obtained in order to quickly resolve the
problem.
Often, administrators will not receive all the information needed to thoroughly define the
problem. They must then rely on tools such as ping, trace, or a network monitor to identify the
trouble.

Consider the possibilities

After a problem has been identified, the next step is to consider all of the possible causes.
Connectivity issues can be very difficult to trace to a single point of failure. In most situations,
there are several possible causes for a network error, and the administrator should identify each
probable cause.

Create and implement an action plan

Once the network problem and possible causes have been identified, it’s time to produce a
solution. When developing a solution, it’s critical to thoroughly analyze the proposed solution
and brainstorm with your peers the potential impacts your solution may have.
Here are a few of the most important guidelines to follow when implementing a solution:
 Make one change at a time.
 Make transparent changes first. This means if there are multiple possible causes for a
problem, solve those problems that have the least impact on your users first.
 Do not create security holes when implementing your changes.
 Finally, and most importantly, always be sure you can back out of any changes you make.

Observe results and, if necessary, try another solution

Some changes may take time to trigger. Observe the results of your solution. Go back to the fact-
gathering phase and determine if your solution solved the problem. If the trouble still exists,
reference your list of possible causes and attempt to resolve the next most likely cause of the
problem.
After a problem has been corrected, the work of the network administrator is not over. Too many
times, network administrators end up solving the same problem repeatedly. The best way to
prevent this is to maintain a problem log and to update this log every time a network failure
occurs.

Solve problems before they happen

Using these eight steps to quickly and efficiently solve problems is great, but the best solution
for your network woes is to solve the problem before it affects your users. The only way to do
that is to devote time to creating baselines for your network and to continually monitor your
network for changes. In network administration, an ounce of prevention can prevent a 24-hour
shift to solve an unnecessary network failure.

Windows Tools
So my first line of defense (or troubleshooting) are built-in Windows tools.

There are a couple of basic commands to diagnose a network problem that every network admin
needs to know. Let’s get down to the nitty gritty.

You have an issue with a computer on your network. It cannot connect to the internet and doesn’t
have any network resources. The first thing you need to do is check the condition of the physical
connection i.e. the network cable. After that is secured, I jump to a command prompt and do a
IPCONFIG /all like so:
I check that the IP address, default gateway and subnet mask are all correct. If they are not, I
make my modifications and we are back online. Too bad the problems don’t usually go away
that easily.  Next up, I attempt to ping the servers by IP address using the ping command, like
so:

Now I check for DNS issues by pinging the server’s name.  If this fails, it is our internal DNS
issue and I know where to move on to.
If I get a correct response, I try to ping a website like www.google.com. That tests external DNS
resolution. If that works as well, the trouble runs deeper. I would then run a Netstat ““a and see
who is connected to my machine and determine if maybe a Trojan or virus has gained control of
it.

Everything looks clean. Now I would try pathping or tracert between the machine and the
internet to diagnose any remaining network problems. This one I will not show you as all the
output would reveal my network settings and what not. I am not looking to create more
problems!
During your tests you might conclude that another machine is using the same IP address or host
name as your desktop and causing issues. For this, I would recommend using Angry
Ipscanner.exe (found here here) to query for that IP address or the entire network to find the host
name”¦

I have been using this application for more than a decade to diagnose network problems! If you
cannot figure out what is going on and why you cannot get to the resource you are trying to, then
the issue might be network-related and has nothing to do with your machine. First, check if you
can get to the resource from a different machine.

Then it might be time to fire up Wireshark (which used to be called Ethereal, covered here for
you old schoolers). Wireshark will listen to your network adapter for all traffic and responses.
The answer is in the data but you do need to know how to read it. There are lots of good
resources online or you could always come knocking at AskTheAdmin.com with your output and
ask us to help!

How would you troubleshoot a fidgety connection? Do you have any secret commands?
Troubleshooting tips for wireless network connection problems.

1. Recheck WAN and LAN physical connections.

Physical connections are an oft-overlooked common culprit. Check all wireless access point
(AP) or wireless router ports to ensure that Ethernet cables are inserted tightly and link status
LEDs are green at both ends. If not:
 Verify that devices at both ends of each Ethernet cable are powered on and that ports are
enabled. For example, your AP may be connected to a wall port that is disabled, or the
upstream switch or modem may be off.
 Try swapping Ethernet cables to isolate a damaged cable or connector.
 Check your AP or router manual to ensure that you're using the right type of cable. For
example, Internet/WAN ports may require crossover cables.
 Connect another Ethernet-capable device, such as a laptop, to the affected AP or router
port. If link status LEDs change, the device that you just replaced may be failing link
auto-negotiation. Check port configurations at both ends and reconfigure as needed to
match speed and duplex mode.

Fig
ure 1. Check physical connections.
2. Verify the wireless adapter is installed and working properly.
It might seem obvious, but it's important to ensure the client's Wi-Fi adapter used for network
troubleshooting is enabled and ready to connect.
 When using a Windows client, select your wireless network adapter from the Network
Connections Control Panel and check to see if its status is Enabled. If not, right-click to
enable the connection. If this fails when using a laptop, look for a function key or
physical button or slider-switch to take the laptop out of airplane mode. If this fails when
using a removable client such as a USB adapter, remove or re-insert it.
 When using an Apple iOS client, use the Settings app to verify that your iPhone or iPad is
not in airplane mode and that Wi-Fi is on and ready to connect. For further iOS client
troubleshooting, see Part 2 of this series.
 On an Android client, use the Settings app in a similar manner to verify that your
smartphone or tablet is not in airplane mode and that Wi-Fi is on. For further Android
client troubleshooting, see Part 3 of this series.
 Fig
ure 2. Verify Wi-Fi client adapter is enabled.

3. Verify access point or router's network settings.

Use your wireless AP or router's administrative GUI to verify network settings for the wireless
network service set identifier (SSID) to which your Wi-Fi client is trying to connect.
 Locate the SSID that you're troubleshooting. On a basic wireless router, there may be just
one SSID, or one for each radio band (2.4 GHz and 5 GHz). On a small business or
enterprise AP, there may be several SSIDs used to segregate wireless clients and their
traffic.
  Identify the IP subnet [and, if applicable, virtual LAN (VLAN) ID] assigned to that
SSID. Upon successful connection, your Wi-Fi client should receive a local IP address
from this subnet.
 Identify the router or AP's own local IP address that should be reachable through this
subnet (and, if applicable, VLAN).
 Check your router's events log or status GUI to verify that an IP address from this subnet
is indeed assigned to your Wi-Fi client when it connects.

F
igure 3. Verify AP or router's network settings.

4. Verify TCP/IP settings.
Although we describe using Windows to manage wireless connections here, troubleshooting is
conceptually similar when using other kinds of Wi-Fi clients.
 Open the network connections control panel and select your wireless network adapter. If
the status is still Disabled, return to step 2.
 If status is Not Connected, select your wireless network's SSID and click Connect. If your
network's SSID does not appear in the list or you cannot connect to your network, go to
step 8 to debug wireless settings.
  While attempting to connect, status may change briefly to Authenticating or Acquiring
Network Address, then Connected. At that point, use Status/Support to determine the
client's assigned IP address. If the client's IP is 0.0.0.0 or 169.254.x.x, click Diagnose. If
that persists, go to step 8.
 Otherwise, if the Wi-Fi client's IP address is not in your AP or router's subnet, use the
Properties/Internet (TCP/IP) panel to reconfigure the connection to get an address
automatically and repeat step 4.

Fig
ure 4. Verify wireless client's TCP/IP settings.

5. Use ping to verify network connectivity.

Once your wireless client has a valid IP address, use ping to verify network connectivity.
Run a Command Prompt window from the wireless client's Start menu and use it to ping your
AP or router's IP address with the Internet Control Message Protocol as shown in Figure 5.
 If pinging your AP or router repeatedly fails, skip to step 6.
  If pinging your AP or router is successful, then ping any other wired or wireless LAN
client that you wish to share files or printers with. If that ping fails, then the destination
may be using a firewall to block incoming messages.
 After disabling the destination's Windows firewall, ping again. If ping is now successful,
then the firewall you disabled may also be blocking Windows network protocols.
Reconfigure the firewall to permit the traffic you want to exchange between LAN clients.
For example, re-enable the firewall and permit inbound file and printer sharing.

Fig
ure 5. Test and permit desired traffic.

6. How to handle wireless-specific problems.

If your wireless client still cannot connect, get a valid IP address or ping your AP or router, then
it's time to consider wireless-specific problems.
The wireless AP or router and client must use compatible 802.11 standards and the same network
name (SSID). Use your AP or router's admin GUI to view WLAN settings and compare them to
your client's wireless connection parameters.
 If your SSID does not appear in the Client's Available Networks list, enable SSID
broadcasts on your AP or router. Alternatively, add the SSID to your client's Wireless
Networks list, allowing devices to connect even if the SSID is hidden. Be sure to match
the SSID exactly, including capitalization.
 802.11ac, dual-band 802.11n and older 802.11a clients can connect to 802.11ac or
802.11n APs or routers using channels in the 5 GHz band.
 802.11n and older 802.11b/g clients can also connect to 802.11n APs or routers using
channels in the 2.4 GHz band.
 To connect older 802.11a or 802.11b/g clients, enable Mixed Mode and slower
modulation and coding scheme rates on your AP or router. For example, to connect to
802.11b clients, at least the 11 Mbps rate must be enabled. To connect to 802.11g clients,
at least the 54 Mbps rate must be supported. Even slow rates are needed to connect to old
clients over longer distances.
 Fig
ure 6. Check radio settings.

7. Look for a security mismatch.

If a matched wireless client and AP or router can "hear" each other but still can't connect or
exchange traffic, look for a security mismatch.
The client must support the security mode the AP or router requires: Open, WEP, WPA or
WPA2. Unless the WLAN is open (unsecured), the AP or router and client must also have (or
dynamically receive) the same keys used to encrypt traffic between them. Compare your AP or
router's WLAN security settings to your client's wireless connection properties to match them.
 If your AP or router uses WEP, set the client's encryption to WEP and match the
authentication type (open or shared). Copy the AP or router's first WEP key to the client,
translating from ASCII to hex if needed.
 If your AP or router uses WPA-Personal, set the client's authentication to WPA-PSK and
match the encryption type (TKIP). Enter the same passphrase on both devices
Remember: Capitalization counts!
 If your AP or router uses WPA2-Personal, set the client's authentication to WPA2-PSK,
match the encryption type (AES) and enter the same passphrase on both devices. If you
must support both WPA and WPA2 clients, set your AP or router to allow both TKIP and
AES encryption.
 If your AP or router uses WPA or WPA2-Enterprise, set the client's authentication to
WPA or WPA2 respectively, match the encryption type and continue 802.1X set-up in
step 8.
 Fig
ure 7. Check security settings.

8. Ensure RADIUS is working.

WPA and WPA2-Enterprise log the client into the network and deliver encryption keys using
an 802.1X-capable RADIUS server. If you do not already have a RADIUS server, consult this
tip. Otherwise, try the following:
 Reconfigure your AP or router and server with a matching RADIUS secret.
 Reconfigure your RADIUS server to accept requests from your AP or router.
 Use ping to verify AP or router-to-RADIUS server network reachability.
 Watch LAN packet counters to verify that RADIUS is being sent, or use a LAN analyzer
debug RADIUS protocol issues.
Figure 8. Ensure RADIUS is working.

9. Check for 802.1X EAP or user login problems.

If RADIUS is working but the client's access requests are rejected, look for an 802.1X Extensible
Authentication Protocol (EAP) or user login problem.
Your client must support one of the EAP types your server requires and must supply a valid
login and password, token, certificate or other kind of credential.
 If your server requires EAP-TLS, select Smart Card or other Certificate on the client's
Network Properties/Authentication panel.
 If your server requires PEAP, select Protected EAP on that panel.
 If your server requires EAP-TTLS or EAP-FAST, install a third-party 802.1X Supplicant
program like Cisco's Trust Agent on the client.
 Make sure that client and server EAP-specific properties match, including server
certificate Trusted Root Authority, server domain name (optional) and tunneled
authentication method (e.g., EAP-MSCHAPv2, EAP-GTC).
  If you are prompted to accept the server's certificate at connect time, examine the
certificate carefully, verifying issuer and identity. Never add an unrecognized or
suspicious certificate to your trusted list.
 If EAP-TLS problems persist, use a Web browser to inspect the client's certificate and
make sure the certificate is valid (e.g., not expired).
 If PEAP problems persist, use CHAP Configure to prevent Windows auto-logon and
enter a valid username and password when prompted.
 If you still haven't spotted the problem, consult your RADIUS server's 802.1X
documentation for EAP configuration and debugging hints.

Figure 9. Verify client's 802.1X/EAP settings.

10. Solving intermittent network connectivity problems.
Finally, if your wireless client connects and pings successfully, but encounters intermittent
network connectivity problems (e.g., some pings work, some fail), you may be experiencing poor
signal strength, RF interference, or disconnection caused by AP roaming.