RMON Event and Alarm Notification

RMON is a standard monitoring specification that enables various network monitors and console systems to exchange network-monitoring data.

The RMON specification defines a set of statistics and functions that can be exchanged between RMON-compliant console managers and network probes. RMON provides network administrators with comprehensive network-fault diagnosis, planning, and performance-tuning information.

The RMON feature identifies activity on individual nodes and allows you to monitor all nodes and their interaction on a LAN segment. Used in conjunction with the SNMP agent in a router, RMON allows you to view both traffic that flows through the router and segment traffic that is not necessarily destined for the router. Combining RMON alarms and events (classes of messages that indicate traffic violations and various unusual occurrences over a network) with existing MIBs allows you to choose where proactive monitoring will occur.

RMON delivers information in RMON groups of monitoring elements, each providing specific sets of data to meet common network-monitoring requirements. Each group is optional so that you do not need to support all the groups within the Management Information Base (MIB). Some RMON groups require support of other RMON groups to function properly.

RMON Groups

• Statistics - Contains statistics measured by the probe for each monitored interface on this device.
• History - Records periodic statistical samples from a network and stores them for later retrieval.
• Alarm - Periodically takes statistical samples from variables in the probe and compares them with previously configured thresholds. If the monitored variable crosses a threshold, an event is generated. Requires the implementation of the event group. 
• Host - Contains statistics associated with each host discovered on the network. 
• HostTopN - Prepares tables that describe the hosts that top a list ordered by one of their base statistics over an interval specified by the management station. Thus, these statistics are rate-based.
• Matrix - Stores statistics for conversations between sets of two addresses. As the device detects a new conversation, it creates a new entry in its table.
• Filters - Enables packets to be matched by a filter equation. These matched packets form a data stream that might be captured or that might generate events.
• Packet - Capture Enables packets to be captured after they flow through a channel.
• Events - Controls the generation and notification of events from this device.

Thresholds allow you to minimize the number of notifications sent on the network. The RMON MIB defines two traps, the risingAlarm trap which is the rising-threshold value and fallingAlarm trap which is the falling-threshold value. Alarms are triggered when a problem exceeds a set rising-threshold value. No alarm notifications are sent until the agent recovers, as defined by the falling-threshold value. This means that notifications are not sent each time a minor failure or recovery occurs.

Configuring RMON Event and Alarm Notifications

rmon event eventIndex [log] [trap community] [description string] [owner string]

• eventIndex— Event number (1–65535)
• log—(Optional) Generate an RMON log when the event fires.
• trap community —(Optional) Generate an SNMP trap when the event fires, for the specified SNMP community string.
• description string —(Optional) Specify a WORD or a description of the event.
• owner string  —(Optional) Specify an owner for the event.

rmon alarm alarmIndex alarmVariable alarmInterval {delta | absolute} rising-threshold alarmRisingThreshold [event-number] falling-threshold alarmFallingThreshold [event-number] [owner string]

