A management station can use this MIB module for the
maintenance of persistent topology information of the
PNNI network. Previously, a management station had to
query the network to retrieve the network topology via
an Integrated Local Management Interface (ILMI) link.
The nodes that are down or the nodes whose ILMI-enabled
links are down will not be included in the topology. To
rectify this limitation, the concept of persistent
topology is used.
The persistent topology feature requires the following:
- a node configured to be the gateway node
- PNNI links between the nodes
- node and feeder database.
A Gateway Node, for the purpose of this MIB module, is
defined to be a node that is capable of maintaining a
persistent topology database based on the PNNI Topology
State Elements (PTSEs) sent by the other nodes in the
PNNI peer group. The topology database is persistent
across reboots.
A feeder, in the context of this MIB, is defined as
an ATM switch which does not have PNNI feature. It is
connected to a node(with PNNI feature, therefore
with routing capability) through a physical link. (The
provisioning of the feeder and the link are beyond
the scope of this MIB.) When a feeder and the link
are provisioned, the feeder will update the routing
node with its information(for example: feeder name,
the feeder's port ifIndex etc.). The routing node will
group these feeder information along with its own
information(for example: its node identifier, its feeder
port's information etc.) and send it to other nodes
in the peer group in the PTSE. Upon receiving this
PTSE, each node will update its database. The same actions
are repeated when some information are modified on
the feeder. A network management station can retrieve
these information from a Gateway Node's database. In the
case of a feeder failure, or a feeder is removed
from the network, or the feeder's routing node failure,
the feeder's corresponding entry in the database will
not be removed. The only way to remove an entry from
the database is for the network management station to
delete this entry explicitly.
A link, in the context of this MIB, is defined as
a PNNI link between two PNNI nodes.
(a) The nodal information for each node in the peer group
stored in the persistent topology database includes:
- node id
- node name
- Primary IP address
- Secondary IP address
- system object identifier
- gateway node flag (a flag which indicates whether the
node is configured to be a Gateway Node)
Each node in a peer group has its own entry in the
database.
(b) The feeder information for each feeder in the peer group
stored in the persistent topology database includes:
- Routing node ID(local node ID)
- A local port's 'ifIndex' which identifies the
port the feeder is connected to on the routing
node.
- The feeder's 'shelf, slot, port' numbers which
identifies the port on the feeder itself.
- The protocol type that is used on the link.
- The name of the feeder.
- The LAN IP address of the feeder.
- The ATM IP address of the feeder.
- The model number of the feeder which identifies
the type of the feeder.
Each feeder in a peer group has its own entry in the
database.
(c) The link information for each node in the peer group
stored in the persistent topology database includes:
- local node's id,
- local node port's ifIndex and corresponding physical
descriptor
- remote node's id
- remote node port's ifIndex and corresponding physical
descriptor
Each link in a peer group has its own entry in the
database.
The concept of peer groups is defined by
PNNI, and each peer group contains at least one node.
The persistent topology database only contains
nodal information for the nodes in a particular
peer group, because the Gateway Nodes extract the
nodal information from PNNI PTSEs, and the PTSEs
are flooded only within a peer group.
The persistent topology database is used by a management
station to discover the topology of the network
irrespective of the state and reachability of the
nodes in that network.
The information in the topology database will not
be deleted automatically. The information can only
be deleted by the network operator as an administrative
measure. This is to ensure that even if a node has gone
down, its information will still be in the topology
database until it is deleted by the network operator.
An outside link is a link that connects to a lowest-level
outside node. In contrast to an inside link (i.e.,
horizontal link) or an uplink, an outside link does not
form part of the PNNI topology, and is therefore not used
in path computation.
Parsed from file CISCO-WAN-TOPOLOGY-MIB.mib
Module: CISCO-WAN-TOPOLOGY-MIB
A management station can use this MIB module for the
maintenance of persistent topology information of the
PNNI network. Previously, a management station had to
query the network to retrieve the network topology via
an Integrated Local Management Interface (ILMI) link.
The nodes that are down or the nodes whose ILMI-enabled
links are down will not be included in the topology. To
rectify this limitation, the concept of persistent
topology is used.
The persistent topology feature requires the following:
- a node configured to be the gateway node
- PNNI links between the nodes
- node and feeder database.
A Gateway Node, for the purpose of this MIB module, is
defined to be a node that is capable of maintaining a
persistent topology database based on the PNNI Topology
State Elements (PTSEs) sent by the other nodes in the
PNNI peer group. The topology database is persistent
across reboots.
A feeder, in the context of this MIB, is defined as
an ATM switch which does not have PNNI feature. It is
connected to a node(with PNNI feature, therefore
with routing capability) through a physical link. (The
provisioning of the feeder and the link are beyond
the scope of this MIB.) When a feeder and the link
are provisioned, the feeder will update the routing
node with its information(for example: feeder name,
the feeder's port ifIndex etc.). The routing node will
group these feeder information along with its own
information(for example: its node identifier, its feeder
port's information etc.) and send it to other nodes
in the peer group in the PTSE. Upon receiving this
PTSE, each node will update its database. The same actions
are repeated when some information are modified on
the feeder. A network management station can retrieve
these information from a Gateway Node's database. In the
case of a feeder failure, or a feeder is removed
from the network, or the feeder's routing node failure,
the feeder's corresponding entry in the database will
not be removed. The only way to remove an entry from
the database is for the network management station to
delete this entry explicitly.
A link, in the context of this MIB, is defined as
a PNNI link between two PNNI nodes.
(a) The nodal information for each node in the peer group
stored in the persistent topology database includes:
- node id
- node name
- Primary IP address
- Secondary IP address
- system object identifier
- gateway node flag (a flag which indicates whether the
node is configured to be a Gateway Node)
Each node in a peer group has its own entry in the
database.
(b) The feeder information for each feeder in the peer group
stored in the persistent topology database includes:
- Routing node ID(local node ID)
- A local port's 'ifIndex' which identifies the
port the feeder is connected to on the routing
node.
- The feeder's 'shelf, slot, port' numbers which
identifies the port on the feeder itself.
- The protocol type that is used on the link.
- The name of the feeder.
- The LAN IP address of the feeder.
- The ATM IP address of the feeder.
- The model number of the feeder which identifies
the type of the feeder.
Each feeder in a peer group has its own entry in the
database.
(c) The link information for each node in the peer group
stored in the persistent topology database includes:
- local node's id,
- local node port's ifIndex and corresponding physical
descriptor
- remote node's id
- remote node port's ifIndex and corresponding physical
descriptor
Each link in a peer group has its own entry in the
database.
The concept of peer groups is defined by
PNNI, and each peer group contains at least one node.
The persistent topology database only contains
nodal information for the nodes in a particular
peer group, because the Gateway Nodes extract the
nodal information from PNNI PTSEs, and the PTSEs
are flooded only within a peer group.
The persistent topology database is used by a management
station to discover the topology of the network
irrespective of the state and reachability of the
nodes in that network.
The information in the topology database will not
be deleted automatically. The information can only
be deleted by the network operator as an administrative
measure. This is to ensure that even if a node has gone
down, its information will still be in the topology
database until it is deleted by the network operator.
An outside link is a link that connects to a lowest-level
outside node. In contrast to an inside link (i.e.,
horizontal link) or an uplink, an outside link does not
form part of the PNNI topology, and is therefore not used
in path computation.
Parsed from file CISCO-WAN-TOPOLOGY-MIB.my.txt
Company: None
Module: CISCO-WAN-TOPOLOGY-MIB
A management station can use this MIB module for the
maintenance of persistent topology information of the
PNNI network. Previously, a management station had to
query the network to retrieve the network topology via
an Integrated Local Management Interface (ILMI) link.
The nodes that are down or the nodes whose ILMI-enabled
links are down will not be included in the topology. To
rectify this limitation, the concept of persistent
topology is used.
The persistent topology feature requires the following:
- a node configured to be the gateway node
- PNNI links between the nodes
- node and feeder database.
A Gateway Node, for the purpose of this MIB module, is
defined to be a node that is capable of maintaining a
persistent topology database based on the PNNI Topology
State Elements (PTSEs) sent by the other nodes in the
PNNI peer group. The topology database is persistent
across reboots.
A feeder, in the context of this MIB, is defined as
an ATM switch which does not have PNNI feature. It is
connected to a node(with PNNI feature, therefore
with routing capability) through a physical link. (The
provisioning of the feeder and the link are beyond
the scope of this MIB.) When a feeder and the link
are provisioned, the feeder will update the routing
node with its information(for example: feeder name,
the feeder's port ifIndex etc.). The routing node will
group these feeder information along with its own
information(for example: its node identifier, its feeder
port's information etc.) and send it to other nodes
in the peer group in the PTSE. Upon receiving this
PTSE, each node will update its database. The same actions
are repeated when some information are modified on
the feeder. A network management station can retrieve
these information from a Gateway Node's database. In the
case of a feeder failure, or a feeder is removed
from the network, or the feeder's routing node failure,
the feeder's corresponding entry in the database will
not be removed. The only way to remove an entry from
the database is for the network management station to
delete this entry explicitly.
A link, in the context of this MIB, is defined as
a PNNI link between two PNNI nodes.
(a) The nodal information for each node in the peer group
stored in the persistent topology database includes:
- node id
- node name
- Primary IP address
- Secondary IP address
- system object identifier
- gateway node flag (a flag which indicates whether the
node is configured to be a Gateway Node)
Each node in a peer group has its own entry in the
database.
(b) The feeder information for each feeder in the peer group
stored in the persistent topology database includes:
- Routing node ID(local node ID)
- A local port's 'ifIndex' which identifies the
port the feeder is connected to on the routing
node.
- The feeder's 'shelf, slot, port' numbers which
identifies the port on the feeder itself.
- The protocol type that is used on the link.
- The name of the feeder.
- The LAN IP address of the feeder.
- The ATM IP address of the feeder.
- The model number of the feeder which identifies
the type of the feeder.
Each feeder in a peer group has its own entry in the
database.
(c) The link information for each node in the peer group
stored in the persistent topology database includes:
- local node's id,
- local node port's ifIndex and corresponding physical
descriptor
- remote node's id
- remote node port's ifIndex and corresponding physical
descriptor
Each link in a peer group has its own entry in the
database.
The concept of peer groups is defined by
PNNI, and each peer group contains at least one node.
The persistent topology database only contains
nodal information for the nodes in a particular
peer group, because the Gateway Nodes extract the
nodal information from PNNI PTSEs, and the PTSEs
are flooded only within a peer group.
The persistent topology database is used by a management
station to discover the topology of the network
irrespective of the state and reachability of the
nodes in that network.
The information in the topology database will not
be deleted automatically. The information can only
be deleted by the network operator as an administrative
measure. This is to ensure that even if a node has gone
down, its information will still be in the topology
database until it is deleted by the network operator.
An outside link is a link that connects to a lowest-level
outside node. In contrast to an inside link (i.e.,
horizontal link) or an uplink, an outside link does not
form part of the PNNI topology, and is therefore not used
in path computation.
ciscoWanTopologyMIB MODULE-IDENTITY LAST-UPDATED "200207160000Z" ORGANIZATION "Cisco System Inc." CONTACT-INFO " Cisco Systems Customer Service Postal: 170 West Tasman Drive, San Jose CA 95134-1706. USA Tel: +1 800 553-NETS E-mail: [email protected]" DESCRIPTION "A management station can use this MIB module for the maintenance of persistent topology information of the PNNI network. Previously, a management station had to query the network to retrieve the network topology via an Integrated Local Management Interface (ILMI) link. The nodes that are down or the nodes whose ILMI-enabled links are down will not be included in the topology. To rectify this limitation, the concept of persistent topology is used. The persistent topology feature requires the following: - a node configured to be the gateway node - PNNI links between the nodes - node and feeder database. A Gateway Node, for the purpose of this MIB module, is defined to be a node that is capable of maintaining a persistent topology database based on the PNNI Topology State Elements (PTSEs) sent by the other nodes in the PNNI peer group. The topology database is persistent across reboots. A feeder, in the context of this MIB, is defined as an ATM switch which does not have PNNI feature. It is connected to a node(with PNNI feature, therefore with routing capability) through a physical link. (The provisioning of the feeder and the link are beyond the scope of this MIB.) When a feeder and the link are provisioned, the feeder will update the routing node with its information(for example: feeder name, the feeder's port ifIndex etc.). The routing node will group these feeder information along with its own information(for example: its node identifier, its feeder port's information etc.) and send it to other nodes in the peer group in the PTSE. Upon receiving this PTSE, each node will update its database. The same actions are repeated when some information are modified on the feeder. A network management station can retrieve these information from a Gateway Node's database. In the case of a feeder failure, or a feeder is removed from the network, or the feeder's routing node failure, the feeder's corresponding entry in the database will not be removed. The only way to remove an entry from the database is for the network management station to delete this entry explicitly. A link, in the context of this MIB, is defined as a PNNI link between two PNNI nodes. (a) The nodal information for each node in the peer group stored in the persistent topology database includes: - node id - node name - Primary IP address - Secondary IP address - system object identifier - gateway node flag (a flag which indicates whether the node is configured to be a Gateway Node) Each node in a peer group has its own entry in the database. (b) The feeder information for each feeder in the peer group stored in the persistent topology database includes: - Routing node ID(local node ID) - A local port's 'ifIndex' which identifies the port the feeder is connected to on the routing node. - The feeder's 'shelf, slot, port' numbers which identifies the port on the feeder itself. - The protocol type that is used on the link. - The name of the feeder. - The LAN IP address of the feeder. - The ATM IP address of the feeder. - The model number of the feeder which identifies the type of the feeder. Each feeder in a peer group has its own entry in the database. (c) The link information for each node in the peer group stored in the persistent topology database includes: - local node's id, - local node port's ifIndex and corresponding physical descriptor - remote node's id - remote node port's ifIndex and corresponding physical descriptor Each link in a peer group has its own entry in the database. The concept of peer groups is defined by PNNI, and each peer group contains at least one node. The persistent topology database only contains nodal information for the nodes in a particular peer group, because the Gateway Nodes extract the nodal information from PNNI PTSEs, and the PTSEs are flooded only within a peer group. The persistent topology database is used by a management station to discover the topology of the network irrespective of the state and reachability of the nodes in that network. The information in the topology database will not be deleted automatically. The information can only be deleted by the network operator as an administrative measure. This is to ensure that even if a node has gone down, its information will still be in the topology database until it is deleted by the network operator. An outside link is a link that connects to a lowest-level outside node. In contrast to an inside link (i.e., horizontal link) or an uplink, an outside link does not form part of the PNNI topology, and is therefore not used in path computation." REVISION "200207160000Z" DESCRIPTION "Added cwtLinkOutsideLink to cwtLinkInfoTable." REVISION "200205200000Z" DESCRIPTION "Added cwtLinkInfoTable to this MIB to support Link Persistency. Also added the following notifications: a) cwtLinkInfoAdd, b) cwtLinkInfoDelete and c) cwtLinkModify." REVISION "200204220000Z" DESCRIPTION "Added cwtFeederInfoTable to this MIB to support Feeder Persistency. Also added the following notifications: a) cwtFeederInfoAdd, b) cwtFeederInfoDelete and c) cwtFeederInfoModify." REVISION "200112030000Z" DESCRIPTION "Initial version of the MIB." ::= { ciscoMgmt 234 }
ciscoWanTopologyMIB OBJECT IDENTIFIER ::= { ciscoMgmt 234 }
Vendor: Cisco
Module: CISCO-WAN-TOPOLOGY-MIB
[Automatically extracted from oidview.com]
ciscoWanTopologyMIB MODULE-IDENTITY LAST-UPDATED "200207160000Z" ORGANIZATION "Cisco System Inc." CONTACT-INFO " Cisco Systems Customer Service Postal: 170 West Tasman Drive, San Jose CA 95134-1706. USA Tel: +1 800 553-NETS E-mail: [email protected]" DESCRIPTION "A management station can use this MIB module for the maintenance of persistent topology information of the PNNI network. Previously, a management station had to query the network to retrieve the network topology via an Integrated Local Management Interface (ILMI) link. The nodes that are down or the nodes whose ILMI-enabled links are down will not be included in the topology. To rectify this limitation, the concept of persistent topology is used. The persistent topology feature requires the following: - a node configured to be the gateway node - PNNI links between the nodes - node and feeder database. A Gateway Node, for the purpose of this MIB module, is defined to be a node that is capable of maintaining a persistent topology database based on the PNNI Topology State Elements (PTSEs) sent by the other nodes in the PNNI peer group. The topology database is persistent across reboots. A feeder, in the context of this MIB, is defined as an ATM switch which does not have PNNI feature. It is connected to a node(with PNNI feature, therefore with routing capability) through a physical link. (The provisioning of the feeder and the link are beyond the scope of this MIB.) When a feeder and the link are provisioned, the feeder will update the routing node with its information(for example: feeder name, the feeder's port ifIndex etc.). The routing node will group these feeder information along with its own information(for example: its node identifier, its feeder port's information etc.) and send it to other nodes in the peer group in the PTSE. Upon receiving this PTSE, each node will update its database. The same actions are repeated when some information are modified on the feeder. A network management station can retrieve these information from a Gateway Node's database. In the case of a feeder failure, or a feeder is removed from the network, or the feeder's routing node failure, the feeder's corresponding entry in the database will not be removed. The only way to remove an entry from the database is for the network management station to delete this entry explicitly. A link, in the context of this MIB, is defined as a PNNI link between two PNNI nodes. (a) The nodal information for each node in the peer group stored in the persistent topology database includes: - node id - node name - Primary IP address - Secondary IP address - system object identifier - gateway node flag (a flag which indicates whether the node is configured to be a Gateway Node) Each node in a peer group has its own entry in the database. (b) The feeder information for each feeder in the peer group stored in the persistent topology database includes: - Routing node ID(local node ID) - A local port's 'ifIndex' which identifies the port the feeder is connected to on the routing node. - The feeder's 'shelf, slot, port' numbers which identifies the port on the feeder itself. - The protocol type that is used on the link. - The name of the feeder. - The LAN IP address of the feeder. - The ATM IP address of the feeder. - The model number of the feeder which identifies the type of the feeder. Each feeder in a peer group has its own entry in the database. (c) The link information for each node in the peer group stored in the persistent topology database includes: - local node's id, - local node port's ifIndex and corresponding physical descriptor - remote node's id - remote node port's ifIndex and corresponding physical descriptor Each link in a peer group has its own entry in the database. The concept of peer groups is defined by PNNI, and each peer group contains at least one node. The persistent topology database only contains nodal information for the nodes in a particular peer group, because the Gateway Nodes extract the nodal information from PNNI PTSEs, and the PTSEs are flooded only within a peer group. The persistent topology database is used by a management station to discover the topology of the network irrespective of the state and reachability of the nodes in that network. The information in the topology database will not be deleted automatically. The information can only be deleted by the network operator as an administrative measure. This is to ensure that even if a node has gone down, its information will still be in the topology database until it is deleted by the network operator. An outside link is a link that connects to a lowest-level outside node. In contrast to an inside link (i.e., horizontal link) or an uplink, an outside link does not form part of the PNNI topology, and is therefore not used in path computation." REVISION "200207160000Z" DESCRIPTION "Added cwtLinkOutsideLink to cwtLinkInfoTable." REVISION "200205200000Z" DESCRIPTION "Added cwtLinkInfoTable to this MIB to support Link Persistency. Also added the following notifications: a) cwtLinkInfoAdd, b) cwtLinkInfoDelete and c) cwtLinkModify." REVISION "200204220000Z" DESCRIPTION "Added cwtFeederInfoTable to this MIB to support Feeder Persistency. Also added the following notifications: a) cwtFeederInfoAdd, b) cwtFeederInfoDelete and c) cwtFeederInfoModify." REVISION "200112030000Z" DESCRIPTION "Initial version of the MIB." ::= { ciscoMgmt 234 }
ciscoWanTopologyMIB MODULE-IDENTITY LAST-UPDATED "200207160000Z" ORGANIZATION "Cisco System Inc." CONTACT-INFO " Cisco Systems Customer Service Postal: 170 West Tasman Drive, San Jose CA 95134-1706. USA Tel: +1 800 553-NETS E-mail: [email protected]" DESCRIPTION "A management station can use this MIB module for the maintenance of persistent topology information of the PNNI network. Previously, a management station had to query the network to retrieve the network topology via an Integrated Local Management Interface (ILMI) link. The nodes that are down or the nodes whose ILMI-enabled links are down will not be included in the topology. To rectify this limitation, the concept of persistent topology is used. The persistent topology feature requires the following: - a node configured to be the gateway node - PNNI links between the nodes - node and feeder database. A Gateway Node, for the purpose of this MIB module, is defined to be a node that is capable of maintaining a persistent topology database based on the PNNI Topology State Elements (PTSEs) sent by the other nodes in the PNNI peer group. The topology database is persistent across reboots. A feeder, in the context of this MIB, is defined as an ATM switch which does not have PNNI feature. It is connected to a node(with PNNI feature, therefore with routing capability) through a physical link. (The provisioning of the feeder and the link are beyond the scope of this MIB.) When a feeder and the link are provisioned, the feeder will update the routing node with its information(for example: feeder name, the feeder's port ifIndex etc.). The routing node will group these feeder information along with its own information(for example: its node identifier, its feeder port's information etc.) and send it to other nodes in the peer group in the PTSE. Upon receiving this PTSE, each node will update its database. The same actions are repeated when some information are modified on the feeder. A network management station can retrieve these information from a Gateway Node's database. In the case of a feeder failure, or a feeder is removed from the network, or the feeder's routing node failure, the feeder's corresponding entry in the database will not be removed. The only way to remove an entry from the database is for the network management station to delete this entry explicitly. A link, in the context of this MIB, is defined as a PNNI link between two PNNI nodes. (a) The nodal information for each node in the peer group stored in the persistent topology database includes: - node id - node name - Primary IP address - Secondary IP address - system object identifier - gateway node flag (a flag which indicates whether the node is configured to be a Gateway Node) Each node in a peer group has its own entry in the database. (b) The feeder information for each feeder in the peer group stored in the persistent topology database includes: - Routing node ID(local node ID) - A local port's 'ifIndex' which identifies the port the feeder is connected to on the routing node. - The feeder's 'shelf, slot, port' numbers which identifies the port on the feeder itself. - The protocol type that is used on the link. - The name of the feeder. - The LAN IP address of the feeder. - The ATM IP address of the feeder. - The model number of the feeder which identifies the type of the feeder. Each feeder in a peer group has its own entry in the database. (c) The link information for each node in the peer group stored in the persistent topology database includes: - local node's id, - local node port's ifIndex and corresponding physical descriptor - remote node's id - remote node port's ifIndex and corresponding physical descriptor Each link in a peer group has its own entry in the database. The concept of peer groups is defined by PNNI, and each peer group contains at least one node. The persistent topology database only contains nodal information for the nodes in a particular peer group, because the Gateway Nodes extract the nodal information from PNNI PTSEs, and the PTSEs are flooded only within a peer group. The persistent topology database is used by a management station to discover the topology of the network irrespective of the state and reachability of the nodes in that network. The information in the topology database will not be deleted automatically. The information can only be deleted by the network operator as an administrative measure. This is to ensure that even if a node has gone down, its information will still be in the topology database until it is deleted by the network operator. An outside link is a link that connects to a lowest-level outside node. In contrast to an inside link (i.e., horizontal link) or an uplink, an outside link does not form part of the PNNI topology, and is therefore not used in path computation." REVISION "200207160000Z" DESCRIPTION "Added cwtLinkOutsideLink to cwtLinkInfoTable." REVISION "200205200000Z" DESCRIPTION "Added cwtLinkInfoTable to this MIB to support Link Persistency. Also added the following notifications: a) cwtLinkInfoAdd, b) cwtLinkInfoDelete and c) cwtLinkModify." REVISION "200204220000Z" DESCRIPTION "Added cwtFeederInfoTable to this MIB to support Feeder Persistency. Also added the following notifications: a) cwtFeederInfoAdd, b) cwtFeederInfoDelete and c) cwtFeederInfoModify." REVISION "200112030000Z" DESCRIPTION "Initial version of the MIB." ::= { ciscoMgmt 234 }
| OID | Name | Sub children | Sub Nodes Total | Description |
|---|---|---|---|---|
| 1.3.6.1.4.1.9.9.234.0 | ciscoWanTopologyMIBNotifs | 11 | 11 | None |
| 1.3.6.1.4.1.9.9.234.1 | ciscoWanTopologyMIBObjects | 4 | 57 | None |
| 1.3.6.1.4.1.9.9.234.2 | cwtMIBConformance | 2 | 12 | 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.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 |
| 1.3.6.1.4.1.9.9.219 | ciscoVoiceDnisMIB | 3 | 24 | The MIB module provides management support for Dialer Number Information Service (DNIS) mapping. A DNIS entry is associated with… |
| 1.3.6.1.4.1.9.9.220 | ciscoPaeMIB | 3 | 231 | Cisco Port Access Entity (PAE) module for managing IEEE Std 802.1x. This MIB provides Port Access Entity information that are eith… |
| 1.3.6.1.4.1.9.9.221 | ciscoEnhancedMemPoolMIB | 3 | 87 | New MIB module for monitoring the memory pools of all physical entities on a managed system. |
| 1.3.6.1.4.1.9.9.222 | ciscoEnhancedWredMIB | 3 | 70 | Cisco WRED MIB - Overview Cisco Weighted Random Early Detection/Drop (WRED) is a method which avoids traffic congestion on an outp… |
| 1.3.6.1.4.1.9.9.223 | ciscoWanNcdpMIB | 3 | 58 | This MIB module is intended for the management of network clock distribution and the Network Clock Distribution Protocol (NCDP) i… |
| 1.3.6.1.4.1.9.9.224 | ciscoDevExcepReportMIB | 3 | 29 | This mib defines the SNMP objects to report exceptions to north-bound NMS. The devices implementing this MIB monitor the status of… |
| 1.3.6.1.4.1.9.9.225 | ciscoLagMIB | 3 | 56 | Cisco Link Aggregation module for managing IEEE Std 802.3ad. This MIB provides Link Aggregation information that are either exclud… |
| 1.3.6.1.4.1.9.9.226 | ciscoNDEMIB | 4 | 17 | The Netflow Data Export (NDE) MIB provides instrumentation for configuration and operation of the Netflow Data Export feature. A … |
| 1.3.6.1.4.1.9.9.227 | ciscoItpAclMIB | 3 | 45 | The MIB for managing access lists that control messages transported over Signalling System No. 7 (SS7) Network via Cisco IP Trans… |
| 1.3.6.1.4.1.9.9.228 | ciscoItpRtMIB | 3 | 47 | This MIB is for managing information required to route messages transported over Signalling System No. 7 (SS7) Network via Cisco … |
| 1.3.6.1.4.1.9.9.229 | ciscoDs1ExtMIB | 2 | 129 | The MIB module to describe DS1/E1 interface objects. This is an extension to the standard DS1/E1 MIB (RFC 2495). Unless mentioned… |
| 1.3.6.1.4.1.9.9.230 | ciscoItpActMIB | 3 | 29 | The MIB for providing information specified in ITU Q752 Monitoring and Measurements for Signalling System No. 7(SS7) Network. This… |
| 1.3.6.1.4.1.9.9.231 | ciscoItpTextualConventions | 0 | 0 | The defines textual conventions used by to manage devices related to the SS7 network. The relevant ITU documents describing this… |
| 1.3.6.1.4.1.9.9.232 | ciscoItpSpMIB | 3 | 384 | The MIB for managing Signalling Points and its associated messages transported over Signalling System No. 7 (SS7) Network via Ci… |
| 1.3.6.1.4.1.9.9.233 | ciscoItpSccpMIB | 3 | 194 | The MIB for Signaling Connection Control Part(SCCP) messages transported over Signalling System No. 7 (SS7) Network via Cisco IP … |
| 1.3.6.1.4.1.9.9.235 | ciscoImaMIB | 2 | 60 | The MIB module describes Cisco IMA objects. This is an extension to the standard of ATM Forum IMA version 1.1, AF-PHY-0086.001 Spe… |
| 1.3.6.1.4.1.9.9.236 | ciscoWanSctMgmtMIB | 2 | 18 | MIB module to manage SCT files in a node. SCTs (Service Class Templates) are nodal configuration files, which define the traffic … |
| 1.3.6.1.4.1.9.9.237 | ciscoNmsApplHealthMIB | 3 | 21 | This MIB defines Cisco NMS Application (cna) Health Status Notifications and the related objects. These notifications will be sen… |
| 1.3.6.1.4.1.9.9.238 | ciscoIGMPFilterMIB | 2 | 45 | IGMP Filter configuration MIB. This MIB provides a mechanism for users to configure the system to intercept IGMP joins for IP Mul… |
| 1.3.6.1.4.1.9.9.240 | cGgsnMIB | 3 | 389 | This MIB module manages the Gateway GPRS Support Node (GGSN) devices. A GGSN device provides interworking with external packet-dat… |
| 1.3.6.1.4.1.9.9.241 | cggsnQosMIB | 2 | 89 | This MIB module manages the Quality of Service parameters of GGSN in a GPRS system. GGSN is the Gateway GPRS Support Node in the … |
| 1.3.6.1.4.1.9.9.242 | ciscoCableAvailabilityMIB | 3 | 60 | This is the MIB module for management of Hot Standby Connection to Connection Protocol (HCCP) features. HCCP is a Cisco proprieta… |
| 1.3.6.1.4.1.9.9.243 | ciscoHealthMonitorMIB | 3 | 22 | Health Monitor MIB module. The Health Monitor uses a model based on events of varying severity and frequency, and predefined rule… |
| 1.3.6.1.4.1.9.9.244 | ciscoNbarProtocolDiscoveryMIB | 3 | 84 | Cisco NBAR Protocol Discovery MIB NBAR - Network Based Application Recognition is an intelligent classification engine that reco… |
| 1.3.6.1.4.1.9.9.245 | ciscoGtpDirectorMIB | 3 | 35 | This MIB module defines objects that are used to manage GTP Director Module. In the GPRS network, the APN is the identifier that s… |
| 1.3.6.1.4.1.9.9.246 | ciscoL2TunnelConfigMIB | 3 | 65 | This MIB module is for layer 2 tunneling related configurations on a device. Tunneling allows separate local networks to be consi… |
| 1.3.6.1.4.1.9.9.248 | ciscoItpSp2MIB | 3 | 30 | The MIB for providing information specified in ITU Q752 Monitoring and Measurements for Signaling System No. 7(SS7) Network. This … |
| 1.3.6.1.4.1.9.9.249 | ciscoEnhancedImageMIB | 2 | 44 | Initial version of the MIB. This MIB has Image table containing the following information related to the running IOS image 1. Enti… |
| 1.3.6.1.4.1.9.9.252 | cTapMIB | 3 | 80 | This module manages Cisco's intercept feature. |
| 1.3.6.1.4.1.9.9.253 | ciscoItpXuaMIB | 3 | 250 | The MIB for MTP3 User Adaptation (M3UA) and SCCP User Adaptation (SUA) for Cisco's IP Transfer Point (ITP) implementation. The Cis… |
| 1.3.6.1.4.1.9.9.254 | ciscoSlbExtMIB | 3 | 425 | The extended MIB for managing Server Load Balancing Manager(s). This MIB extends the SLB management functionality in the CISCO-SL… |
| 1.3.6.1.4.1.9.9.255 | ciscoFabricMcastMIB | 3 | 30 | Fabric Multicast Resource MIB module. This MIB module is used for managing/tracking the fabric multicast resource related informa… |
| 1.3.6.1.4.1.9.9.256 | ciscoFabricMcastApplMIB | 3 | 16 | Fabric multicast resource MIB module. This MIB module is used for managing/tracking the fabric multicast resource application rel… |
| 1.3.6.1.4.1.9.9.257 | ciscoFabricHfrMIB | 3 | 90 | Cisco Enhanced Benes fabric MIB module. This MIB module is used for managing/tracking the Ehanced Benes Fabric entities and/or fa… |
| 1.3.6.1.4.1.9.9.259 | ciscoPsaMicrocodeMIB | 3 | 24 | Cisco PSA Microcode MIB - Overview The PSA is the Packet Switching ASIC used in module like engine 2(E2) line cards in GSR for IP … |
| 1.3.6.1.4.1.9.9.260 | ciscoSsgMIB | 3 | 218 | The MIB Module manages Service Selection Gateway(SSG) devices. Service Selection Gateway(SSG) is a switching solution for service… |
| 1.3.6.1.4.1.9.9.261 | ciscoPtopoExtnMIB | 2 | 18 | This MIB module contains extensions to the PTOPO-MIB that provide support to distinguish between bidirectional and unidirectional… |
| 1.3.6.1.4.1.9.9.262 | ciscoVoaMIB | 2 | 14 | This MIB module defines objects to configure and manage the Variable Optical Attenuator (VOA) modules. VOA modules are typically … |
| 1.3.6.1.4.1.9.9.263 | ciscoIgmpSnoopingMIB | 3 | 286 | The MIB module for IGMP Snooping feature. Internet Group Management Protocol (IGMP) is the protocol used by IPv4 end hosts to ind… |
| 1.3.6.1.4.1.9.9.264 | ciscoOpticalMonitorMIB | 3 | 72 | This MIB module defines objects to monitor optical characteristics and set corresponding thresholds on the optical interfaces in … |
| 1.3.6.1.4.1.9.9.265 | ciscoEntityPfeMib | 3 | 58 | The Packet Forwarding Engine technology are Cisco developed Network Processors, which accelerates certain features in order to pr… |
| 1.3.6.1.4.1.9.9.268 | ciscoWlanVlanMIB | 3 | 41 | This MIB module provides network management support for device VLAN configuration on IEEE 802.11 wireless LAN. ACRONYMS AES Advanced… |
| 1.3.6.1.4.1.9.9.269 | ciscoTBridgeDevIfMIB | 2 | 20 | This MIB module provides network management support for configuration and status information of devices supporting transparent br… |
| 1.3.6.1.4.1.9.9.270 | ciscoSyslogEventExtMIB | 2 | 21 | This MIB module extends the Cisco Syslog MIB and provides network management support to handle and process Syslog messages as devi… |
| 1.3.6.1.4.1.9.9.271 | ciscoL2DevMonMIB | 3 | 24 | This MIB module is for monitoring of active layer 2 devices by hot standby layer 2 devices and the configuration of hot standby s… |
| 1.3.6.1.4.1.9.9.272 | ciscoDot11IfMIB | 3 | 212 | This MIB module provides network management support for Cisco IEEE 802.11 Wireless LAN type device (Access Point) radio interface… |
| 1.3.6.1.4.1.9.9.273 | ciscoDot11AssociationMIB | 2 | 91 | This MIB module provides network management information on IEEE 802.11 wireless device association management and data packet for… |
| 1.3.6.1.4.1.9.9.275 | ciscoBcpMIB | 2 | 25 | This MIB module describes the Managed Objects for of Bridge Control Protocol (RFC2878). This MIB is influenced by RFC1474. |
| 1.3.6.1.4.1.9.9.276 | ciscoIfExtensionMIB | 3 | 143 | A MIB module for extending the IF-MIB (RFC2863) to add objects which provide additional information about interfaces not availabl… |
| 1.3.6.1.4.1.9.9.277 | ciscoDdpIappMIB | 3 | 22 | This MIB module describes the management support for the Inter-Access Point Protocol (IAPP). IAPP is a Cisco propriety Data Deli… |
| 1.3.6.1.4.1.9.9.278 | ciscoIpProtocolMIB | 3 | 63 | The MIB module is for management of information to support packet filtering on IP protocols. The cippfIpProfileTable allows users… |
| 1.3.6.1.4.1.9.9.279 | ciscoAtmQosMIB | 3 | 67 | The MIB is created to provide ATM QoS information in these areas: 1. Traffic shaping on a per-VC basis 2. Traffic shaping on a pe… |
| 1.3.6.1.4.1.9.9.280 | ciscoOutageMIB | 3 | 75 | This MIB module describes, stores, and reports outage related information generated by individual hardware and software component… |
| 1.3.6.1.4.1.9.9.281 | ciscoFabricC12kMIB | 3 | 135 | Cisco Fabric MIB module for c12000 series of routers. This MIB module is used for managing/tracking the c12000 fabric entities an… |
| 1.3.6.1.4.1.9.9.282 | ciscoVsanMIB | 2 | 104 | The MIB module for the management of the Virtual Storage Networks (VSANs) within the frame work of Cisco's VSAN Architecture. T… |
| 1.3.6.1.4.1.9.9.284 | ciscoFcRouteMIB | 2 | 55 | The MIB module for configuring and displaying FC (Fibre Channel) Route Information. |
| ... | ||||