Overview
As of version 2.5.1, RMON is configurable via the command line in SFTOS. It can be enabled, and specific traps and alarms can be configured in the CLI. A configuration example with 2.5.1 and CLI configuration may be found in the latter part of this document.
Prior to 2.5.1, RMON was enabled by default, but RMON statistics and data could only be accessed via SNMP MIB objects.
All the objects within RMON are arranged into the SNMP object name hierarchy within the RMON group, which is group number 16 within the SNMP MIB object tree, 1.3.6.1.2.1. All RMON objects have identifiers starting with 1.3.6.1.2.1.16.
This RMON group consists of several lower-level groups. The S50 supports two such groups – Statistics (1.3.6.1.2.1.16.1) and History (1.3.6.1.2.1.16.2). These groups are described in the following table.
| RMON Group |
What the RMON Group Does |
What the Data Means |
| Statistics |
Records statistics measured by the RMON probe for each monitored interface on the device. This group consists of the etherStatsTable. |
Packets dropped, packets sent and received, bytes sent (octets), broadcast and multicast packets, CRC errors, oversized and undersized packets, fragments, jabbers, and counters for packets. |
| History |
Records periodic statistical samples from a network. This group consists of the historyControlTable and the etherHistoryTable. |
Sample period, number of samples, and item(s) sampled. |
RMON Statistics Group
The RMON Statistics group collects the following information:
1. etherStatsPkts – OID = 1.3.6.1.2.1.16.1.1.1.5
The total number of packets (including bad packets, broadcast packets, and multicast packets) received.
Sent get request to 10.16.24.106 : 161
etherStatsPkts.1:-->21164844
etherStatsPkts.2:-->34563
etherStatsPkts.3:-->3513
2. etherStatsBroadcastPkts: OID 1.3.6.1.2.1.16.1.1.1.6
The total number of good packets received that were directed to the broadcast address. Note that this number does not include multicast packets.
Sent get request to 10.16.24.106 : 161
etherStatsBroadcastPkts.1:-->11894678
etherStatsBroadcastPkts.2:-->13027
etherStatsBroadcastPkts.3:-->21
3. etherStatsMulticastPkts: OID 1.3.6.1.2.1.16.1.1.1.7
The total number of good packets received that were directed to a multicast address. Note that this number does not include packets directed to the broadcast address.
Sent get request to 10.16.24.106 : 161
etherStatsMulticastPkts.1:-->3248
etherStatsMulticastPkts.2:-->14675
etherStatsMulticastPkts.3:-->0
In addition to the above, the S50 can be polled for the number of frames with CRC and alignment errors, undersize packets, oversize packets, fragments, jabbers, collisions, 64-byte packets, 65- to 127-byte packets, 128- to 255-byte packets, etc.
RMON History Group
The RMON History group can be used to poll for information stored in memory over a period of time. The S50 stores this information in certain memory buckets. Two related timers can be configured to control the amount of information in these buckets. By default, these timers are set to 30 seconds and 1800 seconds (30 min). Each interface is assigned, by default, 10 buckets per timer (buckets granted). That is, interface 1/0/1 would have ten buckets for the 30-second interval and 10 buckets for the 30-minute interval. The number of packets received per interval is stored in subsequent buckets. Once all the buckets are filled for that particular interval, the first expires, and a new bucket is added with a new bucket number.
For example, with the 10-bucket default, only 10 buckets, such as 1 to 10 or 2 to 11, will be displayed at a single time. Each current top bucket expires after finishing its time interval, and a new bucket is added at the bottom. For example, if we have buckets 1 - 10, bucket 1 will be the first to expire, and bucket 11 will be added. Now, bucket 2 is at top, and bucket 11 is at bottom. This process continues.
The 30-second buckets are filled sequentially every 30 seconds. Similarly, the 30-minute buckets are filled one after the other every 30 minutes. These counters provide information about the traffic over two, wide time ranges.
The buckets numbering is as follows.
etherHistoryPkts.1.1:-->24
etherHistoryPkts.1.2:-->15
etherHistoryPkts.1.3:-->9
etherHistoryPkts.1.4:-->4
etherHistoryPkts.1.5:-->8
etherHistoryPkts.1.6:-->9
etherHistoryPkts.1.7:-->0
etherHistoryPkts.1.8:-->0
etherHistoryPkts.1.9:-->0
etherHistoryPkts.1.10:-->0
etherHistoryPkts.1.2:-->15
etherHistoryPkts.1.3:-->9
etherHistoryPkts.1.4:-->4
etherHistoryPkts.1.5:-->8
etherHistoryPkts.1.6:-->9
etherHistoryPkts.1.7:-->0
etherHistoryPkts.1.8:-->0
etherHistoryPkts.1.9:-->0
etherHistoryPkts.1.10:-->0
etherHistoryPkts.1.11:-->12
etherHistoryPkts.1.3:-->9
etherHistoryPkts.1.4:-->4
etherHistoryPkts.1.5:-->8
etherHistoryPkts.1.6:-->9
etherHistoryPkts.1.7:-->0
etherHistoryPkts.1.8:-->0
etherHistoryPkts.1.9:-->0
etherHistoryPkts.1.10:-->0
etherHistoryPkts.1.11:-->12
etherHistoryPkts.1.12:-->16
The number of buckets (or buckets requested) can be changed from the default value of 10. In addition, the values of the timers can be adjusted through the RMON MIBs using the UNIX/Linux command snmpset.
Note: If the number of buckets requested (default value of 50) is changed to some value less than 10, then the buckets granted will also change to that value. Otherwise, the buckets granted will stay at 10.
Let's look at some examples from the RMON History group.
1. historyControlBucketsGranted: OID 1.3.6.1.2.1.16.2.1.1.4
Sent get request to 10.16.24.106 : 161
historyControlBucketsGranted.1:-->10
historyControlBucketsGranted.2:-->10
historyControlBucketsGranted.3:-->10
2. historyControlInterval – OID = 1.3.6.1.2.1.16.2.1.1.5
Sent get request to 10.16.24.106 : 161
historyControlInterval.1:-->30
historyControlInterval.2:-->1800
historyControlInterval.3:-->30
historyControlInterval.4:-->1800
historyControlInterval.5:-->30
historyControlInterval.6:-->1800
Indexes 1 and 2 refer to one interface (1/0/1), and indexes 3 and 4 refer to the second interface (1/0/2). An S50 with 50 ports will have 100 such indexes.
3. etherHistoryPkts: OID 1.3.6.1.2.1.16.2.2.1.6
The number of packets (including bad packets) received during this sampling interval.
To read the following example output, first recall that index 1 represents the 30-second timer for port 1/0/1, and index 2 represents the same port’s 30-minute timer. An index of etherHistoryPkts.1.1471 refers to the 1471st 30-second interval on interface 1/0/1. In this example, 24 packets were received during the 30-second interval, and 71 packets were received in the 15th (etherHistoryPkts.2.15) 30-minute interval.
sent get request to 10.16.24.106 : 161
etherHistoryPkts.1.1471:-->24
etherHistoryPkts.1.1472:-->11
etherHistoryPkts.1.1473:-->9
etherHistoryPkts.1.1474:-->4
etherHistoryPkts.1.1475:-->8
etherHistoryPkts.1.1476:-->9
etherHistoryPkts.1.1477:-->0
etherHistoryPkts.1.1478:-->0
etherHistoryPkts.1.1479:-->0
etherHistoryPkts.1.1480:-->0
etherHistoryPkts.2.15:-->71
etherHistoryPkts.2.16:-->78
etherHistoryPkts.2.17:-->52
etherHistoryPkts.2.18:-->9
etherHistoryPkts.2.19:-->98
etherHistoryPkts.2.20:-->60
etherHistoryPkts.2.21:-->19
etherHistoryPkts.2.22:-->0
etherHistoryPkts.2.23:-->57
etherHistoryPkts.2.24:-->60
etherHistoryPkts.3.1471:-->31
etherHistoryPkts.3.1472:-->49
etherHistoryPkts.3.1473:-->53
etherHistoryPkts.3.1474:-->29
etherHistoryPkts.3.1475:-->28
etherHistoryPkts.3.1476:-->39
etherHistoryPkts.3.1477:-->26
etherHistoryPkts.3.1478:-->32
etherHistoryPkts.3.1479:-->62
etherHistoryPkts.3.1480:-->32
etherHistoryPkts.4.15:-->2906
etherHistoryPkts.4.16:-->3127
etherHistoryPkts.4.17:-->2181
etherHistoryPkts.4.18:-->2107
etherHistoryPkts.4.19:-->2374
etherHistoryPkts.4.20:-->2671
etherHistoryPkts.4.21:-->6392
etherHistoryPkts.4.22:-->2280
etherHistoryPkts.4.23:-->2426
etherHistoryPkts.4.24:-->1683
Similar statistics stored in the local switch memory can be obtained for such counters as broadcast packets, multicast packets, CRC error packets, undersize, oversize, fragments, jabbers, collisions, etc.
Configuring RMON in SFTOS 2.5.1+
Before configuring Alarms and Events in SFTOS, it is necessary to understand a couple of concepts.
An alarm occurs when a changing value in an RMON MIB object crosses a threshold. An alarm will occur when it crosses a threshold for the first time after initial configuraration, or a reload. A new rising threshold alarm cannot occur until the falling threshold has been crossed. A new falling threshold alarm cannot occur until the rising threshold has been crossed. See the illustration above for an explanation.
There are two methods for measuring the change in value to determine whether a threshold has been crossed:
- absolute – Actual value of MIB variable. Better for rate measurements that vary +-. If value never falls, falling threshold will never be reached and rising threshold will only be crossed once.
- delta – Best used with counters that only increment. Previous value of MIB variable is subtracted from current to determine whether value is incrementing from its previous value by the Rising Threshold amount, or by an amount equal to or less than the Falling Threshold amount.
An event is triggered by an alarm, and a specified action is taken.
Here is an example of an alarm and its associated events that uses delta measurment.
- If the value of this MIB variable (1.3.6.1.2.1.16.1.1.1.8 - etherStatsCRCAlignErrors) rises by more than 100 from the previous sample, a rising-threshold event (1) will be triggered (log and send trap), presuming that a rising-threshold event has not already been sent - or having been sent, was followed by a falling-threshold event.
- If the value of subsequent samples is unchanged (the difference between the current sample and the previous sample is 0) then the current value is 0 [zero], and a falling-threshold event (2) will be triggered (log and send trap), presuming that a falling-threshold event has not already been sent - or having been sent, was followed by a rising-threshold event.
Information to Collect if You Open a TAC Case
If you would like assistance from Force10 Networks after following the steps above, please use the Create Service Request form on the iSupport page and include the following information if available:
- Console captures showing the steps taken
- Output from the show tech-support command to capture the installed hardware and the SFTOS version
- Network diagrams or other descriptions of the network design, including VLAN configurations and IP address ranges