OSI Model Layer 8
A common misconception about the Open Systems Interconnection model is that it contains only seven layers, named “Physical”, “Data Link”, “Network”, “Transport”, “Session”, “Presentation” and “Application”. This is inconsistent, however, as there exists an eighth layer above “Application” commonly titled “User”:
This eighth layer must be considered when troubleshooting a network issue, as many times it can prove to be more of a common cause than the physical layer. Common causes for failures at the Eighth layer of the OSI model include ID10T errors, politic-related issues, and general stupidity.
Seeing as how the eighth layer interacts directly with the seventh layer, “Application”, an extreme problem at the eighth layer can cause problems at other layers at varying severity, depending on network security and privilege settings. Many layer 8 errors even cause failures at the physical layer, or layer 1, which is a fairly common occurrence.
Indeed, the eighth layer can be in many cases very difficult to troubleshoot, but if kept within consideration all along the process of troubleshooting other layers (e.g. paying attention to terminology in a conversion), then a layer 8 issue may reveal itself to the troubleshooter without going through all of the layers in between.
Common causes of layer eight issues are: users who think they are changing a critical setting to make something “better” or “faster” without the slightest clue about what the setting actually does, e.g. changing TCP/IP settings, a user whom unplugs a network cable for “security” then can’t connect th next day, or even users whom demonstrate the “clicking syndrome”, which causes such a wide array of problems that we couldn’t possibly list them all here.
Unfortunately, the solution to a layer eight issue is not always as easy as solving other layers: you can’t swap out a user like you can a NIC in most cases. However, documenting the problem for future reference is certainly a very recommended action to take for both you and other technicians, and in the case of repeated problems you may want to consider relaying the recorded occurrences to a higher authority.
The use of Group Policy in Windows network Domains and GConf in Linux networks may also aid in reducing some layer eight issues (but certainly not all). Examples include: keeping the user out of system settings, giving the user only permissions to access what they need to access (especially regarding write and execute permissions), and website blocking.
A few prime examples of severe cases of related OSI layer eight issues are demonstrated in these instructional videos, and may prepare an aspiring network administrator for the appearance of layer eight issues. The first video, regarding the website, demonstrates where the need for checking layer eight should have been performed prior to troubleshooting layer 7 (rebooting the webserver), while the second provides an accurate example of the “clicking syndrome”.
In conclusion, if one can take a deep breath, count to ten, and remain somewhat socially engageable during the discovery and troubleshooting process of a layer eight problem, the process will not only go smoother but will also be corrected without any injuries, damaged equipment, or loss of job position (e.g. via quitting, getting fired, or suicide). One such method pf retaining said “cool” could be to utilize the RFC-standardized RITA tool.
Everyone will experience one or more layer eight issues in their time as a network administrator, but by performing the steps outlined in this article you can not only better tolerate the issues at hand, but even prevent some possible future layer eight problems.