Download our free SNMP White Paper. Featuring SNMP Expert Marshall DenHartog.
This guidebook has been created to give you the information you need to successfully implement SNMP-based alarm monitoring in your network.
1-800-693-0351
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 TodaySimple Network Management Protocol (SNMP) is very popular in remote monitoring applications, so it's likely you'll work with it at some point.
You'll have questions when configuring your SNMP gear like "What port does SNMP use?" or "Does SNMP use TCP or UDP?"
Feel free to message us for any help you may need. If not, here are some of the key defaults to keep in mind as you get started:
SNMP uses both port 161 and port 162 for sending commands and messages.
The "SNMP manager" at the head of your system sends commands down to a network device, or "SNMP agent," using destination port 161.
When the agent wants to report something or respond to a command, an agent will send an "SNMP trap" on port 162 to the manager.
An SNMP Trap is a notification sent by a network device to an SNMP manager to alert it of specific events or issues. Unlike regular SNMP polling where the manager requests information, traps are sent automatically when specific conditions occur.
Using SNMP traps reduces network traffic because notifications are only sent when triggered, not continuously requested.
When setting up SNMP-based monitoring systems, ensuring that SNMP ports 161 and 162 are open and correctly configured is essential for seamless operation.
These two ports are fundamental defaults. They are the same in all versions of SNMP, since SNMP v1.
There are two types of protocols used in the Transport Layer (a sub-division of the IP layer): Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). SNMP can be implemented over both protocols via LAN. While SNMP over TCP port is possible, SNMP packets are typically sent over UDP.
There are two types of protocols used in the Transport Layer (a sub-division of the IP layer): Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). SNMP can be implemented over both protocols via LAN. While SNMP over TCP port is possible, SNMP packets are typically sent over UDP.
TCP is connection based, meaning that one program is connected to another program and they send messages across the internet to each other.
TCP is relatively heavy, meaning it requires three packets to set up a connection before user data can be sent.
While TCP can be used for SNMP, it was originally designed with UDP transport only. While UDP may not have all the functionality of TCP, this actually makes it better for some applications. UDP is faster than TCP because it does not order packets (which can be done by the application layer), and it is a connection-less protocol. UDP is actually better suited for repetitive, low-priority functions like alarm monitoring.
Therefore, typically, SNMP uses UDP port 161 and UDP port 162.
By leveraging UDP, SNMP ensures rapid communication suitable for its network management roles, maintaining a balance between speed and reliability.
Note: Agents use UDP 161, while the manager uses UDP 162.
SNMP is community-based, so there's the concept of "community string" that needs to be understood. Fortunately, it's really quite simple.
An SNMP community is something like a VLAN in the SNMP layer. Devices (management stations called "managers" and their managed devices called "agents") include a small text "community string" with each message. A receiving device will discard any message if that string doesn't match its own.
The default SNMP community string is "public" for the vast majority of devices. It's quite common for users to never change from this default, allowing all SNMP agents in the network to communicate with the (usually single) manager.
You might initially view the use of the default community string "public" as a security hole. It feels a bit like using a default password. Even the word "public" describes the people you need to keep out of your secured system.
It's probably a bigger problem, though, to think the community string offers much security at all. Even though you can obstruct unauthorized SNMP traffic by using a non-standard community string, that's not much of an obstacle for a determined intruder.
SNMP (other than SNMPv3) is unencrypted, so a "secret" community string is easy to learn. You should view the community string as a way to control the structure of management information in your network. It's not a security tool. Take care of that challenge in another layer, and/or deploy only SNMPv3-capable devices and activate encryption.
SNMPv3 is the most secure version of the SNMP protocol. The SNMPv3 port is the same port used for SNMPv1 or SNMPv2c. You'll need the port 161 for polling and 162 for notifications (trap messages, for example).
Any manufacturer can make a device SNMP-capable, so there must be an agreed-upon standard to allow managers and agents and communicate.
An SNMP MIB defines the format of information exchange in an SNMP system. It acts as a blueprint for how data is organized and shared between devices. Each SNMP agent maintains an information database that describes the parameters of the device it manages. This database is crucial for the SNMP manager, a software system that collects data for fault management, performance management, and capacity planning.
Shared Database: The SNMP manager stores collected data in an MIB, creating a commonly shared database between the agent and the manager. This allows for seamless communication and data exchange.
File Format: MIBs are saved as text files in a specific format. This format is understood by various tools like MIB editors, SNMP agent builders, network management tools, and network simulation tools, facilitating network building, testing, deployment, and operations.
Object Identifiers (OIDs): The managed objects in an MIB file are called object identifiers, or OIDs. These identifiers are key to understanding the capabilities and parameters of SNMP devices.
That standard is the Management Information Base (MIB). This is a human-readable ASN.1 text file that is parsed by the SNMP manager. It's a bit like a driver file that shares the various things that an SNMP-equipped device can do.
If you need to understand the specifics of your SNMP device, the MIB is a great place to look. It's a bit cryptic at first, but you'll get the hang of it fairly quickly. By providing a structured format for data, MIBs enable efficient network management and device communication, essential for maintaining robust and reliable network systems.
Help me find SNMP capable RTUs.
Some examples of RTUs, or agents, with UDP capability are the NetGuardian 832A, NetGuardian 216 and the NetGuardian LT by DPS Telecom. These RTUs are SNMP compatible and range in discrete input size, allowing your company to select the RTU that fits your needs perfectly. Additionally, they all have UDP capability.
The NetGuardian 832A has 32 discrete alarms and 8 analog alarms, pings 32 network elements, controls 8 relays, provides LAN reach through access to 8 serial ports, and reports via SNMP v3. Even though it fits in just 1 ru of rack space, it is perfect for larger sites.
The NetGuardian 832A G5 has dual Ethernet support for secure network access - both NICs have access to the NetGuardian but not to each other. Additionally, the NetGuardian 832A G5 features a wide range of options and expansion units, so that you get a unit with the perfect capacity for your specific needs.
With this NetGuardian, you can not only send SNMP Traps, but you can also monitor a wide range of other units and sensors. For a large network, the NetGuardian 832A has the ability to report alarms to multiple SNMP managers or TMon Remote Alarm Monitoring System, so it's easier than ever to support a more secure redundant master architecture.
The NetGuardian 216 is a mid-sized RTU. It has the capacity to monitor 16 discrete alarms and 8 analog alarms, pings 32 network elements, controls 2 relays, provides LAN reach-through access to 7 network elements, and reports via SNMP. As mentioned above, the NetGuardian 216 works with the SMS Receiver (discussed below) to report alarms via SMS, either direct to your mobile phone or to your alarm master. You'll be the first to know about a problem.
The smallest of the three RTUs is the NetGuardian LT. The NetGuardian LT G2 is a compact, LAN-based, and rack-mounted remote telemetry unit (RTU). This device is easy to install and features a light capacity - making it the perfect RTU to deploy at small remote sites with just 4 discretes.
Based on the time-tested NetGuardian design, this telco-grade remote is housed in a durable aluminum chassis and is scaled to be a perfect-fit solution where a large capacity RTU would be more than you need. It can also have 1 analog input and can support SNMP. With other options available, this RTU, as well as the others are customizable to fit your monitoring need.
Yet another SNMP transport method is by SMS message via an SMS receiver. Your wireless RTU sends alarms to the SMS receiver and then forwards them to your master station. As normal, the master station then alerts techs or other appropriate personnel that there is a problem.
The SMS Receiver by DPS Telecom allows you to use your wireless RTUs with your alarm master station without paying for an expensive third-party data provider or opening a hole in your firewall to receive alarms on your master station.
Wireless RTUs previously created a lot of unwanted trouble for companies. To send alarms to your master station, you had to pay your cellular carrier or a third-party data provider for a static IP address. Then, you had to punch a hole in your firewall to get that data back into your network - a security risk that some IT departments simply weren't willing to take.
Rather than reporting alarms over IP, simply configure your wireless RTU to send SMS alarm notifications to your SMS Receiver. The SMS Receiver then parses the SMS Notification and forwards an SNMP trap to your T/Mon or alarm master station over LAN.
Reporting alarms via SMS rather than IP allows you to bypass the traditional hassles of wireless IP-based alarm reporting. One SMS Receiver can report alarms for multiple RTUs as well, allowing you to cheaply and easily employ wireless RTUs or establish a backup alarm-reporting path over wireless devices.
We've been helping companies with their network monitoring systems since 1986. If you need help with your project, let us know how we can help!
All DPS Telecom products include comprehensive technical support. If you've purchased one of our products and are encountering any kind of issue, contact DPS Tech Support today at 559-454-1600.
At DPS Telecom, the representative who answers your call isn't an intern reading from a script. DPS Tech Support representatives are engineers who contribute to product development. And, if your problem requires additional expertise, the DPS Engineering Department that designed your product is right down the hall.
Help us connect you to the right engineer by filling out this quick questionnaire. Simply leave your contact information to get started, and we'll call you back. Most preliminary discussions are about 15 minutes, and afterward, we'll send you a custom application diagram of a recommended solution that'll make it easier to justify your project to management.
