SNMP (Simple Network Management Protocol) was designed as the standard language to be used by all computers on a network. The SNMP protocol is used by network management systems to communicate with network elements to monitor and control different aspects of the equipment.
For SNMP to function in a network there needs to be at least two elements:
- The SNMP Manager
- The SNMP Agent.
An SNMP Manager is an application that performs the operational roles of generating requests to modify and retrieve management information and receiving the requested information and trap-event reports that are generated by the SNMP agent. SNMP management applications such as SNMPC etc. can be used and have been verified to operate on to SNMP Agent (VEGA). The VEGA is not limited to the SNMP manager applications mentioned here. Other applications can be utilized, but the applications mentioned above have been verified.
An SNMP Agent is an application that performs the operational role of receiving and processing requests, sending responses to the manager, and sending traps when an event occurs. VEGA acts as an SNMP Agent.
The SNMP agent software must have three sets of hooks into the SNMP Manager:
- In an SNMP operation, network information is exchanged through messages sent between the Manager and Agent.
- The Manager uses messages to request operations to be performed on the SNMP agent.
- The messages sent are GetRequest, GetNextRequest, SetRequest, and GetBulk.
The SNMP Agent responds with a GetResponse message. If a specific condition or event occurs the SNMP Agent sends a Trap message to the Manager for viewing.
SNMP BASIC INFORMATION / DEFINITIONS
Below table show basic information with respect to SNMP Termnologies used as a part of SNMP network
|1||NMS||A Network Management Station is a console that monitors and controls SNMP Agents by executing SNMP Manager Applications. To perform NMS functions, high-performance workstation computers that have fast CPUs and extensive disk space are used. A managed network requires at least one NMS workstation to perform SNMP operations|
A Management Information Base (MIB) is a scheme that contains the hierarchical order of all of the managed objects. Each managed object in an MIB has a unique identifier. The identifier includes the type (such as counter, string, gauge, or address), access level (such as read/write), size restrictions, and range information of the object. The MIB is extensible, which means the manufacturer can append information to an object to extend the tree as much as needed. These new MIB definitions must be added both to the SNMP Agent and to the SNMP Manager (NMS).
There are mainly two different types of MIB's:
|3||Get||A type of SNMP message sent from a manager to an agent which requests to know the value of a particular variable on the agent.|
|4||Notify||A message sent from an SNMP agent (server) to the set of SNMP managers (clients) that have registered to receive it. The agent expects an acknowledgement from the manager. If it does not receive the acknowledgement within the specified interval, it will resend a number of times.|
|5||Community String||The most basic form of SNMP security is the Community String. SNMP Community Strings are like passwords for network elements. Generally, there is one community string which is used for read-only access to an SNMP Agent. The default value for this community string is often "public". Using this community string like a password, the NMS (Network Management System) can retrieve data from network elements. Less often, there is also a read-write community string. The default value for this is often "private". Using this community string, the NMS can actually change MIB variables on a network element.|
|6||Object identifier||An Object Identifier is the identification value of an object that is defined in a MIB. Object identifiers are arranged in a hierarchical tree structure that is compliant with Internet standard and that consists of roots and branches. An object identifier is written as a sequence of sub-identifiers, starting with the tree root, in dotted decimal notation. For example, the VEGA branch of the MIB naming tree is expressed as 18.104.22.168.4.1.4686.11 This identifies the VEGA and would be the identifier for enterprise MIBS.|
VEGA only supports private MIB's (Enterprise MIB's) that is specifc to VEGA
SNMP Implementation on VEGA
There are mainly three different versions of SNMP which are implemented on VEGA as show below:
- SNMP version 1
- SNMP version 2
- SNMP version 3
VEGA supports SNMP version 1 (SNMPv1), SNMP version v2c (SNMPv2c) properly.
Below is the information with respect to different SNMP versions:
SNMP version 1 (SNMPv1)
Below are the key points with respect to SNMP version 1:
- SNMPv1 was the first version of SNMP.
- Defines limited, easily implemented MIB of scalar variables and two dimensional tables and has limited functionality
- Although it accomplished its goal of being an open, standard protocol, it was found to be lacking in key areas for certain applications like security etc.
SNMP version 2 (SNMPv2c)
SNMPv2c is a sub-version of SNMPv2. Below are the key points points with respect to the same:
- Protocol use to exchange management information
- 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.
- SNMPv2 with community-based security allows for configuration of an agent for authentication, encryption, data access, and trap management.
- Improved error handling
- Improved SET commands
To utilize the SNMPv2c features, one must have an SNMP Manager Application loaded on a PC which supports SNMPv2c. SNMPv2c will monitor DS1, DS3 and Ethernet Interfaces using industry standards MIBs
Not all devices are SNMPv2c compliant, so your SNMP manager should be downward compatible with SNMPv1 devices.
SNMP version 3 (SNMPv3)
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.
VEGA also support SNMP version 3(SNMPv3) if authentication and privacy is not enable.
As of now VEGA does not supports SNMPv3 with either of them enable.