Choosing a Network Manager...

If you found your way to this page, it's likely that you become involved in a project to select or upgrade a network manager at your company. In fact, it's quite possible you're conducting your search because an expensive incident caused management to declare, "We need a new network manager right away!"

Of course, it's also possible that your network has simply expanded and now you need a more capable network manager than when your network was smaller. When extending your network, it's understandable that you would have "bigger fish to fry" than the often ignored topic of network management. This can be exacerbated by the fact that the equipment involved in new site installations is generally more modern and, therefore, expected to last longer between failures (MTBF) than older equipment, which probably has a less robust design and is just plain older.

Network managers are very important in both telecom and information technology functions. Unfortunately, as everyone is attempting to be more efficient in response to the economic conditions, it's quite possible that your network manager has gotten much less attention that it deserves in the last several years. Fortunately, a struggling economy can actually prove to be an advantage for you, as competition for dwindling customers increases. Now more than ever, if you can improve your service levels by implementing a high-quality network manager, you stand to gain market share in your industry.

Your customers today have a much greater ability and willingness to switch to a competitor if you fail to provide reliable levels of service by protecting your own network. With increased competition and plenty of research opportunities available on the Internet, your customers don't have to stick with you if you're not providing reliable levels of service.

So what is a network manager? Although the term can also refer to a person, in a telecom or IT context, a network manager is a piece of hardware that collects information from across the network and aggregates it for a human operator to review and, if necessary, respond.

An effective network manager will collect equipment alarms and critical environmental conditions from across your network and display them in an intuitive way on one or more display screens in your central office. When your switches, transport gear, generators, and other critical site equipment experiences troubles, it will generally have a built-in capability to send a message to your network manager (commonly via SNMP protocol).

Older equipment that does not have such abilities can be mediated to your modern LAN-based equipment, so long as it has the ability to output alarms via contact closures or (less commonly) a dedicated serial connection. Alarm remotes can bridge the gap between your older equipment in your network manager by collecting contact closures and similar alarm outputs, converting them to a LAN-based protocol, and sending them across the network to your central office. In this way, you can bring all of your equipment alarms internetworked manager, not just those that are "compatible" with the protocol that your network manager can understand. This is an excellent way to bridge the gap between different generations of equipment, allowing you to keep the investment you've already made in your network infrastructure.

Of course, I've assumed so far that you have a modern network manager. It's also possible that you have several managers of different generations operating side-by-side. This is the inevitable result of ongoing developments in the network management industry, but it still represents a problem that you can resolve.

The DPS telecom approach to a network manager is T/Mon. T/Mon can alleviate the problem of having multiple incompatible network managers running side-by-side, because it supports many different protocols from various generations of equipment. In fact, the list of protocols supported by T/Mon now numbers above 25.

Team also includes T/GFX Software, which represents yet another important element of a high-quality network manager: the ability to see alarms visually on geographic maps rather than in a static list. T/GFX is based on Microsoft MapPoint(R) software, so you are able to move through zoomable maps quickly, then drill down to alarms as they happen. As alarms occur, you'll notice that the circular icons on the T/GFX display screen will change color (generally from a "happy" color like green to a "dangerous" color like red).

T/Mon also handles another common problem experience when working with network managers: the ability to filter out meaningless nuisance alarms that only serve to cloud your alarm list. If you get tens of thousands of alarms piling up in your network manager each day, what are the odds that you'll notice the five that are actually important? This is why it's critical that you shield your human network manager operators from the extraordinarily high numbers of alarms that can occur daily within large networks. Whatever network manager you choose must have the ability to accept your customizable rules for which alarms are important and which ones are unimportant. Without this ability, you will actually train your operators to ignore their alarm console, since 99% of the head turning they do ends up yielding a "no response required" situation.

Another important management function for medium-sized companies (those that may have a NOC center but don't staff it 7x24x365) is the ability to send alarm alert messages to on-call technicians after normal business hours. Unless you have a large enough network to justify a 24-hour a day NOC center, there will be times when no one is in front of your network manager console. To make sure that critical alarms are properly handled during these periods, you need to send some kind of alert messages to your on-call technicians.

After-hours alert messages can take a few forms, but the most commonly is probably simple text messages (SMS) sent to your cell phone. That because it's very easy for a network manager to generate a text message. The text content is simply pulled from the text you've already databased that describes each alarm point. If you're satisfied with text messages as after-hours alerts, great. Just make sure you select a network manager that supports text messages sent to cell phones.

There are other options for after-hours messages, however. Did you know that some network managers can call your phone with a voice message? This can be convenient because it gives you the opportunity to interact with your monitoring system from a home phone and other landline (where text messages cannot be received). A good network manager will ask you to "Press 1 to acknowledge this alarm", etc.

If you do choose a network manager with text-to-speech voice dial-out ability, be sure that it can generate audio on the fly. You don't want to be stuck recording audio descriptions for thousands of alarm points (or, worse yet, hearing a generic message like "critical alarm" when the manager calls you at 3am). That's the approach that DPS took with T/Mon. Since you'll already be typing in a name for each alarm point, why not feed that text into a text-to-speech engine to automatically build audio alarm descriptions?

DPS Telecom projects involving network managers:
One DPS client named Jim called in with project for a network manager. He was dissatisfied with his aging, legacy network manager. His problem was related to SNMP alarm databasing and correlation. Since his manager was an older device, its support for SNMP was "tacked on". Every one of thousands of possible trap messages had to be databased beforehand. This created a huge headache.

Jim wanted a master station that would easily handle inbound SNMP traps for a state government. He wanted to be able to load MIB files, click on a few basic options, then begin receiving traps. Jim explained that his rectifier sent 53 different SNMP traps, and he had to manually database each one. Not only did he have to manually database traps, but he also had to send them off to the manufacturer to be consolidated into a single script. Ouch. Clearly, there was room for improvement as he shopped for a new network manager.

This was also an important project because of the number of network sites involved. Jim had roughly 400 sites (mostly law enforcement, transportation authority, and forest facilities).

T/Mon's automatic SNMP databasing ability was the right solution in this case. After databasing just a few rules for a typical device, T/Mon is able to intelligently break down and automatically database new inbound traps - even if it has never seen that particular message before.

Another team (Jim, Sam, Jack, Shane, Tom, and Michael) evaluated T/Mon because they liked the diversity of products it could monitor. They had a requirement to monitor Juniper, Carrier Access, TVM gateways, a Lucent 5E switch. They received an online web demonstration to provide more detail. They were interested in T/Mon's ability to perform "interactive suppression" on alarm. They wanted to know, if they had a critical piece of equipment like a channel bank go down, whether T/Mon would suppress all underlying "side effect" alarm. This ability was developed within T/Mon in response to client interest.

Related Topics:
Network Performance Management