•  alarmIndex—Alarm number (1–65535)
• alarmVariable—MIB object to monitor (WORD)
• alarmInterval—Sample interval (1–4294967295
• absolute—Test each sample directly.
• delta—Test delta between samples.
• alarmRisingThreshold—Rising threshold value (-2147483648–2147483647)
• event-number —(optional) Event to fire when the rising threshold is crossed (1–65535)
• alarmFallingThreshold—Falling threshold value (-2147483648–2147483647)
• event-number —(optional) Event to fire when the falling threshold is crossed (1–65535)
• owner string —(Optional) Specify an owner for the alarm (WORD).

An absolute sampling threshold is used for variables that increase or decrease over time, and have an upper or lower limit for when a log should be generated (ex: CPU utilization, memory utilization).

A delta sampling threshold is used for variables that either constantly increase (most common) or constantly decrease (ex: interface errors, input packets).

Scenario:

rmon event 1 log description "Traffic exced 500 ppm" owner TEST_RMON
rmon event 2 log description "Traffic less than 200 ppm" owner TEST_RMON
rmon alarm 1 ifInUcastPkts.2 60 delta rising-threshold 500 1 falling-threshold 200 2 owner TEST_RMON

To find out the ifIndex for interface that you want to monitor use next command

R1#show snmp mib ifmib ifindex f1/0
Interface = FastEthernet1/0, Ifindex = 2

Verification: 

R1#show rmon alarms
Alarm 1 is active, owned by TEST_RMON
 Monitors ifInUcastPkts.2 every 60 second(s)
 Taking delta samples, last value was 667
 Rising threshold is 500, assigned to event 1
 Falling threshold is 200, assigned to event 2
 On startup enable rising or falling alarm

 *May  5 14:05:09.355: %RMON-5-RISINGTRAP: Rising trap is generated because the value of ifInUcastPkts.2 exceeded the rising-threshold value 500

*May  5 14:06:09.359: %RMON-5-FALLINGTRAP: Falling trap is generated because the value of ifInUcastPkts.2 has fallen below the falling-threshold value 200

 R1#show rmon alarms              
Alarm 1 is active, owned by TEST_RMON
 Monitors ifInUcastPkts.2 every 60 second(s)
 Taking delta samples, last value was 6
 Rising threshold is 500, assigned to event 1
 Falling threshold is 200, assigned to event 2
 On startup enable rising or falling alarm

SNMPv3

SNMPv3 extends the previous versions of SNMP by introducing a new security model that replaces the old community-based authentication system. SMNPv3 also provides for communication privacy by means of encryption. The new concepts for SNMPv3 are the user, group, and security level.

To configure an SNMP v3 server, specify an SNMP group that maps SNMP users to SNMP views. Then, specify the IP address or port number for the remote SNMP agent of the device where the user resides.


A group defines what access rights a set of users have. The access policy is defined by associating a read, write, or notify view with the group.

The group also defines the security model (SNMP version) and the security level (authentication and/or encryption) for its users

The security models are defined as SNMPv1, SNMPv2, SNMPv3, while the security levels are defined as noAuthNoPriv, AuthNoPriv, and AuthPriv. 

SNMPv3 can implement any of the three above security levels. SNMPv1 and SNMPv2 only support noAuthNoPriv.

In the case that SNMPv3 uses noAuthNoPriv, the username serves as a replacement for the community string.

Configuration:

• Define snmp group 

snmp-server group [group-name {v1 | v2c | v3 [auth | noauth | priv]}] [read read-view] [write write-view] [notify notify-view] [access access-list] 

• Define remote IP address (for NMS) - Optional

  snmp-server engineID {local engine-id | remote ip-address [udp-port udp-port-number] [vrf vrf-name] engine-id-string} 

• Define SNMP user 

snmp-server user user-name group-name [remote ip-address [udp-port port]] {v1 | v2c | v3 [encrypted] [auth {md5 | sha} auth-password]} [access access-list] 

Configuration:

• NoAuthNoPriv

 snmp-server user TEST_NOAUTH_NOPRIV NoAuthNoPriv v3
snmp-server group NoAuthNoPriv v3 noauth 

• verification

R1#show snmp user
ser name: TEST_NOAUTH_NOPRIV
Engine ID: 800000090300CA002A260000
storage-type: nonvolatile active
Authentication Protocol: None
Privacy Protocol: None
Group-name: NoAuthNoPriv

R1#show snmp group
groupname: NoAuthNoPriv                     security model:v3 noauth
readview : v1default                        writeview:      
notifyview:      
row status: active

• AuthNoPriv

snmp-server group AuthNoPriv v3 auth
snmp-server user TEST_AUTH_NOPRIV AuthNoPriv v3 auth md5 CISCO_SNMP

• verification 

R1#show snmp user
User name: TEST_AUTH_NOPRIV
Engine ID: 800000090300CA002A260000
storage-type: nonvolatile  active
Authentication Protocol: MD5
Privacy Protocol: None
Group-name: AuthNoPriv

R1#show snmp group
 groupname: AuthNoPriv                       security model:v3 auth
readview : v1default                        writeview:      
notifyview:      
row status: active

• AuthPriv

snmp-server group AuthPriv v3 priv
snmp-server user TEST_AUTH_PRIV AuthPriv v3 auth md5 CISCO_SNMP priv des CISCO_SNMPv3

• verification 

R1#show snmp user
User name: TEST_AUTH_PRIV
Engine ID: 800000090300CA002A260000
storage-type: nonvolatile active
Authentication Protocol: MD5
Privacy Protocol: DES
Group-name: AuthPriv

R1#show snmp group
groupname: AuthPriv                         security model:v3 priv
readview : v1default                        writeview:      
notifyview:      
row status: active

SNMPv2c

Simple Network Management Protocol (SNMP), an application layer protocol, facilitates the exchange of management information among network devices, such as nodes and routers. It comprises part of the TCP/IP suite. System administrators can remotely manage network performance, find and solve network problems, and plan for network growth by using SNMP.

Instead of defining a large set of commands, SNMP places all operations in a get-request, get-next-request, get-bulk-request, and set-request format. For example, an SNMP manager can get a value from an SNMP agent or store a value in that SNMP agent. The SNMP manager can comprise part of a network management system (NMS), and the SNMP agent can reside on a networking device such as a router.

SNMP comprises of three parts—SNMP manager, SNMP agent, and MIBs. You can compile the Cisco MIB with your network management software.

A network that uses SNMP requires three key components—managed devices, agents, and network management software (NMS).

The NMS uses the Cisco MIB variables to set device variables and to poll devices on the internetwork for specific information. The results of a poll can get graphed and analyzed to help you troubleshoot internetwork problems, increase network performance, verify the configuration of devices, and monitor traffic loads.
The SNMP agent gathers data from the MIB, which is the repository for information about device parameters and network data. The SNMP agent also can send traps (notifications) of certain events, to the SNMP manager.

SNMP Basic Commands

Managed devices get monitored and controlled by using four basic SNMP commands: read, write, trap, and traversal operations.

•NMS uses the read command to monitor managed devices. The NMS examines different variables that are maintained by managed devices.

•NMS uses the write command to control managed devices. The NMS changes the values of variables stored within managed devices.

•Managed devices use the trap command to asynchronously report events to the NMS. When certain types of events occur, a managed device sends a trap to the NMS.

•NMS uses traversal operations to determine which variables a managed device supports and to sequentially gather information in variable tables, such as a routing table.


SNMP Versioning

• SNMPv1 was the first version of SNMP which is defined in RFCs 1155 and 1157
• SNMPv2c is a sub-version of SNMPv2.  It is defined in RFC 1901, RFC 1905, RFC 1906, RFC2578. One 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 provides the following security features:
• Authentication—Verifying that the request comes from a genuine source.
• Privacy—Encrypting data.
• Authorization—Verifying that the user allows the requested operation.
• Access control—Verifying that the user has access to the objects that are requested.

SNMPv3 prevents packets from being exposed on the network. Instead of using community strings like SNMP v1 and v2, SNMP v3 uses SNMP users.

SNMP Community Strings and Users

Although SNMP community strings provide no security, the strings authenticate access to MIB objects and function as embedded passwords. You configure SNMP community strings for SNMP v1 and v2c only.

SNMP v3 does not use community strings. It uses SNMP users that serve the same purpose as community strings but provide security because encryption or authentication is configured.

No default community string or user exists.

SNMPv2c Configuration:

• Enable SNMP aggent on the managed device

snmp-server community string [view view-name] [ro | rw] [number]

•  Community string acts like a password and permits access to the SNMP protocol.
• [view-name] (Optional) Name of a previously defined view. The view defines the objects available to the community.
• The read-write (rw) string allows the management station to make changes to the managed device, as opposed to the read-only (ro) string.
• [number] (Optional) Integer from 1 to 99 that specifies an access list of IP addresses that are allowed to use the community string to gain access to the SNMP agent

• Set interfaces index persist

snmp-server ifindex persist

• SNMP interface index (IfIndex) values are not being the same between reloads by default. You can change that using the above command.

• Set system location string

snmp-server location text  

• text is a string that describes the system location information.

• Set system contact 

snmp-server contact text

• text string that describes the system contact information.

• Allow the NMS to reload the managed device

snmp-server system-shutdown

• Specifies the FTP server list with acceptable addresses to download/upload the router’s configuration when instructed via SNMP

snmp-server tftp-server-list [number]

• [number] Integer from 1 to 99 that specifies an access list 

• Create or update a view entry

snmp-server view view-name oid-tree {included | excluded}

• view-name - Label for the view record that you are updating or creating. The name is used to reference the record.
• oid-tree Object identifier of the ASN.1 subtree to be included or excluded from the view. To identify the subtree, specify a text string consisting of numbers, such as 1.3.6.2.4, or a word, such as system. Replace a single subidentifier with the asterisk (*) wildcard to specify a subtree family; for example 1.3.*.4.

• SNMP traps and informs

SNMP traps are part of SNMPv1 and SNMPv2 specifications. The traps which are to be sent can be configured either globally or on a per-host basis.

snmp-server enable traps

 Additionally SNMPv2 allows sending notifications as informs, which differ from traps in that
they require acknowledgement from the NMS. Informs are kept in router local queue until they are acknowledged or timeout has expired. Informs make SNMP reliable even though the transport protocol is still UDP.

snmp-server host host-addr [traps | informs] community-string [udp-port port] [notification-type]

• traps - (Optional) Sends SNMP traps to this host. This is the default.
• informs - (Optional) Sends SNMP informs to this host.
• community-string -  community string sent with the notification operation
• udp-port - (Optional) UDP port of the host to use. The default is 162
• notification-type - (Optional) type of notification to be sent to the host. If no type is specified, all notifications are sent. Example of notification-type : bgp, hdrp, syslog, snmp, etc.

• show commands

R1#show snmp
Chassis: 4294967295
Contact: John Doe
Location: test lab
0 SNMP packets input
    0 Bad SNMP version errors
    0 Unknown community name
    0 Illegal operation for community name supplied
    0 Encoding errors
    0 Number of requested variables
    0 Number of altered variables
    0 Get-request PDUs
    0 Get-next PDUs
    0 Set-request PDUs
    0 Input queue packet drops (Maximum queue size 1000)
0 SNMP packets output
    0 Too big errors (Maximum packet size 1500)
    0 No such name errors
    0 Bad values errors
    0 General errors
    0 Response PDUs
    0 Trap PDUs
SNMP logging: enabled
    Logging to 10.1.1.2.162, 0/10, 0 sent, 0 dropped.
SNMP Manager-role output packets
    0 Get-request PDUs
    0 Get-next PDUs
    0 Get-bulk PDUs
    0 Set-request PDUs
    0 Inform-request PDUs
    0 Timeouts
    0 Drops
SNMP Manager-role input packets
    0 Inform request PDUs
    0 Trap PDUs
    0 Response PDUs
    0 Responses with errors
SNMP informs: enabled
    Informs in flight 0/25 (current/max)
    Logging to 10.1.1.2.162
        0 sent, 0 in-flight, 0 retries, 0 failed, 0 dropped

R1#show snmp community
Community name: ILMI
Community Index: cisco0
Community SecurityName: ILMI
storage-type: read-only active

Community name: TEST-RO
Community Index: cisco1
Community SecurityName: TEST-RO
storage-type: nonvolatile active access-list: 10

Community name: TEST-RW
Community Index: cisco4
Community SecurityName: TEST-RW
storage-type: nonvolatile active

R1#show snmp host    
Notification host: 10.1.1.2 udp-port: 162 type: inform
user: TEST-RW security model: v2c
Notification host: 10.1.1.2 udp-port: 162 type: trap
user: TEST-RO security model: v1

• snmpwalk command