AD | Application | AWS | Azure | Cloud | Database | Enterprise | Environmental | Event Log | File System | IoT | IT Service | Network/System | Infra | Performance | Protocol | SaaS | Security | Service Level | Storage | Linux | VMware | VoIP | Web | Wireless | SNMP

Crumbtrail

MonitorTools.com » Technical documentation » SNMP » MIB » Cisco » CISCO-WAN-TOPOLOGY-MIB » Objects

CISCO-WAN-TOPOLOGY-MIB.mib object view, vendor Cisco

Introduction

Most network devices and programs ship with so-called MIB files to describe the parameters and meanings (i.e.: friendly names) which are available for monitoring via SNMP.
ActiveXperts Network Monitor 2024 can import vendor-specific MIB files, so it can be used to monitor specific OID's (Object Identifiers). This way, you can monitor your devices, computers, etc. by selecting your relevant OID's by name.

ActiveXperts Network Monitor 2024 can import MIB file CISCO-WAN-TOPOLOGY-MIB and use it to monitor vendor specific OID's.

CISCO-WAN-TOPOLOGY-MIB file content

Object view of CISCO-WAN-TOPOLOGY-MIB:

Scalar Object
cwtGatewayAdminStatus .1.3.6.1.4.1.9.9.234.1.1.1
The value of this object determines whether this node is a Gateway Node or not. A value of `enable' configures this node to be the Gateway Node, and enables the generation of the topology database. A value of `disable' configures this node to not be a Gateway Node, and deletes the topology database if it exists.
cwtGatewayNodeOperStatus .1.3.6.1.4.1.9.9.234.1.1.2
This is the operational status of the Gateway Node. 'disabled' indicates that this node is not a Gateway Node and no topology database is available on this node. 'enabled' indicates that this node has been configured as the Gateway Node and the topology database has been built. 'disabling' indicates that this node is no longer the Gateway Node and is in the process of deleting the topology database. 'enabling' indicates that this node has been configured as the Gateway Node and is in the process of building the topology database. 'enabledAndFull' indicates that this node has been configured as the Gateway Node but its topology database is full. The management station should always poll this object first before taking action to: a) 'enable' or 'disable' the Gateway Node b) remove an entry or entries from 'cwtNodeInfoTable' and its corresponding entries from 'cwtFeederInfoTable'. If the object returns 'disabled', the management station can 'enable' the Gateway Node if it desires. If the object returns 'enabled', the management station can 'disable' the Gateway Node if it desires. If the object returns 'enabling' or 'disabling', the management station should not take any actions. If the object returns 'enabledAndFull', the management station can take one of the following actions: a) remove enties from the cwtNodeInfoTable b) 'disable' and then 'enable' the Gateway Node, which would cause the node to delete and then rebuild the topology database.
cwtDBLastChange .1.3.6.1.4.1.9.9.234.1.1.3
The value of MIB II's sysUpTime object at the time that: a) the topology database is last changed on this node. b) the cwtGatewayAdminStatus is last changed. c) the cwtGatewayNodeOperStatus enters the 'enabledAndFull' state.
cwtNodeInfoEntry .1.3.6.1.4.1.9.9.234.1.2.1.1
This is a row entry in the topology node info table. Each entry corresponds to one node in the network.
cwtFeederInfoEntry .1.3.6.1.4.1.9.9.234.1.3.1.1
This is a row entry in the feeder info table. Each entry corresponds to one 'feeder' in the network.
cwtLinkInfoEntry .1.3.6.1.4.1.9.9.234.1.4.1.1
This is an entry in the 'cwtLinkInfoTable'. Each entry corresponds to one link in the network. a) The entries in this table are derived from PNNI PTSE database or added by a network management station. b) The entries in the PNNI PTSE database time out when no new PTSE is received from a node after a certain time. However, the corresponding entries are not removed from this table. c) Only the network management station can delete an entry from this table. d) A network management station cannot modify an existing entry in this table.
Tabular Object
cwtIndex .1.3.6.1.4.1.9.9.234.1.2.1.1.1
This is the index into the topology database array. This value should remain persistent while the topology database exists, which means that it'll be consistent across boots. However, if this node is disabled as the gateway node, and later on enabled (by changing the value of cwtGatewayAdminStatus), then the cwtIndex may be different for the same node info entry in the topology database.
cwtGatewayNodeFlag .1.3.6.1.4.1.9.9.234.1.2.1.1.2
This variable indicates if the corresponding entry is a Gateway Node or not. If this value contains 'true', the corresponding node is a Gateway Node. If this value contains 'false', then the corresponding node is not a Gateway Node.
cwtNodeId .1.3.6.1.4.1.9.9.234.1.2.1.1.3
The unique Id which identifies the node in the entry. This value is different from cwtIndex because it is a unique number which identifies a node in the ATM network, while cwtIndex is an index for an entry in the topology database. The same physical node can have different cwtIndex in different topology databases.
cwtNodeName .1.3.6.1.4.1.9.9.234.1.2.1.1.4
The configured name of the node.
cwtPrimIPIfType .1.3.6.1.4.1.9.9.234.1.2.1.1.5
This object specifies the type of interface for the associated instance of cwtPrimIP.
cwtPrimIPIfName .1.3.6.1.4.1.9.9.234.1.2.1.1.6
This object specifies the name of the interface for the associated instance of cwtPrimIP.
cwtPrimIPAddrType .1.3.6.1.4.1.9.9.234.1.2.1.1.7
This object specifies the type of address contained in the associated instance of cwtPrimIP.
cwtPrimIP .1.3.6.1.4.1.9.9.234.1.2.1.1.8
Primary IP address of the corresponding node. This value is taken from the PNNI Nodal PTSE. The primary IP address is used by the NMS to manage the switch. The type of interface (i.e. ATM interface, LAN interface, etc) for this IP address is specified by cwtPrimIPIfType. The NMS will use this IP address first, but if it can not connect to the switch on this address, then it will try to contact the switch using the secondary IP address instead.
cwtSecIPIfType .1.3.6.1.4.1.9.9.234.1.2.1.1.9
This object specifies the type of interface for the associated instance of cwtSecIP.
cwtSecIPIfName .1.3.6.1.4.1.9.9.234.1.2.1.1.10
This object specifies the name of the interface for the associated instance of cwtSecIP.
cwtSecIPAddrType .1.3.6.1.4.1.9.9.234.1.2.1.1.11
This object specifies the type of address contained in the associated instance of cwtSecIP.
cwtSecIP .1.3.6.1.4.1.9.9.234.1.2.1.1.12
Secondary IP address of the corresponding node. This value is taken from the PNNI Nodal PTSE. This value is used by the NMS to manage the switch. Please refer to the Description section of cwtPrimIP for more information.
cwtSysObjId .1.3.6.1.4.1.9.9.234.1.2.1.1.13
This variable contains the sysObjectID of the node, which is used to identify different hardware platforms. The actual values are defined in CISCO-PRODUCTS-MIB.
cwtNodeInfoTimeOutFlag .1.3.6.1.4.1.9.9.234.1.2.1.1.14
This variable indicates if the PTSE of this node is currently contained in the PNNI PTSE database. The nodal information in the persistent topology database is derived from the PTSEs in the PNNI PTSE database. The entries in the PNNI PTSE database times out if no new PTSE is received from a node after a certain time. If that happens, this object is set to 'false'. This object would allow the NMS to determine whether this node currently has connectivity with the rest of the network.
cwtRowStatus .1.3.6.1.4.1.9.9.234.1.2.1.1.15
In our implementation, we'll be supporting 'active', 'createAndGo', and 'destroy'. The value of this variable is set to 'active' by the managed system for each valid entry. If a management station wants to delete an entry from the database, this value is set to 'destroy'. If a management station wants to create a new entry, this value is set to 'createAndGo'.
cwtFeederIndex .1.3.6.1.4.1.9.9.234.1.3.1.1.1
This is the index into the feeder database array. This value should remain persistent while the feeder database exists, which means that it'll be consistent across boots. However, if this node is disabled as the gateway node, and later on enabled, then the 'cwtFeederIndex' may be different for the same feeder info entry in the 'feeder database'.
cwtLocalNodeId .1.3.6.1.4.1.9.9.234.1.3.1.1.2
The unique Id which identifies the node the feeder is attached to.
cwtLocalIfIndex .1.3.6.1.4.1.9.9.234.1.3.1.1.3
This variable contains the 'ifIndex' of the local port this feeder is connected to.
cwtLocalIfName .1.3.6.1.4.1.9.9.234.1.3.1.1.4
The textual name of the interface of the local port this feeder is connected to. This should contain the same 'ifName' associated with the 'cwtLocalIfIndex'. If this interface does not have a textual name, the value of this object is a zero length string.
cwtFeederShelf .1.3.6.1.4.1.9.9.234.1.3.1.1.5
This variable contains the physcial shelf number of the feeder module.
cwtFeederSlot .1.3.6.1.4.1.9.9.234.1.3.1.1.6
This variable contains the physical slot number of the feeder module.
cwtFeederPort .1.3.6.1.4.1.9.9.234.1.3.1.1.7
This variable contains the physical port number of the feeder module.
cwtFeederLMIType .1.3.6.1.4.1.9.9.234.1.3.1.1.8
This object identifies the 'link' type. feeder(1) is applicable when cwtFeederType contains a value other than fdrNON(12). xLMI(2) is applicable only when cwtFeederType contains a value of fdrNON(12). Both feeder(1) and xLMI(2) are CISCO proprietary interfaces. xLMI stands for 'extended local management interface.
cwtFeederType .1.3.6.1.4.1.9.9.234.1.3.1.1.9
This identifies the feeder type. fdrNON(12) is applicable when cwfLMIType is xLMI(2). Other values are applicable when cwtFeederLMIType is feeder(1). The possible values are : fdrIPX -- Feeder is an IPX node in a routing network fdrBPX -- Feeder is an BPX node in a routing network fdrIpxAF -- Feeder is a stand-alone IPX node fdrBASIS -- Feeder is a stand-alone BASIS node fdrUNKNOWN -- Feeder is unknown fdrUNI -- Feeder is a UNI AIT (phase 0) fdrAPS -- Feeder is an APS (Adjunct Processor Shelf) fdrIGX -- Feeder is an IGX node in a routing network fdrIgxAF -- Feeder is a stand-alone IGX node fdrVSI -- Feeder is an VSI Controller fdrPAR -- Feeder is a PAR fdrNON -- This is non-feeder type
cwtFeederName .1.3.6.1.4.1.9.9.234.1.3.1.1.10
The configured name of the feeder.
cwtFeederLanIPAddrType .1.3.6.1.4.1.9.9.234.1.3.1.1.11
This object specifies the type of address contained in the associated instance of cwtFeederLanIP.
cwtFeederLanIP .1.3.6.1.4.1.9.9.234.1.3.1.1.12
This object specifies the LAN IP address of the 'feeder'. The type of this address is specified by cwtFeederLanIPAddrType.
cwtFeederAtmIPAddrType .1.3.6.1.4.1.9.9.234.1.3.1.1.13
This object specifies the type of address contained in the associated instance of cwtFeederAtmIP.
cwtFeederAtmIP .1.3.6.1.4.1.9.9.234.1.3.1.1.14
This object identifies the ATM IP address of the 'feeder'. The type of this address is specified by cwtFeederAtmIP.
cwtFeederModelNumber .1.3.6.1.4.1.9.9.234.1.3.1.1.15
This variable contains the 'model number' of the corresponding feeder. This is an implementation specific integer value which is used to differentiate between feeder platforms.
cwtFeederRowStatus .1.3.6.1.4.1.9.9.234.1.3.1.1.16
In our implementation, we'll be supporting 'active', and 'destroy'. The value of this variable is set to 'active' by the managed system for each valid entry. If a management station wants to delete an entry from the database, this value is set to 'destroy'.
cwtLinkIndex .1.3.6.1.4.1.9.9.234.1.4.1.1.1
This is the index into the link database array. This value is of local significance to the gateway node. As long as a node remains 'enabled' as a gateway node, this value remains persistent across boots. However, if this node is disabled as the gateway node, and is enabled later on, the cwtLinkIndex may be different for the same link info entry in the topology database.
cwtLinkLocalNodeId .1.3.6.1.4.1.9.9.234.1.4.1.1.2
The unique Id which identifies the local node this link resides on.
cwtLinkRemoteNodeId .1.3.6.1.4.1.9.9.234.1.4.1.1.3
The unique Id which identifies the remote node this link resides on.
cwtLinkLocalIfIndex .1.3.6.1.4.1.9.9.234.1.4.1.1.4
The local 'ifIndex' of this link.
cwtLinkRemoteIfIndex .1.3.6.1.4.1.9.9.234.1.4.1.1.5
The remote 'ifIndex' of this link.
cwtLinkLocalPhysicalId .1.3.6.1.4.1.9.9.234.1.4.1.1.6
The local physical port identifier of this link.
cwtLinkRemotePhysicalId .1.3.6.1.4.1.9.9.234.1.4.1.1.7
The remote physcial port identifier of this link.
cwtLinkInfoTimeOutFlag .1.3.6.1.4.1.9.9.234.1.4.1.1.8
This variable indicates if the PTSE of this link is currently contained in the PNNI PTSE database. If this entry is also contained in the PNNI PTSE database, the agent sets the value of this variable to 'true'. If this entry is not contained in the PNNI PTSE database, the agent set the value of this variable to 'false'.
cwtLinkOutsideLink .1.3.6.1.4.1.9.9.234.1.4.1.1.9
This variable indicates if the link is an outside link.
cwtLinkRowStatus .1.3.6.1.4.1.9.9.234.1.4.1.1.10
In our implementation, we'll be supporting 'active', 'createAndGo', and 'destroy'. The value of this variable is set to 'active' by the managed system for each valid entry. If a management station wants to delete an entry from the database, this value is set to 'destroy'. If a management station wants to create a new entry, this value is set to 'createAndGo'. The network management station should provide the intial values of all mib objects when setting this variable to 'createAndGo'.
Table
cwtNodeInfoTable .1.3.6.1.4.1.9.9.234.1.2.1
A table of node topology information is to be maintained for the management station. This table contains the information for the nodes in the peer group.
cwtFeederInfoTable .1.3.6.1.4.1.9.9.234.1.3.1
A table of 'feeder' information to be maintained for the management station. This table contains the information for the 'feeders' in this peer group.
cwtLinkInfoTable .1.3.6.1.4.1.9.9.234.1.4.1
A table of 'link' information in the PNNI network. If a switch is managed by multiple network management stations, these network management stations can have a persistent view of links in the network by retrieving this table. A link is a PNNI link between two nodes.
Trap
cwtConfigGatewayStatus .1.3.6.1.4.1.9.9.234.0.1
This notification is generated when the gateway node admin status is changed.
cwtTopoInfoAdd .1.3.6.1.4.1.9.9.234.0.2
This notification is generated when a new topology nodal info entry is added in the topology database.
cwtTopoInfoModify .1.3.6.1.4.1.9.9.234.0.3
This notification is generated when an existing topology nodal info entry is modified in the topology database.
cwtTopoInfoDelete .1.3.6.1.4.1.9.9.234.0.4
This notification is generated when an existing topology nodal info entry is deleted in the topology database.
cwtTopoDbFull .1.3.6.1.4.1.9.9.234.0.5
This notification is generated when the topology database becomes full.
cwtFeederInfoAdd .1.3.6.1.4.1.9.9.234.0.6
This notification is generated when a new feeder info entry is added in the database.
cwtFeederInfoModify .1.3.6.1.4.1.9.9.234.0.7
This notification is generated when an existing feeder info entry is modified in the database.
cwtFeederInfoDelete .1.3.6.1.4.1.9.9.234.0.8
This notification is generated when an existing feeder info entry is deleted in the database.
cwtLinkInfoAdd .1.3.6.1.4.1.9.9.234.0.9
This notification is generated when a new link info entry is added in the 'link' database.
cwtLinkInfoModify .1.3.6.1.4.1.9.9.234.0.10
This notification is generated when an existing link info entry is modified in the 'link' database.
cwtLinkInfoDelete .1.3.6.1.4.1.9.9.234.0.11
This notification is generated when an existing link info entry is deleted in the 'link' database.
Object Identifier
ciscoWanTopologyMIB .1.3.6.1.4.1.9.9.234
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.
ciscoWanTopologyMIBNotifs .1.3.6.1.4.1.9.9.234.0
ciscoWanTopologyMIBObjects .1.3.6.1.4.1.9.9.234.1
cwtMIBConformance .1.3.6.1.4.1.9.9.234.2
cwtSystemGroup .1.3.6.1.4.1.9.9.234.1.1
cwtNodalInfoGroup .1.3.6.1.4.1.9.9.234.1.2
cwtFeederInfoGroup .1.3.6.1.4.1.9.9.234.1.3
cwtLinkInfoGroup .1.3.6.1.4.1.9.9.234.1.4
cwtMIBCompliances .1.3.6.1.4.1.9.9.234.2.1
cwtMIBGroups .1.3.6.1.4.1.9.9.234.2.2
Group
cwtSystemMIBGroups .1.3.6.1.4.1.9.9.234.2.2.1
This group contains the object which enables a node to function as a Gateway Node.
cwtNodalMIBGroups .1.3.6.1.4.1.9.9.234.2.2.2
This group contains objects which identify a node in the network.
cwtFeederMIBGroups .1.3.6.1.4.1.9.9.234.2.2.3
This group contains objects which identify a node in the network.
cwtLinkMIBGroups .1.3.6.1.4.1.9.9.234.2.2.7
This group contains objects which identify a link in the network.
cwtNotificationsGroup .1.3.6.1.4.1.9.9.234.2.2.4
A collection of notifications which indicate changes in the topology database.
cwtNotificationsGroup2 .1.3.6.1.4.1.9.9.234.2.2.5
A collection of notifications which indicate changes in the topology database.
cwtNotificationsGroup3 .1.3.6.1.4.1.9.9.234.2.2.6
A collection of notifications which indicate changes in the topology database.