How to Configure T/Mon Event Forwarding via SNMP

When monitoring a large number of devices in multiple different remote sites, it's important to have a master station to consolidate all your network in one single screen. The T/Mon is our master station, it is designed and built to monitor all your network equipment, regardless of device type or protocol used.

T/Mon monitors, mediates, and forwards alarm data in over 25 standard and proprietary protocols. Simple Network Management Protocol (SNMP) is one of these protocols.

T/Mon is a multiprotocol master station that eliminates the need to have multiple master stations to monitor all your different devices.

T/Mon quickly became a popular choice for remote monitoring systems that run on SNMP. That's because:

• T/Mon translates event-driven messages into traditional telemetry (alarm and clear, severity, etc.) and presents its information in an organized window system.
• T/Mon allows acknowledgment of alarms. This is specially useful for trap messages that do not have a corresponding clear, as you can get the alarm off of your standing list.
• It supports nuisance alarm management with tagging and silencing capabilities.
• T/Mon provides automated alarm response via:
• Automatic notifications through text message, email, and etc.
• Alarm forwarding
• Derived controls
• It provides a standing alarm list (not just a change of state list)
• It also can gather alarms from a broad range of SNMP devices (telephone switches, microwave radios, computer servers) while simultaneously polling devices in over 25 different communications protocols.

One of your first steps when using T/Mon in a SNMP network is to configure Event Forwarding. Take a look at how you can do this.

Before Anything Else, What is SNMP?

The Simple Network Management Protocol (SNMP) is an open standard protocol designed to mitigate the monitoring issues caused by proprietary protocols, such as:

• Master and RTU compatibility
• Multiple master stations running at the same time to monitor incompatible protocols
• Multiple screens to watch increased the chance of missing a critical alarm

As the use of IP increased, a standardized IP-based protocol made sense. So, with SNMP:

• Many RTUs from different manufacturers can report to a single master
• Less screens to keep an eye on, less staffing requirements, and reduced costs
• Compatible masters can be selected from many different manufacturers

Advantages of SNMP

• UDP/IP - Uses standard IP network
• Dual message delivery method - autonomous alerting and polling potential
• Standard for universal use

Disadvantages of SNMP

• Bulky protocol - SNMP uses standard IP network.
• Interpretable - Extensible open standard allows for variable interpretation and differing applications.

SNMP RTU and SNMP Master

The SNMP RTU or SNMP remote is the device that sends a trap when an event happens. It will also respond to the master's requests (Get commands) and perform actions upon receiving master's commands (Set commands).

The SNMP master receives traps and displays event information on an HMI (human-machine interface) - masters use MIB files to interpret the information contained in traps. It sends requests for remote device information (Get commands) and sends commands for a remote device for action (Set commands).

Trap Messages: Granular Vs Variable Bindings

SNMP traps are alert messages sent from a remote SNMP agent to the SNMP manager to notify about a change of status. There are two primary methods of representing alarms with SNMP traps:

• Granular traps
• There are 2 trap IDs for every alarm point (1 for alarm, 1 for clear)
• The SNMP master gets complete alarm data from the trap ID alone
• For example, Trap ID 8001 = Point 1 Alarm / Trap ID 3001 = Point 1 Clear

• Variable bindings traps
  
• A single trap ID may be used for all alarms
• Contained within each trap are variable bindings that contain site, description, state, and other alarm information
• For example, Trap ID 8000 can be used for all alarms

Object Identifiers (OIDs)

OIDs are series of numbers that identify a trap within the entire SNMP universe. For example, the OID 1.3.6.1.4.1.2682.1.2.102 represents "dpsRTUsumPClr", which means "DPS Telecom remote telemetry unit, all points clear". Pay special attention to "2682" in this OID, as it denotes a DPS Telecom SNMP product.

Here's a sample OID breakdown:

1 (iso): The International Organization for Standardization.

3 (org): An ISO-recognized organization.

6 (dod): U.S. Department of Defense, the agency originally responsible for the Internet.

1 (internet): Internet OID.

4 (private): Private organizations.

1 (enterprises): Business enterprises.

2682 (dpsInc): DPS Telecom.

1 (dpsAlarmControl): DPS alarm and control devices.

2 (dpsRTU): DPS remote telemetry unit.

102 (dpsRTUsumPClr): A Trap generated when all the alarm points on an RTU are clear.

Right after the 1 for "enterprises" in the MIB above, 2682 indicates DPS as the device's manufacturer. Below is a list of other numbers corresponding to common device manufacturers.

2 IBM

4 Unix

9 ciscoSystems

11 Hewlett-Packard

2682 DPS Inc.

30607 Saskatchewan Blue

Management Information Base (MIB)

The MIB defines the alarm structure and format for remote devices and it is used by the master station as a dictionary to interpret messages from RTUs.

