Vendor Highlight Archive


There are so many network management products available, ranging from the completely free to community plus commercial to fully commercial. Choosing management tools albeit free or otherwise needs careful consideration, or systems you put in place can quickly become shelf-ware.

In order to gain acceptance with the rest of the organisation, the products you select must be intuitive.

If you find yourself reaching for documentation every five minutes to understand key concepts, or have a team of the vendor's support staff sitting in your office continuously, then you run the risk of spending more time administering the product rather than your network.

There are many organisations that spend huge resources on network management equipment with one individual responsible for the entire system.

If this key person leaves the organisation, the business adapts to function without the product or finds a replacement solution, rather than going through the vertical learning curve of re-training.

Evaluation

Since the protocols used by network management agents are universal, SNMP, NetFlow and Jflow, network management is an ideal candidate for continuously evaluating new products for suitability for your environment.

Nearly all products offer an evaluation program that can help decide whether there is something better over the horizon. As with any type of software application, there are always features which are missing or you wish it had.

As network speeds increase and applications become more sophisticated, it is important to stay abreast of evolving technologies.

Training

Depending on the size of your organisation, you are probably going to need to put together your own internal training and reference manuals, which are relevant to your environment.

Vendor documentation will cover every aspect of product features and although it may be satisfactory for reference, it won't be helpful for your day to day operations.

The NMS training and reference information should include detailed information on fault contacts escalation procedure, back up, restoration and re-creating commonly used reports responding to alarms. Now, there are many different types of network management tools available today and they all have their limitations.

The following listed in priority would be my recommendation to consider when sourcing a new NMS system.

 1.Fault Management System(FMS)

This should be the first item on your NMS shopping list. Even if you haven’t decided or do not have the immediate budget for a complete solution, the FMS can still be used as a standalone solution. This is probably the most important component. It will create an incident assign responsibility, and manage expectations and report on the overall handling of the case.

A good FMS should support generation of incidents via multiple methods (call centre, e-mail, html, sms, etc). Encouraging users to use electronic means to open a support ticket is the best usage of resources. Using a dedicated team of support staff for this function is expensive.

There are many commercial fault management systems available. It is important to ensure the selected system is either part of the NMS (monitoring solution) or has some form of database integration, otherwise you may find that a lot of double handling of information is transferred between systems.

2. NetFlow SNMP Device Poller with Alarming

This is probably the next product your shopping list. A reporting NMS will sweep the network with pings discovering your devices and then attempting to draw a network map of your topology. Once up and running, you should have a dashboard with green icons representing your network and servers components.

If your organisation is large, you will probably have a network operations centre with staff keeping an eye on the on the network during the active hours of operation.

If your company is small, then you will need a mechanism, which will send a SMS or e-mail to your phone when the ping response from a device fails.

Most NMS solutions support some form of NetFlow logging and an IPSLA polling. If these features are going to be important in the future, make sure they are either included or provision has been made in the selection process.

3. Cisco IP/SLA

If your organisation is running a Cisco environment, then IP/SLA is probably the next best thing to enable. Unlike NetFlow, the processing overhead on your exiting equipment is minimal.

You should probably dedicate a small to medium size router as an IPSLA source device (shadow router) if you are going to run more than a few SLA tests continuously. If you are considering looking at this as a future option, make sure the SNMP suite you purchase has the option to integrate IPSLA as an option, or is already included.

4. Network Based Probes

 If your network operates in a hub-and-spoke manner with a central site containing most or all of your application servers, then deploying dedicated network probes to generate reports on application throughput is the next best option. (These reports can be either daily, weekly or on a monthly basis.)

Probes can also capture traffic directly from the circuit or interface they are monitoring, providing critical response time information helpful in establishing SLA.

Many of these devices operate in both a standalone mode allowing you to connect directly to the unit itself using either web or client based console, or integrate into the vendor's complete management solution.

Probe based solutions are typically expensive when compared to other network management components. This is due to the complexity of concurrent capturing, recording and reporting.

5. NetFlow/sFlow/jFlow

If your firm does not have the budget or only uses a few known applications and has a requirement for mainly reporting, then NetFlow would be my last choice. Cisco does not recommend enabling NetFlow on high speed core network components.

It should be deployed on edge devices where it is un-economical to deploy other reporting solutions. NetFlow consumes CPU cycles and if you enable sampling to reduce this, the application throughput would decrease accordingly.

NetFlow will not provide any deep packet inspection and won't provide information on application response time.

However, for the purposes of capacity planning and reporting, it can be helpful for understanding user trend analysis and application throughput.


By Craig Sutherland






You have no rights to post comments