Troubleshooting with the OSI Model Still Effective
Network technology has changed considerably since the dawn of computer inter-networking. Early commercial networks used x.25, a protocol suite for packet switching. Originally designed to carry voice traffic, x.25 remains in use today for some automated teller machine or credit card verification networks, or other applications where limited bandwidth is sufficient. In the 1970's, Ethernet was accepted as an open standard, and in 1995 transmission speed increased from 10 Mbit/s to 100 Mbit/s. Data networking solutions have made use of frame relay, asynchronous transfer mode (ATM), private lines, and virtual private network (VPN) tunneling. Mobile broadband networks use third generation (3G) or fourth generation (4G) technologies to transmit data wirelessly through the air.
As each of these technologies came into use, it became necessary to find efficient means to control them. Network monitoring tools and practices were developed, network components were seen as managed objects, and a host of support personnel learned the trade. Of significant importance to the network management technician or engineer is the OSI model. This is a seven-layer conceptual model created by the International Organization for Standardization (ISO) that still today provides a meaningful framework for network configuration and troubleshooting.
The OSI layers
Typical troubleshooting is done from the bottom up. If an application does not work, is there an underlying physical connection that is down? Is there an outage in the network? What data link or network protocols may be affected? Are there problems with any transport protocols, such as TCP, SCTP, or UDP? What about the operating system or any initiated sessions? These network issues are generally transparent to the user.
But practitioners of network management love to handle these challenges. Network engineers spend many hours preparing for industry-recognized certifications that may be vendor-specific (e.g., Cisco, Microsoft) or vendor-neutral (e.g., CompTIA). Certifications are helpful, but there is no substitute for experience. A seasoned engineer might hear about a network problem and immediately start spouting questions to localize the problem:
- When did the problem start?
- Were there any changes just prior to the problem?
- Have you seen this problem before?
- What network components are involved?
- What are the protocols?
- What are the requirements of the Service Level Agreement?
- How critical is this issue?
Despite the constant flow of changes in the industry, the framework provided by the OSI model remains a tremendous aid to network engineers and troubleshooters. While actual network architectures continue to develop in various forms, every successful network professional will have a firm grasp of these concepts.