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 quickly became a popular choice for remote monitoring systems that run on SNMP. That's because:
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.
The Simple Network Management Protocol (SNMP) is an open standard protocol designed to mitigate the monitoring issues caused by proprietary protocols, such as:
As the use of IP increased, a standardized IP-based protocol made sense. So, with SNMP:
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).
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:
Our monitoring devices use granular traps.
OIDs are series of numbers that identify a trap within the entire SNMP universe. For example, the OID 188.8.131.52.4.1.26184.108.40.206 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.
2682 DPS Inc.
30607 Saskatchewan Blue
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.
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.
The structure of fields that contain alarm-specific information.
The structure of commands that will operate a control relay on a DPS RTU.
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.
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.
The SNMP protocol has three main versions. They are:
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.
Most of our clients that have SNMP networks choose to invest in the T/Mon master station because it can:
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:
The T/Mon SNMP Agent is SNMPv1 and supports the following commands:
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.
SNMP Event Forwarding configuration is now complete and ready to be used.
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 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.
You need to see DPS gear in action. Get a live demo with our engineers.
Check out our White Paper Series!
A complete library of helpful advice and survival guides for every aspect of system monitoring and control.
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