This MIB module defines a MIB which provides
mechanisms to monitor an NTP server.
The MIB is derived from the Technical Report
#Management of the NTP with SNMP# TR No. 98-09
authored by A.S. Sethi and Dave Mills in the
University of Delaware.
Below is a brief overview of NTP system architecture
and implementation model. This will help understand
the objects defined below and their relationships.
NTP Intro:
The Network Time Protocol (NTP) Version 3, is used to
synchronize timekeeping among a set of distributed
time servers and clients. The service model is based
on a returnable-time design which depends only on
measured clock offsets, but does not require reliable
message delivery. The synchronization subnet uses a
self-organizing, hierarchical master-slave
configuration, with synchronization paths determined
by a minimum-weight spanning tree. While multiple
masters (primary servers) may exist, there is no
requirement for an election protocol.
System Archiecture:
In the NTP model a number of primary reference
sources, synchronized by wire or radio to national
standards, are connected to widely accessible
resources, such as backbone gateways, and operated as
primary time servers. The purpose of NTP is to convey
timekeeping information from these servers to other
time servers via the Internet and also to cross-check
clocks and mitigate errors due to equipment or
propagation failures. Some number of local-net hosts
or gateways, acting as secondary time servers, run NTP
with one or more of the primary servers. In order to
reduce the protocol overhead, the secondary servers
distribute time via NTP to the remaining local-net
hosts. In the interest of reliability, selected hosts
can be equipped with less accurate but less expensive
radio clocks and used for backup in case of failure of
the primary and/or secondary servers or communication
paths between them.
NTP is designed to produce three products: clock
offset, round-trip delay and dispersion, all of which
are relative to a selected reference clock. Clock
offset represents the amount to adjust the local clock
to bring it into correspondence with the reference
clock. Roundtrip delay provides the capability to
launch a message to arrive at the reference clock at a
specified time. Dispersion represents the maximum
error of the local clock relative to the reference
clock. Since most host time servers will synchronize
via another peer time server, there are two components
in each of these three products, those determined by
the peer relative to the primary reference source of
standard time and those measured by the host relative
to the peer. Each of these components are maintained
separately in the protocol in order to facilitate
error control and management of the subnet itself.
They provide not only precision measurements of offset
and delay, but also definitive maximum error bounds,
so that the user interface can determine not only the
time, but the quality of the time as well.
Implementation Model:
In what may be the most common client/server model a
client sends an NTP message to one or more servers and
processes the replies as received. The server
interchanges addresses and ports, overwrites certain
fields in the message, recalculates the checksum and
returns the message immediately. Information included
in the NTP message allows the client to determine the
server time with respect to local time and adjust the
local clock accordingly. In addition, the message
includes information to calculate the expected
timekeeping accuracy and reliability, as well as
select the best from possibly several servers.
While the client/server model may suffice for use on
local nets involving a public server and perhaps many
workstation clients, the full generality of NTP
requires distributed participation of a number of
client/servers or peers arranged in a dynamically
reconfigurable, hierarchically distributed
configuration. It also requires sophisticated
algorithms for association management, data
manipulation and local-clock control.
Glossary:
1. Host: Refers to an instantiation of the NTP
protocol on a local processor.
2. Peer: Refers to an instantiation of the NTP
protocol on a remote processor connected by
a network path from the local host.
Parsed from file CISCO-NTP-MIB.mib
Module: CISCO-NTP-MIB
This MIB module defines a MIB which provides
mechanisms to monitor an NTP server.
The MIB is derived from the Technical Report
#Management of the NTP with SNMP# TR No. 98-09
authored by A.S. Sethi and Dave Mills in the
University of Delaware.
Below is a brief overview of NTP system architecture
and implementation model. This will help understand
the objects defined below and their relationships.
NTP Intro:
The Network Time Protocol (NTP) Version 3, is used to
synchronize timekeeping among a set of distributed
time servers and clients. The service model is based
on a returnable-time design which depends only on
measured clock offsets, but does not require reliable
message delivery. The synchronization subnet uses a
self-organizing, hierarchical master-slave
configuration, with synchronization paths determined
by a minimum-weight spanning tree. While multiple
masters (primary servers) may exist, there is no
requirement for an election protocol.
System Archiecture:
In the NTP model a number of primary reference
sources, synchronized by wire or radio to national
standards, are connected to widely accessible
resources, such as backbone gateways, and operated as
primary time servers. The purpose of NTP is to convey
timekeeping information from these servers to other
time servers via the Internet and also to cross-check
clocks and mitigate errors due to equipment or
propagation failures. Some number of local-net hosts
or gateways, acting as secondary time servers, run NTP
with one or more of the primary servers. In order to
reduce the protocol overhead, the secondary servers
distribute time via NTP to the remaining local-net
hosts. In the interest of reliability, selected hosts
can be equipped with less accurate but less expensive
radio clocks and used for backup in case of failure of
the primary and/or secondary servers or communication
paths between them.
NTP is designed to produce three products: clock
offset, round-trip delay and dispersion, all of which
are relative to a selected reference clock. Clock
offset represents the amount to adjust the local clock
to bring it into correspondence with the reference
clock. Roundtrip delay provides the capability to
launch a message to arrive at the reference clock at a
specified time. Dispersion represents the maximum
error of the local clock relative to the reference
clock. Since most host time servers will synchronize
via another peer time server, there are two components
in each of these three products, those determined by
the peer relative to the primary reference source of
standard time and those measured by the host relative
to the peer. Each of these components are maintained
separately in the protocol in order to facilitate
error control and management of the subnet itself.
They provide not only precision measurements of offset
and delay, but also definitive maximum error bounds,
so that the user interface can determine not only the
time, but the quality of the time as well.
Implementation Model:
In what may be the most common client/server model a
client sends an NTP message to one or more servers and
processes the replies as received. The server
interchanges addresses and ports, overwrites certain
fields in the message, recalculates the checksum and
returns the message immediately. Information included
in the NTP message allows the client to determine the
server time with respect to local time and adjust the
local clock accordingly. In addition, the message
includes information to calculate the expected
timekeeping accuracy and reliability, as well as
select the best from possibly several servers.
While the client/server model may suffice for use on
local nets involving a public server and perhaps many
workstation clients, the full generality of NTP
requires distributed participation of a number of
client/servers or peers arranged in a dynamically
reconfigurable, hierarchically distributed
configuration. It also requires sophisticated
algorithms for association management, data
manipulation and local-clock control.
Glossary:
1. Host: Refers to an instantiation of the NTP
protocol on a local processor.
2. Peer: Refers to an instantiation of the NTP
protocol on a remote processor connected by
a network path from the local host.
Parsed from file CISCO-NTP-MIB.my.txt
Company: None
Module: CISCO-NTP-MIB
This MIB module defines a MIB which provides
mechanisms to monitor an NTP server.
The MIB is derived from the Technical Report
#Management of the NTP with SNMP# TR No. 98-09
authored by A.S. Sethi and Dave Mills in the
University of Delaware.
Below is a brief overview of NTP system architecture
and implementation model. This will help understand
the objects defined below and their relationships.
NTP Intro:
The Network Time Protocol (NTP) Version 3, is used to
synchronize timekeeping among a set of distributed
time servers and clients. The service model is based
on a returnable-time design which depends only on
measured clock offsets, but does not require reliable
message delivery. The synchronization subnet uses a
self-organizing, hierarchical master-slave
configuration, with synchronization paths determined
by a minimum-weight spanning tree. While multiple
masters (primary servers) may exist, there is no
requirement for an election protocol.
System Archiecture:
In the NTP model a number of primary reference
sources, synchronized by wire or radio to national
standards, are connected to widely accessible
resources, such as backbone gateways, and operated as
primary time servers. The purpose of NTP is to convey
timekeeping information from these servers to other
time servers via the Internet and also to cross-check
clocks and mitigate errors due to equipment or
propagation failures. Some number of local-net hosts
or gateways, acting as secondary time servers, run NTP
with one or more of the primary servers. In order to
reduce the protocol overhead, the secondary servers
distribute time via NTP to the remaining local-net
hosts. In the interest of reliability, selected hosts
can be equipped with less accurate but less expensive
radio clocks and used for backup in case of failure of
the primary and/or secondary servers or communication
paths between them.
NTP is designed to produce three products: clock
offset, round-trip delay and dispersion, all of which
are relative to a selected reference clock. Clock
offset represents the amount to adjust the local clock
to bring it into correspondence with the reference
clock. Roundtrip delay provides the capability to
launch a message to arrive at the reference clock at a
specified time. Dispersion represents the maximum
error of the local clock relative to the reference
clock. Since most host time servers will synchronize
via another peer time server, there are two components
in each of these three products, those determined by
the peer relative to the primary reference source of
standard time and those measured by the host relative
to the peer. Each of these components are maintained
separately in the protocol in order to facilitate
error control and management of the subnet itself.
They provide not only precision measurements of offset
and delay, but also definitive maximum error bounds,
so that the user interface can determine not only the
time, but the quality of the time as well.
Implementation Model:
In what may be the most common client/server model a
client sends an NTP message to one or more servers and
processes the replies as received. The server
interchanges addresses and ports, overwrites certain
fields in the message, recalculates the checksum and
returns the message immediately. Information included
in the NTP message allows the client to determine the
server time with respect to local time and adjust the
local clock accordingly. In addition, the message
includes information to calculate the expected
timekeeping accuracy and reliability, as well as
select the best from possibly several servers.
While the client/server model may suffice for use on
local nets involving a public server and perhaps many
workstation clients, the full generality of NTP
requires distributed participation of a number of
client/servers or peers arranged in a dynamically
reconfigurable, hierarchically distributed
configuration. It also requires sophisticated
algorithms for association management, data
manipulation and local-clock control.
Glossary:
1. Host: Refers to an instantiation of the NTP
protocol on a local processor.
2. Peer: Refers to an instantiation of the NTP
protocol on a remote processor connected by
a network path from the local host.
ciscoNtpMIB MODULE-IDENTITY LAST-UPDATED "200607310000Z" ORGANIZATION "Cisco Systems, Inc." CONTACT-INFO "Cisco Systems Customer Service Postal: 170 W. Tasman Drive San Jose, CA 95134 USA Tel: +1 800 553-NETS E-mail: [email protected]" DESCRIPTION "This MIB module defines a MIB which provides mechanisms to monitor an NTP server. The MIB is derived from the Technical Report #Management of the NTP with SNMP# TR No. 98-09 authored by A.S. Sethi and Dave Mills in the University of Delaware. Below is a brief overview of NTP system architecture and implementation model. This will help understand the objects defined below and their relationships. NTP Intro: The Network Time Protocol (NTP) Version 3, is used to synchronize timekeeping among a set of distributed time servers and clients. The service model is based on a returnable-time design which depends only on measured clock offsets, but does not require reliable message delivery. The synchronization subnet uses a self-organizing, hierarchical master-slave configuration, with synchronization paths determined by a minimum-weight spanning tree. While multiple masters (primary servers) may exist, there is no requirement for an election protocol. System Archiecture: In the NTP model a number of primary reference sources, synchronized by wire or radio to national standards, are connected to widely accessible resources, such as backbone gateways, and operated as primary time servers. The purpose of NTP is to convey timekeeping information from these servers to other time servers via the Internet and also to cross-check clocks and mitigate errors due to equipment or propagation failures. Some number of local-net hosts or gateways, acting as secondary time servers, run NTP with one or more of the primary servers. In order to reduce the protocol overhead, the secondary servers distribute time via NTP to the remaining local-net hosts. In the interest of reliability, selected hosts can be equipped with less accurate but less expensive radio clocks and used for backup in case of failure of the primary and/or secondary servers or communication paths between them. NTP is designed to produce three products: clock offset, round-trip delay and dispersion, all of which are relative to a selected reference clock. Clock offset represents the amount to adjust the local clock to bring it into correspondence with the reference clock. Roundtrip delay provides the capability to launch a message to arrive at the reference clock at a specified time. Dispersion represents the maximum error of the local clock relative to the reference clock. Since most host time servers will synchronize via another peer time server, there are two components in each of these three products, those determined by the peer relative to the primary reference source of standard time and those measured by the host relative to the peer. Each of these components are maintained separately in the protocol in order to facilitate error control and management of the subnet itself. They provide not only precision measurements of offset and delay, but also definitive maximum error bounds, so that the user interface can determine not only the time, but the quality of the time as well. Implementation Model: In what may be the most common client/server model a client sends an NTP message to one or more servers and processes the replies as received. The server interchanges addresses and ports, overwrites certain fields in the message, recalculates the checksum and returns the message immediately. Information included in the NTP message allows the client to determine the server time with respect to local time and adjust the local clock accordingly. In addition, the message includes information to calculate the expected timekeeping accuracy and reliability, as well as select the best from possibly several servers. While the client/server model may suffice for use on local nets involving a public server and perhaps many workstation clients, the full generality of NTP requires distributed participation of a number of client/servers or peers arranged in a dynamically reconfigurable, hierarchically distributed configuration. It also requires sophisticated algorithms for association management, data manipulation and local-clock control. Glossary: 1. Host: Refers to an instantiation of the NTP protocol on a local processor. 2. Peer: Refers to an instantiation of the NTP protocol on a remote processor connected by a network path from the local host." REVISION "200607310000Z" DESCRIPTION "Added ciscoNtpSysExtGroup and ciscoNtpSrvNotifGroup groups to support monitoring of NTP server status. ciscoNtpMIBComplianceRev3 is deprecated and replaced by ciscoNtpMIBComplianceRev4." REVISION "200407230000Z" DESCRIPTION "Added cntpPeersPeerName and cntpPeersPeerType objects to cntpPeerVarTable." REVISION "200307290000Z" DESCRIPTION "Added cntpPeersPrefPeer object to cntpPeersVarTable." REVISION "200307070000Z" DESCRIPTION "ciscoNtpPeersGroup is deprecated by ciscoNtpPeersGroupRev1. ciscoNtpMIBCompliance is deprecated by ciscoNtpMIBComplianceRev1." REVISION "200202200000Z" DESCRIPTION "cntpPeersUpdateTime is deprecated by cntpPeersUpdateTimeRev1." REVISION "200006160000Z" DESCRIPTION "Initial version of this MIB module." ::= { ciscoMgmt 168 }
ciscoNtpMIB OBJECT IDENTIFIER ::= { ciscoMgmt 168 }
Vendor: Cisco
Module: CISCO-NTP-MIB
[Automatically extracted from oidview.com]
ciscoNtpMIB MODULE-IDENTITY LAST-UPDATED "200607310000Z" ORGANIZATION "Cisco Systems, Inc." CONTACT-INFO "Cisco Systems Customer Service Postal: 170 W. Tasman Drive San Jose, CA 95134 USA Tel: +1 800 553-NETS E-mail: [email protected]" DESCRIPTION "This MIB module defines a MIB which provides mechanisms to monitor an NTP server. The MIB is derived from the Technical Report #Management of the NTP with SNMP# TR No. 98-09 authored by A.S. Sethi and Dave Mills in the University of Delaware. Below is a brief overview of NTP system architecture and implementation model. This will help understand the objects defined below and their relationships. NTP Intro: The Network Time Protocol (NTP) Version 3, is used to synchronize timekeeping among a set of distributed time servers and clients. The service model is based on a returnable-time design which depends only on measured clock offsets, but does not require reliable message delivery. The synchronization subnet uses a self-organizing, hierarchical master-slave configuration, with synchronization paths determined by a minimum-weight spanning tree. While multiple masters (primary servers) may exist, there is no requirement for an election protocol. System Archiecture: In the NTP model a number of primary reference sources, synchronized by wire or radio to national standards, are connected to widely accessible resources, such as backbone gateways, and operated as primary time servers. The purpose of NTP is to convey timekeeping information from these servers to other time servers via the Internet and also to cross-check clocks and mitigate errors due to equipment or propagation failures. Some number of local-net hosts or gateways, acting as secondary time servers, run NTP with one or more of the primary servers. In order to reduce the protocol overhead, the secondary servers distribute time via NTP to the remaining local-net hosts. In the interest of reliability, selected hosts can be equipped with less accurate but less expensive radio clocks and used for backup in case of failure of the primary and/or secondary servers or communication paths between them. NTP is designed to produce three products: clock offset, round-trip delay and dispersion, all of which are relative to a selected reference clock. Clock offset represents the amount to adjust the local clock to bring it into correspondence with the reference clock. Roundtrip delay provides the capability to launch a message to arrive at the reference clock at a specified time. Dispersion represents the maximum error of the local clock relative to the reference clock. Since most host time servers will synchronize via another peer time server, there are two components in each of these three products, those determined by the peer relative to the primary reference source of standard time and those measured by the host relative to the peer. Each of these components are maintained separately in the protocol in order to facilitate error control and management of the subnet itself. They provide not only precision measurements of offset and delay, but also definitive maximum error bounds, so that the user interface can determine not only the time, but the quality of the time as well. Implementation Model: In what may be the most common client/server model a client sends an NTP message to one or more servers and processes the replies as received. The server interchanges addresses and ports, overwrites certain fields in the message, recalculates the checksum and returns the message immediately. Information included in the NTP message allows the client to determine the server time with respect to local time and adjust the local clock accordingly. In addition, the message includes information to calculate the expected timekeeping accuracy and reliability, as well as select the best from possibly several servers. While the client/server model may suffice for use on local nets involving a public server and perhaps many workstation clients, the full generality of NTP requires distributed participation of a number of client/servers or peers arranged in a dynamically reconfigurable, hierarchically distributed configuration. It also requires sophisticated algorithms for association management, data manipulation and local-clock control. Glossary: 1. Host: Refers to an instantiation of the NTP protocol on a local processor. 2. Peer: Refers to an instantiation of the NTP protocol on a remote processor connected by a network path from the local host." REVISION "200607310000Z" DESCRIPTION "Added ciscoNtpSysExtGroup and ciscoNtpSrvNotifGroup groups to support monitoring of NTP server status. ciscoNtpMIBComplianceRev3 is deprecated and replaced by ciscoNtpMIBComplianceRev4." REVISION "200407230000Z" DESCRIPTION "Added cntpPeersPeerName and cntpPeersPeerType objects to cntpPeerVarTable." REVISION "200307290000Z" DESCRIPTION "Added cntpPeersPrefPeer object to cntpPeersVarTable." REVISION "200307070000Z" DESCRIPTION "ciscoNtpPeersGroup is deprecated by ciscoNtpPeersGroupRev1. ciscoNtpMIBCompliance is deprecated by ciscoNtpMIBComplianceRev1." REVISION "200202200000Z" DESCRIPTION "cntpPeersUpdateTime is deprecated by cntpPeersUpdateTimeRev1." REVISION "200006160000Z" DESCRIPTION "Initial version of this MIB module." ::= { ciscoMgmt 168 }
ciscoNtpMIB MODULE-IDENTITY LAST-UPDATED "200607310000Z" ORGANIZATION "Cisco Systems, Inc." CONTACT-INFO "Cisco Systems Customer Service Postal: 170 W. Tasman Drive San Jose, CA 95134 USA Tel: +1 800 553-NETS E-mail: [email protected]" DESCRIPTION "This MIB module defines a MIB which provides mechanisms to monitor an NTP server. The MIB is derived from the Technical Report #Management of the NTP with SNMP# TR No. 98-09 authored by A.S. Sethi and Dave Mills in the University of Delaware. Below is a brief overview of NTP system architecture and implementation model. This will help understand the objects defined below and their relationships. NTP Intro: The Network Time Protocol (NTP) Version 3, is used to synchronize timekeeping among a set of distributed time servers and clients. The service model is based on a returnable-time design which depends only on measured clock offsets, but does not require reliable message delivery. The synchronization subnet uses a self-organizing, hierarchical master-slave configuration, with synchronization paths determined by a minimum-weight spanning tree. While multiple masters (primary servers) may exist, there is no requirement for an election protocol. System Archiecture: In the NTP model a number of primary reference sources, synchronized by wire or radio to national standards, are connected to widely accessible resources, such as backbone gateways, and operated as primary time servers. The purpose of NTP is to convey timekeeping information from these servers to other time servers via the Internet and also to cross-check clocks and mitigate errors due to equipment or propagation failures. Some number of local-net hosts or gateways, acting as secondary time servers, run NTP with one or more of the primary servers. In order to reduce the protocol overhead, the secondary servers distribute time via NTP to the remaining local-net hosts. In the interest of reliability, selected hosts can be equipped with less accurate but less expensive radio clocks and used for backup in case of failure of the primary and/or secondary servers or communication paths between them. NTP is designed to produce three products: clock offset, round-trip delay and dispersion, all of which are relative to a selected reference clock. Clock offset represents the amount to adjust the local clock to bring it into correspondence with the reference clock. Roundtrip delay provides the capability to launch a message to arrive at the reference clock at a specified time. Dispersion represents the maximum error of the local clock relative to the reference clock. Since most host time servers will synchronize via another peer time server, there are two components in each of these three products, those determined by the peer relative to the primary reference source of standard time and those measured by the host relative to the peer. Each of these components are maintained separately in the protocol in order to facilitate error control and management of the subnet itself. They provide not only precision measurements of offset and delay, but also definitive maximum error bounds, so that the user interface can determine not only the time, but the quality of the time as well. Implementation Model: In what may be the most common client/server model a client sends an NTP message to one or more servers and processes the replies as received. The server interchanges addresses and ports, overwrites certain fields in the message, recalculates the checksum and returns the message immediately. Information included in the NTP message allows the client to determine the server time with respect to local time and adjust the local clock accordingly. In addition, the message includes information to calculate the expected timekeeping accuracy and reliability, as well as select the best from possibly several servers. While the client/server model may suffice for use on local nets involving a public server and perhaps many workstation clients, the full generality of NTP requires distributed participation of a number of client/servers or peers arranged in a dynamically reconfigurable, hierarchically distributed configuration. It also requires sophisticated algorithms for association management, data manipulation and local-clock control. Glossary: 1. Host: Refers to an instantiation of the NTP protocol on a local processor. 2. Peer: Refers to an instantiation of the NTP protocol on a remote processor connected by a network path from the local host." REVISION "200607310000Z" DESCRIPTION "Added ciscoNtpSysExtGroup and ciscoNtpSrvNotifGroup groups to support monitoring of NTP server status. ciscoNtpMIBComplianceRev3 is deprecated and replaced by ciscoNtpMIBComplianceRev4." REVISION "200407230000Z" DESCRIPTION "Added cntpPeersPeerName and cntpPeersPeerType objects to cntpPeerVarTable." REVISION "200307290000Z" DESCRIPTION "Added cntpPeersPrefPeer object to cntpPeersVarTable." REVISION "200307070000Z" DESCRIPTION "ciscoNtpPeersGroup is deprecated by ciscoNtpPeersGroupRev1. ciscoNtpMIBCompliance is deprecated by ciscoNtpMIBComplianceRev1." REVISION "200202200000Z" DESCRIPTION "cntpPeersUpdateTime is deprecated by cntpPeersUpdateTimeRev1." REVISION "200006160000Z" DESCRIPTION "Initial version of this MIB module." ::= { ciscoMgmt 168 }
| OID | Name | Sub children | Sub Nodes Total | Description |
|---|---|---|---|---|
| 1.3.6.1.4.1.9.9.168.0 | ciscoNtpMIBNotifs | 5 | 5 | None |
| 1.3.6.1.4.1.9.9.168.1 | ciscoNtpMIBObjects | 3 | 64 | None |
| 1.3.6.1.4.1.9.9.168.2 | ciscoNtpMIBConformance | 2 | 15 | 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.118 | ciscoUdldpMIB | 3 | 51 | Cisco Uni Direction Link Detection Protocol MIB |
| 1.3.6.1.4.1.9.9.120 | ciscoNetworkRegistrarMIB | 3 | 125 | MIB for Cisco Network Registrar (CNR). |
| 1.3.6.1.4.1.9.9.121 | ciscoAtmNetworkClockMIB | 3 | 53 | The MIB module for management of network clock distribution and the Network Clock Distribution Protocol (NCDP) in Cisco de… |
| 1.3.6.1.4.1.9.9.122 | ciscoCasaMIB | 3 | 78 | This MIB contains the basic objects for managing a Cisco Appliance Services Architecture (CASA) Entity. A CASA Entity can be a Ma… |
| 1.3.6.1.4.1.9.9.124 | ciscoCallResourcePoolMIB | 3 | 114 | The MIB module for call resource pool management. This MIB supports the resource pool manager feature of CISCO IOS. This feature … |
| 1.3.6.1.4.1.9.9.125 | ciscoWANRsrcPartMIB | 2 | 55 | The MIB module to manage resource partition objects. A resource partition is configured on a virtual interface (ifType value atmV… |
| 1.3.6.1.4.1.9.9.126 | ciscoSonetMIB | 3 | 136 | The MIB module to describe SONET/SDH interfaces objects. This is an extension to the standard SONET MIB(RFC 2558). |
| 1.3.6.1.4.1.9.9.128 | ciscoVlanIfTableRelationshipMIB | 1 | 12 | ciscoVlanIftableRelationshipMIB |
| 1.3.6.1.4.1.9.9.129 | ciscoAtmVirtualIfMIB | 2 | 139 | The MIB module to manage ATM Virtual interface objects. ATM virtual interfaces are configured on a physical line. |
| 1.3.6.1.4.1.9.9.130 | ciscoAdslDmtLineMIB | 3 | 72 | This MIB module serves as an enterprise-specific extension of the ADSL-LINE-MIB. The structure of this MIB module shadows the st… |
| 1.3.6.1.4.1.9.9.131 | ciscoSystemMIB | 3 | 57 | The systemGroup (see RFC 1907) provides a standard set of basic system information. This MIB module contains Cisco-defined exten… |
| 1.3.6.1.4.1.9.9.132 | ciscoDs3MIB | 2 | 140 | The MIB module to describe DS3 line objects. This is an extension to the standard DS3 MIB(RFC 2496). |
| 1.3.6.1.4.1.9.9.133 | ciscoAtmCellLayerMIB | 1 | 138 | The MIB module to describe ATM cell layer objects and statistics of a physical line. |
| 1.3.6.1.4.1.9.9.134 | ciscoClusterMIB | 3 | 49 | The MIB module for the management of a group of devices called a 'cluster'. A cluster comprises: 1. A command switch, which is a… |
| 1.3.6.1.4.1.9.9.135 | ciscoWirelessP2pBpiMIB | 3 | 66 | This is the MIB Module for the Baseline Privacy Interface (BPI) at Point to Point Wireless Radio Card. This is a specialization o… |
| 1.3.6.1.4.1.9.9.136 | ciscoWirelessIfMIB | 3 | 307 | This is the MIB Module for the Cisco Wireless Radio Point to Point interface specification. I) Relationship of the Cisco Wireless… |
| 1.3.6.1.4.1.9.9.137 | ciscoWirelessTextualConventions | 0 | 0 | This module defines textual conventions used in Cisco Wireless MIBs. |
| 1.3.6.1.4.1.9.9.138 | ciscoEntityAlarmMIB | 3 | 66 | This MIB module defines the managed objects that support the monitoring of alarms generated by physical entities contained by the… |
| 1.3.6.1.4.1.9.9.139 | ciscoEntityProvMIB | 3 | 13 | This MIB module defines the objects that support provisioning of 'container' class physical entities. Provisioning sets up a 'co… |
| 1.3.6.1.4.1.9.9.140 | ciscoCopsClientMIB | 3 | 43 | This MIB module is for configuration & statistic query of Common Open Policy Service(COPS) client feature on the Cisco device. C… |
| 1.3.6.1.4.1.9.9.141 | ciscoVSIControllerMIB | 2 | 21 | This MIB module is used for configuring ATM Capable Switch to be aware of VSI Controller information. Terminolgies used: VSI … |
| 1.3.6.1.4.1.9.9.144 | ciscoTransactionConnectionMIB | 2 | 66 | The MIB module for retrieving Cisco Transaction Connection configuration and status. Cisco Transaction Connection routes transac… |
| 1.3.6.1.4.1.9.9.145 | ciscoWanModuleMIB | 3 | 32 | The MIB to configure Connection Specific parameters and statistics related information in a Service Module. The Service Module(SM… |
| 1.3.6.1.4.1.9.9.146 | ciscoCallApplicationMIB | 2 | 548 | This MIB allows management of call applications on a network device. A 'call application' is a software module that processes cal… |
| 1.3.6.1.4.1.9.9.147 | ciscoFirewallMIB | 3 | 75 | MIB module for monitoring Cisco Firewalls. |
| 1.3.6.1.4.1.9.9.148 | ciscoBgpPolAcctMIB | 2 | 15 | BGP policy based accounting information |
| 1.3.6.1.4.1.9.9.149 | ciscoAdslLineCapMIB | 3 | 46 | This MIB module serves as an enterprise-specific extension of the ADSL-LINE-MIB. The structure of this MIB module shadows the st… |
| 1.3.6.1.4.1.9.9.150 | ciscoAAASessionMIB | 3 | 31 | This MIB module provides data for accounting sessions based on Authentication, Authorization, Accounting (AAA) protocols. Referenc… |
| 1.3.6.1.4.1.9.9.151 | ciscoL2L3IfConfigMIB | 2 | 11 | Interface switchport mode configuration management MIB. This MIB is used to monitor and control configuration of interface switch… |
| 1.3.6.1.4.1.9.9.152 | ciscoSipUaMIB | 4 | 504 | Cisco User Agent Session Initiation Protocol (SIP) MIB module. SIP is an application-layer signalling protocol for creating, mod… |
| 1.3.6.1.4.1.9.9.154 | ciscoIdslLineMIB | 3 | 148 | This MIB module describes IDSL (ISDN Digital Line Subscriber) line interfaces. The structure of this module resembles that of th… |
| 1.3.6.1.4.1.9.9.155 | ciscoSdslLineMIB | 3 | 170 | This MIB module describes all variations of the symmetric DSL line interfaces. The structure of this module resembles and mainta… |
| 1.3.6.1.4.1.9.9.156 | ciscoCcmMIB | 3 | 487 | The MIB Module for the management of a Cisco Unified Communications Manager (CUCM) application running with a Cisco Communication… |
| 1.3.6.1.4.1.9.9.157 | ciscoCdmaPdsnMIB | 3 | 984 | This MIB is to support the CDMA PDSN (Packet Data Serving Node) feature. A CDMA2000 network supports wireless data communication… |
| 1.3.6.1.4.1.9.9.158 | ciscoAAAClientMIB | 3 | 25 | This MIB module provides data for authentication method priority based on Authentication, Authorization, Accounting (AAA) protoco… |
| 1.3.6.1.4.1.9.9.159 | ciscoQosPolicyConfigMIB | 3 | 35 | This MIB module defines managed objects that support the policy source configuration of Quality of Service (QoS) on the device. T… |
| 1.3.6.1.4.1.9.9.160 | ciscoCircuitInterfaceMIB | 2 | 11 | The MIB module to configure the circuit description for an interface. The circuit description can be used to describe and identify… |
| 1.3.6.1.4.1.9.9.161 | ciscoSlbMIB | 3 | 279 | The MIB for managing Server Load Balancing Manager(s), such as the Cisco IOS SLB product. This MIB includes instrumentation for t… |
| 1.3.6.1.4.1.9.9.162 | ciscoVsiMasterMIB | 3 | 100 | This MIB module contains objects related to the master side of the Virtual Switch Interface protocol used for control of ATM swit… |
| 1.3.6.1.4.1.9.9.163 | ciscoCallTrackerMIB | 3 | 104 | CISCO-CALL-TRACKER-MIB |
| 1.3.6.1.4.1.9.9.164 | ciscoCallTrackerTCPMIB | 3 | 25 | This MIB module provides TCP service connection related data for tracking the progress and status of a call. This module extends t… |
| 1.3.6.1.4.1.9.9.165 | ciscoCallTrackerModemMIB | 3 | 97 | This MIB module provides modem call related data for tracking the progress and status of a call. This module extends tables defin… |
| 1.3.6.1.4.1.9.9.166 | ciscoCBQosMIB | 2 | 544 | Cisco Class-Based QoS MIB ********************************** Overview ********************************** This MIB provides read acc… |
| 1.3.6.1.4.1.9.9.167 | ciscoWirelessDocsIfMib | 3 | 140 | This is the MIB Module for MCNS compliant Radio Frequency (RF) interfaces in wireless point-to-multipoint subscriber units (SU) a… |
| 1.3.6.1.4.1.9.9.169 | ciscoWirelessDocsExtMIB | 3 | 99 | This MIB module defines Cisco-specific objects that add to the functionality defined in CISCO-WIRELESS-DOCS-IF-MIB. These objects … |
| 1.3.6.1.4.1.9.9.170 | ciscoWirelessPhyMIB | 2 | 112 | This is the MIB Module for the Cisco Wireless Radio Point to MultiPoint interface. |
| 1.3.6.1.4.1.9.9.171 | ciscoIpSecFlowMonitorMIB | 3 | 507 | This is a MIB Module for monitoring the structures in IPSec-based Virtual Private Networks. The MIB has been designed to be adopt… |
| 1.3.6.1.4.1.9.9.172 | ciscoIpSecPolMapMIB | 3 | 21 | The MIB module maps the IPSec entities created dynamically to the policy entities that caused them. This is an appendix to the IPS… |
| 1.3.6.1.4.1.9.9.173 | ciscoPrivateVlanMIB | 2 | 56 | The MIB module to support Private VLAN feature on Cisco's switching devices. |
| 1.3.6.1.4.1.9.9.174 | ciscoMobileIpMIB | 3 | 533 | An extension to the IETF MIB module defined in RFC-2006 for managing Mobile IP implementations. Mobile IP introduces the followin… |
| 1.3.6.1.4.1.9.9.175 | ciscoIfLinkConfigMIB | 2 | 15 | The MIB module for configuration of bulk distribution (de-multiplexing of traffic from higher-bandwidth to lower-bandwidth interf… |
| 1.3.6.1.4.1.9.9.176 | ciscoRFMIB | 3 | 117 | This MIB provides configuration control and status for the Redundancy Framework (RF) subsystem. RF provides a mechanism for logic… |
| 1.3.6.1.4.1.9.9.177 | ciscoSaaApmMIB | 3 | 38 | Acronyms and Terms: SAA - Service Assurance Agent APM - Application Performance Monitoring A MIB for controlling SAA APM. APM provi… |
| 1.3.6.1.4.1.9.9.178 | ciscoContentEngineMIB | 3 | 263 | The MIB module for the Cisco Content Engine from Cisco Systems, Inc. |
| 1.3.6.1.4.1.9.9.179 | ciscoCatOSAclQosMIB | 3 | 470 | This MIB module is for Access Control Lists(ACLs) configuration of Quality of Service (QoS) as well as Security feature on the Ci… |
| 1.3.6.1.4.1.9.9.180 | ciscoWirelessRfMetricsMIB | 5 | 99 | This is the MIB Module for the Cisco Wireless Radio Point to MultiPoint interface specification. |
| 1.3.6.1.4.1.9.9.181 | ciscoWirelessLinkMetricsMIB | 4 | 141 | This is the MIB Module for the Cisco Wireless Radio Point to MultiPoint interface link metrics specification. Glossary The followin… |
| 1.3.6.1.4.1.9.9.183 | ciscoGprsAccPtMIB | 3 | 338 | This MIB module supports access point configuration for GGSN in a GPRS system. GPRS [1] is a GSM network providing mobile wireles… |
| 1.3.6.1.4.1.9.9.184 | ciscoPimMIB | 3 | 36 | This MIB module defines the cisco specific variables for Protocol Independent Multicast (PIM) management. These definitions are a… |
| 1.3.6.1.4.1.9.9.185 | ciscoBertMIB | 2 | 46 | The MIB module to configure and perform Bit Error Rate Testing (BERT) on DS3, DS1/E1 and DS0/DS0Bundle interfaces. Bit error rate… |
| 1.3.6.1.4.1.9.9.187 | ciscoBgp4MIB | 4 | 137 | An extension to the IETF BGP4 MIB module defined in RFC 1657. Following is the terminology associated with Border Gateway Protocol… |
| 1.3.6.1.4.1.9.9.188 | cGtpMIB | 3 | 248 | This MIB module manages the GPRS Tunnelling Protocol (GTP) on GGSN and SGSN. GPRS provides wireless access to packet data network… |
| 1.3.6.1.4.1.9.9.189 | ciscoPortQosMIB | 3 | 114 | Cisco PORT QOS MIB - Overview This MIB module is for the management of Cisco's per port rate-limiting and traffic shaping on L3 sw… |
| 1.3.6.1.4.1.9.9.190 | ciscoVoiceAppsMIB | 3 | 40 | The MIB Module for the management of Cisco Voice Applications. This MIB is designed to work in conjunction with the SYSAPPL-MIB … |
| 1.3.6.1.4.1.9.9.191 | ciscoIpUplinkRedirectMIB | 3 | 11 | This MIB module is for the configuration of Cisco IP Uplink Redirect feature. |
| 1.3.6.1.4.1.9.9.192 | ciscoGprsChargingMIB | 3 | 315 | This MIB module manages the charging related function on the GGSN node of a GPRS system. The following diagram illustrates a simp… |
| 1.3.6.1.4.1.9.9.194 | ciscoPppoeMIB | 3 | 89 | Cisco PPPoE sessions management MIB Module. |
| 1.3.6.1.4.1.9.9.195 | ciscoEntityExtMIB | 3 | 64 | This MIB is an extension of the ENTITY-MIB specified in RFC2737. This MIB module contains Cisco-defined extensions to the entit… |
| 1.3.6.1.4.1.9.9.197 | ciscoDistDirMIB | 3 | 123 | Cisco Distributed Director MIB. The Cisco Distributed Director provides global Internet scalability and increased performance as … |
| 1.3.6.1.4.1.9.9.198 | ciscoRfSupMIB | 3 | 58 | This MIB was designed to complement the CISCO-RF-MIB by providing additional optional status and configuration control for redund… |
| 1.3.6.1.4.1.9.9.199 | ciscoSmFileDownloadMIB | 3 | 23 | The MIB module for downloading files to the Service Modules specifically designed for an architecture containing a controller car… |
| 1.3.6.1.4.1.9.9.201 | ciscoSwitchUsageMIB | 3 | 15 | This MIB defines objects related to statistics for the usage of switch fabric. The switch fabric is used by the incoming packets … |
| 1.3.6.1.4.1.9.9.202 | ciscoOscpMIB | 3 | 52 | The MIB module for managing the Cisco Optical Supervisory Channel Protocol (OSCP). The OSCP is used to determine and maintain wav… |
| 1.3.6.1.4.1.9.9.204 | ciscoXdslLineMIB | 2 | 32 | The tables defined by this MIB module contain a collection of managed objects that are general in nature and apply to different t… |
| 1.3.6.1.4.1.9.9.215 | ciscoMacNotificationMIB | 3 | 72 | This MIB module is for configuration of the MAC notification feature. MAC notification is a mechanism to inform monitoring device… |
| 1.3.6.1.4.1.9.9.216 | ciscoContentNetworkMIB | 3 | 34 | This MIB module defines objects for Content Network devices. A Content Network is a collection of devices that optimizes the deli… |
| 1.3.6.1.4.1.9.9.217 | ciscoCat6kCrossbarMIB | 3 | 210 | The Catalyst 6000 Crossbar MIB provides instrumentation for configuration and operation of the crossbar switching fabric module, … |
| 1.3.6.1.4.1.9.9.218 | ciscoIfThresholdMIB | 3 | 65 | ciscoIfthresholdMIB |
| ... | ||||