To work properly, MIBs need to be imported and compiled at the master station. Also, a MIB can reference one or more MIBs. If all of these "nested" MIBs are not present when the main MIB is compiled, an error will occur.

The DPS MIB

MIB files are written in ASN.1 notation (Abstract Syntax Notation 1). ASN.1 is a standard notation maintained by the ISO (International Organization for Standardization), and it's used in everything from the Web to aviation control systems.

Our MIBs define general properties for the SNMP communication between the T/Mon and our RTUs.

Alarm information objects

The structure of fields that contain alarm-specific information.

Control objects

The structure of commands that will operate a control relay on a DPS RTU.

Traps

The standard trap format to be received from our RTUs.

Our MIBs provide a framework for communicating with our RTUs, but you will still need to compile RTU-specific MIBs to T/Mon. These MIBs should be available from your SNMP device manufacturer.

RFC MIBs

Usually, manufacturer-specific MIBs require reference (RFC) MIBs to compile properly. RFC MIBs contain general SNMP specifications that are common to most or all device manufacturers. Using RFC MIBs helps manufacturers to avoid including redundant information.

These MIBs are available to the public, and if you search for them on the Internet, you'll be able to locate many sites where you can download them.

To find out what other MIBs might be needed, search for the word "imports" in your specific MIB file. You will have to do the same search in their MIBs to see if any other RFC's are needed.

It's also important when setting up the SNMP Processor, to know which version of SNMP traps you will be sending the T/Mon.

Verify SNMP Version

The SNMP protocol has three main versions. They are:

• SNMPv1
  
  • First version of SNMP
  • Messages are unencrypted
  • No security features
  • Delivery is not guaranteed
• SNMPv2c
  
  • Messages are not encrypted
  • Added inform command which echoes the entire trap back to the RTU once the manager receives it, so the RTU knows it was received
• SNMPv3
  
  • Latest version of SNMP
  • Provides message integrity to ensure that a packet has not been tampered with in transit
  • Authentication feature that verifies that the message is from a valid source
  • Provides encryption of packets to prevent snooping by an unauthorized source
  • Encrypts password and username using either the "DES or AGE" encryption algorithm

If you are not sure about what SNMP version to use, open your MIB on your computer by right clicking it and open it as a text file. Each SNMP version, whether it is v1, v2c, or v2c-Inform, all use different verbiage.

If you search the MIB and find the term "Trap-Type" then you are dealing with SNMPv1. If you search and find "Notification-Type" then you are using SNMPv2c, and the term "Inform-Type" deals with v2c-Inform.

Setting Up Event Forwarding via SNMP on T/Mon

Most of our clients that have SNMP networks choose to invest in the T/Mon master station because it can:

• Send trap messages to multiple SNMP managers when an alarm point is set or cleared.
• Respond to SNMP get commands for alarm status.
• Process set commands to operate controls.

If you have more than one SNMP manager, it's not an issue. T/Mon can send trap to multiple managers for disaster recovery capability.

Now, what can your SNMP manager or network management system do? Well, it can:

• Query the T/Mon Integrated SNMP Agent for alarm information.
• Send commands to the Agent for the T/Mon system to perform the alarm points.

The T/Mon SNMP Agent is SNMPv1 and supports the following commands:

• Get
• Set
• Get-Next

To interpret trap messages from T/Mon, your SNMP Manager must be running the latest version of our MIB, which is found on the MyDPS section of our website.

The step-by-step

• Log into "Edit" interface
• Select SNMP >Trap Managers
• Click "Add"
• Enter the information corresponding to where the SNMP traps will be sent
  
  • Description: Text describing Trap Manager
  • Window: Only alarms sent to this window will be forwarded as traps. Use window 1 to forward all alarms
  • Source address: The address of your T/Mon
  • Trap address: The address of the Trap Manager that will receive the T/Mon traps
  • Trap port: The port to send events to on the Trap Manager (usually 162)
  • SNMP version: The version of trap that the T/Mon will send
  • Community string: This must match community string on your Trap Manager
• Click "Save" when finished

SNMP Event Forwarding configuration is now complete and ready to be used.

Bottom Line

After configuring the T/Mon SNMP Agent, you must configure your SNMP manager(s) to interact with T/Mon. The exact procedure will vary from manager to manager, but remember that you must always compile the latest version of our MIB to your SNMP manager(s).

If you have any questions about the process of setup Event Forwarding via SNMP, let us know and we can help you. Also, if you have any questions about our devices and monitoring solutions, reach out to us, we can make sure your network is safe at all times.

Morgana Siggins

Morgana Siggins is a marketing writer, content creator, and documentation specialist at DPS Telecom. She has created over 200 blog articles and videos sharing her years of experience in the remote monitoring industry.