Archive for August, 2009

IT Cost Savings Through Bloatware Elimination

August 21, 2009

Compare the following two software scenarios:

Software package #1: 6meg download requires a Pentium 200mhz system with 64megs of RAM and 500megs of hard disk space.  It runs well on any Windows OS, with any service pack, and doesn’t require any additional licensing or external packages to accomplish its goal.  It will work well on a shared server or virtual server.

Software package #2: 400meg download requires a dual-core 2ghz system with 2gigs of RAM, and 2gigs of hard disk space.  It must run under Windows Server 2003 or 2008, and also requires a database license (database potentially installed on a secondary server due to loading).  Virtualization is possible but not recommended due to the fact that its design has it constantly hungry for more resources.  Appling service pack updates and/or .NET library updates may require this package to have a patch applied.  Database maintenance and patching should be performed to insure security and continued operation.

Which scenario costs more in terms of:

  • Server footprint?
  • Deployment cost?
  • Ongoing engineering support cost?
  • Air conditioning & power costs?

Let’s add some more details:

Software package #1 scales to monitor a network of 30,000 nodes with a single deployment, and collects 27 different data elements for each monitored interface.

Software package #2 is designed to monitor 8,000 nodes with a single deployment, and collects 13 different data elements for each monitored interface.

Now which software package do you want to run on your network?

A New Spin on NetFlow

August 8, 2009

Netflow as a technology originally seemed to be really cool: You could identify who’s hogging the bandwidth and then go clobber them.

The problem is that Netflow (and all of the other flow protocols jflow, sflow, etc.) are “after the fact” reporting mechanisms:  The router only transmits a flow record after the 40gig download has completed (2 hours after the network slowdown started).

Some products claim to show “real-time” netflow records, but they’re only showing you the records as they arrive in their system (still after-the-fact).

Thus, when the network slows down, Network engineers still have to set up analyzers and a span ports to hunt down who’s stealing the bandwidth and what they are doing.  This process takes a skilled engineer and at least 10 minutes to set up and start analyzing packets.

Since the problem of “why is the network slow” isn’t solved with existing Netflow implementations, I figured there has to be a better way.  With a bit of poking, prodding, and painstaking research, I discovered that there WAS a better way: Read the LIVE flow-table INSIDE the router!

That’s how we coded SwitchMonitor’s Netflow solution.  This gives you a number of advantages over the “netflow collector” type of solution:

  1. You get to see LIVE flows and instantly know who’s stealing the bandwidth and what they are doing
  2. You can monitor HUNDREDS of interfaces with our Netflow solution (other “collectors” require gobs of disk space, CPU performance, and RAM to be able to monitor just 5 interfaces!)
  3. When we send a high utilization alert email, we send the Netflow information along with the alert.  This gives you the alert as well as WHO is taking the bandwidth and WHAT they are doing

We posted a video explaining how this solution can benefit your network on our website:

We do recognize that some companies may still want the historical Netflow records.  That’s fine.  There’s tons of historical Netflow solutions on the market.

When you’re interested in solving the problem for live flows, or for many interfaces, we’re the only game in town because all of the other solutions seem to have missed answering the original question: “What’s slowing down the network RIGHT NOW?”