Since its creation in 1988 as a short-term solution to manage elements in the growing Internet and other attached networks, the Simple Network Management Protocol (SNMP) has achieved widespread acceptance.
SNMP was derived from its predecessor SGMP (Simple Gateway Management Protocol) and was intended to be replaced by a solution based on the CMIS/CMIP (Common Management Information Service/Protocol) architecture. This long-term solution, however, never received the widespread acceptance of SNMP.
Part of why SNMP has reached such wide adoption is due to the fact that it is an open standard. While there are widely accepted standards, there is no governing body that controls how SNMP can and cannot be used, or declares and set rules for how messages are created and processed, making it extremely flexible and unable to be made obsolete by a singular vendor going out of business.
This protocol is based on the manager/agent model consisting of a manager, an agent, a database of management information, managed objects and the network protocol. The manager provides the interface between the human network manager and the management system. The agent provides the interface between the manager and the physical device(s) being managed.
The manager and agent use a Management Information Base (MIB) and a relatively small set of commands to exchange information. The MIB is organized in a tree structure with individual variables, such as point status or description, being represented as leaves on the branches. A long numeric tag or object identifier (OID) is used to distinguish each variable uniquely in the MIB and in SNMP messages
There have been several versions of the SNMP. These different generations of SNMP have created a definite fracturing of what was once a simple architecture. Now, you have to consider the multi-generational SNMP versions you have in play and consider mediation devices to convert older SNMP to the newer version.
The latest (SNMPv3) adds encryption for the secure transmission of critical data. This presents a problem if you have a large deployment of earlier gear that only uses SNMPv1 or SNMPv2 (v2c is the most common sub-version of v2).
It's important to determine which is best for your unique monitoring applications. If you need the most secure data transmission available, you should monitor strictly in SNMPv3 protocol. However, if you're in an environment where high-level security is not necessary, it's probably better to stick with SNMP v1 or v2c if that's what you already have.
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.
Of course, it is technically possible to secure your entire network. That would theoretically eliminate the need for encrypted SNMP. Unfortunately, that level of security is difficult to achieve.
Furthermore, most organizations that care about security would prefer to also encrypt SNMP protocol in order to have redundant security layers.
If you've got a lot of SNMP v1 & v2c equipment in your network combined with a requirement to use only secure SNMP v3, it may seem like you've been given 2 incompatible goals:
Stop using all of your SNMP v1 & v2c equipment.
Don't spend budget money on new SNMPv3 equipment.
What you need, in order to give your older SNMP gear the advantage of modern security, is a fairly simple box that collects unsecured SNMP messages (traps) before they ever leave the building's local network. The collected traps would then be converted to SNMPv3 before being forwarded to your SNMP manager.
This is becoming the favored solution for military and other government organizations, as well as private companies that need a higher level of security. In today's environment, they most likely won't have the funding to replace all of the installed gear they've deployed in the last decade. Since they can't afford to compromise security, either, they're frequently using SNMPv3 converters instead. A single converter at a site can handle just about any number of local SNMP (v1 or v2c) devices, so purchasing costs are dramatically reduced.
You can also get more than just protocol conversion out of an SNMPv3 converter box. Some are also designed to perform alarm monitoring and management, such as RTUs (discrete inputs, analog inputs, temperature sensors, control relay outputs). If, like most people, you need some general purpose monitoring at any of your locations that have SNMP engines, you can now solve two problems with one device.
The key is to choose a manufacturer that will help you to build an effective system that addresses several of your needs at the same time.
If you're transitioning to SNMPv3 in your network, the NetGuardian 832A G5 can help you make the change. You can start reporting alarms in SNMP v1 or v2c and switch over to v3 whenever you're ready.
SNMPv3 support is a standard feature of the NetGuardian 832A G5 SNMP RTU, allowing you to monitor all of your SNMP devices with enhanced security via message encryption. The NetGuardian allows you to report alarms in SNMP v1, v2c, or v3, leveraging the full NetGuardian feature set and your existing SNMP manager.
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.