SNMP and RMON 101
SNMP Basics
SNMP requires a SNMP Manager (usually a NMS – Network Management System) that sends SNMP requests (get or set) and a SNMP Agent (usually running on the managed device – router, switch) that responds to these requests. The SNMP Agent listens for requests on UDP port 161.
In addition, SNMP Agents can send unsolicited messages to the NMS when a certain event occurs. These messages are called Traps or Informs. The SNMP Manager listens for Traps or Informs on UDP port 162. Informs are similar to Traps but the SNMP Agent will resend them until they are acknowledged by the SNMP Manager. Traps are sent only once and no acknowledgement is expected.
Data that is available for the SNMP Agent is organized in a tree format known as a MIB (Management Information Base). The leaves of the MIB tree are known as OIDs (Object Identifiers) and they contain the actual data. A SNMP Manager can receive the data in one OID (get command) or it can navigate the tree by running multiple getNext commands. When receiving a getNext command, the SNMP agent recursively moves to the next OID and replies with its data. Support for the getBulk command was introduced in SNMPv2. It uses only one command to get data for multiple OIDs.
A Cisco Router supports SNMP v1, v2c and v3. SNMP v1 and v2c both use a community based security model, but SNMP v2 adds support for additional SNMP commands like getBulk (instead of multiple getNext commands) SNMPv3 only improves the security of SNMP by adding integrity checks, authentication and encryption.
SNMP Groups
A SNMP Group is an entity that binds together SNMP Views and Security Model. A SNMP View is a subset of the MIB Tree. A Security Model is the set of security features that are used in order to accept a SNMP request.
SNMP Views
A SNMP View is a subset of the entire MIB tree. By default, a Cisco Router already has a SNMP view defined, called v1default. This is the default view used for SNMPv1 and SNMPv2c when no custom views are configured. The v1default view gives access to almost all MIB tree (iso = .1), except a fiew branches:
You can define additional custom views with the command:
Security Models
SNMPv1 and SNMPv2 both use a Community based security model. This Security Model uses a clear text password (community string). SNMPv3 adds additional security features like integrity checks, authentication and encryption. There are 3 different Security Models for SNMPv3
v1
noAuthNoPriv
Community String
No
v2c
noAuthNoPriv
Community String
No
v3
noAuthNoPriv
Username, no Password
No
v3
authNoPriv
Username and Password (MD5/SHA)
No
v3
authPriv
Username and Password (MD5/SHA)
DES, 3DES, AES
SNMP Communities (v1, v2c)
The SNMP Agent for v1 and v2c must be configured with a community. SNMP Requests that are received by the agent must match one of the defined communities. When a community is defined, a SNMP Groups is automatically created for each community-based security model (v1 and v2c). This group binds the COMMUNITY to a ReadView (default: v1default), a WriteView (default: none) and a Security Model (v1/v2c).
E.g:
if you want to disable one of the versions you must disable the group for that version using:
User-Based Security Model (v3)
The concept of SNMP Communities doesn’t apply to SNMPv3. For SNMPv3 you must configure the SNMP Group and SNMP users that are part of that group.
noauth – NoAuthNoPriv = No Authentication, No Privacy. No Authentication means only the username is checked. When defining a user for this group, do not set a password. No Privacy means that no encryption is used in the packets that are sent/received for this group.
auth – AuthNoPriv = Authentication, No Privacy. Authentication means that the username and a password (stored as MD5 or SHA) are checked. When defining a user for this group, configure a password. No Privacy means that no encryption is used in the packets that are sent/received for this group.
priv – AuthPriv = Authentication and Privacy. Authentication means that the username and a password (stored as MD5 or SHA) are checked. Privacy means that encryption (DES, 3DES or AES) is used in the packets that are sent/received for this group. When defining a user for this group, configure a password and an encryption method.
To configure a user, use:
When specifying an Authentication password, you can use an already encrypted string:
Customizing SNMP Agent
You can set system information for the device, using the command:
These values will be accessible via the system mib of MIB2 and will help identify the device and who manages it. To enable the SNMP agent to accept and perform a shutdown (reload) request from the management station, use:
To configure the maximum allowed SNMP packets, use:
A router’s configuration can be saved to a TFTP file using a SNMP command. To limit the list of accepted TFTP files, use:
To disable the SNMP Agent, use:
When the agent is re-enabled, all previous config will be available. Upon each restart, a SNMP agent will assign a ID to each interface. This ID will be used as an index in different TableViews of the MIB, so it becomes important to have the same ID assigned to the same interface at each restart. You can enable ifIndex persistance globally or per interface, with:
You can view the assigned values using:
SNMP Traps and Informs
Traps and Informs are SNMP messages that are sent unsolicited by a SNMP Agent. The SNMP Manager listens for Traps or Informs on UDP port 162. Informs are similar to Traps but the SNMP Agent will resend them until they are acknowledged by the SNMP Manager. Traps are sent only once and no acknowledgement is expected.
You can set the interface used as the source of Traps/Informs with:
The events that can send notifications must be also globally enabled, using:
The agent must then be configured with the address and the of the management station
SNMP v1 or v2c
For SNMPv1 or v2c:
SNMP v3
For version 3, use:
After you run this command, the router will automatically create a group with the same name as the USER. Then, you should define the snmp username as part of this group. (This is automatically done for noauth model).
RMON can be configured to monitor a SNMP MIB Object and generate events when the value changes. You will have to define a RMON Alarm to define a monitored object:
The alarm can generate events based on the changes in the values of the monitored object. To define an event, use:
To monitor RMON, use:
Last updated