The network is slow.” How many of
you out there have heard this time and time again from your users or even from
other IT professionals in the department? When I was specifically in charge of
just the “network” — connectivity to and from users, locations, and servers — I
heard this on a daily basis.
The term “network,” when it comes to information technology, is generally a loose one that can consist of anything from the server running day-to-day applications or the physical switches, routers, and cables interconnecting the infrastructure of the business. This is typically fine, unless, of course, your title actually caries the word “network.”
If you’re like me, the phrase, “the network is slow," is heard often and it becomes your job to either prove the masses of their observations or debunk them entirely. To do this I knew I needed a way to solve the riddle quickly, and with definitive proof. Let’s face it, we can tell our co-workers it’s not the network until we’re blue in the face, but unless you can prove it, no one will listen.
For a while, I chased my tail on this with elaborate software, monitoring applications, log servers, scripts, event notifications and the like. What I found was an exhausting and daunting pile of garbage to sift through each time “the network was is slow” that really never gave me the answers I was looking for or was so overly complicated that explaining it to my team usually returned blank stares of a hypnotic-like state.
When things are slow, people get cranky and they typically want answers and resolutions fast. Combing through thousands of event logs or countless pages of log files wasn’t a quick answer. Monitoring applications are nice, if you take the time to develop a true baseline weekly and monitor it daily, but even then, most monitoring applications just show you there is a problem, not the cause or source.
This brought about a second issue. As IT professionals grow their knowledge and advance in their skill level, all too often I find myself, and others, over-diagnosing some of the simplest problems. We tend to always assume the worse when a problem crosses our plate and a majority of the time it can be solved using simple methodology.
So, what is the simplest method for solving 99% of all network problems? Well, never afraid to ask for help, I called my old mentor up, who has worked on several large-scale networks, to get his advice. It was no surprise to him to hear me mention the dreaded “the network is slow” phrase, which was becoming the go-to blame for everything wrong in our department.
To my surprise, he stated that not only could he solve it for me, but he could show me within five minutes the proof I would need to determine the actual cause — all this for the price of a beer. To say the least, I was a bit skeptical. Was there some magic application I didn’t know about that network and system engineers had been using all this time? Not taking any chances, I put on my best cloak-and-dagger disguise and headed to the pub.
Upon arrival, I quietly sat beside my mentor while slowly sliding a piece of paper asking for the “secret” to diagnosing the network slowness. After a good laugh at my expense he began to explain that I’ve had the tool the entire time. In fact, it’s one of the earliest things taught in diagnosing any network issue; the problem was most of us had forgotten it.
That tool is the Open Systems Interconnection (OSI) model. The very foundation in which every network operates and the layers involved for successful operation. Let’s take a quick look at how this tool can be used to make your troubleshooting life easier. I’m not going to go into deep depth on each layer but rather give a very generic definition and the simple ways it can be checked.
Seven-layer dip
A crabby user calls up to say that the intranet is taking forever to load, thus the network is slow. Let’s get to work using the OSI model to determine if the network truly is slow, or, more than likely, if the user is the slow one.
The term “network,” when it comes to information technology, is generally a loose one that can consist of anything from the server running day-to-day applications or the physical switches, routers, and cables interconnecting the infrastructure of the business. This is typically fine, unless, of course, your title actually caries the word “network.”
If you’re like me, the phrase, “the network is slow," is heard often and it becomes your job to either prove the masses of their observations or debunk them entirely. To do this I knew I needed a way to solve the riddle quickly, and with definitive proof. Let’s face it, we can tell our co-workers it’s not the network until we’re blue in the face, but unless you can prove it, no one will listen.
For a while, I chased my tail on this with elaborate software, monitoring applications, log servers, scripts, event notifications and the like. What I found was an exhausting and daunting pile of garbage to sift through each time “the network was is slow” that really never gave me the answers I was looking for or was so overly complicated that explaining it to my team usually returned blank stares of a hypnotic-like state.
When things are slow, people get cranky and they typically want answers and resolutions fast. Combing through thousands of event logs or countless pages of log files wasn’t a quick answer. Monitoring applications are nice, if you take the time to develop a true baseline weekly and monitor it daily, but even then, most monitoring applications just show you there is a problem, not the cause or source.
This brought about a second issue. As IT professionals grow their knowledge and advance in their skill level, all too often I find myself, and others, over-diagnosing some of the simplest problems. We tend to always assume the worse when a problem crosses our plate and a majority of the time it can be solved using simple methodology.
So, what is the simplest method for solving 99% of all network problems? Well, never afraid to ask for help, I called my old mentor up, who has worked on several large-scale networks, to get his advice. It was no surprise to him to hear me mention the dreaded “the network is slow” phrase, which was becoming the go-to blame for everything wrong in our department.
To my surprise, he stated that not only could he solve it for me, but he could show me within five minutes the proof I would need to determine the actual cause — all this for the price of a beer. To say the least, I was a bit skeptical. Was there some magic application I didn’t know about that network and system engineers had been using all this time? Not taking any chances, I put on my best cloak-and-dagger disguise and headed to the pub.
Upon arrival, I quietly sat beside my mentor while slowly sliding a piece of paper asking for the “secret” to diagnosing the network slowness. After a good laugh at my expense he began to explain that I’ve had the tool the entire time. In fact, it’s one of the earliest things taught in diagnosing any network issue; the problem was most of us had forgotten it.
That tool is the Open Systems Interconnection (OSI) model. The very foundation in which every network operates and the layers involved for successful operation. Let’s take a quick look at how this tool can be used to make your troubleshooting life easier. I’m not going to go into deep depth on each layer but rather give a very generic definition and the simple ways it can be checked.
Seven-layer dip
A crabby user calls up to say that the intranet is taking forever to load, thus the network is slow. Let’s get to work using the OSI model to determine if the network truly is slow, or, more than likely, if the user is the slow one.
- Layer 1: The physical layer — This is simple. It’s the physical hardware. So how do we rule this out? Is the network cable plugged in at both ends? Is everything powered on?
- Layer 2: The data layer — This is the layer transferring the bits and bytes, checking for errors and handling media access. A quick check to see if there are network lights at both ends can rule out the basic issues with this layer. Even a basic user can tell you if there are pretty lights on the phone cable–looking thing on the back of the computer.
- Layer 3: The network layer — This layer is in charge of getting the data from point A to point B through all of the stops along the way. Run a ping to the user complaining and vise versa. If it returns results, then you’ve confirmed that the networking layer is in fact working at both ends. Guess what? In just a few minutes, you’ve ruled out the basics of it being a network issue. There is much more depth to these layers in the OSI model, and problematic network devices or cables can still be the cause, but remember, we’re out for the quickest and easiest answer first. The last thing we want to do is start rebooting equipment because one user called screaming “EVERYONE” and “EVERYTHING” is slow. This may be sufficient enough evidence to take to your superiors or colleagues but typically it’s not, so let’s continue.
- Layer 4: The transport layer — This layer is responsible for getting the data to an application and in all definitions is still considered the network layer, but begins crossing over into the application layers. You can see by that why we can pretty much rule out the network as being the cause of the slowness at this point. Yep, I know, it still could be a corrupt stack or a number of other things, but remember, simple first and complex later. Try these simple tests: ping the local host 127.0.0.1, ping the gateway setup on the machine and, lastly, ping a local server. If they all pass, then you passed the transport layer.
- Layer 5: The session layer — This layer takes care of telling an application when to open and close a connection. Again, it's not much on our network side, since we already determined that the data got from point A to point B. If the application isn’t smart enough to say how long to hold the connection open, that’s not our problem.
- Layer 6: The presentation layer — This is the layer where you can tell your application developers it’s their fault since this layer deals with how code, to and from an application, is formatted. If certain portions of the page just aren’t loading or are loading with error, that would be the application itself having issues.
- Layer 7: The application layer — Finally, our last layer, the application layer, is where things like FTP, email, or your browser operate. Can the user get to other websites? Does the website open fine with a different browser?
The above
was just one simple example of a typical “the network is slow” situation, but
in reality the same logic can be applied to so much more, such as mail-flow issues,
file-transfer issues and even shared-drive connectivity using simple tools such
as ping, nslookup, tracert and your own eyes and ears (looking for the obvious
and listening to what the actual problem is from the user). If you aren’t
already doing so, I highly suggest integrating the OSI model into your everyday
troubleshooting of network problems.
Published By
S.G.Godwin Dinesh.MCA
Sr.System Administrator
No comments:
Post a Comment