RMON (Remote Monitoring) MIB

# Control Tab

> The following table describes the Control Tab fields.

> Field | Description
> Port | Any Ethernet interface on the device.
> BucketsRequested | The requested number of discrete time intervals over which data is to be saved in the part of the media-specific table associated with this entry.
> BucketsGranted | The number of discrete sampling intervals over which data is saved in the part of the media-specific table associated with this entry. There are instances when the actual number of buckets associated with this entry is less than the value of this object. In this case, at the end of each sampling interval, a new bucket is added to the media-specific table.
> Interval | The interval in seconds over which the data is sampled for each bucket in the part of the media-specific table associated with this entry. You can set this interval to any number of seconds between 1 and 3600 (1 hour). Because the counters in a bucket may overflow at their maximum value with no indication, note the possibility of overflow in any of the associated counters. It is important to consider the minimum time in which any counter could overflow on a particular media type and set the historyControlInterval object to a value less than this interval. This is typically most important for the octets counter in any media-specific table. For example, on an Ethernet network, the etherHistoryOctets counter could overflow in about one hour at the Ethernet's maximum utilization.
> Owner | The network management system that created this entry.
> Status | The status of this entry. Each instance of the media-specific table associated with this is deleted by the agent if this entry is not equal to valid(1).

# Ether Stats Control Tab

> The following table describes the Control Tab fields.

> Field | Description
> Port | Any Ethernet interface on the device.
> Status | Valid if the agent is collecting this history.
> Owner | The network management system which created this entry.

# Alarm Tab

> The following table describes the Alarm Tab fields.

> Field | Description
> Interval | The interval in seconds over which data is sampled and compared with the rising and falling thresholds. When setting this variable, note that in the case of deltaValue sampling, you should set the interval short enough so that the sampled variable is very unlikely to increase or decrease by more than 2^31 - 1 during a single sampling interval.
> Variable | The object identifier of the particular variable to be sampled. Only variables that resolve to an ASN.1 primitive type of INTEGER (INTEGER, Counter, Gauge, or TimeTicks) may be sampled.
> Sample Type | The method of sampling the selected variable and calculating the value to be compared against the thresholds. If the value of this object is absoluteValue(1), the value of the selected variable will be compared directly with the thresholds at the end of the sampling interval. If the value of this object is deltaValue(2), the value of the selected variable at the last sample will be subtracted from the current value, and the difference compared with the thresholds.
> Value | The value of the statistic during the last sampling period. For example, if the sample type is deltaValue, this value is the difference between the samples at the beginning and end of the period. If the sample type is absoluteValue, this value is the sampled value at the end of the period. This is the value that is compared with the rising and falling thresholds. The value during the current sampling period is not made available until the period is completed and remains available until the next period completes.
> StartupAlarm | The alarm that may be sent when this entry is first set to valid. If the first sample after this entry becomes valid is greater than or equal to the risingThreshold and alarmStartupAlarm is equal to risingAlarm(1) or risingOrFallingAlarm(3), then a single rising alarm is generated. If the first sample after this entry becomes valid is less than or equal to the fallingThreshold and alarmStartupAlarm is equal to fallingAlarm(2) or risingOrFallingAlarm(3), then a single falling alarm is generated.
> RisingThreshold | A threshold for the sampled statistic. When the current sampled value is greater than or equal to this threshold, and the value at the last sampling interval was less than this threshold, a single event is generated. A single event is also generated if the first sample after this entry becomes valid is greater than or equal to this threshold and the associated alarmStartupAlarm is equal to risingAlarm(1) or risingOrFallingAlarm(3). After a rising event is generated, another such event is not generated until the sampled value falls below this threshold and reaches the alarmFallingThreshold.
> RisingEventIndex | The index of the eventEntry that is used when a rising threshold is crossed. The eventEntry identified by a particular value of this index is the same as identified by the same value of the eventIndex object. If there is no corresponding entry in the eventTable, then no association exists. In particular, if this value is zero, no associated event is generated, because zero is not a valid event index.
> FallingThreshold | A threshold for the sampled statistic. When the current sampled value is less than or equal to this threshold, and the value at the last sampling interval was greater than this threshold, a single event is generated. A single event is also generated if the first sample after this entry becomes valid is less than or equal to this threshold and the associated alarmStartupAlarm is equal to fallingAlarm(2) or risingOrFallingAlarm(3). After a falling event is generated, another such event is not generated until the sampled value rises above this threshold and reaches the alarmRisingThreshold.
> FallingEventIndex | The index of the eventEntry that is used when a falling threshold is crossed. The eventEntry identified by a particular value of this index is the same as identified by the same value of the eventIndex object. If there is no corresponding entry in the eventTable, then no association exists. In particular, if this value is zero, no associated event is generated, because zero is not a valid event index.
> Owner | The network management system which created this entry.
> Status | The status of this alarm entry.

