How to use the OSI Model to Troubleshoot Networks

Is your network cable plugged in? (physical)

Is there a link light on the Ethernet switch and Ethernet NIC? (data-link)

Do you have an IP address? (network)

Can you ping your default gateway? (network, testing LAN IP connectivity)

Do you have DNS server information?

Can you ping your DNS server? (network, testing IP connectivity)

Do you have a firewall configured? (network on up to application)

Can you ping the host you are trying to get to by name? (application, DNS and network WAN IP connectivity)

What format is the graphic in? Do you have a viewer for that format? (presentation)

Can your web browser open up another website? (basic application troubleshooting)

It may turn out that the graphic they were trying to bring up was a .TIFF file and they didn’t have a decoder for that type of file. Thus, this would have been a presentation error issue as the presentation layer deals with formats of graphics & files, as well as compression and encryption.
Methods of using the OSI model

I just gave you an example for using the OSI model with a “bottom up” approach to troubleshooting. There are three different ways to use the OSI model:

Bottom up – troubleshooting by going from the physical layer (layer 1) up to the application layer (layer 7)

Top down - troubleshooting by going from the application layer (layer 7) down to the physical layer (layer 1)

Divide and Conquer – in this method, you start with whatever layer you feel is most likely the cause of the problem, then move in whatever direction you feel is the more likely cause of the issue (either up or down the OSI model)

Popular posts from this blog

AD LDS – Syncronizing AD LDS with Active Directory

DNS Scavenging.