You need to see DPS gear in action. Get a live demo with our engineers.
Have a specific question? Ask our team of expert engineers and get a specific answer!
Sign up for the next DPS Factory Training!
Whether you're new to our equipment or you've used it for years, DPS factory training is the best way to get more from your monitoring.Reserve Your Seat Today
The following mini-guides will teach you the essentials of network alarm monitoring:
A solid network reliability management plan begins with a vulnerability assessment and few essential precautions against network outages. Unfortunately, too many network managers don't take these precautions.
Here are 10 essential first steps you should take to reduce your network's vulnerability to an outage. Use this checklist to make sure you're covering the basics of sound network reliability management.
Make sure that you have remote monitoring of every critical piece of equipment in your network
Don't rely on embedded scan points to report alarms
Have a backup power supply - and monitor and test it to make sure it's in working order
Have an alternate data path for transporting alarms in case the primary network fails
Create a disaster recovery plan and make sure your staff knows what to do in case of a natural disaster
Monitor and control environmental factors at your remote sites
Create a systematic sparing plan, and have spare parts for all critical equipment
Include remote site security in your network reliability management plan
Integrate all your remote monitoring on one uniform platform
Make sure you have quality support from your network monitoring equipment vendor
Long a requirement for equipment used in the Central Office in the North American Public Switched Network, the rigorous Network Equipment Building System (NEBS) criteria have become a universal measure of network product excellence.
Reliability of the telephone system is considered a national security issue, is demanded by consumers, and makes good business sense. Therefore, NEBS testing is taken very seriously by both the RBOCs and other service providers.
Deploying NEBS certified network equipment is a key advantage for access providers including ILECs, CLECs, CAPs, ISPs, ASPs, and, of course, RBOCs. Products that are NEBS certified are also expected to be top performers in enterprise network environments as well.
These terms are often casually used by equipment vendors as though they were synonymous. This is not the case. Most NEBS testing laboratories publish their testing procedures. Products that claim to be "compliant" are merely reproducing the rigorous testing procedures in-house (and very rarely perform them all).
While that makes for a better product than one that hasn't been tested in-house, it is still a long way from sending equipment to a nationally recognized testing facility and paying them tens of thousands of dollars to make absolutely certain that a piece of equipment meets the demanding NEBS requirements for certification.
Imagine if a cellular tower light failed and went undetected for several hours - or even days. That tower is now a highly dangerous flight hazard to aircraft. Without warning, a simple light failure could cause a tragedy.
The Federal Communications Commission (FCC) has several rules for antenna structures to ensure aircraft safety. Here are a few examples of FCC rules that tower owners should know.
The owner of any antenna structure which is registered with the Commission and has been assigned lighting specifications referenced in this part:
Shall make an observation of the antenna structure's lights at least once each 24 hours either visually or by observing an automatic properly maintained indicator designed to register any failure of such lights, to insure that all such lights are functioning properly as required; or alternatively, shall provide and properly maintain an automatic alarm system designed to detect any failure of such lights and to provide indication of such failure to the owner.
Shall inspect at intervals not to exceed 3 months all automatic or mechanical control devices, indicators, and alarm systems associated with the antenna structure lighting to insure that such apparatus is functioning properly.
It is an age-old problem: getting an accurate view of how a vendor will perform after the sale.
It's difficult - all vendors are on their "best behavior" and doing everything they can to keep from losing the sale.
The good news is that if you know what to look for you can see some of the cracks in the "image" that a vendor might be projecting ...
Here are 7 questions you can ask your prospective vendors. The answers can help you get a better understanding of what you are getting into:
How many people are on your payroll?
Do I get a personalized proposal… or a two-page fax?
Is part of the proposal a list of board member resumes?
Can you back up all your claims of superiority?
Do you ever talk to more than one person?
Do you have a money back guarantee?
What is the real core competency of the company?
With a few questions and paying attention to some of your subtle concerns you can achieve a win-win relationship with your vendor.
Installing LAN connections at remote sites is a significant cost - it can be the single biggest expense of your SNMP implementation. Many remote sites are distant and isolated, making them difficult to be integrated into your network infrastructure.
Fortunately, you don't need a LAN connection at every remote site. SNMP data can also travel over an alternative transport, like PPP over a dial-up connection or dedicated line.
That's a good immediate solution, but in the long run you'll still want to move as many sites as possible to LAN. Compared to dial-up and dedicated lines, LAN is faster, more reliable - and most importantly, doesn't require repeating monthly costs.
So now you face a dilemma: avoiding the repeating high costs of a dedicated line means taking on the immediate and enormous costs of installing LAN at your remote sites.
How can you get through this dilemma? The answer is controlled migration to LAN transport.
In a controlled LAN migration strategy, you first integrate your remote sites into your SNMP-based monitoring system, using existing transport.
To do this, all you need is an SNMP-based remote telemetry unit (RTU) or proxy device that supports both LAN transport and your existing transport.
Later, a LAN connection is installed at the remote site. The same SNMP RTU installed in Step One can be immediately transferred to LAN transport with minimal configuration - and without disconnecting alarm inputs. (Figure 2).
A dial-up connection can be retained as backup secondary connection in case of LAN failure.
You don't have to cut over all your sites at once - you can gradually migrate different sectors of your network to LAN, as your budget and installation manpower allows.
Here's a list of seven key telemetry functions that off-the-shelf SNMP managers typically do not support. These are essential functions that you need for best-quality monitoring of your network. Before you buy an SNMP manager, make sure it supports these seven essential functions.
Complete, precise alarm descriptions
A basic SNMP manager doesn't record the location, time, severity, or a precise description of alarm events. To adapt an off-the-shelf SNMP manager to monitor these factors, you must create and maintain a master alarm list representing all the monitored points in your network - and then also create and maintain a database associating all the traps that may be sent to the SNMP manager with the alarms on that list.
Identification of cleared alarms
Even more database work is required to identify whether a trap corresponds to an alarm condition or a clear condition. Creating this addition to the trap association database often requires analyzing multiple variable bindings within the trap packet
Standing alarm list
Relying on a basic SNMP manager for alarm management can potentially result in completely losing visibility of threats to your network. A basic SNMP manager doesn't maintain a list of standing alarms.
Instead, the typical SNMP manager maintains an event log of newly reported traps and a history log of acknowledged traps. As soon as a trap is acknowledged, it is considered cleared. Imagine what might happen to your network if a system operator acknowledges an alarm, and then, for whatever reason, fails to correct the alarm condition. Who would know the alarm is still standing?
System operator identification
Basic SNMP managers do not record the identity of the system operator who acknowledges an alarm. In the example of the negligent system operator, it would be impossible to determine who had made the mistake or to assign responsibility for the resulting problems.
Out of the box, the typical SNMP manager is not designed for multi-user security. All traps are posted to one alarm list; all users may view all alarms, and all users may acknowledge all alarms.
Alarm sorting and organization
Basic SNMP managers have no built-in functions for organizing alarms by logical category, posting the same alarm to multiple logical categories, or sorting which alarms the user wants to see.
If Jones is in charge of all equipment for the Western region, and Smith is in charge of power plants, both need to know about a generator failure in Tucson, but neither one needs to know about all the alarms in the network. And if one manager corrects the alarm condition and acknowledges the alarm, the other manager needs to know it was acknowledged and by whom. Unfortunately, standard SNMP managers will not support these functions.
Nuisance alarm management and after-hours notification
No SNMP manager supports the advanced features necessary for best quality telemetry monitoring, such as notifications escalation, legacy protocol mediation, nuisance alarm silencing, automatic control relay operation, and automatic notifications by pager and email.
SNMP can be an effective tool, but it's only one item in your telemetry monitoring toolkit, and it can be used more effectively when it is part of a total alarm management solution.
An alarm master that does not support multiple protocols.
A vendor that does not have the engineering resources to support nonstandard interface protocols.
A vendor that does not have the ability to do a site survey and determine a solution based off of an evaluation of my network.
You end up $250K into your installation and nothing works (and no refund!)
You select a system that has never been tested in YOUR network.
You select a system that does not come with a money-back guarantee.
You are proposed a buy-it-all-at-once solution instead of an incremental solution.
You are proposed a system that does not have engineering flexibility.
Have you done this before?
Do you poll my currently installed remotes, or do I have to do a wholesale swapout?
What protocols do you support?
Do you have references or testimonials or am I your first customer?
Do you support transport diversity (RS-232, RS-422, LAN, 202) or will I have to reinvest and purchase a new transport layer?
Can you port my database from my existing master or will I have to manually re-enter the data?
Is this solution affordable, or will it cost me a ton of money?
Will you support me during the transition or am I on my own once you are paid?
If surprises crop up - do you have the ability to reengineer the solution to make sure I am up and running?
Does your remote support dual interfaces / protocols for both my new sites as well as my legacy sites?
Do you offer installation and training or does my staff have to figure it out from the manual (if they even read it)?
Do you have the ability to custom engineer a perfect fit solution or is your sales staff just a bunch of order takers?
After you design the perfect system - do you have materials and tools that I need to successfully present this to upper management?
As my network grows - is there a clear upgrade process for my equipment?
Are you able to customize my master to support my "special" needs - or do I have to hire a full time programmer?
Do you have a master, or are you simply selling remotes?
Do you have remotes, or are you simply selling master stations?
What type of remote and network debugging and visibility do you have built-in to your products to aid me in troubleshooting communication problems?
Can I get emergency tech support?
When I have an issue, will I get an automated call system or will I get a real voice?
Are you a vertically integrated supplier - or are you part of five-team consortium?
Will you fly someone out here, do a site survey to review my alarms, transport, and general needs, help me design a perfect fit solution, field trial it with me, and support me after installation?
Does your solution fit with my manpower and resource availability?
Get the information you need - register now for a free, live Web demonstration of alarm monitoring solutions with the T/Mon LNX Remote Alarm Monitoring System. There's no obligation to buy - no high-pressure salesmen - just straightforward information to help you make the best decision about your network monitoring. You'll get complete information on hardware, network monitor software, specific applications, specifications, features, and benefits … plus you'll be able to ask questions and get straight answers.
Call 1-800-693-0351 today to schedule your free Web demo of SNMP monitoring solutions