EMP's CCIE Blog: ALU

Foreward: An ALU is an Autonomous Learning Unit, you can read this post to learn more about them.

During a consulting job, you discovered a small organization which has no formal NOC or NMS capability, however, they would like to have some form of alerting if thresholds are exceeded. Configure R2 to send a SYSLOG entry with the text "Octets in Serial exceeds 10,000" to 1.1.2.114 if the number of octets coming in Interface Serial0/1 exceeds 10,000 over a 10 second period. Send another SYSLOG message with the text "Octets in Serial no longer exceeds 5,000" when the number of octets goes below 5,000.

The MIB for the number of octets coming in an interface is 1.3.6.1.2.1.2.2.1.10.X where X is the ifindex value of the Interface.

Highlight below for the solution:

Solution:

R2:

logging 1.1.2.114

rmon event 1 log description "Octets in Serial exceeds 10,000" owner config

rmon event 2 log description "Octets in Serial no longer exceeds 5,000" owner config

rmon alarm 10 ifInOctets.3 10 delta rising-threshold 10000 1 falling-threshold 5000 2 owner config

Confirmation:

R2(config)#do ping 1.1.23.3 size 1500 repeat 750

Type escape sequence to abort.

Sending 750, 1500-byte ICMP Echos to 1.1.23.3, timeout is 2 seconds:

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Success rate is 100 percent (750/750), round-trip min/avg/max = 4/6/76 ms

*Mar 2 17:37:17.169: %RMON-5-RISINGTRAP: Rising trap is generated because the value of ifInOctets.3 exceeded the rising-threshold value 10000

*Mar 2 17:37:27.177: %RMON-5-FALLINGTRAP: Falling trap is generated because the value of ifInOctets.3 has fallen below the falling-threshold value 5000

R2#show logging | begin Trap

Trap logging: level informational, 38 message lines logged

Logging to 1.1.2.114(global) (udp port 514, audit disabled, link up), 8 message lines logged, xml disabled,

filtering disabled

Rack1R2#show rmon alarms

Alarm 10 is active, owned by config

Monitors ifInOctets.3 every 10 second(s)

Taking delta samples, last value was 363

Rising threshold is 10000, assigned to event 1

Falling threshold is 5000, assigned to event 2

On startup enable rising or falling alarm

Rack1R2#show rmon events

Event 1 is active, owned by config

Description is Octets in Serial exceeds 10,000

Event firing causes log,

last event fired at 0y0w1d,17:37:17,

Current uptime 0y0w1d,17:39:14

Current log entries:

index uptime description

1 0y0w1d,17:36:27 Octets in Serial exceeds 10,000

2 0y0w1d,17:37:17 Octets in Serial exceeds 10,000

Event 2 is active, owned by config

Description is Octets in Serial no longer exceeds 5,000

Event firing causes log,

last event fired at 0y0w1d,17:37:27,

Current uptime 0y0w1d,17:39:14

Current log entries:

index uptime description

1 0y0w1d,17:36:17 Octets in Serial no longer exceeds 5,000

R2#show snmp mib ifmib ifindex

FastEthernet0/0: Ifindex = 1

Loopback0: Ifindex = 8

Null0: Ifindex = 7

VoIP-Null0: Ifindex = 6

Serial0/0: Ifindex = 2

Serial0/1: Ifindex = 3

Serial0/2: Ifindex = 4

Serial0/3: Ifindex = 5

Explanation:

This question is a classic RMON question with a slight twist that it requires you to identify the ifindex value for Serial0/1. The way to do that is to enable a SNMP community string on the router, then issue the "show snmp mib ifmib ifindex" command. RMON questions will always need to give you the MIB value to query, but for MIB values that require the ifindex value of an interface you should know how to find the ifindex value.

RMON alarms have two modes of data collection, the first is absolute value. An absolute value measure compares the SNMP value to a static value. An example of a SNMP value that would work to compare against an absolute would be something that rises and falls, such as CPU usage, rolling five-minute averages of interface usage, or temperature. Those values all go up and come back down.

The other type of RMON alarm is a delta alarm. A delta alarm compares the current SNMP value to what the value was the last time RMON checked. The difference, or delta of those two numbers is what is compared to the thresholds. For example, the number of octets coming in an interface will never decrease, so comparing that number against a static value would not be useful. However, if we compare the amount of octets that have come in the interface in the past ten seconds to a number, we have a useful statistic.

When identifying what type of RMON alarm to use always ask yourself if the value can ever go down. If it can, it is likely going to be an absolute alarm. If the value can never go down, such as in octets on an interface, seconds since last reload, or the configuration revision of a VLAN database, it is going to be a delta value.

The only other area of confusion for some CCIE candidates is when a RMON question requests that you forward RMON events to a SYSLOG server. There is no magic involved there, you just issue the "logging IP" command to send all messages generated locally to the syslog server.

To test this alarm we can issue a ping with a high repeat count and large packet size to generate enough octets to cause the rising threshold to be exceeded.

DocCD items to reference: