| cOutageApplVersion |
.1.3.6.1.4.1.9.9.280.1.1.1 |
|
outage monitoring application version
string.
The format will be:
'Version.Release.Patch-Level: Textual-Description'
For example: '1.0.0: Initial Outage Monitor
Application'
|
| cOutageNotificationsSent |
.1.3.6.1.4.1.9.9.280.1.1.2 |
|
The number of outage notifications that have been
sent. This number may include notifications
that were prevented from being transmitted due to
reasons such as resource limitations and/or
non-connectivity. If one is receiving notifications,
one can periodically poll this object to determine if
any notifications were missed. If missed, a poll of
the cOutageHistoryTable might be necessary.
|
| cOutageNotificationsEnabled |
.1.3.6.1.4.1.9.9.280.1.1.3 |
|
This object indicates whether outage notifications
will or will not be sent when an outage related event
is generated by the device. Disabling notifications
does not prevent outage event from being added
to the cOutageHistoryTable.
|
| cOutageNotificationFilterEnabled |
.1.3.6.1.4.1.9.9.280.1.1.4 |
|
This object indicates whether certain outage related
event notifications will or will not be sent when the
cOutageNotificationsEnabled is TRUE.
In the event structure, it is possible to have
certain hierarchies such that an event causes several
related events. The original event is called a root
event and other related events are called sub-events.
If it is enabled, only a root event notification will
be sent out and all other related sub-events will be
filtered out. The cOutageHistoryTable maintains only
the root event. However, it does not prevent the object
entries from being updated in the cOutageObjectTable.
The filtering policy, which correlates a root event and
the following sub-events, may vary and can be controlled
by the configuration.
|
| cOutageFilteredEvents |
.1.3.6.1.4.1.9.9.280.1.1.5 |
|
The number of events which were filtered out.
This object can be utilized to determine how
many following events got filtered out related
to the notified event.
|
| cOutageHistTableSize |
.1.3.6.1.4.1.9.9.280.1.2.1 |
|
The upper limit on the number of entries that the
cOutageHistoryTable may contain.
|
| cOutageHistMsgsFlushed |
.1.3.6.1.4.1.9.9.280.1.2.2 |
|
The number of entries that have been removed from
the cOutageHistoryTable in order to make room for new
entries. The value of this object starts at '0' and
monotonically increases for each flushed message.
If the value of this object is '4294967295', the value
will become '0'. This object can be utilized to
determine whether your polling frequency on the
history table is fast enough and/or the size of your
history table is large enough such that you are not
missing events.
|
| cOutageHistoryEntry |
.1.3.6.1.4.1.9.9.280.1.2.3.1 |
|
This entry contains information about an outage related
event which has been generated by this router.
|
| cOutageEventTypeMapEntry |
.1.3.6.1.4.1.9.9.280.1.3.1.1 |
|
A mapping between an event type and an event description.
|
| cOutageObjectEntry |
.1.3.6.1.4.1.9.9.280.1.4.1.1 |
|
An entry containing outage related information
applicable to a particular measurement object.
|
| cOutageCpmMapEntry |
.1.3.6.1.4.1.9.9.280.1.5.1.1 |
|
A mapping between an object index and a pair of cpm indexes.
|
| cOutageRemoteObjMapEntry |
.1.3.6.1.4.1.9.9.280.1.6.1.1 |
|
A mapping between a remote object and a remote object
description.
|
| cOutageEventIndex |
.1.3.6.1.4.1.9.9.280.1.2.3.1.1 |
|
An arbitrary non-zero integer value that uniquely
identifies a COutageHistoryEntry in the table.
The value of this table starts at '1' and monotonically
increases for each object failure and recovery event
received by the agent. If the value of this object is
'4294967295', the agent will reset it to '1' upon
receiving the next event.
|
| cOutageEventObjectType |
.1.3.6.1.4.1.9.9.280.1.2.3.1.2 |
|
This object specifies the monitored object's type.
It comprises interface(1), physicalEntity(2),
swProcess(3), and remoteObject(4).
The detailed description has been presented above
in the OutageMonObjectType definition.
|
| cOutageEventMonObjectIndex |
.1.3.6.1.4.1.9.9.280.1.2.3.1.3 |
|
This object identifies a specific index of the
monitored object based upon the cOutageEventObjectType.
If it is interface(1), it correlates the object
with ifIndex in ifTable in the IF-MIB.
If it is physicalEntity(2), it correlates the object
with entPhysicalIndex in entPhysicalTable in the
ENTITY-MIB.
If it is swProcess(3), the value corresponds to an entry
in the cOutageCpmMapTable, which correlates the object
with cpmCPUTotalIndex and cpmProcessPID in
cpmProcessTable in the CISCO-PROCESS-MIB.
If it is remoteObject(4), the value corresponds to an
entry in the cOutageRemoteObjMapTable, which correlates the
object with its ID and description.
It also correlates the event entry with a specific
entry in cOutageObjectTable.
|
| cOutageEventTypeIndex |
.1.3.6.1.4.1.9.9.280.1.2.3.1.4 |
|
The type of outage related event. The value
corresponds to an entry in the cOutageEventTypeMapTable.
|
| cOutageEventTime |
.1.3.6.1.4.1.9.9.280.1.2.3.1.5 |
|
This object specifies the date and time of the
event was generated.
The value of sysUpTime, which is reinitialized during
the router boot-up, is not sufficient, since it
shall be able to measure the outage time of the
router failure over the measurement period.
|
| cOutageEventInterval |
.1.3.6.1.4.1.9.9.280.1.2.3.1.6 |
|
Object that identifies the time duration between
transitions in available state of a component.
According to the cOutageEventTypeIndex, If the event type
is up, the interval time from the last down time is
TTR (Time To Recovery).
Otherwise, the interval time from the last up is TTF
(Time To Failure).
|
| cOutageEventTypeMapIndex |
.1.3.6.1.4.1.9.9.280.1.3.1.1.1 |
|
This object uniquely identifies an event description.
|
| cOutageEventTypeName |
.1.3.6.1.4.1.9.9.280.1.3.1.1.2 |
|
The name of the outage related event.
|
| cOutageEventTypeDescrText |
.1.3.6.1.4.1.9.9.280.1.3.1.1.3 |
|
This object specifies a human-readable
message describing information about the
outage related event.
|
| cOutageObjectType |
.1.3.6.1.4.1.9.9.280.1.4.1.1.1 |
|
This object specifies the monitored object's type.
It comprises interface(1), physicalEntity(2),
swProcess(3), and remoteObject(4).
The detailed description has been presented above
in the OutageMonObjectType definition.
|
| cOutageMonitoredObjectIndex |
.1.3.6.1.4.1.9.9.280.1.4.1.1.2 |
|
This object identifies a specific index of the
monitored object based upon the cOutageObjectType.
If it is interface(1), it correlates the object
with ifIndex in ifTable in the IF-MIB.
If it is PhysicalEntity(2), it correlates the object
with entPhysicalIndex in entPhysicalTable in the
ENTITY-MIB.
If it is SWProcess(3), the value corresponds to an entry
in the cOutageCpmMapTable, which correlates the object
with cpmCPUTotalIndex and cpmProcessPID in
cpmProcessTable in the CISCO-PROCESS-MIB.
If it is remoteObject(4), the value corresponds to an
entry in the cOutageRemoteObjMapTable, which correlates the
object with its ID and description.
|
| cOutageCurrentStatus |
.1.3.6.1.4.1.9.9.280.1.4.1.1.3 |
|
The current operational state of the monitored object.
The Up(1) state indicates that the monitored object is
actively or passively running in the normal condition.
The Down(2) state indicates that the monitored object
is experiencing some degree of outage.
|
| cOutageAOTSinceMeasureStarted |
.1.3.6.1.4.1.9.9.280.1.4.1.1.4 |
|
The total outage time in second of a component from the
beginning of the measurement. The table stores the outage
time up to the last recovery event. However, a request
comes in during the down status of a component, the report
adds the outage time between the last failure to the
current.
|
| cOutageNAFSinceMeasureStarted |
.1.3.6.1.4.1.9.9.280.1.4.1.1.5 |
|
The total number of failure instances from the beginning
of the measurement. Every failure event of a component
adds 1 to this object.
|
| cOutageCpmMapIndex |
.1.3.6.1.4.1.9.9.280.1.5.1.1.1 |
|
This object uniquely identifies cpmCPUTotalIndex and
cpmProcessPID in CISCO-PROCESS-MIB. The cpmCPUTotalIndex
is used for the cpmCPUTotalTable reference. A pair of
{ cpmCPUTotalIndex, cpmProcessPID } is used for the
cpmProcessTable reference.
|
| cOutageCpmCPUTotalIndex |
.1.3.6.1.4.1.9.9.280.1.5.1.1.2 |
|
An index that uniquely represents a CPU in cpmCPUTotalTable
in CISCO-PROCESS-MIB.
|
| cOutageCpmProcessPID |
.1.3.6.1.4.1.9.9.280.1.5.1.1.3 |
|
This object contains the process ID. It identifies an
entry combined with cpmCPUTotalIndex in cpmProcessTable
in CISCO-PROCESS-MIB.
|
| cOutageRemoteObjMapIndex |
.1.3.6.1.4.1.9.9.280.1.6.1.1.1 |
|
This object uniquely identifies a remote object
description.
|
| cOutageRemoteObjIDType |
.1.3.6.1.4.1.9.9.280.1.6.1.1.2 |
|
Represents the type of address stored in
cOutageRemoteObjID.
|
| cOutageRemoteObjID |
.1.3.6.1.4.1.9.9.280.1.6.1.1.3 |
|
This object represents the Network Layer Address
of the remote object, which is configured by
users via configuration file or CLI.
It could be an IP address or DNS
depends on users input.
|
| cOutageRemoteObjDescrText |
.1.3.6.1.4.1.9.9.280.1.6.1.1.4 |
|
This object specifies a human-readable
message describing information about the
monitored remote components such as router name
or interface name, etc.
|
| cOutageHistoryTable |
.1.3.6.1.4.1.9.9.280.1.2.3 |
|
A table of outage related events generated by this router.
Conceptual row entries are dynamically added into this
table when outage related events occur.
Entries are stored in FIFO order. When the maximum number
of entries has been reached in the table, the oldest entry
in the table is removed immediately.
When a table is reduced to a smaller size N, the oldest
entries are immediately removed from the table leaving
a maximum of N entries.
|
| cOutageEventTypeMapTable |
.1.3.6.1.4.1.9.9.280.1.3.1 |
|
A table containing information about
cOutageEventTypeMapIndex value mapping.
Each conceptual row specifies a unique mapping
between a cOutageEventTypeMapIndex value, and an
outage related event type.
|
| cOutageObjectTable |
.1.3.6.1.4.1.9.9.280.1.4.1 |
|
A table of monitored object entries generated
by this router, which include interface, physical
entry, and software process.
The conceptual row entries are initially established
during the monitoring start-up procedure based upon
configuration set-up. The entries are also dynamically
added into this table when a new object is detected.
The entry information will be updated, when the outage
related event occurs.
The entry will be removed only by configuration reset.
|
| cOutageCpmMapTable |
.1.3.6.1.4.1.9.9.280.1.5.1 |
|
A table containing information about
cOutageMonitoredObjectIndex value mapping,
when the cOutageObjectType is swProcess.
Each conceptual row specifies a unique mapping
between a cOutageMonitoredObjectIndex value, and
cpmCPUTotalIndex and cpmProcessPID in
cpmProcessTable in the CISCO-PROCESS-MIB.
|
| cOutageRemoteObjMapTable |
.1.3.6.1.4.1.9.9.280.1.6.1 |
|
A table containing information about
cOutageMonitoredObjectIndex value mapping,
when the cOutageObjectType is remoteObject.
Each conceptual row specifies a unique mapping
between a cOutageMonitoredObjectIndex value, and
a remote object related information such as the
object ID and the object description.
Using IP ICMP protocol to monitor the remote object,
the object ID can be Network Layer Address, which
has been configured by users via configuration file
or CLI.
|
| ciscoOutageMIB |
.1.3.6.1.4.1.9.9.280 |
|
This MIB module describes, stores, and reports outage
related information generated by individual hardware
and software components comprising a router. They includes
physical interfaces, logical interfaces, physical
entities such as chassis, slots, modules, ports,
power supplies, and fan, and software processes
running on each card.
The outage related information comprises entity or
interface up and down, process start and abnormal
or normal termination, unusually high CPU utilization
caused, for example, by Denial of Service (DoS) attack,
etc.
The outage related event can be collected by means of
Cisco's fault manager, Cisco's event manager, and
syslog messages, etc.
An outage manager maintains the following outage data
for each component.
1) Accumulated Outage Time (AOT): total outage
time of a component from the beginning of
the measurement.
2) Number of Accumulated Failure (NAF): total
number of failure instance from the
beginning of the measurement.
Using aforementioned outage data, users can calculate
and correlate to derive availability information as
follows:
1) Component Availability: the probability
that a component will operate when needed.
= (1 - (Outage Time / Duration))
2) DPM (Defects per Million): measure(s) of the
defects of the system that have an immediate
impact on the end-user.
= ([AOTi / (Measurement Interval)] x 10**6)
3) MTTR(Mean Time To Recovery): expected average
time to restore a failed component.
= (AOTi / NAFi)
4) MTBF (Mean Time Between Failure): expected
average time between failures of a component.
= (T2 - T1) / NAFi
5) MTTF (Mean Time To Failure): the mean time to
failure once the device starts working.
= (MTBFi - MTTRi = (T2 - T1 - AOTi) / NAFi)
measurement 1
|<----------------->|
| |
System Up @------|-------------------|----> Time
T1 T2
At the beginning T1:
tmp_AOT = AOTi (from the MIB polling);
LastPollingTime = Current Time(T1);
At the end T2:
Duration = Current Time(T2) - LastPollingTime(T1);
Outage Time = AOTj - tmp_AOT;
|
| ciscoOutageMIBObjects |
.1.3.6.1.4.1.9.9.280.1 |
| cOutageBasicInfo |
.1.3.6.1.4.1.9.9.280.1.1 |
| cOutageHistory |
.1.3.6.1.4.1.9.9.280.1.2 |
| cOutageDescription |
.1.3.6.1.4.1.9.9.280.1.3 |
| cOutageMonObject |
.1.3.6.1.4.1.9.9.280.1.4 |
| cOutageCpmMapping |
.1.3.6.1.4.1.9.9.280.1.5 |
| cOutageRmtMapping |
.1.3.6.1.4.1.9.9.280.1.6 |
| ciscoOutageMIBNotificationPrefix |
.1.3.6.1.4.1.9.9.280.2 |
| ciscoOutageMIBNotifications |
.1.3.6.1.4.1.9.9.280.2.0 |
| ciscoOutageMIBConformance |
.1.3.6.1.4.1.9.9.280.3 |
| ciscoOutageMIBCompliances |
.1.3.6.1.4.1.9.9.280.3.1 |
| ciscoOutageMIBGroups |
.1.3.6.1.4.1.9.9.280.3.2 |
