RMON Refresher
Think about this given Router-Configuration:
class-map match-all CM_VOIP_CTRL match dscp af31 class-map match-all CM_VOIP_RTP match dscp ef policy-map PM_OUT class CM_VOIP_RTP priority percent 10 class CM_VOIP_CTRL bandwidth percent 1 class class-default fair-queue ! interface GigabitEthernet1 ip address 192.168.2.72 255.255.255.0 service-policy output PM_OUT
Three Queues at interface Gig1:
- CM_VOIP_RTP
- CM_VOIP_CTRL
- class-default
with per-Queue-Statistics:
- Packet counters
- Drop-counters
- etc.
In these first examples, i don’t want to wait for queue-drops, i’ll just generate DSCP=EF-Traffic by the ping-command and watch the Queue-Packet-Counters, not Drops.
Configure RMON Alarms and Events
I’ll add two RMON-Events
rmon event 10 log owner RMONevent rmon event 11 log owner RMONevent
event #10 = rising-threshold – in my example: >1 Packet has been dropped forwarded
event #11 = the falling-threshold – no packets have been…
Than, instruct the Router to have a look at a QoS-counter:
rmon alarm 10001 enterprises.9.9.166.1.15.1.1.2.18.65536 300 delta rising-threshold 1 11 falling-threshold 0 10 owner RMONevent
In the upcoming post I’ll discover the RMON-MIB to illustrate where the „enterprise.9….65536“-Parameter comes from.
This alarm #10001 monitors:
- the value the QoS-counter with OID „enterprises.9.9.166.1.15.1.1.2.18.65536“ (Pkt-Counter of the RTP-Queue).
- every 300s
- watch for delta-values (not for absolute counters which might be interesting when monitoring temperatures, fan-speed etc…)
- define a hysteresis:
- rising: if the last counter-delta „was <1" and "is now >=1″ – it raises event#11.
- falling: if the last counter-delta „was >=1“ and „is now <1" - it raises event#10.
Both events instruct the router to generate a syslog-message.
In production event 10 will be configured without the „log“-option [to do nothing]. This config is for demonstration purpose.
Forward some Traffic
Generate some Traffic (TOS 184 = DSCP 46 = Expedited Forwarding (EF).
IOS-RTR#ping 192.168.2.1 tos 184 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/5 ms
So – the Queue wasn’t used before:
- the old-counter has been „0“
- now 5 Packets have been forwarded
This delta-counter „5“ has exceeded rising-threshold „1“:
- event#11 should be raised.
When?
- we’ll have to wait between 0..300s for the cyclic 300s-alarm-interval to fire
IOS-RTR# *Nov 20 14:54:39.015: %RMON-5-RISINGTRAP: Rising threshold has been crossed because the value of cbQosCMStatsEntry.2.18.65536 exceeded the rising-threshold value 1
The current counter is „5“:
- whithout rtp-data, the next delta-counter will be 0.
Wait for the next 300s interval:
- the falling-event#10 should get raised.
IOS-RTR# *Nov 20 14:59:38.837: %RMON-5-FALLINGTRAP: Falling threshold has been crossed because the value of cbQosCMStatsEntry.2.18.65536 has fallen below the falling-threshold value 0
Works, perfect!