Before you start with analyzing a problem, you need to know what kind of problems occur. Identifying the problem is the first step. In this step, it is important that you do not make any assumptions. Ask questions to the person who mentioned the problem. Is this person the only person that has this problem, or are there multiple people that have this problem? Error messages, location, certain moment of the day, device and so on are various examples of questions that you can ask.
The second step is to discover the scale. Is it a single user or a whole department or certain applications that are not working correctly? Those questions you can ask also during the identify part. As you see, asking questions before finding causes is an important step. It is a waste of time when you look for the wrong causes.
The third step is the step where most engineers start. Define the possible causes. With wireless, you need to understand that you do not only troubleshoot the wireless side. In the blog about common problems, you see a couple wire-related causes as well. DNS, DHCP, routing and switch configurations, application server, the Internet connection itself and last but for sure not least, the client. It is possible that there is a misconfiguration on the client or maybe the user itself.
The first three step you will do the troubleshooting. The questions with the people who have the problems, operating system commands (PING, TRACERT, NETSH, NETSTAT, NSLOOKUP), cable tester, check the application servers such as RADIUS, DHCP, DNS, or use protocol and/or spectrum analyzer.
After analyzing the information from the first three steps it is time to narrow it down to the most possible cause, in step four. This step is more from your own experience. Some problems you see more often than others and you know the possible cause quicker than other problems. This is more an experiential step. You cannot learn troubleshooting from books, you need to do it in the environment. So, this is why step eight is important in a troubleshoot methodology.
Step five is the step in which you create a plan of action. You know a possible cause and you need to have a solution for that, or you need to escalate it. Escalating does not mean that you are not good enough for troubleshooting, but it can be that you do not have the rights to implement the action. For example, as a network engineer you may have no access on the Windows DNS or DHCP servers that are managed by another department in your company. In that case you need to escalate it to the right department. If you can do it by yourself a plan is also needed. In some companies, you need to fill in forms for every change that you want to do.
The sixth step is the plan that you have created in step five to implement. Every time you implement something you need to verify your actions. This is the seventh step. If the problem is not solved in the seventh step you need to start over. Narrow it down to another problem, write a new plan of action (or escalate it), perform the actions and verify it again.
As said earlier, the eighth step is the most important one. The eighth step is to document everything that you did. Next time, when the same problem occurs, you can read in the knowledge base (or another place where you store all the documentation) and fix the problem faster. As said troubleshooting is a learning curve and you cannot learn it from books. During the troubleshooting, keep the OSI model always in your head. It is a good reference model for troubleshooting.
Per layer there are some tools that will be helpful. For example, if you need to troubleshoot layer 2 you cannot use a cable tester or a spectrum analyzer since those tools are for layer 1.
Operating system commands
PING, for connection or resolving DNS records.
TRACERT, TRACEROUTE, TRACEPATH for information about the nodes along the path
NSLOOKUP for sending DNS queries.
NETSH, is only for windows. Examples of NETSH is:
– NETSH WLAN SHOW INTERFACES
This command reveals all the information from the current network. Authentication and key management (AKM), encryption, channel, RSSI and data rates.
– NETSH WLAN SHOW NETWORKS
This command reveals all the visible networks that are visible for the client with the network type, encryption and authentication method.
– NETSH WLAN SHOW DRIVERS
This command reveals the drivers file of the wireless Network Interface Card (NIC). It shows the security information of the adapter as well as the PHYs supported by the adapter.
– NETSH WLAN SHOW PROFILES
This command reveals all the profiles that are installed on the local machine with the PSK when the profile use WPA-Personal or WPA2-Personal.