Posts Tagged ‘snmp’

Green-Running Software

January 15, 2010

Saving money by reducing the number of servers in your infrastructure makes natural sense.

The next step that needs to be considered is green-running software.  This is software that scales incredibly well for any size of organization, and also does not require “big iron” to run.

If you have software that requires a dual-processor environment with 2gigs of RAM and a large disk array, it will cost you twice as much to operate as one that fulfills the same needs yet only requires one low-powered CPU and a gig of RAM.

This becomes even more important if the software requires remote agents to be deployed across the network, each agent taking a measured amount of resources to operate (CPU, RAM, disk space, air-conditioning).

Strong consideration should be given to the solution that requires less maintenance, less hardware, and less footprint on the earth, as it will save far more than money in the long-term:  Your sanity.

Flying Blind on Your Network

November 30, 2009

Many network administrators are satisfied with a limited view of their network.  They ping their routers and switches and configure utilization monitoring of their WAN links and that’s as far as they go.

What’s terrible is that they paid for some really nice enterprise-grade switches and routers that have some serious smarts built in.  Too bad they aren’t getting the full value out of these devices.

The problem lies in the fact that the “smarts” for these devices are trapped inside the SNMP agents and require a lot of programming & configuration to extract the information, then you have to do some manual analysis to make sense out of the information.

This is what frustrated me a long time ago.  I knew that the routers & switches in my network new where the problems were, but getting them to disclose this information took a lot of work and thinking.

If only there was a solution that would disclose the information in a useful, plain-English format…

Network Instrumentation: Sniffing, Simulating, and Sampling

March 19, 2008

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. 

“There’s gold in them thar hills!”

February 21, 2008

As I drive down highway 101 through Silicon Valley, I look at the buildings around me and think about the switches and routers running each company’s network.  They each are continuously collecting statistics about their operation, yet nobody who works for the companies have any knowledge of these health indicators until something crashes.

Most network switches and routers support SNMP, but very few companies are able to gain any benefit from this capability.

There are three main reasons for this:

  1. Training required to understand how SNMP works
  2. Research required to determine which specific OIDs should be monitored
  3. Massive amount of bugs that exist in device SNMP implementations

Many network engineers never achieve understanding of SNMP due to its complexity.  They are tasked with a multitude of business driven projects, but are rarely able to focus on improving their network’s management infrastructure so their network runs smoother.

Once SNMP as a technology is understood, one would need to determine which MIB files a specific device running a specific OS version supports.  Then, the OIDs from ASN.1 formatted MIB files need to be determined.  Even with a MIB browser, it can still be difficult to determine which variable is going to provide the information you want.  (Gaaaacckkk!!!  Too many three letter acronyms!)

Now that you know which variables to query, you run straight into the bugs that exist in SNMP.  Various equipment manufacturers have taken liberties with the SNMP standards to their benefit.  Sometimes it’s as simple boastful marketing, like “Yes, we do currently support the BRIDGE-MIB, but it’s going to be released in a future release.”  (ie: they don’t current support it, but they’re saying they do).

Sometimes there are bugs that at best make your job tougher, and at worst crashes the box.

Occassionally there are manufacturers who decide that they don’t want to fully support a MIB the way it’s defined and they change the rules to suit their own needs.

With all of these difficulties, its no wonder that more companies have difficulty getting valid information on their network.