Troubleshooting networking using the OSI model

[ajay]

When troubleshooting networking it is always sensible to approach the problem from the perspective of the OSI model. The OSI, or Open System Interconnection, model defines a networking framework for implementing protocols in seven layers. The beauty of this model is the fact that you can individually troubleshoot every layer using simple methods. I suggest working from layer 1 upwards until you find the problem.

Physical, Layer 1 : This layer conveys the bit stream - electrical impulse, light or radio signal -- through the network at the electrical and mechanical level. It provides the hardware means of sending and receiving data on a carrier, including defining cables, cards and physical aspects. Fast Ethernet, RS232, and ATM are protocols with physical layer components.

I always start here to make sure that I don't waste time making things over complicated. If there are no lights on the network card, chances are that the cable is broken of there is a hardware failure on the network card itself. You can use cable testers to check cables, or use some common sense when swapping things round to isolate the cause of the problem. Making sure your operating system can see the hardware (and shows that it is functional) is also covered at this layer.

Data Link, Layer 2 : At this layer, data packets are encoded and decoded into bits. It furnishes transmission protocol knowledge and management and handles errors in the physical layer, flow control and frame synchronization. The data link layer is divided into two sublayers: The Media Access Control (MAC) layer and the Logical Link Control (LLC) layer. The MAC sublayer controls how a computer on the network gains access to the data and permission to transmit it. The LLC layer controls frame synchronization, flow control and error checking.

Most problems at this layer can be troubleshooted with the arp command (in windows anyway). MAC addresses are supposedly globally unique to a device, but some people like to play around which can cause problems (google for arp poisoning / spoofing). Using 'arp -a' will show you which MAC addresses are mapped to which IP addresses locally which is sometimes helpfull. You could also setup a network sniffer to look at the frames being sent across your hubs / switches.

Network, Layer 3 : This layer provides switching and routing technologies, creating logical paths, known as virtual circuits, for transmitting data from node to node. Routing and forwarding are functions of this layer, as well as addressing, internetworking, error handling, congestion control and packet sequencing.

This is a massive area to cover in a brief tutorial. It covers the routing protocols (rip1 and 2, ospf, igrp and a few others) as well as the routed protocols (most notably IP) . You can troubleshoot IP with icmp packets. Utilities like ping and tracert use icmp packets to get responses back from networked hosts.Packet sniffers can be setup to look at IP packets travelling across your hubs / switches in the same way as you would look at frame headers.

The 'route print' command will show you your routing table in windows. Every other operating system will have commands to show the routing table (in IOS it would be 'sho ip route'). Common problems at this layer will be things like duplicate IP addresses on your network.

Transport, Layer 4 : This layer provides transparent transfer of data between end systems, or hosts, and is responsible for end-to-end error recovery and flow control. It ensures complete data transfer.

Most of the troubleshooting here would be done with a packet sniffer. TCP is used with IP as a means to ensure that the data within the packets is sent and received without any loss. If there is an error, packets are re-sent (it would be worth googling tcp packet header structure) with the correct sequence number so that no data is lost (it ensures complete data transfer). You can use packet sniffers to examine the tcp/udp packet headers to see what is happening at layer 4.

Session, Layer 5 : This layer establishes, manages and terminates connections between applications. The session layer sets up, coordinates, and terminates conversations, exchanges, and dialogues between the applications at each end. It deals with session and connection coordination.

The most likely thing you would be troubleshooting at this layer would be netbios over tcpip. Windows has some very useful utilities like nbtstat and the group of 'net' commands which will help you. Common mistakes are that people forget to install 'file and printer sharing' and 'client for microsoft networks' under Win9x operating systems and then wonder why they can't map drives or share folders. Other protocols like DNS, LDAP (this is used for most of the active directory replication), NFS, SQL, RPC and XWindows are also things that would be troubleshooted at this layer.

Presentation, Layer 6 : This layer provides independence from differences in data representation (e.g., encryption) by translating from application to network format, and vice versa. The presentation layer works to transform data into the form that the application layer can accept. This layer formats and encrypts data to be sent across a network, providing freedom from compatibility problems. It is sometimes called the syntax layer.

This layer looks at things like JPEG, MPEG, MIDI, QUICKTIME and other files of the same nature. Most of your troubleshooting will be with the applications that create them (at layer 7) but be aware that you can hex files to look at the structure and change them.

Application, Layer 7 : This layer supports application and end-user processes. Communication partners are identified, quality of service is identified, user authentication and privacy are considered, and any constraints on data syntax are identified. Everything at this layer is application-specific. This layer provides application services for file transfers, e-mail, and other network software services. Telnet and FTP are applications that exist entirely in the application level. Tiered application architectures are part of this layer.

If all of the other layers are working and have been tested, then this is usually just a matter of applying patches to software or reinstalling. Everyone probably has experience troubleshooting problems in windows. Telnet is an excellent tool for connecting to virtually any port to check to see if the above layers are functioning properly.

This document was not written as a step by step guide to setting up a network, nor was it designed to give detailed instructions on how to troubleshoot each layer. There will be many utilities out there to help you find problems that aren't covered by the scope of this document. Also, google is a wonderful thing. I suggest you all use it. Please just look at this and keep it in your head as a model of how to breakdown networking into easily manageable layers so you can identify and fix problems in a more systematic way. If I have left anything major out please let me know.

Thanks

_________________________

[William Robert]

Here you have shared very informative post, Nothing is missed to me.