This chapter is from the book
This chapter is from the book
This chapter is from the book
The Bottom-Up Troubleshooting Approach
The bottom-up approach to troubleshooting a networking problem starts with the physical components of the network and works its way up the layers of the OSI model. If you conclude that all the elements associated to a particular layer are in good working condition, you inspect the elements associated with the next layer up until the cause(s) of the problem is/are identified. Figure 6-1 shows the bottom-up troubleshooting approach.
)
Figure
6-1 A Bottom-Up Troubleshooting Approach
Bottom-up troubleshooting is an effective and efficient approach for situations when the problem is suspected to be physical. Most networking problems reside at the lower levels, so implementing the bottom-up approach often results in effective and perhaps fast results. When faced with a complex troubleshooting case, the bottom-up approach is usually favored. That is because after you ascertain that the elements associated with a particular OSI layer are in good working condition, you can shift your focus on the next layer above, and so on, until you identify the faulty layer.
The downside to the bottom-up approach is that it requires you to check every device, interface, and so on. In other words, regardless of the nature of the problem, the bottom-up approach starts with an exhaustive check of all the elements of each layer, starting with the physical layer, and works its way up. At each layer, selecting the element to start with is somewhat arbitrary because it is up to you as the troubleshooter. One way to avoid having to start troubleshooting from the bottom layer (physical layer) is to test the health of the bottom layers by using the ping or traceroute/tracert tool. A fully successful ping across a link eliminates the possibility of broken hardware (physical layer) or data link layer issues such as mismatch encapsulations or inactive frame relay DLCIs. Ping or traceroute/tracert failure would tell you that problems might exist at the lower layers, requiring investigation.
NOTE
When you are testing tools such as ping and traceroute (or tracert on Windows operating systems), you must first ascertain that those applications or the protocols they utilize are supported in the network. In other words, in certain environments, in accordance with management policies, internetworking devices drop or filter packets associated with utilities such as ping or traceroute. In such circumstances, failure of those applications can be misleading or confusing. You can verify whether those applications (or the protocols and the associated application port numbers they utilize) are supported by talking to the administrators or the network engineers. Otherwise, you must inspect the access lists on routers or firewalls.