Simple Network Management Protocol (SNMP) Monitoring

If your network is spread out across a wide area with many unmanned sites, you need SNMP monitoring. There's just no way that you and your team can watch all of your gear without some form of automated monitoring. The network is simply too big, and there are too few hours in a day to be constantly driving between network sites, burning both fuel and labor time.

SNMP monitoring is distinct from other forms of monitoring because it involves the use of SNMP protocol. SNMP, of course, stands for "Simple Network Management Protocol"). SNMP messages are, most commonly, created by an SNMP agent (some kind of gear at the site) and received by a central SNMP manager (a software program, ideally running on its own dedicated hardware platform). Sometimes, an SNMP manager will send a message to an SNMP agent. This message might ask, "What is the current temperature inside your site enclosure?", or any number of other important questions.

You can extract a lot of benefit from using SNMP, and there really aren't any significant disadvantages to be wary of.

The most important gain you'll make by using SNMP is the ability to select from many gear vendors in the future. In the past, most network gear manufacturers used their own in-house protocols to support communication between their alarming gear and their central master stations. This wasn't necessarily intended to entrap customers. After all, someone had to come up with the early site-to-site communication protocols. Unfortunately, some companies began to take advantage of their install bases by quickly raising prices. Other times, they just collapsed, leaving an entire customer list without any way to repair or extend their monitoring systems.

In response to this expensive problem, open standard protocols became the norm. Now, SNMP has become the most popular network management protocol in a variety of industries. The "nuts and bolts" of SNMP are published, so any up-and-coming manufacturers can join the marketplace with a new offering that supports SNMP. This widespread availability of alternatives keeps prices in check for you, the network professional who must buy network monitoring gear.

Implementing SNMP correctly also means that recruiting new NOC center staff will be easier. Many potential candidates will already have extensive experience using SNMP to monitor networks, dramatically reducing training time and errors.

Of course, using the most popular protocol isn't without some threats. Anytime you use something that is common, there will be a larger population of people who are familiar with it. Some of these people may have ill intent. They might use the common knowledge of SNMP to break into your system. There are strong cyber terrorism issues here.

SNMP monitoring is no longer without any defenses. For many years, the lack of security in SNMP was viewed by many as its Achilles' heel. For all its wonderful business benefits, the threat of cyber terrorists and virtual vandals loomed large.

With the release of SNMPv3, security concerns among protocol users were reduced in a big way. For the first time, SNMP included message encryption for all site-to-site communication. SNMPv3 devices do require more horsepower in general to support message encryption. That's a small concession for organizations concerned about data security.

Of course, just because SNMPv3 has been released doesn't mean that your existing SNMP network is magically upgraded. Unfortunately, all of your existing devices that support SNMP natively are likely not upgradeable. They likely just don't have the horsepower to handle message encryption.

There is, however, a way to minimize the costs associated with SNMPv3 monitoring, while still bringing your existing gear under the security umbrella of encryption. The first thing you'll need to do is upgrade or replace your SNMP manager. You need a central SNMP monitoring device that can accept SNMPv3 trap messages from remote devices. If your manufacturer cannot or will not provide an upgrade, it's likely time you think about company you're buying your monitoring gear from.

One recommended option for SNMP monitoring is the T/Mon master station. It can bring in SNMP v1, v2c, and v3 messages, plus alarms from over 25 other protocols. Even if you have an SNMP manager you already like, T/Mon can collect all of these alarm types, then forward them as a single SNMP stream to your preferred SNMP manager. A single unsecured stream sent to your older manager can be acceptable if it is logically disconnected from the outside internet. T/Mon accomplishes this by having a lot of NICs that do not route traffic to one another.

T/Mon is also recommended for its hardware platform. You need to be careful about any SNMP manager that is simply installed on a consumer-grade PC. What kind of reliability can you expect from your network if the centralized hub of your SNMP monitoring system is subject to routine crashes and other nonsense? Whatever SNMP manager you choose for monitoring your network, be sure that it runs on its own ultra-stable platform. Insider tip: It's also much easier to tell your boss that you invested budget dollars into "this impressive-looking device right here" rather than "this $600 computer and an SNMP manager install CD".

Overall, transitioning to SNMP monitoring from an older protocol (if this applies to you) is not too troublesome if you choose the right tools. You need to guard yourself against expensive "forklift swap-outs" of your entire old monitoring system all at once. The fact is, you've invested a lot in that system, and you need to continue extracting value from it to maximize your ROI.

Again, T/Mon will be a useful tool for you. By just replacing your master station at first, you can keep all of your existing non-SNMP gear online and monitored by T/Mon's multi-protocol capability. You'll instantly gain the ability to add SNMP v1, v2c, and SNMPv3 gear to your monitoring system for new expansions and replacement of any failed gear. This will help you to transition to SNMP across many budget cycles, rather than all at once.

SNMP Monitoring Case Studies.

One DPS client named Armand came to DPS in search of an effective SNMP remote that would meet his single needs. LAN was obviously a necessity to report alarms back to the SNMP manager. Some SNMP devices actually use alternative transport like T1 or Fiber, but LAN is most common.

Armand also needed about 20 digital alarm inputs (on/off) to accept gear alarms, 8 analog sensor inputs to measure humidity, temperature, battery voltage, fuel tank levels, power feeds, and a pair of control relays. These are handy for the remote control of site gear. You can wire a control relay into a button or switch to effectively manipulate those manual controls without driving out to the site (a trip that could take a few hours).

Armand also needed built-in monitoring of site temperature and battery life. To remotely access this and other monitored values, he also needed a web interface. This is a handy option, because the device can be accessed from any PC on the network using a simple web browser. No software installation is required. It also means that the device can be monitored independent of any SNMP manager.

There were also physical constraints on Armand's ideal device. To avoid eating up space in frequently cramped gear racks, he needed a device that would fit in just 1.75" of rack height in a 19" gear rack.

The NetGuardian 420 (a relatively new model) proved to be the correct option to meet these needs. Armand was really satisfied by the HTTP (web) interface for changing device settings and viewing alarms, as well as SNMP capability. SNMPv3 was included at no extra charge, but Armand actually only required SNMPv1 or v2c. Security was not a big concern at this layer. The IT department was taking care of it at a higher level.

Nonetheless, SNMPv3 did provide vital protection against an SNMPv3 transition in the future. Should Armand find himself in that situation, the NetGuardian 420's he had deployed would deliver extra ROI.

Another DPS client, Marco, wanted to monitoring a pair of optical networking rings using the TL1 protocol they output. He also needed SNMP monitoring for other SNMP devices. About 2 dozen RTUs would be needed in total for sites throughout both rings.

Marco also needed to monitor copper line pressure to protect against copper theft. T/Mon fit the bill here, with a selection of medium and large NetGuardian RTU's at his few dozen network nodes/sites.