OSI Model?

J

jardows

2[H]4U
Joined
Jun 10, 2015
Messages
2,313
Yesterday, I had to take a "network administration" test for a job I applied for. It was almost all OSI layer, IPv4 math, and IP protocol questions. Simple, basic, Net + stuff, not anything that really applies to net admin stuff. Anyway, It gets me every time I study for this stuff or take a test - the only time I have ever needed to know the OSI layers has been on tests! Outsid of being a product developer, has anyone here ever really needed to know this information?
 
Personally most of my issues i troubleshoot do happen at layer 8 the user level :). really though I do a lot of troubleshooting at layer 2 and 3.
 
Yea... what do you think people are talking about when they are discussing layer 2 and layer 3 switches, and application layer firewalls?
 
Cmustang87 said:
Yea... what do you think people are talking about when they are discussing layer 2 and layer 3 switches, and application layer firewalls?
Click to expand...
I know that, but knowing how to configure and how they function seems to be more important than knowing the list of the layers by name.
 
If you're just configuring switches and the occasional router, then understanding the layers may not seem important. However, in troubleshooting beyond that or designing an architecture, the knowledge is important. That's the difference between an administrator versus engineer.
 
jardows said:
I know that, but knowing how to configure and how they function seems to be more important than knowing the list of the layers by name.
Click to expand...

Names don't really matter anywhere, they are just labels to describe something anyway.
 
Well, I work in at an ISP. So, I deal with layer 1, 2 and 3 all day long. Normally anything over that I don't care about that.
 
A network administrator will deal with all levels at one time or another. Figuring out at which layer the problem is at is the first step to solving the problem.
That said off the top of my head I couldn't name them off.
 
OSI model gives you a foundation of troubleshooting and problem solving, and of better understanding the technology you are working with. At my previous company we built up an global VDI infrastructure environment on VMware Horizon View with over 500 VDIs with pools configurations from {floating assignment to user-assigned, automated and manual pools (dedicated VM assignments), and with persistent user profiles} on over a dozen VMware hypervisors packed to the max with 256GB RAM, quad octocore Xeons, and combination of SSD and magnetic storage. End-users no longer had desktop PCs, laptops, or thin clients on their desk; everyone (except special and legitimate functional cases) had LG zero clients. From my experience working in manufacturing buildings where original cabling was laid 10 years ago, buildings with unreliable power (due to city utilities of whatever city), layer 3 network switches (ex. simple dumb Netgear switches), life cycles of networking equipment, ... having been exposed to OSI made a huge difference.

It isn't about memorizing the OSI model as much as it is understanding it, and sure, it makes a big difference to have a real-world scenario (aka a practical application). In our environment you had to consider these kind of things when a user is experiencing problems:

  • How/from where is the user connecting to a virtual workspace/application server (laptop, desktop, thin client, zero client, Intermec Windows Mobile hand-held computer, iPad; wireless or wired connection; facility)?
  • Are they the only user affected by this problem?
  • Are users in the same department the only ones affected by this problem?
  • Are users in the same facility the only ones affected by this problem?
  • Are users within the same region/country the only ones affected by this problem?
  • Are users connecting to datacenter X the only ones affected by this problem?
  • Are users of all datacenters affected by this problem?
  • Does the symptoms of the problem affect a specific application, every application?
  • Does clearing the cache of the application have any impact?
  • Does logging in and out of the application have any impact?
  • Does clearing user customization in the application have any impact? (note: we used Epicor)
  • Has the user tried power cycling their zero client/thin client?
  • Are the symptoms of this problem occurring for just this user's profile on the VM or is it affecting all user profiles on the machine?
  • What error message are they receiving?
  • What VMware Horizon View server are they connecting to (external Internet address or internal private address)?
This list isn't complete, but is a huge part of it. From these questions I have been able to pinpoint issues from Layer 1 to Layer 7, every single layer, usually very quickly. The fault has sometimes been aging network equipment (dead ports, blown dumb switches from electrical surges, or merely the fact that a dumb switch is present can cause unwarranted packetloss/latency/drops, CAT5e/6 cables gone bad because of the plugs or somehow the cables themselves, wireless interference / wired EMI, internal private network routing, external internet routing and hops, ISP issues, someone plugging an Ethernet cable into a network drop on one side of the room and then the other end to the other side of the room), corruption in user profiles, corruption of VMs, permissions for redirected profiles, stuck/bugged application user sessions, corrupted application caches, client device needing a power cycle (outdated cache/uptime too great/firmware and configuration updates needed), power utility issues, users not connecting to the correct VMware Horizon View gateway, users mistyping their password, users not selecting the right pool / a full floating pool, users printing to a redirected printer rather than a connected or locally installed printer on their laptop/desktop PC, misconfigured thermal label printer, incorrect printer driver, needing to disable "SNMP Status Enabled" on a printer's Port Settings on the Windows Server print server, remotely pushing latest configs and firmware to zero clients (date/time/IP/other settings could be causing an issue), users (and extremely few) using RDP vs PCoIP connections (having a big impact), PCoIP APEX card issues, ... ah, I know there is much more but it has been a couple or so years since my last job. ;)

I think, I hope, you understand what I'm sharing and how understanding the OSI model and infrastructure + critical thinking and problem solving skills + application of scientific methods can go a looooooooong way to quickly identifying problems.

Divide and conquer. Narrow your "search results" in troubleshooting (is problem hardware-side or software-side? etcetera). Sometimes you have to step back and take a different approach and examine other factors (can you ping the router? DNS? external DNS? external WAN IP? well known hosts like facebook.com, google.com, 8.8.8.8, 4.2.2.3, 208.67.220.220? packetloss? high latency? can you do the same from a different facility/datacenter backwards?)...
 