# Insert Alarm Window

> The following table describes the Insert Alarm window fields.

> Field | Description
> Variable | Name and type of alarm—indicated by the format: alarmname.x where x=0 indicates a chassis alarm. Alarmname, where the user must specify the index. This will be a card number for module-related alarms, an STG ID for spanning tree group alarms (the default STG is 1, other STG IDs are user-configured), or the Ether Statistics Control Index for RMON Stats alarms alarmname with no dot or index is a port-related alarm and results in display of the port selection tool.
> Sample Type | Can be either absolute or delta.
> Sample Interval | Time period (in seconds) over which the data is sampled and compared with the rising and falling thresholds.
> Index | Uniquely identifies an entry in the alarm table. Each such entry defines a diagnostic sample at a particular interval for an object on the device.
> Threshold Type | Rising Value: When the current sampled value is greater than or equal to this threshold, and the value at the last sampling interval was less than this threshold, generates a single event. Falling Value: When the current sampled value is less than or equal to this threshold, and the value at the last sampling interval was greater than this threshold, generates a single event.
> Event Index | Index of the event entry that is used when a rising or falling threshold is crossed. The event entry identified by a particular value of this index is the same as identified by the same value of the event index object. (Generally, accept the default that is already filled in.)
> Severity | Only used when creating a script. The severity level is passed to the script associated with the alarm as the only command line argument.
> Script | Insert a name for your script.

# Event Tab

> The following table describes the Event Tab fields.

> Field | Description
> No field name - Index | This index uniquely identifies an entry in the event table. Each entry defines one event that is to be generated when the appropriate conditions occur.
> Description | Specifies whether the event is a rising or falling event.
> Type | The type of notification that the Device Manager provides about this event. In the case of log, an entry is made in the log table for each event. In the case of trap, an SNMP trap is sent to one or more management stations. Possible notifications follow: none, log, trap, log-and-trap.
> Community | The SNMP community string acts as a password. Only those management applications with this community string can view the alarms.
> LastTimeSent | If traps are specified to be sent to the owner, then this is the name of the machine that will receive alarm traps.
> Owner | If traps are specified to be sent to the owner, then this is the name of the machine that will receive alarm traps.
> Status | Normally valid. A not-valid field indicates that an SNMP agent other than the Device Manager has tried to modify an RMON parameter or that network conditions have corrupted an SNMP packet sent by the Device Manager. The status would temporarily appear as “under creation” and then the status would become either “valid” or the field would be deleted.

# Log Tab

> The following table describes the Log Tab fields.

> Field | Description
> Time | The value of sysUpTime when this log entry was created.
> Description | An implementation dependent description of the event that activated this log entry.

# RMON EtherStat Tab

> The following table describes the RMON EtherStat Tab fields.

> Field | Description
> Octets | The total number of octets of data (including those in bad packets) received on the network (excluding framing bits but including FCS octets). You can use this object as a reasonable estimate of Ethernet utilization. For greater precision, sample the etherStatsPkts and etherStatsOctets objects before and after a common interval.
> Pkts | The total number of packets (including bad packets, broadcast packets, and multicast packets) received.
> BroadcastPkts | The total number of good packets received that were directed to the broadcast address. Note that this does not include multicast packets.
> MulticastPkts | 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.
> CRAlignErrors | The total number of packets received that had a length (excluding framing bits, but including FCS octets) of between 64 and 1518 octets, inclusive, but had either a bad Frame Check Sequence (FCS) with an integral number of octets (FCS Error) or a bad FCS with a nonintegral number of octets (Alignment Error).
> UndersizePkts | The total number of packets received that were less than 64 octets long (excluding framing bits but including FCS octets) and were otherwise well formed.
> OversizePkts | The total number of packets received that were longer than 1518 octets (excluding framing bits but including FCS octets) and were otherwise well formed.
> Fragments | The total number of packets received that were less than 64 octets in length (excluding framing bits but including FCS octets) and had either a bad Frame Check Sequence (FCS) with an integral number of octets (FCS Error) or a bad FCS with a nonintegral number of octets (Alignment Error). It is entirely normal for etherStatsFragments to increment because it counts both runts (which are normal occurrences due to collisions) and noise hits.
> Collisions | The best estimate of the total number of collisions on this Ethernet segment.
> Jabbers | The total number of packets received that were longer than 1518 octets (excluding framing bits, but including FCS octets), and had either a bad Frame Check Sequence (FCS) with an integral number of octets (FCS Error) or a bad FCS with a non-integral number of octets (Alignment Error). Jabber is defined as the condition where any packet exceeds 20 ms. The allowed range to detect jabber is between 20 ms and 150 ms.
> <=64 | The total number of packets (including bad packets) received that were less than or equal to 64 octets in length (excluding framing bits but including FCS octets).
> >64 | The total number of packets (including bad packets) received that were greater than 64 octets in length (excluding framing bits but including FCS octets).
> >127 | The total number of packets (including bad packets) received that were greater than 127 octets in length (excluding framing bits but including FCS octets).
> >255 | The total number of packets (including bad packets) received that were greater than 255 octets in length (excluding framing bits but including FCSoctets).
> >511 | The total number of packets (including bad packets) received that were greater than 511 octets in length (excluding framing bits but including FCS octets).
> >1023 | The total number of packets (including bad packets) received that were greater than 1023 octets in length (excluding framing bits but including FCS octets).

