This MIB module defines objects that describe flow monitoring.
A typical application of this MIB module will facilitate
monitoring media flows, especially flows carrying video streams.
However, by no means does the definition of this MIB module
prevents other applications from using it.
FLOW MONITORS
=================
At the top level, this MIB module describes the notion of a flow
monitor. A flow monitor is a hardware or software entity that
classifies traffic flows, collects data on conforming traffic
flows, and periodically computes metrics that reflect the
quality of the traffic flows. Because a device can support more
than one flow monitor, the MIB module defines the
cfmFlowMonitorTable. Consider an edge router that supports a
certain line card that has an integrated capability to monitor
video flows. In this example, the cfmFlowMonitorTable would
contain a row describing each line card installed in the device.
TRAFFIC FLOWS
=================
At the next level, this MIB module describes the notion of a
traffic flow. This MIB module uniquely identifies a traffic
flow using an auxiliary variable called cfmFlowId; however, an
implementation only has guarantee its uniqueness within the
scope of the flow monitor that has the responsibility for
monitoring the traffic flow. Thus, we can think of the flow
monitor as a container for the traffic flows for which it
collects data and periodically computes metrics, as the figure
below illustrates.
+
| cfmFlowTable |
| |
+
| cfmFlowMonitorId = 3
+
| | cfmFlowId = 101 | |
| +
| +
| | cfmFlowMonitorId = 3 | |
| | cfmFlowId = 102 | |
| +
| : |
| : |
| +
| | cfmFlowMonitorId = 3 | |
| | cfmFlowId = 150 | |
| +
+
| |
+
| cfmFlowMonitorId = 4
+
| | cfmFlowId = 1 | |
| +
| +
| | cfmFlowMonitorId = 4 | |
| | cfmFlowId = 2 | |
| +
| : |
| : |
| +
| | cfmFlowMonitorId = 4 | |
| | cfmFlowId = 150 | |
| +
+
| |
+
While the identifying of a traffic flow using this auxiliary
variable is convenient for the MIB module, it is does suffice
for an EMS/NMS trying to isolate faults in a network delivering
these traffic flows. To aid an EMS/NMS in this task, this MIB
module defines a number of tables that provide layers of data
relating to a traffic flow, including:
o cfmFlowL2VlanTable - describes L2 VLAN data relating to
traffic flows.
o cfmFlowIpTable - describes IP data relating to traffic
flows.
o cfmFlowUdpTable - describes UDP data relating to traffic
flows.
o cfmFlowTcpTable - describes TCP data relating to traffic
flows.
o cfmFlowRtpTable - describes RTP data relating to traffic
flows.
Each of these tables have a sparse dependent relationship on the
cfmFlowTable, as there exist situations when the data may not be
available for a traffic flow, including:
1) The flow monitor simply may not collect the particular
data for the traffic flows that it has the
responsibility of monitoring. For example, a flow
monitor may not have any concern for L2 VLAN data.
2) The data may not apply to a traffic flow. For example,
a TCP and RTP data do not apply for a UDP traffic flow.
To help an EMS/NMS navigate the data collected for a traffic
flow, the corresponding rows are daisy-chained using 'next
objects'. An EMS/NMS starts with cfmFlowNext, which indicates a
reference to the row in the next table containing data related
to the traffic flow. The first object contained by each of
these tables is a 'next object'. Consider a RTP traffic flow
for which the flow monitor has collected IP, UDP, and RTP data.
The figure below illustrates how this MIB module daisy chains
this data through the relevant tables.
+
| cfmFlowTable |
| +
| | cfmFlowMonitorId = 3 | |
| | cfmFlowId = 42 | |
| | cfmFlowNext = cfmFlowIpNext.3.42
| +
+
|
+
| cfmFlowIpTable | |
| +
| | cfmFlowMonitorId = 3 |<
| | cfmFlowId = 42 | |
| | cfmFlowIpNext = cfmFlowUdpNext.3.42
| +
+
|
+
| cfmFlowUdpTable | |
| +
| | cfmFlowMonitorId = 3 |<
| | cfmFlowId = 42 | |
| | cfmFlowUdpNext = cfmFlowRtpNext.3.42
| +
+
|
+
| cfmFlowRtpTable | |
| +
| | cfmFlowMonitorId = 3 |<
| | cfmFlowId = 42 | |
| | cfmFlowRtpNext = zeroDotZero | |
| +
+
Observe that this structure simplifies the task of extending the
MIB module to support additional layers of data. For example,
if there is a need for a device to collect data relating to the
MPEG-TS layer of a flow carrying a video stream, then it is as
simple as defining a table containing this data. However, the
definition of such a table must comply with the following
requirements:
1) The table must have a sparse dependent relationship on
the cfmFlowTable.
2) The first object contained by the table must be a 'next
object' to support daisy chaining.
REPORTING FLOW METRICS
==========================
At the next level, the MIB defines two tables that together form
the foundation for reporting metrics. The cfmFlowMetricsTable
has a one-to-one dependent relationship on the cfmFlowTable, and
it contains data aggregate metrics and data relating to the
collection of metrics for the corresponding traffic flow. A row
in this table also serves as a container for the historic
metrics computed by the corresponding flow monitor, as the
figure below illustrates.
+
| cfmFlowMetricsIntTable |
| |
+
| cfmFlowMetricsEntry |
| | | | cfmFlowMonitorId = 3 | |
| cfmFlowMonitorId = 3 | | | cfmFlowId = 101 | |
| cfmFlowid = 101 | | | cfmFlowMetricsIntNumber = 1 | |
+
| +
| | cfmFlowMonitorId = 3 | |
| | cfmFlowId = 101 | |
| | cfmFlowMetricsIntNumber = 2 | |
| +
| : |
| : |
| +
| | cfmFlowMonitorId = 3 | |
| | cfmFlowId = 101 | |
| | cfmFlowMetricsIntNumber = N | |
| +
+
| |
+
The device collects data for a traffic flow over a configured
measurement interval, indicated by cfmFlowMetricsIntervalTime.
At the end of a measurement interval, the device computes
metrics from this data, generating a report. An EMS/NMS can
access this report using the cfmFlowMetricsIntTable.
cfmFlowMetricsMaxInterval indicates the maximum number of
reports a device will save for the corresponding traffic flow,
while cfmFlowMetricsIntervals indicates the number of reports
currently saved by the device.
The cfmFlowMetricsTable and cfmFlowMetricsIntTable have the
intent of providing a foundation for reporting metrics for a
traffic flow. Furthermore, it is the intent that additional MIB
modules define extensions to these tables describing specific
sets of metrics. The following list provides some examples:
o CISCO-FLOW-MON-MDI-MIB - this MIB module defines
extensions that describe MDI metrics defined by
RFC-4445.
o CISCO-FLOW-MON-RTP-MIB - this MIB module defines
extensions that describe RTP metrics defined by
RFC-3550.
o CISCO-FLOW-MON-IP-CBR-MIB - this MIB module defines
extension that describe IP CBR metrics.
The tables defined by these MIB modules have a sparse dependent
relationhip on the cfmFlowMetricsTable and
cfmFlowMetricsIntTable. An EMS/NMS can determine the metrics
collected for a traffic flow from the corresponding instance of
cfmFlowMetricsCollected, which is nothing more than a bit
string-value for which each bit corresponds to a different set
of metrics.
FAULT MANAGEMENT
====================
At the next level, this MIB module defines tables that describe
standing conditions. A standing condition is a lasting error,
fault, or warning resulting from the application of a set of
criteria to the state of an entity.
For example, a flow monitor ceases monitoring a traffic flow
when it has not received any packets for that traffic flow in a
configured interval of time. If flow monitor expires a
significantly large number of traffic flows during a measurement
interval, then this might signal a fault.
In this example, the 'set of criteria' is a rising threshold and
the 'state of an entity' is the number of traffic flows
expired by a flow monitor.
The cfmConditionTable describes the criteria applied to entities
managed by the device, specifically flow monitors and traffic
flows. The table groups these criteria into 'conditions
profiles'. The device periodically applies these criteria
to an entity and saves the results in a bit string-value
associated with the entity.
An EMS/NMS can monitor the most recent standing conditions for a
flow monitor by retrieving the corresponding instance of
cfmFlowMonitorConditions. Likewise, an EMS/NMS can monitor the
most recent standing conditions for a traffic flow by retrieving
the corresponding instance of cfmFlowMetricsConditions.
It goes without saying that monitoring the standing conditions
for significantly large numbers of traffic flows becomes
problematic. To aid an EMS/NMS in this task, this MIB module
defines many mechanisms. The most basic of these mechanisms is
the notion of an alarm, which is simply a standing condition for
which the device signals changes in state. This MIB module
provides for three means of signaling when the device raises or
clears an alarm condition:
1) Logging - the device creates a record of the event and
saves it in a historical account.
2) syslog - the device generates a syslog message
containing details of the event and sends it to one
or more configured syslog server.
3) SNMP - the device generates a SNMP notification
containing details of the event and sends it to one
or more configured targets.
An EMS/NMS can monitor the most recent alarm conditions for a
flow monitor by retrieving the corresponding instance of
cfmFlowMonitorAlarms. Likewise, the EMS/NMS can monitor the
most recent alarm conditions for a traffic flow by retrieving
the corresponding instance of cfmFlowMetricsAlarms.
Additionally, the EMS/NMS can poll a summary of alarm conditions
maintained for each flow monitor and the traffic flows that it
monitors. The following list summarizes the data contained by
this summary:
o cfmFlowMonitorAlarmSeverity
o cfmFlowMonitorAlarmCriticalCount
o cfmFlowMonitorAlarmMajorCount
o cfmFlowMonitorAlarmMinorCount
o cfmFlowMonitorAlarmWarningCount
o cfmFlowMonitorAlarmInfoCount
An EMS/NMS can also poll cfmAlarmHistoryLastId, which indicates
the value of the identifier assigned to the last record saved to
the historical account. When it observes a change in the value
of this object, then it can retrieve the new records from the
cfmAlarmHistoryTable.
The burden of monitoring alarm conditions for sufficiently large
numbers of traffic flows can itself become a daunting task.
Thus, this MIB module defines the notion of an alarm group,
which represents a single alarm condition that aggregates a
standing condition for a set of traffic flows. The
cfmAlarmGroupTable describes the alarm groups configured for a
device, and the cfmAlarmGroupFlowTable describes the sets of
flows aggregated by these alarm groups.
GLOSSARY
============
Alarm Action - a method used by the device to signal changes in
an alarm condition.
Alarm Aggregation - a technique used to efficiently monitor the
same standing condition for a flow set.
Alarm Condition - a standing condition for which the device
signals changes in state.
Alarm Group - a flow set for which the device monitors a
configured standing condition, raising an alarm when a
configured number of flows in the flow set assert the
standing standing.
Alarm Severity - the relative disposition of an alarm condition
when raised by the device. For example, a provider may
regard a flow stop alarm as having a higher severity than a
flow's loss fraction exceeding a configured threshold.
Flow Monitor - a hardware or software entity that classifies
traffic flows, collects flow data, and periodically
computes flow metrics.
Flow Metric - a measurement that reflects the quality of a
traffic flow.
Flow Point - represents the ingress or egress of a traffic flow.
Flow Set - a group of traffic flows.
Measurement Interval - the length of time over which a flow
monitor collects data related to a traffic flow, after which
the flow monitor computes flow metrics using the collected
data.
Standing Condition - represents a lasting error, fault, or
warning resulting from the application of a set of criteria
to the state of an entity, such as a flow monitor or traffic
flow. For example, a flow monitor may assert a standing
condition if the number of traffic flows that expire in a
measurement interval exceeds a configured threshold.
Traffic Flow - a unidirectional stream of packets conforming to
a classifier. For example, packets having a particular
source IP address, destination IP address, protocol type,
source port number, and destination port number.
Parsed from file CISCO-FLOW-MONITOR-MIB.mib
Module: CISCO-FLOW-MONITOR-MIB
This MIB module defines objects that describe flow monitoring.
A typical application of this MIB module will facilitate
monitoring media flows, especially flows carrying video streams.
However, by no means does the definition of this MIB module
prevents other applications from using it.
FLOW MONITORS
=================
At the top level, this MIB module describes the notion of a flow
monitor. A flow monitor is a hardware or software entity that
classifies traffic flows, collects data on conforming traffic
flows, and periodically computes metrics that reflect the
quality of the traffic flows. Because a device can support more
than one flow monitor, the MIB module defines the
cfmFlowMonitorTable. Consider an edge router that supports a
certain line card that has an integrated capability to monitor
video flows. In this example, the cfmFlowMonitorTable would
contain a row describing each line card installed in the device.
TRAFFIC FLOWS
=================
At the next level, this MIB module describes the notion of a
traffic flow. This MIB module uniquely identifies a traffic
flow using an auxiliary variable called cfmFlowId; however, an
implementation only has guarantee its uniqueness within the
scope of the flow monitor that has the responsibility for
monitoring the traffic flow. Thus, we can think of the flow
monitor as a container for the traffic flows for which it
collects data and periodically computes metrics, as the figure
below illustrates.
+
| cfmFlowTable |
| |
+
| cfmFlowMonitorId = 3
+
| | cfmFlowId = 101 | |
| +
| +
| | cfmFlowMonitorId = 3 | |
| | cfmFlowId = 102 | |
| +
| : |
| : |
| +
| | cfmFlowMonitorId = 3 | |
| | cfmFlowId = 150 | |
| +
+
| |
+
| cfmFlowMonitorId = 4
+
| | cfmFlowId = 1 | |
| +
| +
| | cfmFlowMonitorId = 4 | |
| | cfmFlowId = 2 | |
| +
| : |
| : |
| +
| | cfmFlowMonitorId = 4 | |
| | cfmFlowId = 150 | |
| +
+
| |
+
While the identifying of a traffic flow using this auxiliary
variable is convenient for the MIB module, it is does suffice
for an EMS/NMS trying to isolate faults in a network delivering
these traffic flows. To aid an EMS/NMS in this task, this MIB
module defines a number of tables that provide layers of data
relating to a traffic flow, including:
o cfmFlowL2VlanTable - describes L2 VLAN data relating to
traffic flows.
o cfmFlowIpTable - describes IP data relating to traffic
flows.
o cfmFlowUdpTable - describes UDP data relating to traffic
flows.
o cfmFlowTcpTable - describes TCP data relating to traffic
flows.
o cfmFlowRtpTable - describes RTP data relating to traffic
flows.
Each of these tables have a sparse dependent relationship on the
cfmFlowTable, as there exist situations when the data may not be
available for a traffic flow, including:
1) The flow monitor simply may not collect the particular
data for the traffic flows that it has the
responsibility of monitoring. For example, a flow
monitor may not have any concern for L2 VLAN data.
2) The data may not apply to a traffic flow. For example,
a TCP and RTP data do not apply for a UDP traffic flow.
To help an EMS/NMS navigate the data collected for a traffic
flow, the corresponding rows are daisy-chained using 'next
objects'. An EMS/NMS starts with cfmFlowNext, which indicates a
reference to the row in the next table containing data related
to the traffic flow. The first object contained by each of
these tables is a 'next object'. Consider a RTP traffic flow
for which the flow monitor has collected IP, UDP, and RTP data.
The figure below illustrates how this MIB module daisy chains
this data through the relevant tables.
+
| cfmFlowTable |
| +
| | cfmFlowMonitorId = 3 | |
| | cfmFlowId = 42 | |
| | cfmFlowNext = cfmFlowIpNext.3.42
| +
+
|
+
| cfmFlowIpTable | |
| +
| | cfmFlowMonitorId = 3 |<
| | cfmFlowId = 42 | |
| | cfmFlowIpNext = cfmFlowUdpNext.3.42
| +
+
|
+
| cfmFlowUdpTable | |
| +
| | cfmFlowMonitorId = 3 |<
| | cfmFlowId = 42 | |
| | cfmFlowUdpNext = cfmFlowRtpNext.3.42
| +
+
|
+
| cfmFlowRtpTable | |
| +
| | cfmFlowMonitorId = 3 |<
| | cfmFlowId = 42 | |
| | cfmFlowRtpNext = zeroDotZero | |
| +
+
Observe that this structure simplifies the task of extending the
MIB module to support additional layers of data. For example,
if there is a need for a device to collect data relating to the
MPEG-TS layer of a flow carrying a video stream, then it is as
simple as defining a table containing this data. However, the
definition of such a table must comply with the following
requirements:
1) The table must have a sparse dependent relationship on
the cfmFlowTable.
2) The first object contained by the table must be a 'next
object' to support daisy chaining.
REPORTING FLOW METRICS
==========================
At the next level, the MIB defines two tables that together form
the foundation for reporting metrics. The cfmFlowMetricsTable
has a one-to-one dependent relationship on the cfmFlowTable, and
it contains data aggregate metrics and data relating to the
collection of metrics for the corresponding traffic flow. A row
in this table also serves as a container for the historic
metrics computed by the corresponding flow monitor, as the
figure below illustrates.
+
| cfmFlowMetricsIntTable |
| |
+
| cfmFlowMetricsEntry |
| | | | cfmFlowMonitorId = 3 | |
| cfmFlowMonitorId = 3 | | | cfmFlowId = 101 | |
| cfmFlowid = 101 | | | cfmFlowMetricsIntNumber = 1 | |
+
| +
| | cfmFlowMonitorId = 3 | |
| | cfmFlowId = 101 | |
| | cfmFlowMetricsIntNumber = 2 | |
| +
| : |
| : |
| +
| | cfmFlowMonitorId = 3 | |
| | cfmFlowId = 101 | |
| | cfmFlowMetricsIntNumber = N | |
| +
+
| |
+
The device collects data for a traffic flow over a configured
measurement interval, indicated by cfmFlowMetricsIntervalTime.
At the end of a measurement interval, the device computes
metrics from this data, generating a report. An EMS/NMS can
access this report using the cfmFlowMetricsIntTable.
cfmFlowMetricsMaxInterval indicates the maximum number of
reports a device will save for the corresponding traffic flow,
while cfmFlowMetricsIntervals indicates the number of reports
currently saved by the device.
The cfmFlowMetricsTable and cfmFlowMetricsIntTable have the
intent of providing a foundation for reporting metrics for a
traffic flow. Furthermore, it is the intent that additional MIB
modules define extensions to these tables describing specific
sets of metrics. The following list provides some examples:
o CISCO-FLOW-MON-MDI-MIB - this MIB module defines
extensions that describe MDI metrics defined by
RFC-4445.
o CISCO-FLOW-MON-RTP-MIB - this MIB module defines
extensions that describe RTP metrics defined by
RFC-3550.
o CISCO-FLOW-MON-IP-CBR-MIB - this MIB module defines
extension that describe IP CBR metrics.
The tables defined by these MIB modules have a sparse dependent
relationhip on the cfmFlowMetricsTable and
cfmFlowMetricsIntTable. An EMS/NMS can determine the metrics
collected for a traffic flow from the corresponding instance of
cfmFlowMetricsCollected, which is nothing more than a bit
string-value for which each bit corresponds to a different set
of metrics.
FAULT MANAGEMENT
====================
At the next level, this MIB module defines tables that describe
standing conditions. A standing condition is a lasting error,
fault, or warning resulting from the application of a set of
criteria to the state of an entity.
For example, a flow monitor ceases monitoring a traffic flow
when it has not received any packets for that traffic flow in a
configured interval of time. If flow monitor expires a
significantly large number of traffic flows during a measurement
interval, then this might signal a fault.
In this example, the 'set of criteria' is a rising threshold and
the 'state of an entity' is the number of traffic flows
expired by a flow monitor.
The cfmConditionTable describes the criteria applied to entities
managed by the device, specifically flow monitors and traffic
flows. The table groups these criteria into 'conditions
profiles'. The device periodically applies these criteria
to an entity and saves the results in a bit string-value
associated with the entity.
An EMS/NMS can monitor the most recent standing conditions for a
flow monitor by retrieving the corresponding instance of
cfmFlowMonitorConditions. Likewise, an EMS/NMS can monitor the
most recent standing conditions for a traffic flow by retrieving
the corresponding instance of cfmFlowMetricsConditions.
It goes without saying that monitoring the standing conditions
for significantly large numbers of traffic flows becomes
problematic. To aid an EMS/NMS in this task, this MIB module
defines many mechanisms. The most basic of these mechanisms is
the notion of an alarm, which is simply a standing condition for
which the device signals changes in state. This MIB module
provides for three means of signaling when the device raises or
clears an alarm condition:
1) Logging - the device creates a record of the event and
saves it in a historical account.
2) syslog - the device generates a syslog message
containing details of the event and sends it to one
or more configured syslog server.
3) SNMP - the device generates a SNMP notification
containing details of the event and sends it to one
or more configured targets.
An EMS/NMS can monitor the most recent alarm conditions for a
flow monitor by retrieving the corresponding instance of
cfmFlowMonitorAlarms. Likewise, the EMS/NMS can monitor the
most recent alarm conditions for a traffic flow by retrieving
the corresponding instance of cfmFlowMetricsAlarms.
Additionally, the EMS/NMS can poll a summary of alarm conditions
maintained for each flow monitor and the traffic flows that it
monitors. The following list summarizes the data contained by
this summary:
o cfmFlowMonitorAlarmSeverity
o cfmFlowMonitorAlarmCriticalCount
o cfmFlowMonitorAlarmMajorCount
o cfmFlowMonitorAlarmMinorCount
o cfmFlowMonitorAlarmWarningCount
o cfmFlowMonitorAlarmInfoCount
An EMS/NMS can also poll cfmAlarmHistoryLastId, which indicates
the value of the identifier assigned to the last record saved to
the historical account. When it observes a change in the value
of this object, then it can retrieve the new records from the
cfmAlarmHistoryTable.
The burden of monitoring alarm conditions for sufficiently large
numbers of traffic flows can itself become a daunting task.
Thus, this MIB module defines the notion of an alarm group,
which represents a single alarm condition that aggregates a
standing condition for a set of traffic flows. The
cfmAlarmGroupTable describes the alarm groups configured for a
device, and the cfmAlarmGroupFlowTable describes the sets of
flows aggregated by these alarm groups.
GLOSSARY
============
Alarm Action - a method used by the device to signal changes in
an alarm condition.
Alarm Aggregation - a technique used to efficiently monitor the
same standing condition for a flow set.
Alarm Condition - a standing condition for which the device
signals changes in state.
Alarm Group - a flow set for which the device monitors a
configured standing condition, raising an alarm when a
configured number of flows in the flow set assert the
standing standing.
Alarm Severity - the relative disposition of an alarm condition
when raised by the device. For example, a provider may
regard a flow stop alarm as having a higher severity than a
flow's loss fraction exceeding a configured threshold.
Flow Monitor - a hardware or software entity that classifies
traffic flows, collects flow data, and periodically
computes flow metrics.
Flow Metric - a measurement that reflects the quality of a
traffic flow.
Flow Point - represents the ingress or egress of a traffic flow.
Flow Set - a group of traffic flows.
Measurement Interval - the length of time over which a flow
monitor collects data related to a traffic flow, after which
the flow monitor computes flow metrics using the collected
data.
Standing Condition - represents a lasting error, fault, or
warning resulting from the application of a set of criteria
to the state of an entity, such as a flow monitor or traffic
flow. For example, a flow monitor may assert a standing
condition if the number of traffic flows that expire in a
measurement interval exceeds a configured threshold.
Traffic Flow - a unidirectional stream of packets conforming to
a classifier. For example, packets having a particular
source IP address, destination IP address, protocol type,
source port number, and destination port number.
Parsed from file CISCO-FLOW-MONITOR-MIB.my.txt
Company: None
Module: CISCO-FLOW-MONITOR-MIB
This MIB module defines objects that describe flow monitoring.
A typical application of this MIB module will facilitate
monitoring media flows, especially flows carrying video streams.
However, by no means does the definition of this MIB module
prevents other applications from using it.
FLOW MONITORS
=================
At the top level, this MIB module describes the notion of a flow
monitor. A flow monitor is a hardware or software entity that
classifies traffic flows, collects data on conforming traffic
flows, and periodically computes metrics that reflect the
quality of the traffic flows. Because a device can support more
than one flow monitor, the MIB module defines the
cfmFlowMonitorTable. Consider an edge router that supports a
certain line card that has an integrated capability to monitor
video flows. In this example, the cfmFlowMonitorTable would
contain a row describing each line card installed in the device.
TRAFFIC FLOWS
=================
At the next level, this MIB module describes the notion of a
traffic flow. This MIB module uniquely identifies a traffic
flow using an auxiliary variable called cfmFlowId; however, an
implementation only has guarantee its uniqueness within the
scope of the flow monitor that has the responsibility for
monitoring the traffic flow. Thus, we can think of the flow
monitor as a container for the traffic flows for which it
collects data and periodically computes metrics, as the figure
below illustrates.
+
| cfmFlowTable |
| |
+
| cfmFlowMonitorId = 3
+
| | cfmFlowId = 101 | |
| +
| +
| | cfmFlowMonitorId = 3 | |
| | cfmFlowId = 102 | |
| +
| : |
| : |
| +
| | cfmFlowMonitorId = 3 | |
| | cfmFlowId = 150 | |
| +
+
| |
+
| cfmFlowMonitorId = 4
+
| | cfmFlowId = 1 | |
| +
| +
| | cfmFlowMonitorId = 4 | |
| | cfmFlowId = 2 | |
| +
| : |
| : |
| +
| | cfmFlowMonitorId = 4 | |
| | cfmFlowId = 150 | |
| +
+
| |
+
While the identifying of a traffic flow using this auxiliary
variable is convenient for the MIB module, it is does suffice
for an EMS/NMS trying to isolate faults in a network delivering
these traffic flows. To aid an EMS/NMS in this task, this MIB
module defines a number of tables that provide layers of data
relating to a traffic flow, including:
o cfmFlowL2VlanTable - describes L2 VLAN data relating to
traffic flows.
o cfmFlowIpTable - describes IP data relating to traffic
flows.
o cfmFlowUdpTable - describes UDP data relating to traffic
flows.
o cfmFlowTcpTable - describes TCP data relating to traffic
flows.
o cfmFlowRtpTable - describes RTP data relating to traffic
flows.
Each of these tables have a sparse dependent relationship on the
cfmFlowTable, as there exist situations when the data may not be
available for a traffic flow, including:
1) The flow monitor simply may not collect the particular
data for the traffic flows that it has the
responsibility of monitoring. For example, a flow
monitor may not have any concern for L2 VLAN data.
2) The data may not apply to a traffic flow. For example,
a TCP and RTP data do not apply for a UDP traffic flow.
To help an EMS/NMS navigate the data collected for a traffic
flow, the corresponding rows are daisy-chained using 'next
objects'. An EMS/NMS starts with cfmFlowNext, which indicates a
reference to the row in the next table containing data related
to the traffic flow. The first object contained by each of
these tables is a 'next object'. Consider a RTP traffic flow
for which the flow monitor has collected IP, UDP, and RTP data.
The figure below illustrates how this MIB module daisy chains
this data through the relevant tables.
+
| cfmFlowTable |
| +
| | cfmFlowMonitorId = 3 | |
| | cfmFlowId = 42 | |
| | cfmFlowNext = cfmFlowIpNext.3.42
| +
+
|
+
| cfmFlowIpTable | |
| +
| | cfmFlowMonitorId = 3 |<
| | cfmFlowId = 42 | |
| | cfmFlowIpNext = cfmFlowUdpNext.3.42
| +
+
|
+
| cfmFlowUdpTable | |
| +
| | cfmFlowMonitorId = 3 |<
| | cfmFlowId = 42 | |
| | cfmFlowUdpNext = cfmFlowRtpNext.3.42
| +
+
|
+
| cfmFlowRtpTable | |
| +
| | cfmFlowMonitorId = 3 |<
| | cfmFlowId = 42 | |
| | cfmFlowRtpNext = zeroDotZero | |
| +
+
Observe that this structure simplifies the task of extending the
MIB module to support additional layers of data. For example,
if there is a need for a device to collect data relating to the
MPEG-TS layer of a flow carrying a video stream, then it is as
simple as defining a table containing this data. However, the
definition of such a table must comply with the following
requirements:
1) The table must have a sparse dependent relationship on
the cfmFlowTable.
2) The first object contained by the table must be a 'next
object' to support daisy chaining.
REPORTING FLOW METRICS
==========================
At the next level, the MIB defines two tables that together form
the foundation for reporting metrics. The cfmFlowMetricsTable
has a one-to-one dependent relationship on the cfmFlowTable, and
it contains data aggregate metrics and data relating to the
collection of metrics for the corresponding traffic flow. A row
in this table also serves as a container for the historic
metrics computed by the corresponding flow monitor, as the
figure below illustrates.
+
| cfmFlowMetricsIntTable |
| |
+
| cfmFlowMetricsEntry |
| | | | cfmFlowMonitorId = 3 | |
| cfmFlowMonitorId = 3 | | | cfmFlowId = 101 | |
| cfmFlowid = 101 | | | cfmFlowMetricsIntNumber = 1 | |
+
| +
| | cfmFlowMonitorId = 3 | |
| | cfmFlowId = 101 | |
| | cfmFlowMetricsIntNumber = 2 | |
| +
| : |
| : |
| +
| | cfmFlowMonitorId = 3 | |
| | cfmFlowId = 101 | |
| | cfmFlowMetricsIntNumber = N | |
| +
+
| |
+
The device collects data for a traffic flow over a configured
measurement interval, indicated by cfmFlowMetricsIntervalTime.
At the end of a measurement interval, the device computes
metrics from this data, generating a report. An EMS/NMS can
access this report using the cfmFlowMetricsIntTable.
cfmFlowMetricsMaxInterval indicates the maximum number of
reports a device will save for the corresponding traffic flow,
while cfmFlowMetricsIntervals indicates the number of reports
currently saved by the device.
The cfmFlowMetricsTable and cfmFlowMetricsIntTable have the
intent of providing a foundation for reporting metrics for a
traffic flow. Furthermore, it is the intent that additional MIB
modules define extensions to these tables describing specific
sets of metrics. The following list provides some examples:
o CISCO-FLOW-MON-MDI-MIB - this MIB module defines
extensions that describe MDI metrics defined by
RFC-4445.
o CISCO-FLOW-MON-RTP-MIB - this MIB module defines
extensions that describe RTP metrics defined by
RFC-3550.
o CISCO-FLOW-MON-IP-CBR-MIB - this MIB module defines
extension that describe IP CBR metrics.
The tables defined by these MIB modules have a sparse dependent
relationhip on the cfmFlowMetricsTable and
cfmFlowMetricsIntTable. An EMS/NMS can determine the metrics
collected for a traffic flow from the corresponding instance of
cfmFlowMetricsCollected, which is nothing more than a bit
string-value for which each bit corresponds to a different set
of metrics.
FAULT MANAGEMENT
====================
At the next level, this MIB module defines tables that describe
standing conditions. A standing condition is a lasting error,
fault, or warning resulting from the application of a set of
criteria to the state of an entity.
For example, a flow monitor ceases monitoring a traffic flow
when it has not received any packets for that traffic flow in a
configured interval of time. If flow monitor expires a
significantly large number of traffic flows during a measurement
interval, then this might signal a fault.
In this example, the 'set of criteria' is a rising threshold and
the 'state of an entity' is the number of traffic flows
expired by a flow monitor.
The cfmConditionTable describes the criteria applied to entities
managed by the device, specifically flow monitors and traffic
flows. The table groups these criteria into 'conditions
profiles'. The device periodically applies these criteria
to an entity and saves the results in a bit string-value
associated with the entity.
An EMS/NMS can monitor the most recent standing conditions for a
flow monitor by retrieving the corresponding instance of
cfmFlowMonitorConditions. Likewise, an EMS/NMS can monitor the
most recent standing conditions for a traffic flow by retrieving
the corresponding instance of cfmFlowMetricsConditions.
It goes without saying that monitoring the standing conditions
for significantly large numbers of traffic flows becomes
problematic. To aid an EMS/NMS in this task, this MIB module
defines many mechanisms. The most basic of these mechanisms is
the notion of an alarm, which is simply a standing condition for
which the device signals changes in state. This MIB module
provides for three means of signaling when the device raises or
clears an alarm condition:
1) Logging - the device creates a record of the event and
saves it in a historical account.
2) syslog - the device generates a syslog message
containing details of the event and sends it to one
or more configured syslog server.
3) SNMP - the device generates a SNMP notification
containing details of the event and sends it to one
or more configured targets.
An EMS/NMS can monitor the most recent alarm conditions for a
flow monitor by retrieving the corresponding instance of
cfmFlowMonitorAlarms. Likewise, the EMS/NMS can monitor the
most recent alarm conditions for a traffic flow by retrieving
the corresponding instance of cfmFlowMetricsAlarms.
Additionally, the EMS/NMS can poll a summary of alarm conditions
maintained for each flow monitor and the traffic flows that it
monitors. The following list summarizes the data contained by
this summary:
o cfmFlowMonitorAlarmSeverity
o cfmFlowMonitorAlarmCriticalCount
o cfmFlowMonitorAlarmMajorCount
o cfmFlowMonitorAlarmMinorCount
o cfmFlowMonitorAlarmWarningCount
o cfmFlowMonitorAlarmInfoCount
An EMS/NMS can also poll cfmAlarmHistoryLastId, which indicates
the value of the identifier assigned to the last record saved to
the historical account. When it observes a change in the value
of this object, then it can retrieve the new records from the
cfmAlarmHistoryTable.
The burden of monitoring alarm conditions for sufficiently large
numbers of traffic flows can itself become a daunting task.
Thus, this MIB module defines the notion of an alarm group,
which represents a single alarm condition that aggregates a
standing condition for a set of traffic flows. The
cfmAlarmGroupTable describes the alarm groups configured for a
device, and the cfmAlarmGroupFlowTable describes the sets of
flows aggregated by these alarm groups.
GLOSSARY
============
Alarm Action - a method used by the device to signal changes in
an alarm condition.
Alarm Aggregation - a technique used to efficiently monitor the
same standing condition for a flow set.
Alarm Condition - a standing condition for which the device
signals changes in state.
Alarm Group - a flow set for which the device monitors a
configured standing condition, raising an alarm when a
configured number of flows in the flow set assert the
standing standing.
Alarm Severity - the relative disposition of an alarm condition
when raised by the device. For example, a provider may
regard a flow stop alarm as having a higher severity than a
flow's loss fraction exceeding a configured threshold.
Flow Monitor - a hardware or software entity that classifies
traffic flows, collects flow data, and periodically
computes flow metrics.
Flow Metric - a measurement that reflects the quality of a
traffic flow.
Flow Point - represents the ingress or egress of a traffic flow.
Flow Set - a group of traffic flows.
Measurement Interval - the length of time over which a flow
monitor collects data related to a traffic flow, after which
the flow monitor computes flow metrics using the collected
data.
Standing Condition - represents a lasting error, fault, or
warning resulting from the application of a set of criteria
to the state of an entity, such as a flow monitor or traffic
flow. For example, a flow monitor may assert a standing
condition if the number of traffic flows that expire in a
measurement interval exceeds a configured threshold.
Traffic Flow - a unidirectional stream of packets conforming to
a classifier. For example, packets having a particular
source IP address, destination IP address, protocol type,
source port number, and destination port number.
ciscoFlowMonitorMIB MODULE-IDENTITY LAST-UPDATED "200904080000Z" ORGANIZATION "Cisco Systems, Inc." CONTACT-INFO "Cisco Systems Customer Service Postal: 170 W Tasman Drive San Jose, CA 95134 Tel: +1 800 553-NETS E-mail: [email protected]" DESCRIPTION "This MIB module defines objects that describe flow monitoring. A typical application of this MIB module will facilitate monitoring media flows, especially flows carrying video streams. However, by no means does the definition of this MIB module prevents other applications from using it. FLOW MONITORS ================= At the top level, this MIB module describes the notion of a flow monitor. A flow monitor is a hardware or software entity that classifies traffic flows, collects data on conforming traffic flows, and periodically computes metrics that reflect the quality of the traffic flows. Because a device can support more than one flow monitor, the MIB module defines the cfmFlowMonitorTable. Consider an edge router that supports a certain line card that has an integrated capability to monitor video flows. In this example, the cfmFlowMonitorTable would contain a row describing each line card installed in the device. TRAFFIC FLOWS ================= At the next level, this MIB module describes the notion of a traffic flow. This MIB module uniquely identifies a traffic flow using an auxiliary variable called cfmFlowId; however, an implementation only has guarantee its uniqueness within the scope of the flow monitor that has the responsibility for monitoring the traffic flow. Thus, we can think of the flow monitor as a container for the traffic flows for which it collects data and periodically computes metrics, as the figure below illustrates. + | cfmFlowTable | | | + | cfmFlowMonitorId = 3 + | | cfmFlowId = 101 | | | + | + | | cfmFlowMonitorId = 3 | | | | cfmFlowId = 102 | | | + | : | | : | | + | | cfmFlowMonitorId = 3 | | | | cfmFlowId = 150 | | | + + | | + | cfmFlowMonitorId = 4 + | | cfmFlowId = 1 | | | + | + | | cfmFlowMonitorId = 4 | | | | cfmFlowId = 2 | | | + | : | | : | | + | | cfmFlowMonitorId = 4 | | | | cfmFlowId = 150 | | | + + | | + While the identifying of a traffic flow using this auxiliary variable is convenient for the MIB module, it is does suffice for an EMS/NMS trying to isolate faults in a network delivering these traffic flows. To aid an EMS/NMS in this task, this MIB module defines a number of tables that provide layers of data relating to a traffic flow, including: o cfmFlowL2VlanTable - describes L2 VLAN data relating to traffic flows. o cfmFlowIpTable - describes IP data relating to traffic flows. o cfmFlowUdpTable - describes UDP data relating to traffic flows. o cfmFlowTcpTable - describes TCP data relating to traffic flows. o cfmFlowRtpTable - describes RTP data relating to traffic flows. Each of these tables have a sparse dependent relationship on the cfmFlowTable, as there exist situations when the data may not be available for a traffic flow, including: 1) The flow monitor simply may not collect the particular data for the traffic flows that it has the responsibility of monitoring. For example, a flow monitor may not have any concern for L2 VLAN data. 2) The data may not apply to a traffic flow. For example, a TCP and RTP data do not apply for a UDP traffic flow. To help an EMS/NMS navigate the data collected for a traffic flow, the corresponding rows are daisy-chained using 'next objects'. An EMS/NMS starts with cfmFlowNext, which indicates a reference to the row in the next table containing data related to the traffic flow. The first object contained by each of these tables is a 'next object'. Consider a RTP traffic flow for which the flow monitor has collected IP, UDP, and RTP data. The figure below illustrates how this MIB module daisy chains this data through the relevant tables. + | cfmFlowTable | | + | | cfmFlowMonitorId = 3 | | | | cfmFlowId = 42 | | | | cfmFlowNext = cfmFlowIpNext.3.42 | + + | + | cfmFlowIpTable | | | + | | cfmFlowMonitorId = 3 |< | | cfmFlowId = 42 | | | | cfmFlowIpNext = cfmFlowUdpNext.3.42 | + + | + | cfmFlowUdpTable | | | + | | cfmFlowMonitorId = 3 |< | | cfmFlowId = 42 | | | | cfmFlowUdpNext = cfmFlowRtpNext.3.42 | + + | + | cfmFlowRtpTable | | | + | | cfmFlowMonitorId = 3 |< | | cfmFlowId = 42 | | | | cfmFlowRtpNext = zeroDotZero | | | + + Observe that this structure simplifies the task of extending the MIB module to support additional layers of data. For example, if there is a need for a device to collect data relating to the MPEG-TS layer of a flow carrying a video stream, then it is as simple as defining a table containing this data. However, the definition of such a table must comply with the following requirements: 1) The table must have a sparse dependent relationship on the cfmFlowTable. 2) The first object contained by the table must be a 'next object' to support daisy chaining. REPORTING FLOW METRICS ========================== At the next level, the MIB defines two tables that together form the foundation for reporting metrics. The cfmFlowMetricsTable has a one-to-one dependent relationship on the cfmFlowTable, and it contains data aggregate metrics and data relating to the collection of metrics for the corresponding traffic flow. A row in this table also serves as a container for the historic metrics computed by the corresponding flow monitor, as the figure below illustrates. + | cfmFlowMetricsIntTable | | | + | cfmFlowMetricsEntry | | | | | cfmFlowMonitorId = 3 | | | cfmFlowMonitorId = 3 | | | cfmFlowId = 101 | | | cfmFlowid = 101 | | | cfmFlowMetricsIntNumber = 1 | | + | + | | cfmFlowMonitorId = 3 | | | | cfmFlowId = 101 | | | | cfmFlowMetricsIntNumber = 2 | | | + | : | | : | | + | | cfmFlowMonitorId = 3 | | | | cfmFlowId = 101 | | | | cfmFlowMetricsIntNumber = N | | | + + | | + The device collects data for a traffic flow over a configured measurement interval, indicated by cfmFlowMetricsIntervalTime. At the end of a measurement interval, the device computes metrics from this data, generating a report. An EMS/NMS can access this report using the cfmFlowMetricsIntTable. cfmFlowMetricsMaxInterval indicates the maximum number of reports a device will save for the corresponding traffic flow, while cfmFlowMetricsIntervals indicates the number of reports currently saved by the device. The cfmFlowMetricsTable and cfmFlowMetricsIntTable have the intent of providing a foundation for reporting metrics for a traffic flow. Furthermore, it is the intent that additional MIB modules define extensions to these tables describing specific sets of metrics. The following list provides some examples: o CISCO-FLOW-MON-MDI-MIB - this MIB module defines extensions that describe MDI metrics defined by RFC-4445. o CISCO-FLOW-MON-RTP-MIB - this MIB module defines extensions that describe RTP metrics defined by RFC-3550. o CISCO-FLOW-MON-IP-CBR-MIB - this MIB module defines extension that describe IP CBR metrics. The tables defined by these MIB modules have a sparse dependent relationhip on the cfmFlowMetricsTable and cfmFlowMetricsIntTable. An EMS/NMS can determine the metrics collected for a traffic flow from the corresponding instance of cfmFlowMetricsCollected, which is nothing more than a bit string-value for which each bit corresponds to a different set of metrics. FAULT MANAGEMENT ==================== At the next level, this MIB module defines tables that describe standing conditions. A standing condition is a lasting error, fault, or warning resulting from the application of a set of criteria to the state of an entity. For example, a flow monitor ceases monitoring a traffic flow when it has not received any packets for that traffic flow in a configured interval of time. If flow monitor expires a significantly large number of traffic flows during a measurement interval, then this might signal a fault. In this example, the 'set of criteria' is a rising threshold and the 'state of an entity' is the number of traffic flows expired by a flow monitor. The cfmConditionTable describes the criteria applied to entities managed by the device, specifically flow monitors and traffic flows. The table groups these criteria into 'conditions profiles'. The device periodically applies these criteria to an entity and saves the results in a bit string-value associated with the entity. An EMS/NMS can monitor the most recent standing conditions for a flow monitor by retrieving the corresponding instance of cfmFlowMonitorConditions. Likewise, an EMS/NMS can monitor the most recent standing conditions for a traffic flow by retrieving the corresponding instance of cfmFlowMetricsConditions. It goes without saying that monitoring the standing conditions for significantly large numbers of traffic flows becomes problematic. To aid an EMS/NMS in this task, this MIB module defines many mechanisms. The most basic of these mechanisms is the notion of an alarm, which is simply a standing condition for which the device signals changes in state. This MIB module provides for three means of signaling when the device raises or clears an alarm condition: 1) Logging - the device creates a record of the event and saves it in a historical account. 2) syslog - the device generates a syslog message containing details of the event and sends it to one or more configured syslog server. 3) SNMP - the device generates a SNMP notification containing details of the event and sends it to one or more configured targets. An EMS/NMS can monitor the most recent alarm conditions for a flow monitor by retrieving the corresponding instance of cfmFlowMonitorAlarms. Likewise, the EMS/NMS can monitor the most recent alarm conditions for a traffic flow by retrieving the corresponding instance of cfmFlowMetricsAlarms. Additionally, the EMS/NMS can poll a summary of alarm conditions maintained for each flow monitor and the traffic flows that it monitors. The following list summarizes the data contained by this summary: o cfmFlowMonitorAlarmSeverity o cfmFlowMonitorAlarmCriticalCount o cfmFlowMonitorAlarmMajorCount o cfmFlowMonitorAlarmMinorCount o cfmFlowMonitorAlarmWarningCount o cfmFlowMonitorAlarmInfoCount An EMS/NMS can also poll cfmAlarmHistoryLastId, which indicates the value of the identifier assigned to the last record saved to the historical account. When it observes a change in the value of this object, then it can retrieve the new records from the cfmAlarmHistoryTable. The burden of monitoring alarm conditions for sufficiently large numbers of traffic flows can itself become a daunting task. Thus, this MIB module defines the notion of an alarm group, which represents a single alarm condition that aggregates a standing condition for a set of traffic flows. The cfmAlarmGroupTable describes the alarm groups configured for a device, and the cfmAlarmGroupFlowTable describes the sets of flows aggregated by these alarm groups. GLOSSARY ============ Alarm Action - a method used by the device to signal changes in an alarm condition. Alarm Aggregation - a technique used to efficiently monitor the same standing condition for a flow set. Alarm Condition - a standing condition for which the device signals changes in state. Alarm Group - a flow set for which the device monitors a configured standing condition, raising an alarm when a configured number of flows in the flow set assert the standing standing. Alarm Severity - the relative disposition of an alarm condition when raised by the device. For example, a provider may regard a flow stop alarm as having a higher severity than a flow's loss fraction exceeding a configured threshold. Flow Monitor - a hardware or software entity that classifies traffic flows, collects flow data, and periodically computes flow metrics. Flow Metric - a measurement that reflects the quality of a traffic flow. Flow Point - represents the ingress or egress of a traffic flow. Flow Set - a group of traffic flows. Measurement Interval - the length of time over which a flow monitor collects data related to a traffic flow, after which the flow monitor computes flow metrics using the collected data. Standing Condition - represents a lasting error, fault, or warning resulting from the application of a set of criteria to the state of an entity, such as a flow monitor or traffic flow. For example, a flow monitor may assert a standing condition if the number of traffic flows that expire in a measurement interval exceeds a configured threshold. Traffic Flow - a unidirectional stream of packets conforming to a classifier. For example, packets having a particular source IP address, destination IP address, protocol type, source port number, and destination port number." REVISION "200904080000Z" DESCRIPTION "The initial version of the MIB module." ::= { ciscoMgmt 692 }
ciscoFlowMonitorMIB OBJECT IDENTIFIER ::= { ciscoMgmt 692 }
Vendor: Cisco
Module: CISCO-FLOW-MONITOR-MIB
[Automatically extracted from oidview.com]
ciscoFlowMonitorMIB MODULE-IDENTITY LAST-UPDATED "200904080000Z" ORGANIZATION "Cisco Systems, Inc." CONTACT-INFO "Cisco Systems Customer Service Postal: 170 W Tasman Drive San Jose, CA 95134 Tel: +1 800 553-NETS E-mail: [email protected]" DESCRIPTION "This MIB module defines objects that describe flow monitoring. A typical application of this MIB module will facilitate monitoring media flows, especially flows carrying video streams. However, by no means does the definition of this MIB module prevents other applications from using it. FLOW MONITORS ================= At the top level, this MIB module describes the notion of a flow monitor. A flow monitor is a hardware or software entity that classifies traffic flows, collects data on conforming traffic flows, and periodically computes metrics that reflect the quality of the traffic flows. Because a device can support more than one flow monitor, the MIB module defines the cfmFlowMonitorTable. Consider an edge router that supports a certain line card that has an integrated capability to monitor video flows. In this example, the cfmFlowMonitorTable would contain a row describing each line card installed in the device. TRAFFIC FLOWS ================= At the next level, this MIB module describes the notion of a traffic flow. This MIB module uniquely identifies a traffic flow using an auxiliary variable called cfmFlowId; however, an implementation only has guarantee its uniqueness within the scope of the flow monitor that has the responsibility for monitoring the traffic flow. Thus, we can think of the flow monitor as a container for the traffic flows for which it collects data and periodically computes metrics, as the figure below illustrates. + | cfmFlowTable | | | + | cfmFlowMonitorId = 3 + | | cfmFlowId = 101 | | | + | + | | cfmFlowMonitorId = 3 | | | | cfmFlowId = 102 | | | + | : | | : | | + | | cfmFlowMonitorId = 3 | | | | cfmFlowId = 150 | | | + + | | + | cfmFlowMonitorId = 4 + | | cfmFlowId = 1 | | | + | + | | cfmFlowMonitorId = 4 | | | | cfmFlowId = 2 | | | + | : | | : | | + | | cfmFlowMonitorId = 4 | | | | cfmFlowId = 150 | | | + + | | + While the identifying of a traffic flow using this auxiliary variable is convenient for the MIB module, it is does suffice for an EMS/NMS trying to isolate faults in a network delivering these traffic flows. To aid an EMS/NMS in this task, this MIB module defines a number of tables that provide layers of data relating to a traffic flow, including: o cfmFlowL2VlanTable - describes L2 VLAN data relating to traffic flows. o cfmFlowIpTable - describes IP data relating to traffic flows. o cfmFlowUdpTable - describes UDP data relating to traffic flows. o cfmFlowTcpTable - describes TCP data relating to traffic flows. o cfmFlowRtpTable - describes RTP data relating to traffic flows. Each of these tables have a sparse dependent relationship on the cfmFlowTable, as there exist situations when the data may not be available for a traffic flow, including: 1) The flow monitor simply may not collect the particular data for the traffic flows that it has the responsibility of monitoring. For example, a flow monitor may not have any concern for L2 VLAN data. 2) The data may not apply to a traffic flow. For example, a TCP and RTP data do not apply for a UDP traffic flow. To help an EMS/NMS navigate the data collected for a traffic flow, the corresponding rows are daisy-chained using 'next objects'. An EMS/NMS starts with cfmFlowNext, which indicates a reference to the row in the next table containing data related to the traffic flow. The first object contained by each of these tables is a 'next object'. Consider a RTP traffic flow for which the flow monitor has collected IP, UDP, and RTP data. The figure below illustrates how this MIB module daisy chains this data through the relevant tables. + | cfmFlowTable | | + | | cfmFlowMonitorId = 3 | | | | cfmFlowId = 42 | | | | cfmFlowNext = cfmFlowIpNext.3.42 | + + | + | cfmFlowIpTable | | | + | | cfmFlowMonitorId = 3 |< | | cfmFlowId = 42 | | | | cfmFlowIpNext = cfmFlowUdpNext.3.42 | + + | + | cfmFlowUdpTable | | | + | | cfmFlowMonitorId = 3 |< | | cfmFlowId = 42 | | | | cfmFlowUdpNext = cfmFlowRtpNext.3.42 | + + | + | cfmFlowRtpTable | | | + | | cfmFlowMonitorId = 3 |< | | cfmFlowId = 42 | | | | cfmFlowRtpNext = zeroDotZero | | | + + Observe that this structure simplifies the task of extending the MIB module to support additional layers of data. For example, if there is a need for a device to collect data relating to the MPEG-TS layer of a flow carrying a video stream, then it is as simple as defining a table containing this data. However, the definition of such a table must comply with the following requirements: 1) The table must have a sparse dependent relationship on the cfmFlowTable. 2) The first object contained by the table must be a 'next object' to support daisy chaining. REPORTING FLOW METRICS ========================== At the next level, the MIB defines two tables that together form the foundation for reporting metrics. The cfmFlowMetricsTable has a one-to-one dependent relationship on the cfmFlowTable, and it contains data aggregate metrics and data relating to the collection of metrics for the corresponding traffic flow. A row in this table also serves as a container for the historic metrics computed by the corresponding flow monitor, as the figure below illustrates. + | cfmFlowMetricsIntTable | | | + | cfmFlowMetricsEntry | | | | | cfmFlowMonitorId = 3 | | | cfmFlowMonitorId = 3 | | | cfmFlowId = 101 | | | cfmFlowid = 101 | | | cfmFlowMetricsIntNumber = 1 | | + | + | | cfmFlowMonitorId = 3 | | | | cfmFlowId = 101 | | | | cfmFlowMetricsIntNumber = 2 | | | + | : | | : | | + | | cfmFlowMonitorId = 3 | | | | cfmFlowId = 101 | | | | cfmFlowMetricsIntNumber = N | | | + + | | + The device collects data for a traffic flow over a configured measurement interval, indicated by cfmFlowMetricsIntervalTime. At the end of a measurement interval, the device computes metrics from this data, generating a report. An EMS/NMS can access this report using the cfmFlowMetricsIntTable. cfmFlowMetricsMaxInterval indicates the maximum number of reports a device will save for the corresponding traffic flow, while cfmFlowMetricsIntervals indicates the number of reports currently saved by the device. The cfmFlowMetricsTable and cfmFlowMetricsIntTable have the intent of providing a foundation for reporting metrics for a traffic flow. Furthermore, it is the intent that additional MIB modules define extensions to these tables describing specific sets of metrics. The following list provides some examples: o CISCO-FLOW-MON-MDI-MIB - this MIB module defines extensions that describe MDI metrics defined by RFC-4445. o CISCO-FLOW-MON-RTP-MIB - this MIB module defines extensions that describe RTP metrics defined by RFC-3550. o CISCO-FLOW-MON-IP-CBR-MIB - this MIB module defines extension that describe IP CBR metrics. The tables defined by these MIB modules have a sparse dependent relationhip on the cfmFlowMetricsTable and cfmFlowMetricsIntTable. An EMS/NMS can determine the metrics collected for a traffic flow from the corresponding instance of cfmFlowMetricsCollected, which is nothing more than a bit string-value for which each bit corresponds to a different set of metrics. FAULT MANAGEMENT ==================== At the next level, this MIB module defines tables that describe standing conditions. A standing condition is a lasting error, fault, or warning resulting from the application of a set of criteria to the state of an entity. For example, a flow monitor ceases monitoring a traffic flow when it has not received any packets for that traffic flow in a configured interval of time. If flow monitor expires a significantly large number of traffic flows during a measurement interval, then this might signal a fault. In this example, the 'set of criteria' is a rising threshold and the 'state of an entity' is the number of traffic flows expired by a flow monitor. The cfmConditionTable describes the criteria applied to entities managed by the device, specifically flow monitors and traffic flows. The table groups these criteria into 'conditions profiles'. The device periodically applies these criteria to an entity and saves the results in a bit string-value associated with the entity. An EMS/NMS can monitor the most recent standing conditions for a flow monitor by retrieving the corresponding instance of cfmFlowMonitorConditions. Likewise, an EMS/NMS can monitor the most recent standing conditions for a traffic flow by retrieving the corresponding instance of cfmFlowMetricsConditions. It goes without saying that monitoring the standing conditions for significantly large numbers of traffic flows becomes problematic. To aid an EMS/NMS in this task, this MIB module defines many mechanisms. The most basic of these mechanisms is the notion of an alarm, which is simply a standing condition for which the device signals changes in state. This MIB module provides for three means of signaling when the device raises or clears an alarm condition: 1) Logging - the device creates a record of the event and saves it in a historical account. 2) syslog - the device generates a syslog message containing details of the event and sends it to one or more configured syslog server. 3) SNMP - the device generates a SNMP notification containing details of the event and sends it to one or more configured targets. An EMS/NMS can monitor the most recent alarm conditions for a flow monitor by retrieving the corresponding instance of cfmFlowMonitorAlarms. Likewise, the EMS/NMS can monitor the most recent alarm conditions for a traffic flow by retrieving the corresponding instance of cfmFlowMetricsAlarms. Additionally, the EMS/NMS can poll a summary of alarm conditions maintained for each flow monitor and the traffic flows that it monitors. The following list summarizes the data contained by this summary: o cfmFlowMonitorAlarmSeverity o cfmFlowMonitorAlarmCriticalCount o cfmFlowMonitorAlarmMajorCount o cfmFlowMonitorAlarmMinorCount o cfmFlowMonitorAlarmWarningCount o cfmFlowMonitorAlarmInfoCount An EMS/NMS can also poll cfmAlarmHistoryLastId, which indicates the value of the identifier assigned to the last record saved to the historical account. When it observes a change in the value of this object, then it can retrieve the new records from the cfmAlarmHistoryTable. The burden of monitoring alarm conditions for sufficiently large numbers of traffic flows can itself become a daunting task. Thus, this MIB module defines the notion of an alarm group, which represents a single alarm condition that aggregates a standing condition for a set of traffic flows. The cfmAlarmGroupTable describes the alarm groups configured for a device, and the cfmAlarmGroupFlowTable describes the sets of flows aggregated by these alarm groups. GLOSSARY ============ Alarm Action - a method used by the device to signal changes in an alarm condition. Alarm Aggregation - a technique used to efficiently monitor the same standing condition for a flow set. Alarm Condition - a standing condition for which the device signals changes in state. Alarm Group - a flow set for which the device monitors a configured standing condition, raising an alarm when a configured number of flows in the flow set assert the standing standing. Alarm Severity - the relative disposition of an alarm condition when raised by the device. For example, a provider may regard a flow stop alarm as having a higher severity than a flow's loss fraction exceeding a configured threshold. Flow Monitor - a hardware or software entity that classifies traffic flows, collects flow data, and periodically computes flow metrics. Flow Metric - a measurement that reflects the quality of a traffic flow. Flow Point - represents the ingress or egress of a traffic flow. Flow Set - a group of traffic flows. Measurement Interval - the length of time over which a flow monitor collects data related to a traffic flow, after which the flow monitor computes flow metrics using the collected data. Standing Condition - represents a lasting error, fault, or warning resulting from the application of a set of criteria to the state of an entity, such as a flow monitor or traffic flow. For example, a flow monitor may assert a standing condition if the number of traffic flows that expire in a measurement interval exceeds a configured threshold. Traffic Flow - a unidirectional stream of packets conforming to a classifier. For example, packets having a particular source IP address, destination IP address, protocol type, source port number, and destination port number." REVISION "200904080000Z" DESCRIPTION "The initial version of the MIB module." ::= { ciscoMgmt 692 }
ciscoFlowMonitorMIB MODULE-IDENTITY LAST-UPDATED "200904080000Z" ORGANIZATION "Cisco Systems, Inc." CONTACT-INFO "Cisco Systems Customer Service Postal: 170 W Tasman Drive San Jose, CA 95134 Tel: +1 800 553-NETS E-mail: [email protected]" DESCRIPTION "This MIB module defines objects that describe flow monitoring. A typical application of this MIB module will facilitate monitoring media flows, especially flows carrying video streams. However, by no means does the definition of this MIB module prevents other applications from using it. FLOW MONITORS ================= At the top level, this MIB module describes the notion of a flow monitor. A flow monitor is a hardware or software entity that classifies traffic flows, collects data on conforming traffic flows, and periodically computes metrics that reflect the quality of the traffic flows. Because a device can support more than one flow monitor, the MIB module defines the cfmFlowMonitorTable. Consider an edge router that supports a certain line card that has an integrated capability to monitor video flows. In this example, the cfmFlowMonitorTable would contain a row describing each line card installed in the device. TRAFFIC FLOWS ================= At the next level, this MIB module describes the notion of a traffic flow. This MIB module uniquely identifies a traffic flow using an auxiliary variable called cfmFlowId; however, an implementation only has guarantee its uniqueness within the scope of the flow monitor that has the responsibility for monitoring the traffic flow. Thus, we can think of the flow monitor as a container for the traffic flows for which it collects data and periodically computes metrics, as the figure below illustrates. + | cfmFlowTable | | | + | cfmFlowMonitorId = 3 + | | cfmFlowId = 101 | | | + | + | | cfmFlowMonitorId = 3 | | | | cfmFlowId = 102 | | | + | : | | : | | + | | cfmFlowMonitorId = 3 | | | | cfmFlowId = 150 | | | + + | | + | cfmFlowMonitorId = 4 + | | cfmFlowId = 1 | | | + | + | | cfmFlowMonitorId = 4 | | | | cfmFlowId = 2 | | | + | : | | : | | + | | cfmFlowMonitorId = 4 | | | | cfmFlowId = 150 | | | + + | | + While the identifying of a traffic flow using this auxiliary variable is convenient for the MIB module, it is does suffice for an EMS/NMS trying to isolate faults in a network delivering these traffic flows. To aid an EMS/NMS in this task, this MIB module defines a number of tables that provide layers of data relating to a traffic flow, including: o cfmFlowL2VlanTable - describes L2 VLAN data relating to traffic flows. o cfmFlowIpTable - describes IP data relating to traffic flows. o cfmFlowUdpTable - describes UDP data relating to traffic flows. o cfmFlowTcpTable - describes TCP data relating to traffic flows. o cfmFlowRtpTable - describes RTP data relating to traffic flows. Each of these tables have a sparse dependent relationship on the cfmFlowTable, as there exist situations when the data may not be available for a traffic flow, including: 1) The flow monitor simply may not collect the particular data for the traffic flows that it has the responsibility of monitoring. For example, a flow monitor may not have any concern for L2 VLAN data. 2) The data may not apply to a traffic flow. For example, a TCP and RTP data do not apply for a UDP traffic flow. To help an EMS/NMS navigate the data collected for a traffic flow, the corresponding rows are daisy-chained using 'next objects'. An EMS/NMS starts with cfmFlowNext, which indicates a reference to the row in the next table containing data related to the traffic flow. The first object contained by each of these tables is a 'next object'. Consider a RTP traffic flow for which the flow monitor has collected IP, UDP, and RTP data. The figure below illustrates how this MIB module daisy chains this data through the relevant tables. + | cfmFlowTable | | + | | cfmFlowMonitorId = 3 | | | | cfmFlowId = 42 | | | | cfmFlowNext = cfmFlowIpNext.3.42 | + + | + | cfmFlowIpTable | | | + | | cfmFlowMonitorId = 3 |< | | cfmFlowId = 42 | | | | cfmFlowIpNext = cfmFlowUdpNext.3.42 | + + | + | cfmFlowUdpTable | | | + | | cfmFlowMonitorId = 3 |< | | cfmFlowId = 42 | | | | cfmFlowUdpNext = cfmFlowRtpNext.3.42 | + + | + | cfmFlowRtpTable | | | + | | cfmFlowMonitorId = 3 |< | | cfmFlowId = 42 | | | | cfmFlowRtpNext = zeroDotZero | | | + + Observe that this structure simplifies the task of extending the MIB module to support additional layers of data. For example, if there is a need for a device to collect data relating to the MPEG-TS layer of a flow carrying a video stream, then it is as simple as defining a table containing this data. However, the definition of such a table must comply with the following requirements: 1) The table must have a sparse dependent relationship on the cfmFlowTable. 2) The first object contained by the table must be a 'next object' to support daisy chaining. REPORTING FLOW METRICS ========================== At the next level, the MIB defines two tables that together form the foundation for reporting metrics. The cfmFlowMetricsTable has a one-to-one dependent relationship on the cfmFlowTable, and it contains data aggregate metrics and data relating to the collection of metrics for the corresponding traffic flow. A row in this table also serves as a container for the historic metrics computed by the corresponding flow monitor, as the figure below illustrates. + | cfmFlowMetricsIntTable | | | + | cfmFlowMetricsEntry | | | | | cfmFlowMonitorId = 3 | | | cfmFlowMonitorId = 3 | | | cfmFlowId = 101 | | | cfmFlowid = 101 | | | cfmFlowMetricsIntNumber = 1 | | + | + | | cfmFlowMonitorId = 3 | | | | cfmFlowId = 101 | | | | cfmFlowMetricsIntNumber = 2 | | | + | : | | : | | + | | cfmFlowMonitorId = 3 | | | | cfmFlowId = 101 | | | | cfmFlowMetricsIntNumber = N | | | + + | | + The device collects data for a traffic flow over a configured measurement interval, indicated by cfmFlowMetricsIntervalTime. At the end of a measurement interval, the device computes metrics from this data, generating a report. An EMS/NMS can access this report using the cfmFlowMetricsIntTable. cfmFlowMetricsMaxInterval indicates the maximum number of reports a device will save for the corresponding traffic flow, while cfmFlowMetricsIntervals indicates the number of reports currently saved by the device. The cfmFlowMetricsTable and cfmFlowMetricsIntTable have the intent of providing a foundation for reporting metrics for a traffic flow. Furthermore, it is the intent that additional MIB modules define extensions to these tables describing specific sets of metrics. The following list provides some examples: o CISCO-FLOW-MON-MDI-MIB - this MIB module defines extensions that describe MDI metrics defined by RFC-4445. o CISCO-FLOW-MON-RTP-MIB - this MIB module defines extensions that describe RTP metrics defined by RFC-3550. o CISCO-FLOW-MON-IP-CBR-MIB - this MIB module defines extension that describe IP CBR metrics. The tables defined by these MIB modules have a sparse dependent relationhip on the cfmFlowMetricsTable and cfmFlowMetricsIntTable. An EMS/NMS can determine the metrics collected for a traffic flow from the corresponding instance of cfmFlowMetricsCollected, which is nothing more than a bit string-value for which each bit corresponds to a different set of metrics. FAULT MANAGEMENT ==================== At the next level, this MIB module defines tables that describe standing conditions. A standing condition is a lasting error, fault, or warning resulting from the application of a set of criteria to the state of an entity. For example, a flow monitor ceases monitoring a traffic flow when it has not received any packets for that traffic flow in a configured interval of time. If flow monitor expires a significantly large number of traffic flows during a measurement interval, then this might signal a fault. In this example, the 'set of criteria' is a rising threshold and the 'state of an entity' is the number of traffic flows expired by a flow monitor. The cfmConditionTable describes the criteria applied to entities managed by the device, specifically flow monitors and traffic flows. The table groups these criteria into 'conditions profiles'. The device periodically applies these criteria to an entity and saves the results in a bit string-value associated with the entity. An EMS/NMS can monitor the most recent standing conditions for a flow monitor by retrieving the corresponding instance of cfmFlowMonitorConditions. Likewise, an EMS/NMS can monitor the most recent standing conditions for a traffic flow by retrieving the corresponding instance of cfmFlowMetricsConditions. It goes without saying that monitoring the standing conditions for significantly large numbers of traffic flows becomes problematic. To aid an EMS/NMS in this task, this MIB module defines many mechanisms. The most basic of these mechanisms is the notion of an alarm, which is simply a standing condition for which the device signals changes in state. This MIB module provides for three means of signaling when the device raises or clears an alarm condition: 1) Logging - the device creates a record of the event and saves it in a historical account. 2) syslog - the device generates a syslog message containing details of the event and sends it to one or more configured syslog server. 3) SNMP - the device generates a SNMP notification containing details of the event and sends it to one or more configured targets. An EMS/NMS can monitor the most recent alarm conditions for a flow monitor by retrieving the corresponding instance of cfmFlowMonitorAlarms. Likewise, the EMS/NMS can monitor the most recent alarm conditions for a traffic flow by retrieving the corresponding instance of cfmFlowMetricsAlarms. Additionally, the EMS/NMS can poll a summary of alarm conditions maintained for each flow monitor and the traffic flows that it monitors. The following list summarizes the data contained by this summary: o cfmFlowMonitorAlarmSeverity o cfmFlowMonitorAlarmCriticalCount o cfmFlowMonitorAlarmMajorCount o cfmFlowMonitorAlarmMinorCount o cfmFlowMonitorAlarmWarningCount o cfmFlowMonitorAlarmInfoCount An EMS/NMS can also poll cfmAlarmHistoryLastId, which indicates the value of the identifier assigned to the last record saved to the historical account. When it observes a change in the value of this object, then it can retrieve the new records from the cfmAlarmHistoryTable. The burden of monitoring alarm conditions for sufficiently large numbers of traffic flows can itself become a daunting task. Thus, this MIB module defines the notion of an alarm group, which represents a single alarm condition that aggregates a standing condition for a set of traffic flows. The cfmAlarmGroupTable describes the alarm groups configured for a device, and the cfmAlarmGroupFlowTable describes the sets of flows aggregated by these alarm groups. GLOSSARY ============ Alarm Action - a method used by the device to signal changes in an alarm condition. Alarm Aggregation - a technique used to efficiently monitor the same standing condition for a flow set. Alarm Condition - a standing condition for which the device signals changes in state. Alarm Group - a flow set for which the device monitors a configured standing condition, raising an alarm when a configured number of flows in the flow set assert the standing standing. Alarm Severity - the relative disposition of an alarm condition when raised by the device. For example, a provider may regard a flow stop alarm as having a higher severity than a flow's loss fraction exceeding a configured threshold. Flow Monitor - a hardware or software entity that classifies traffic flows, collects flow data, and periodically computes flow metrics. Flow Metric - a measurement that reflects the quality of a traffic flow. Flow Point - represents the ingress or egress of a traffic flow. Flow Set - a group of traffic flows. Measurement Interval - the length of time over which a flow monitor collects data related to a traffic flow, after which the flow monitor computes flow metrics using the collected data. Standing Condition - represents a lasting error, fault, or warning resulting from the application of a set of criteria to the state of an entity, such as a flow monitor or traffic flow. For example, a flow monitor may assert a standing condition if the number of traffic flows that expire in a measurement interval exceeds a configured threshold. Traffic Flow - a unidirectional stream of packets conforming to a classifier. For example, packets having a particular source IP address, destination IP address, protocol type, source port number, and destination port number." REVISION "200904080000Z" DESCRIPTION "The initial version of the MIB module." ::= { ciscoMgmt 692 }
| OID | Name | Sub children | Sub Nodes Total | Description |
|---|---|---|---|---|
| 1.3.6.1.4.1.9.9.692.0 | ciscoFlowMonitorMIBNotifs | 1 | 1 | None |
| 1.3.6.1.4.1.9.9.692.1 | ciscoFlowMonitorMIBObjects | 7 | 170 | None |
| 1.3.6.1.4.1.9.9.692.2 | ciscoFlowMonitorMIBConform | 2 | 11 | None |
| 1.3.6.1.4.1.9.9.692.3 | ciscoFlowMonitorMIBIds | 1 | 9 | None |
To many brothers! Only 100 nearest brothers are shown.
| OID | Name | Sub children | Sub Nodes Total | Description |
|---|---|---|---|---|
| ... | ||||
| 1.3.6.1.4.1.9.9.642 | ciscoBridgeDomainMIB | 3 | 24 | A bridge domain is one of the means by which it is possible to define a broadcast domain on a bridging device. It is an alternati… |
| 1.3.6.1.4.1.9.9.643 | ciscoTelepresenceMIB | 3 | 119 | The MIB module defines the managed objects for a Telepresence system. Telepresence refers to a set of technologies which allow a p… |
| 1.3.6.1.4.1.9.9.644 | ciscoTelepresenceCallMIB | 3 | 178 | The MIB module defines the managed objects for Telepresence calls. Telepresence refers to a set of technologies which allow a pers… |
| 1.3.6.1.4.1.9.9.645 | ciscoEtherExtMIB | 3 | 18 | The MIB module to describe generic objects for ethernet-like network interfaces. This MIB provides ethernet-like network interfac… |
| 1.3.6.1.4.1.9.9.646 | ciscoAonStatusMIB | 3 | 80 | This MIB module defines managed objects that facilitate the management of AON node. The information available through this MIB in… |
| 1.3.6.1.4.1.9.9.647 | ciscoGgsnExtMIB | 3 | 212 | This MIB module extends the CISCO-GGSN-MIB. This MIB module manages the Gateway GPRS Support Node (GGSN) devices. A GGSN device pr… |
| 1.3.6.1.4.1.9.9.648 | ciscoVirtualInterfaceMIB | 2 | 32 | The MIB module for creation and deletion of Virtual Interfaces and Virtual Interface Groups. In addition to this MIB, interface … |
| 1.3.6.1.4.1.9.9.650 | ciscoL4L7moduleRedundancyMIB | 3 | 71 | The L4-7 SLB devices are used for scaling websites, building web enabled applications, and migrating to web services. The followin… |
| 1.3.6.1.4.1.9.9.651 | ciscoCommonRolesExtMIB | 3 | 37 | A MIB Module for managing the roles that are common between access methods like Command Line Interface (CLI), SNMP and XML interf… |
| 1.3.6.1.4.1.9.9.652 | ciscoSwitchStatsMIB | 3 | 106 | The MIB module provides management information for configuration and monitoring of traffic statistics on Cisco's switching device… |
| 1.3.6.1.4.1.9.9.653 | ciscoAdmissionPolicyMIB | 3 | 36 | This MIB module defines managed objects that facilitate the management of policies upon host(s) admission to a network. The inform… |
| 1.3.6.1.4.1.9.9.654 | ciscoMabMIB | 3 | 20 | MIB module for monitoring and configuring MAC Authentication Bypass (MAB) feature in the system. MAC Auth Bypass feature provides… |
| 1.3.6.1.4.1.9.9.655 | ciscoDigitalMediaSystemsMIB | 3 | 195 | Acronyms and Definitions The following acronyms and terms are used in this document: DMS: Digital Media Systems DAM: Digital As… |
| 1.3.6.1.4.1.9.9.656 | ciscoAuthFrameworkMIB | 3 | 117 | MIB module for Authentication Framework in the system. Authentication Framework provides generic configurations for authenticatio… |
| 1.3.6.1.4.1.9.9.657 | ciscoSbcCallStatsMIB | 3 | 201 | The main purpose of this MIB is to define the statistics information for Session Border Controller application. The statistics ar… |
| 1.3.6.1.4.1.9.9.658 | ciscoSessBorderCtrlrEventMIB | 3 | 208 | The main purpose of this MIB is to define the SNMP notifications and alarms generated by Session Border Controller application an… |
| 1.3.6.1.4.1.9.9.660 | ciscoNportVirtualizationMIB | 3 | 19 | The MIB module for the management of N_port Virtualization or NPV within the framework of Cisco's N_port virtualization (NPV) Arc… |
| 1.3.6.1.4.1.9.9.661 | ciscoWan3gMIB | 3 | 378 | This MIB module provides network management support for Cisco cellular 3G WAN products. *** ABBREVIATIONS, ACRONYMS, AND SYMBOLS … |
| 1.3.6.1.4.1.9.9.662 | ciscoCbpTcMIB | 0 | 0 | This MIB module defines textual conventions used by the CISCO-CBP-BASE-CFG-MIB, CISCO-CBP-BASE-MON-MIB, and any MIB modules exten… |
| 1.3.6.1.4.1.9.9.663 | ciscoSwitchHardwareCapacityMIB | 3 | 141 | This MIB module defines the managed objects for hardware capacity of Cisco switching devices. The hardware capacity information c… |
| 1.3.6.1.4.1.9.9.664 | ciscoMmodalContactAppsMIB | 3 | 359 | The Cisco Unified Multi-Modal Contact Applications (MMCA) platform is a highly scalable, modular, extensible, open and secure pl… |
| 1.3.6.1.4.1.9.9.667 | ciscoServiceControllerMIB | 2 | 31 | This MIB module defines objects describing traffic controllers used by a service control entity. A service control entity is a ne… |
| 1.3.6.1.4.1.9.9.668 | ciscoP2PIfMIB | 3 | 16 | The Point to Point Interface MIB module. This MIB manages the generic objects for Serial link or SONET/SDH like point to point ne… |
| 1.3.6.1.4.1.9.9.669 | ciscoCdmaPdsnExtMIB | 3 | 178 | This MIB is an extension to the CISCO-CDMA-PDSN-MIB. A CDMA network supports wireless data communication through 3G CDMA radio acc… |
| 1.3.6.1.4.1.9.9.670 | ciscoReportIntervalTcMIB | 0 | 0 | CISCO-REPORT-INTERVAL-TC-MIB |
| 1.3.6.1.4.1.9.9.672 | ciscoMobilityTapMIB | 3 | 24 | This module manages Cisco's intercept feature for Mobility Gateway Products. This MIB is used along with CISCO-TAP2-MIB MIB to int… |
| 1.3.6.1.4.1.9.9.673 | ciscoFCoEMIB | 2 | 45 | This MIB module is for configuring and monitoring Fibre Channel over Ethernet (FCoE) related entities. This MIB defines the Virtu… |
| 1.3.6.1.4.1.9.9.679 | ciscoIeee8021CfmExtMIB | 3 | 55 | A MIB module for extending the IEEE8021-CFM-MIB and IEEE8021-CFM-V2-MIB to add objects which provide additional information about… |
| 1.3.6.1.4.1.9.9.680 | ciscoNhrpExtMIB | 3 | 36 | This MIB module is an extension of the NHRP MIB module as defined in RFC 2677. It defines notifications associated with critical … |
| 1.3.6.1.4.1.9.9.683 | ciscoEnergywiseMIB | 3 | 162 | The MIB is used to manage and optimize power usage in networks. Cisco EnergyWise is a specification of data, discovery and protoco… |
| 1.3.6.1.4.1.9.9.686 | ciscoLwappInterfaceMIB | 3 | 27 | ciscoLwappInterfaceMIB MODULE-IDENTITY LAST-UPDATED "200901090000Z" ORGANIZATION "Cisco Systems Inc." CONTACT-INFO "Cisco Syste… |
| 1.3.6.1.4.1.9.9.688 | ciscoFlowMonitorTcMIB | 0 | 0 | This MIB module defines textual conventions used by the MIB modules defining objects describing flow monitoring. GLOSSARY ========… |
| 1.3.6.1.4.1.9.9.689 | ciscoSlbDfpMIB | 3 | 22 | This MIB reports the congestion status of the real server. A server can be in congested state due to high memory consumption, hig… |
| 1.3.6.1.4.1.9.9.690 | ciscoMobilePolicyChargingControlMIB | 3 | 143 | Mobile PCC Infrastructure built on top of Policy Shim Layer, is a common interface to send and receive PCC related messages for a… |
| 1.3.6.1.4.1.9.9.691 | ciscoEthernetFabricExtenderMIB | 3 | 23 | The MIB module for configuring one or more fabric extenders to connect into a core switch. Since fabric extenders might not be m… |
| 1.3.6.1.4.1.9.9.693 | ciscoServiceControlAttackMIB | 3 | 55 | This MIB provides data related to different types of attacks detected by a service control entity. A service control entity is a … |
| 1.3.6.1.4.1.9.9.694 | ciscoCtsTcMIB | 0 | 0 | This module defines the textual conventions used within Cisco Trusted Security framework. |
| 1.3.6.1.4.1.9.9.695 | ciscoGtcapMIB | 3 | 194 | The MIB for Transaction Capabilities(TCAP) messages transported over Signalling System No. 7 (SS7) Network via Cisco IP Transfer P… |
| 1.3.6.1.4.1.9.9.696 | ciscoBootHwDiagsMIB | 3 | 22 | This MIB is used to configure those devices that support boot-time hardware diagnostics. It provides the reports about the respe… |
| 1.3.6.1.4.1.9.9.697 | ciscoIpCbrMetricsMIB | 4 | 42 | This MIB module defines objects that describe the a set of metrics used to measure the quality of a IP CBR traffic flow. An IP CB… |
| 1.3.6.1.4.1.9.9.698 | ciscoObmiMIB | 3 | 60 | The On-Board Management Interface (OBMI) provides an out-of-band communications channel (in Cisco terms: a console port), that is… |
| 1.3.6.1.4.1.9.9.699 | ciscoMdiMetricsMIB | 4 | 46 | This MIB module defines objects that describe the Media Delivery Index (MDI). The MDI [RFC4445] measurement describes the qualit… |
| 1.3.6.1.4.1.9.9.700 | ciscoCableL2vpnMIB | 3 | 28 | This MIB module defines managed objects that facilitate the management of Cisco devices complying to the DOCSIS L2VPN Feature for… |
| 1.3.6.1.4.1.9.9.701 | ciscoSeuMitigationMIB | 3 | 51 | This MIB reports the status of non-automatic and automatic, rate-adaptive Single Event Upset (SEU) mitigation algorithms and adju… |
| 1.3.6.1.4.1.9.9.702 | ciscoSanBaseSvcMIB | 3 | 57 | Common MIB module to manage services in Storage Area Network (SAN). Service is deployed on service nodes on multiple switches fo… |
| 1.3.6.1.4.1.9.9.703 | ciscoRtpMetricsMIB | 4 | 61 | This MIB module defines objects that describe the quality metrics of RTP streams, similar to those described by an RTCP Receiver … |
| 1.3.6.1.4.1.9.9.706 | ciscoInterfaceXcvrMonitorMIB | 3 | 33 | A MIB module that provides monitoring information about the transceivers plugged into interface on a system. |
| 1.3.6.1.4.1.9.9.708 | ciscoContentDeliveryStreamingMIB | 2 | 30 | This MIB instrumentation is for managing the Content Delivery and Streaming functionality on Cisco devices. Contents are ingested… |
| 1.3.6.1.4.1.9.9.709 | ciscoVlanGroupMIB | 3 | 18 | MIB module for monitoring and configuring VLAN Group Mapping information. |
| 1.3.6.1.4.1.9.9.710 | ciscoVirtualNicMIB | 3 | 36 | This MIB module defines MIB objects which provide mechanisms to manage the parameters used by or related to Virtual NIC. Virtual s… |
| 1.3.6.1.4.1.9.9.711 | ciscoVrfMIB | 3 | 48 | The MIB module for provisioning and managing network virtualization features. This module provides manageability for VRF, VRF-Lit… |
| 1.3.6.1.4.1.9.9.712 | ciscoWirelessNotificationMIB | 3 | 30 | This MIB is intended to be implemented on those Network Management applications that manage a network of wireless devices through… |
| 1.3.6.1.4.1.9.9.713 | ciscoTrustSecPolicyMIB | 3 | 204 | This MIB module defines managed objects that facilitate the management of various policies within the Cisco Trusted Security (Tru… |
| 1.3.6.1.4.1.9.9.714 | ciscoHwModuleControlMIB | 3 | 27 | The MIB module providing configuration and control information for management of hardware modules and components on Cisco devices… |
| 1.3.6.1.4.1.9.9.715 | ciscoEntityQfpMIB | 3 | 82 | This MIB module defines managed objects that facilitate the management of Quantum Flow Processors (QFP), which are listed in the … |
| 1.3.6.1.4.1.9.9.716 | ciscoVoIpTapMIB | 3 | 18 | This module manages Cisco's intercept feature for Voice over IP (VoIP). This MIB is used along with CISCO-TAP2-MIB to intercept V… |
| 1.3.6.1.4.1.9.9.718 | ciscoCuicappsMIB | 3 | 130 | The Cisco Unified Intelligence Center (CUIC) is a scalable robust and secure reporting solution for contact center applications. T… |
| 1.3.6.1.4.1.9.9.719 | ciscoUnifiedComputingMIB | 5 | 13463 | This MIB module defines the managed objects for Unified Computing System (UCS) Manager. Cisco UCS Manager provides centralized m… |
| 1.3.6.1.4.1.9.9.720 | ciscoTrustSecSxpMIB | 3 | 140 | This MIB module is for the configuration and status query of SGT Exchange Protocol over TCP (SXPoTCP) feature of the device on th… |
| 1.3.6.1.4.1.9.9.721 | ciscoMldSnoopingMIB | 3 | 215 | This MIB module defines objects that describe IGMP/MLD snooping. It provides remote network management system the ability to manag… |
| 1.3.6.1.4.1.9.9.724 | cggsnGeoMIB | 2 | 12 | This MIB provide additional information for passive interface configured for each OSPF process, independent of object creation in… |
| 1.3.6.1.4.1.9.9.725 | ciscoSmartInstallMIB | 3 | 101 | This MIB module defines managed objects that facilitate the management of Smart Install feature. Smart Install is a plug-and-pla… |
| 1.3.6.1.4.1.9.9.729 | ciscoCdstvServicesMIB | 3 | 21 | This MIB module defines service monitoring objects that faciliate the management of the Cisco Content Delivery System for TV (CDS… |
| 1.3.6.1.4.1.9.9.730 | ciscoTrustSecMIB | 3 | 128 | This MIB module is for the configuration of a network device on the Cisco Trusted Security (TrustSec) system. TrustSec secures a … |
| 1.3.6.1.4.1.9.9.731 | ciscoEpcGatewayMIB | 3 | 130 | This MIB module manages the features and configuration for PDN Gateway(PGW) and Serving Gateway(SGW) in Evolved Packet Core(EPC) … |
| 1.3.6.1.4.1.9.9.732 | ciscoDeviceLocationMIB | 3 | 49 | This MIB is used for managing location information of end point devices(Telepresence, IP Camera, Digital media player etc) connec… |
| 1.3.6.1.4.1.9.9.733 | ciscoMeetingPlaceMIB | 3 | 70 | This MIB allows management of Cisco Unified MeetingPlace (CUMP) features, CUMP is the key conferencing solution component for Cis… |
| 1.3.6.1.4.1.9.9.734 | ciscoGtpv2MIB | 2 | 160 | This MIB module manages the GPRS Tunneling Protocol version 2(GTPv2) statistics for the Evolved Packet Core(EPC) architecture. SGW… |
| 1.3.6.1.4.1.9.9.735 | ciscoCdstvFsiMIB | 3 | 25 | This MIB module defines FSI configurartion objects that faciliate the management of the Cisco Content Delivery System for TV (CDS… |
| 1.3.6.1.4.1.9.9.736 | ciscoRadiusExtMIB | 2 | 51 | This MIB module defines objects describing RADIUS (Remote Access Dialin User Service), serving as an extension of the following M… |
| 1.3.6.1.4.1.9.9.737 | ciscoSwitchNetflowMIB | 3 | 40 | This MIB module defines management objects for the Netflow features on Cisco Layer 2 and Layer 3 devices. |
| 1.3.6.1.4.1.9.9.738 | cmplsTeStdExtMIB | 3 | 72 | This MIB module contains Cisco specific managed object definitions for MPLS Traffic Engineering (TE), not contained in MPLS-TE-ST… |
| 1.3.6.1.4.1.9.9.739 | ciscoCdstvIngestmgrMIB | 3 | 69 | This MIB module defines ingest manager configuration objects that faciliate the management of the Cisco Content Delivery System f… |
| 1.3.6.1.4.1.9.9.740 | ciscoTrustSecIfMIB | 3 | 143 | This MIB module defines management objects for configuration and monitoring of the interfaces in Cisco Trusted Security environme… |
| 1.3.6.1.4.1.9.9.741 | ciscoTrustSecServerMIB | 3 | 85 | This MIB module defines management objects for configuration and monitoring of the AAA servers in Cisco Trusted Security environm… |
| 1.3.6.1.4.1.9.9.742 | ciscoIpAddressPoolTcMIB | 0 | 0 | This MIB module defines textual conventions used by MIB modules defining objects describing IP address pools. |
| ... | ||||