Network Instrumentation: Sniffing, Simulating, and Sampling

All networks have faults.  It’s part of an operational network.

Knowing which faults will affect your business and when is key to being a network professional.  That’s why network instrumentation is important both from a business level and a technical level.

There are three different methods to instrument a network: Sniffing, Simulating, and Sampling.

Sniffing

Sniffing involves looking at individual packets as they pass through a network analyzer.  This type of instrumentation is valuable for seeing protocol problems or looking at specific fields inside specific packets.

If a computer cannot get a DHCP IP address, it may be beneficial to try sniffing the connection to determine what the problem is.  It will show the transmitted DHCP request, and you can then see if a response is received or not.

Pro: Deep packet level inspection.

Con: Only looks at packets passing through one interface at a time.

Usage: Typically employed ad-hoc.

Training: Must understand how network protocols interoperate.

Simulating

Simulating involves creating a simulation of the event you are trying to debug and watching operational characteristics of the simulation.

If you simulate an HTML transaction from the server’s console (ie: no network involved) and it responds quickly, but the same HTML transaction responds very slowly from a remote network, that creates proof that the network is causing the slowdown for the HTML page.  No matter what performance improvements are done on the server, it won’t help resolve the problem.

Pro: Typically quick and easy to deploy.

Con: Limited ability to see WHERE the problem lies, or WHAT is causing it to occur.

Usage: Typically employed ad-hoc.

Training: Little or none required.

Sampling

Sampling involves querying the network for performance characteristics on a regular basis.  This can allow for correlation between a simulation and the root cause of the issue.

In the former example of the slow loading HTML page, if it has been determined that the network is causing the slowdown, it will need to be determined where in the network the slowdown is coming from and what is causing it.

If all of the network links are sampled for performance information on a regular basis, it will be easy to look at the performance of each link utilized in the transaction to determine if errors or over-utilization caused the performance problem.

Pro: Can determine the exact location of problems and specific cause.

Con: Typically requires a great deal of deployment effort.

Usage: Continuously monitors network conditions.

Training: Requires SNMP knowledge as well as specific device MIBs and OIDs.

These three troubleshooting methodologies disclose different types of information to be disclosed about a networks’ operation.

Make sure you choose the right tool to solve the problem or you may be stuck looking at the problem from the wrong angle and not be able to get resolution in any reasonable timeframe. 

Advertisements

Tags: , , ,

4 Responses to “Network Instrumentation: Sniffing, Simulating, and Sampling”

  1. gavincurtis Says:

    It’s true. They have to recalibrate it I think every 3 months. And you have the right to see the radar reading for yourself.

  2. thomazchamberlain Says:

    Which approach is the most popular? Also, for simulating, just thought I’d comment that I think a pro is that you can easily see where an error is through debugging or a well developed environment. I use OMNeT++ at the moment and outputs a lot of good verbose insightful text when there is an error, includes diagrams too. I enjoyed your post a lot, thanks.

  3. thomazchamberlain Says:

    Also in Simulation, for training, surely a lot is required, such as object orientated programming and low-level networking knowledge.

  4. pathsolutions Says:

    I can’t say that any approach is “popular”, as there’s a right tool to use for trying to solve each type of problem.

    Simulating is limited in value because it can only confirm that a problem exists, and sheds very little light into WHERE or WHY the problem occurred.

    Simulation is like commuting to work inside a windowless car. You know how long it took to get to the office, but you have no idea why it was so bad.

    That’s why you typically need to see what the network infrastructure is doing (roads & interchanges) so you can quickly determine that there’s a traffic jam at a particular intersection, or road construction.

    Most people who want to do simulation don’t want to have to learn programming languages — they just need to solve the problem that occurs in their network. The less training a solution requires, the better the solution is for the end user.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: