Archive for February, 2008

“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.


Initial Frustrations

February 21, 2008

So why did I feel the need to found a company? 

I’ll share a bit about myself first to set the stage.

I started my career in networking in 1989 working as a desktop technician for a small semiconductor company.  The company was growing rapidly and I was  given the responsibility for 12 Novell v2.10 servers and the co-ax based ArcNet network.

Tools to help fix problems were all home grown.  There were few hardware tools and even fewer software tools.

The industry slowly started to converge on Ethernet as the dominant standard with ArcNet and Token Ring dropping into obsolesence.  This helped a lot of engineers because tools for Ethernet started to florish.

SNMP standards for monitoring Ethernet were established and network equipment manufacturers started to build management into their devices because they realized they could make more profits by including management software along with their devices.

Skip forward a number of years to the dot-com boom: Companies created a new set of network management tools, but they were very poorly designed (“we’ve got to be first to market no matter what!”).  They solved problems, but were very cumbersome to use and required gobs of memory.

What’s worse is that they didn’t always work well, and frequently frustrated the people who needed quick answers to complex problems.  Network management systems were far too complex to operate, and barely did their job.  Network engineers also needed to learn a variety of complex technologies to operate the system.

This is where my initial frustration grew from.  Working as a network manager for a software company, I realized that my engineers were spending way too much time managing the network management tool, and not enough time resolving problems.

This is where I started to look for a solution that was easy to use, automated, and massively informative of “what is the network doing”.

After not finding anything that solved the problem, I founded NetLatency in 1998 and started to build SwitchMonitor.

Alpha Entry

February 21, 2008


I figure that starting a blog is appropriate at this point of the game, as I figure there’s a lot of news and information that can be shared a lot more efficiently through this communications medium.

I’ll post interesting information about networking and the world of network management that I run across in my daily life.