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 TodaySNMP remote monitoring is a vital function for any company with a large network. When you have a network that isn't isolated within a single area, you need assistance to manage it remotely. There's just no way (at least, no economical way) to station a live human being at each remote site to monitor everything that happens there.
What distinguishes SNMP remote monitoring from other types of remote monitoring is the use of SNMP ("Simple Network Management Protocol") to transmit messages between central alarm master (an SNMP manager, by definition, in this case) and the SNMP remotes at each network site. The pros of SNMP are many, and the cons are quite a few.
In an SNMP remote monitoring system, the two major components are the manager and the agents.
The SNMP manager is the central console used by a human operator. It sorts alarm data received from each remote SNMP agent throughout the network.
SNMP agents are located at remote sites, and they fall into two major groups. A lot of modern gear supports SNMP natively. It can send its own alarm messages to the SNMP manager directly. Since not all gear that must be remotely monitored is SNMP-capable, however, SNMP remotes are also required. These network devices accept alarms from non-SNMP gear, usually in the form of a discrete contact closure. The alarm remote, which is SNMP-capable, then sends an SNMP message back to the SNMP manager. In this way, both SNMP and non-SNMP devices can be managed under the same SNMP manager group.
We continue to examine the Simple Network Management Protocol (SNMP) focusing specifically on the layered communication model used to exchange information. The last section focused on the structure of SNMP messages, however, an SNMP message is not sent by itself. It is wrapped in the User Datagram Protocol (UDP), which in turn is wrapped in the Internet Protocol (IP). These are commonly referred to as layers and are based on a four-layer model developed by the Department of Defense (you may recall the DoD origins of the Internet).
SNMP resides in what is called the Application layer, UDP resides in the Transport layer and IP resides in the Internet layer (somewhat obvious). The fourth layer is the Network Interface layer where the assembled packet is actually interfaced to some kind of transport media (for example, twisted pair copper, RG58 co-axial or fiber). While this multi-layer model may seem a bit confusing, it effectively isolates the tasks of communication and ultimately assists in designing and implementing a network.
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.
The SNMP manager sends a Get or GetNext to read a variable or variables and the agent's response contains the requested information if managed. The manager sends a Set to change a variable or variables and the agent's response confirms the change if allowed. The agent sends a Trap when a specific event occurs.
To illustrate the function of this layered model, let's look at a single SNMP GET request from the agent's perspective. The SNMP manager wants to know what the Agent's System Name is and prepares a GET message for the appropriate OID (object identifier). It then passes the message to the UDP layer. The UDP layer adds a data block that identifies the manager port to which the response packet should be sent and the port on which it expects the SNMP agent to be listening for messages. The packet thus formed is then passed to the IP layer. Here a data block containing the IP and Media Access addresses of the manager and the agent is added before the entire assembled packet gets passed to the Network Interface layer. The Network Interface layer verifies media access and availability and places the packet on the media for transport.
After working its way across bridges and through routers (the modern equivalent of over the rivers and through the woods) based on the IP information, the packet finally arrives at the agent. Here it passes through the same four layers in exactly the opposite order as it did at the manager. First, it is pulled off the media by the Network Interface layer. After confirming that the packet is intact and valid, the Network Interface layer simply passes it to the IP layer. The IP layer verifies the Media Access and IP address and passes it on to the UDP layer where the target port is checked for connected applications. If an application is listening at the target port, the packet is passed to the Application layer. If the listening application is the SNMP agent, the GET request is processed as we have discussed in previous articles. The agent response then follows the identical path in reverse to reach the manager.
Understanding this layered model makes it easier to troubleshoot communication problems. When there is a problem, you can simply trace it down, out one end, into, and up the other. LAN/WAN link and activity status indicators provide some visibility to the Network Interface layer. ICMP echo requests and responses (PINGs) provide some information regarding the proper functioning of the IP layer. SNMP processing indicators can be used to verify the passage of the packet through the UDP layer and the functioning of the Application layer. Each step can be verified independently until all steps are working correctly for end-to-end communication.
Before you make a decision about your SNMP network monitoring, there's a lot more you need to know. There are dangers you want to avoid - and there are also opportunities to improve your remote site maintenance that you don't want to miss.
When you're choosing a network monitoring vendor, don't take chances. Be skeptical. Ask the hard questions. Above all, look for experience. Don't take a sales rep's word that his company can do custom development. Ask how many systems they've worked with, how many protocols they can integrate with SNMP, and check for client testimonials.
DPS Telecom has created hundreds of successful monitoring implementations for telecoms, utilities, and transportation companies. DPS Telecom monitoring solutions are proven performers under real-world conditions. You're never taking any risk when you work with DPS Telecom. Your SCADA monitoring solution is backed by a 30-day, no-risk, money-back guarantee. Test your DPS monitoring solution at your site for 30 days. If you're dissatisfied for any reason, just send it back for a full refund.
Get the information you need. Send an e-mail to support@dpstelecom.com for "A Practical, Step-by-Step Guide" on how to implement SCADA monitoring in your network. You can also call us today at 1-800-622-3314 to schedule your free Web demo of SCADA monitoring solutions.
