"Simple Network Management Protocol" SNMP is very popular in remote monitoring applications, so it's likely you'll work with it at some point.
Here are some of the key defaults to keep in mind as you get started:
"SNMP uses which port by default?"
SNMP uses both port 161 and port 162 for sending commands and messages.
The SNMP manager at the top of the system sends commands down to a network device (called an "SNMP agent") using destination port 161.
When it wants to report something or respond to a command, an agent will send a message to port 162 on the SNMP manager.
These two ports are fundamental defaults. They are the same in all versions of SNMP, from snmp v1 onward.
SNMP uses UDP by Default, but TCP is Possible 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.
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 for 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 connectionless protocol. UDP is actually better suited for repetitive, low-priority functions like alarm monitoring.
As discussed above, SNMP uses UDP ports 161 and 162 by default.
SNMP is community based, so there's the concept of "community string" that you need to be understand. Fortunately, it's really quite simple.
An SNMP community is something like a VLAN in the SNMP layer. Devices (managements 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 secure 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.
Any manufacturer can make a device SNMP-capable, so there must be an agreed-upon standard to allow managers and agents and communicate.
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.
Some examples of RTUs 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 (discused 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.
Have a specific question? Ask our team of expert engineers and get a specific answer!
Click here for more information.
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.
Click here for more information.