When you engage in the Top Down troubleshooting approach, you are using the OSI reference model as a guide, and you are hoping that the problem is one of the higher layers! You are beginning your troubleshooting in the higher layers, trying to find the highest layer that is working. You see, the way the OSI reference model works, if we can determine that a particular layer works, then it is a pretty safe assumption that all the layers below it are functional. Notice I say “pretty” safe. There might indeed be problems at a lower layer that are so specific, they are not showing up in your initial evidence collection.
What is an example of a Trouble Ticket where we might immediately latch on to the Top-Down Troubleshooting approach? Well, how about this…
TROUBLE TICKET 4
Users in Subnet 101 are reporting that they can access Web content from Subnet 201, but they are unable to transfer files to or from an FTP server in that subnet.
Here we can see that a Top Down Troubleshooting approach certainly makes sense. Especially when we balance this against starting with a Bottom Up approach (covered in the next blog post). It is quite clear that we do not have a physical layer issue, since the Web connectivity would not work.



