How to monitor legacy non-SNMP equipment using SNMP

Most networks have significant equipment diversity. Some is very modern, but some may be more than a decade old. This naturally happens as technology evolves. You can't afford to throw out your infrastructure every time a new protocol or transport comes along. The challenge this presents for you is: How do you bring older non-SNMP equipment into your SNMP monitoring system?

Fortunately, there are solutions, because the alternatives aren't pretty. Maintaining two (or more) monitoring systems is a bad practice. You're dividing the attention of your technicians, increasing the chance that they miss an important alarm. You're probably also struggling to maintain aging legacy systems with minimal parts availability.

So how do you bring non-SNMP equipment under the monitoring "umbrella" of your SNMP manager? The first step is to use a multi-protocol master station, either as your top-level master or as a mediation device to your preferred SNMP manager. A master station that can interpret older/legacy protocols and forward the data as SNMP traps is a powerful tool. Also, any manufacturer that offers such a master console generally has a lot of experience adding support for unusual protocols. If yours isn't supported yet, you can probably get it added. Some of the best manufacturers will even do this at no charge in order to create and sell you the precise master station that you need.

You can also add mediation devices at the site level. Some advanced RTUs, in addition to collecting basic discrete alarms and analog inputs, are capable of collecting protocol-based communications from your legacy devices. One excellent example are the older protocols TBOS and TABS. An RTU called the NetMediator can collect alarms from TBOS and TABS devices and mediate them as SNMP traps to any SNMP manager.

Above, a NetMediator converts legacy protocols (various types) to SNMP traps.

In fact, some "SNMP mediation" is simply between two different versions of SNMP itself. This most commonly arises at security-conscious organizations. The first versions of SNMP were designed without much thought for security - or the assumption that SNMP traffic would only be routed over secure networks. SNMPv3 changes this by adding multiple forms of encryption and privacy. For that reason, many organizations (especially governments concerned about cyber security) have - through policy - rendered their SNMPv1 and SNMPv2c devices obsolete.

In this diagram, an SNMP conversion device collects SNMP traps in v1 and v2c formats (unsecured). These traps are converted to encrypted SNMPv3 before they leave the site, dramatically enhancing the security of your alarm data.

The solution for an SNMP version problem is to convert unsecured SNMP traps to encrypted SNMPv3 before they leave the site at all. An "SNMPv3 converter box" is capable of collecting unsecured SNMP traps, then forwarding them with added encryption to your SNMP manager as SNMPv3.

Another (even more secure) variant of this tactic is to use alarm relays (if available) on your older SNMP device rather than having it output SNMP traps. These non-protocol communications can then be wired into the discrete inputs of an SNMPv3 RTU.

As you can see, it's very possible to bring your older non-SNMP, SNMPv1, or SNMPv2c devices up to whatever modern standard you need in your network. Although there is some cost involved, it's nothing compared to the idea of replacing all of your functional infrastructure immediately (and repeatedly every time a new standard comes along). You don't have to suffer with multiple, incompatible, and unsecured monitoring systems.

Just make sure that you're working with an industry expert during your project. Some manufacturers don't have much expertise and simply try to sell you the newest, most expensive options. Choose a vendor who values your long-term success and loyalty more than a just closing a quick sale.