If a manager wants to gather the current status of a device, it doesn't have to wait for an incoming trap (which may never come if the device has completely failed). SNMP managers can send GET requests to "get" a value from a device.
Depending on the data needed, your manager may send a GET that demands the device's on-board temperature reading, whether it has any alarm conditions to report, or just about any other information. Upon receiving a GET, an agent response with a GET response that contains the requested data.
Your manager has an overarching "bird's eye" view of your network, so it's a great place for automated decision making.
Imagine that your manager is made aware (via traps or GET responses) that several devices in one server room are overheating. Your manager can be configured to make an immediate, automated decision to activate your backup air-conditioning (HVAC) system. To do this, it must send a SET message to "set" a value on the target device (the backup HVAC, in this case). A SET-response (see the pattern?) is sent by the agent to confirm that it has received and followed the SET instructions.
There are a few other SNMP message types, but you understand all the basic concepts if you understand traps, GETs, and SETs.
The structure of Management Information Base (MIB) is a formatted text file that lists all of the data objects used by a particular piece of equipment. When you buy a monitor device that uses SNMP (for example, a managed switch), you'll tell it to send messages to your central manager. But there are tens of thousands of different SNMP products, and your manager doesn't natively understand each one.
That's where the MIB comes in. The manufacturer of your device will supply you with a MIB file (usually a download from their website) that you'll load ("compile") into your SNMP manager. Compiling converts the MIB from its raw ASCII format into a binary format the SNMP manager can use. If you've ever installed a device driver on a PC, you understand this concept.
Without the MIB for SNMP message translation, communication simply won't happen.
In other words, the MIB is a text file that describes SNMP network elements (any device in the network) as a list of data objects. It is essentially a dictionary of the SNMP language, where every object referred to in an SNMP message must be listed in the MIB. So, as far as many SNMP managers and agents are concerned, if a component of a network device isn't described in the MIB, it doesn't exist.
The elements defined in the MIB syntax can be extremely broad (for example, all objects created by private businesses) or they can be extremely specific (like a particular Trap message generated by a specific alarm point on an RTU.) Each element in the MIB is given an object identifier, or OID. An OID is a number that uniquely identifies an element in the SNMP universe. Each OID is associated with a human-readable text label.
The MIB provides a text label called for each OID. Your SNMP manager uses the MIB as a codebook for translating the OID numbers into a human-readable display.
SNMPv1, SNMPv2c and SNMPv3 are the three major SNMP versions.
SNMPv1 was the first version of SNMP. Although it accomplished its goal of being an open, standard protocol, it was found to be lacking in key areas for certain applications. Later versions have addressed many of these problems. Smaller RTUs commonly support SNMPv1.
SNMPv2c is a sub-version of SNMPv2. Its key advantage over previous versions is the Inform command. Unlike Traps, which are simply received by a manager, Informs are positively acknowledged with a response message. If a manager does not reply to an Inform, the SNMP agent will resend the Inform.
SNMPv3 is the newest version of SNMP. Its primary feature is enhanced security.
The "EngineID" Identifier in SNMPv3 uniquely identifies each SNMP entity. Conflicts can occur if two SNMP entities have duplicate EngineID's. The EngineID is used to generate the key for authenticated messages.
SNMPv3 security comes primarily in 2 forms:
Authentication is used to ensure that traps are read by only the intended recipient. As messages are created, they are given a special key that is based on the EngineID of the entity. The key is shared with the intended recipient and used to receive the message.
Privacy encrypts the payload of the SNMP message to ensure that it cannot be read by unauthorized users. Any intercepted traps will be filled with garbled characters and will be unreadable. Privacy is especially useful in applications where SNMP messages must be routed over the Internet.
SNMP uses both port 161 and port 162 for sending commands and messages.
The manager at the top of the system sends commands down to a network device 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 manager.
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.
There is no other network on the planet that is exactly like yours. For that reason, you need to build a monitoring system that's the right fit for you.
"Buying more than you need" and "buying less than you need" are real risks. You also have to think about training, tech support, and upgrade availability.
Send me a quick online message about what you're trying to accomplish. I'll work with you to build a custom PDF application diagram that's a perfect fit for your network.
Your network isn't off-the-shelf.
Your monitoring system shouldn't be, either.
We'll walk you through this with a customized monitoring diagram.
Just tell us what you're trying to accomplish with remote monitoring.Get a Custom Diagram