Last edited:
Cerulean said:
OSI model gives you a foundation of troubleshooting and problem solving, and of better understanding the technology you are working with. At my previous company we built up an global VDI infrastructure environment on VMware Horizon View with over 500 VDIs with pools configurations from {floating assignment to user-assigned, automated and manual pools (dedicated VM assignments), and with persistent user profiles} on over a dozen VMware hypervisors packed to the max with 256GB RAM, quad octocore Xeons, and combination of SSD and magnetic storage. End-users no longer had desktop PCs, laptops, or thin clients on their desk; everyone (except special and legitimate functional cases) had LG zero clients. From my experience working in manufacturing buildings where original cabling was laid 10 years ago, buildings with unreliable power (due to city utilities of whatever city), layer 3 network switches (ex. simple dumb Netgear switches), life cycles of networking equipment, ... having been exposed to OSI made a huge difference.

It isn't about memorizing the OSI model as much as it is understanding it, and sure, it makes a big difference to have a real-world scenario (aka a practical application). In our environment you had to consider these kind of things when a user is experiencing problems:

  • How/from where is the user connecting to a virtual workspace/application server (laptop, desktop, thin client, zero client, Intermec Windows Mobile hand-held computer, iPad; wireless or wired connection; facility)?
  • Are they the only user affected by this problem?
  • Are users in the same department the only ones affected by this problem?
  • Are users in the same facility the only ones affected by this problem?
  • Are users within the same region/country the only ones affected by this problem?
  • Are users connecting to datacenter X the only ones affected by this problem?
  • Are users of all datacenters affected by this problem?
  • Does the symptoms of the problem affect a specific application, every application?
  • Does clearing the cache of the application have any impact?
  • Does logging in and out of the application have any impact?
  • Does clearing user customization in the application have any impact? (note: we used Epicor)
  • Has the user tried power cycling their zero client/thin client?
  • Are the symptoms of this problem occurring for just this user's profile on the VM or is it affecting all user profiles on the machine?
  • What error message are they receiving?
  • What VMware Horizon View server are they connecting to (external Internet address or internal private address)?
This list isn't complete, but is a huge part of it. From these questions I have been able to pinpoint issues from Layer 1 to Layer 7, every single layer, usually very quickly. The fault has sometimes been aging network equipment (dead ports, blown dumb switches from electrical surges, or merely the fact that a dumb switch is present can cause unwarranted packetloss/latency/drops, CAT5e/6 cables gone bad because of the plugs or somehow the cables themselves, wireless interference / wired EMI, internal private network routing, external internet routing and hops, ISP issues, someone plugging an Ethernet cable into a network drop on one side of the room and then the other end to the other side of the room), corruption in user profiles, corruption of VMs, permissions for redirected profiles, stuck/bugged application user sessions, corrupted application caches, client device needing a power cycle (outdated cache/uptime too great/firmware and configuration updates needed), power utility issues, users not connecting to the correct VMware Horizon View gateway, users mistyping their password, users not selecting the right pool / a full floating pool, users printing to a redirected printer rather than a connected or locally installed printer on their laptop/desktop PC, misconfigured thermal label printer, incorrect printer driver, needing to disable "SNMP Status Enabled" on a printer's Port Settings on the Windows Server print server, remotely pushing latest configs and firmware to zero clients (date/time/IP/other settings could be causing an issue), users (and extremely few) using RDP vs PCoIP connections (having a big impact), PCoIP APEX card issues, ... ah, I know there is much more but it has been a couple or so years since my last job. ;)

I think, I hope, you understand what I'm sharing and how understanding the OSI model and infrastructure + critical thinking and problem solving skills + application of scientific methods can go a looooooooong way to quickly identifying problems.

Divide and conquer. Narrow your "search results" in troubleshooting (is problem hardware-side or software-side? etcetera). Sometimes you have to step back and take a different approach and examine other factors (can you ping the router? DNS? external DNS? external WAN IP? well known hosts like facebook.com, google.com, 8.8.8.8, 4.2.2.3, 208.67.220.220? packetloss? high latency? can you do the same from a different facility/datacenter backwards?)...
Click to expand...

Thanks for the rundown. I do have an understanding of how it works, and have been troubleshooting for years. It just frustrating that a test that is supposed to evaluate my ability to be a network admin is really a test of how well I remember the OSI layer names!
 
Ya I hear ya. I remember when I took all my CCNP tests back in 2008. Cisco likes to ask those crazy multiple choice, multiple answer questions. Could be 1, 2, or 3 correct answers. And a lot of them were irrelevant to the real workplace, and I've never used some features/commands my entire career!

A few months ago I was looking for work, and a recruiter asked me to take this Network test from IKM, it was for a job with Ball Aerospace. It was actually very difficult. It had a lot of Netflow, VMWare, and Cisco Nexus questions. Like how to configure a VMWare port on a Nexus switch. I was like WTF, I had no idea never worked on that before in my 10 years of experience. I scored a 75%. And never got a response from the employer.
 
jardows said:
Yesterday, I had to take a "network administration" test for a job I applied for. It was almost all OSI layer, IPv4 math, and IP protocol questions. Simple, basic, Net + stuff, not anything that really applies to net admin stuff. Anyway, It gets me every time I study for this stuff or take a test - the only time I have ever needed to know the OSI layers has been on tests! Outsid of being a product developer, has anyone here ever really needed to know this information?
Click to expand...

In Incident Handling you have to be intimately familiar with how the models work and how communication happens, same generally for Firewall Engineers, Network Engineers, Network programmers, etc. What are sockets and ports? How does a programmer know what he is doing when he writes code to communicate over a network?
 
You must log in or register to reply here.
Back
Top