# RMON History Tab

> The following table describes the RMON History Tab fields.

> Fields | Description
> SampleIndex | Uniquely identifies a specific etherStats entry. The value range is 1 to 65535.
> Utilization | The percent utilization of the Ethernet segment on a scale of 0 to 100 percent. If you want greater precision, sample the etherStstsPkts and etherStatsOctets objects before and after a common interval. The differences in the sampled values are Pkts and Octets, respectively. The number of seconds in the interval is Interval.
> Octets | The total number of octets of data (including those in bad packets) received on the network (excluding framing bits but including FCS octets). You can use this object as a reasonable estimate of Ethernet utilization. For greater precision, sample the etherStatsPkts and etherStatsOctets objects before and after a common interval.
> Pkts | The total number of packets (including bad packets, broadcast packets, and multicast packets) received.
> BroadcastPkts | The total number of good packets received that were directed to the broadcast address. Note that this does not include multicast packets.
> MulticastPkts | 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.
> DropEvents | The total number of events in which packets were dropped by the probe due to lack of resources. Note that this number is not necessarily the number of packets dropped; it is the number of times this condition has been detected.
> CRCAlignErrors | The total number of packets received that had a length (excluding framing bits, but including FCS octets) of between 64 and 1518 octets, inclusive, but had either a bad Frame Check Sequence (FCS) with an integral number of octets (FCS Error) or a bad FCS with a nonintegral number of octets (Alignment Error).
> UndersizePkts | The total number of packets received that were less than 64 octets long (excluding framing bits but including FCS octets) and were otherwise well formed.
> OversizePkts | The total number of packets received that were longer than 1518 octets (excluding framing bits but including FCS octets) and were otherwise well formed.
> Fragments | The total number of packets received that were less than 64 octets in length (excluding framing bits but including FCS octets) and had either a bad Frame Check Sequence (FCS) with an integral number of octets (FCS Error) or a bad FCS with a nonintegral number of octets (Alignment Error). It is entirely normal for etherStatsFragments to increment because it counts both runts (which are normal occurrences due to collisions) and noise hits.
> Collisions | The best estimate of the total number of collisions on this Ethernet segment.

#

Errors

> The following table describes error messages.

> Error | Description
> DropEvents | The total number of events in which packets were dropped by the probe due to lack of resources. Note that this number is not necessarily the number of packets dropped; it is only the number of times this condition has been detected.
> CRCAlignErrors | The total number of packets received that had a length (excluding framing bits, but including FCS octets) of between 64 and 1518 octets, inclusive, but but had either a bad Frame Check Sequence (FCS) with an integral number of octets (FCS Error) or a bad FCS with a non-integral number of octets (Alignment Error).
> UndersizePkts | The total number of packets received that were less than 64 octets long (excluding framing bits, but including FCS octets) and were otherwise well formed.
> OversizePkts | The total number of packets received that were longer than 1518 octets (excluding framing bits, but including FCS octets) and were otherwise well formed.
> Fragments | The total number of packets received that were less than 64 octets in length (excluding framing bits but including FCS octets) and had either a bad Frame Check Sequence (FCS) with an integral number of octets (FCS Error) or a bad FCS with a non-integral number of octets (Alignment Error). Note that it is entirely normal for etherStatsFragments to increment. This is because it counts both runts (which are normal occurrences due to collisions) and noise hits.
> Jabbers | The total number of packets received that were longer than 1518 octets (excluding framing bits, but including FCS octets), and had either a bad Frame Check Sequence (FCS) with an integral number of octets (FCS Error) or a bad FCS with a non-integral number of octets (Alignment Error). We define jabber as the condition where any packet exceeds 20 ms. The allowed range to detect jabber is between 20 ms and 150 ms.
> Collisions | The best estimate of the total number of collisions on this Ethernet segment. The value returned will depend on the location of the RMON probe. Section 8.2.1.3 (10BASE-5) and section 10.3.1.3 (10BASE-2) of IEEE standard 802.3 states that a station must detect a collision, in the receive mode, if three or more stations are transmitting simultaneously. A repeater port must detect a collision when two or more stations are transmitting simultaneously. Thus a probe placed on a repeater port could record more collisions than a probe connected to a station on the same segment would.