Information gathering is the first step in the network troubleshooting methodology, which is similar to many other processes in the IT world, including the process of handling a security incident. Information gathering is also called the reconnaissance phase and it aims to obtain as quickly as possible all the relevant information that will assist you during the next phases.
The event that generated the information gathering phase is a network issue that was most likely reported by an end-user who discovered it or who was directly affected by the issue. The end-user could have reported this via e-mail, phone, or by opening a help desk ticket.
One of the first things that should occur in this phase is interviewing the affected parties and impacted users to find out the exact nature of the network incident. You should correlate these interviews with the application/device logs and error messages gathered from the affected systems. One of the first things that you need to do is isolate the issue and figure out whether the problem affects a single user (end-station) or a group of users, such as an entire VLAN or network segment.
Depending on the number of users affected, you can start the troubleshooting process at the Physical Layer or at an upper layer in the OSI reference model. For example, if you have multiple users in a VLAN/subnet and none of them are able to access a specific application, you should not begin by examining the cabling from their workstations to see if they are plugged in; instead, you should immediately move up the OSI model, as the probability of physical connectivity issues is low. Focus on the things all those users have in common from a networking perspective and this might lead to a particular switch that they are all connected to and that might be malfunctioning.
If the problem reported involves an application issue, you should try to gather some screenshots from the affected users to see how the problem manifested. Depending on the situation, you might need to walk the users through certain areas over the phone or remotely connect to their station via RDP or other terminal services to analyze the issue. If this is not possible, the network administrator or operator might have to personally go to the affected system and do some hands-on analysis in order to properly gather the necessary information.
After all of these steps are completed, you should document the relevant information gathered, including the following:
- The type of problem
- Problem description
- Which systems were affected
- How the systems were affected
- In what context the problem manifested
Possible effects of the problem on the systems affected include:
- Slow performance/response
- Data corruption
- Logon issues
- Resource access issues
- Misconfigurations
Another critical aspect you should cover during the information gathering phase is identifying the specific moment at which the problem manifested. The time of occurrence should be correlated with different network events that happened in that period, including changes made by users in different areas. This information, together with details about the symptoms and error messages, should offer a complete information set specific to this phase and should allow you to proceed to the next step in the troubleshooting process.