Cisco-apent-mib.txt download

The enumeration 'module' is applicable if the physical entity class is some sort of self-contained sub-system. If it is removable, then it should be modeled within a container entity, otherwise it should be modeled directly within another physical entity e. The enumeration 'stack' is applicable if the physical entity class is some sort of super-container possibly virtual , intended to group together multiple chassis entities.

A stack may be realized by a 'virtual' cable, a real interconnect cable, attached to multiple chassis, or may in fact be comprised of multiple interconnect cables. A stack should not be modeled within any other physical entities, but a stack may be contained within another stack. Only chassis entities should be contained within a stack. There is always at least one row for an 'overall' physical entity. This object should contain a string which identifies the manufacturer's name for the physical entity, and should be set to a distinct value for each version or model of the physical entity.

An agent should set this object to a enterprise-specific registration identifier value indicating the specific equipment type in detail. The associated instance of entPhysicalClass is used to indicate the general type of hardware device. A value of zero indicates this physical entity is not contained in any other physical entity. Note that the set of 'containment' relationships define a strict hierarchy; that is, recursion is not allowed.

In the event a physical entity is contained by more than one physical entity e. An agent should set this object to the standard enumeration value which most accurately indicates the general class of the physical entity, or the primary class if there is more than one. If no appropriate standard registration identifier exists for this physical entity, then the value 'other 1 ' is returned. If the value is unknown by this agent, then the value 'unknown 2 ' is returned.

Sibling components are defined as entPhysicalEntries which share the same instance values of each of the entPhysicalContainedIn and entPhysicalClass objects. An NMS can use this object to identify the relative ordering for all sibling components of a particular parent identified by the entPhysicalContainedIn instance in each sibling entry. This value should match any external labeling of the physical component if possible. For example, for a container e. If the physical position of this component does not match any external numbering or clearly visible ordering, then user documentation or other external reference material should be used to determine the parent-relative position.

If this is not possible, then the the agent should assign a consistent but possibly arbitrary ordering to a given set of 'sibling' components, perhaps based on internal representation of the components. If the agent cannot determine the parent-relative position for some reason, or if the associated value of entPhysicalContainedIn is '0', then the value '-1' is returned. Otherwise a non-negative integer is returned, indicating the parent-relative position of this physical entity. Parent-relative ordering normally starts from '1' and continues to 'N', where 'N' represents the highest positioned child entity.

However, if the physical entities e. Note that this ordering may be sparse or dense, depending on agent implementation. The actual values returned are not globally meaningful, as each 'parent' component may use different numbering algorithms. The ordering is only meaningful among siblings of the same parent component. The agent should retain parent-relative position values across reboots, either through algorithmic assignment or use of non-volatile storage.

If there is no local name, or this object is otherwise not applicable, then this object contains a zero-length string. Note that the value of entPhysicalName for two physical entities will be the same in the event that the console interface does not distinguish between them, e.

The preferred value is the hardware revision identifier actually printed on the component itself if present. Note that if revision information is stored internally in a non-printable e. If no specific hardware revision string is associated with the physical component, or this information is unknown to the agent, then this object will contain a zero-length string.

If no specific firmware programs are associated with the physical component, or this information is unknown to the agent, then this object will contain a zero-length string. If no specific software programs are associated with the physical component, or this information is unknown to the agent, then this object will contain a zero-length string.

The preferred value is the serial number string actually printed on the component itself if present. On the first instantiation of an physical entity, the value of entPhysicalSerialNum associated with that entity is set to the correct vendor-assigned serial number, if this information is available to the agent.

If a serial number is unknown or non-existent, the entPhysicalSerialNum will be set to a zero-length string instead. Note that implementations which can correctly identify the serial numbers of all installed physical entities do not need to provide write access to the entPhysicalSerialNum object. Agents which cannot provide non-volatile storage for the entPhysicalSerialNum strings are not required to implement write access for this object.

Not every physical component will have a serial number, or even need one. FICON is an IBM standard of transport mechanism for communication between the mainframes and devices and is a major consideration for enterprise data centers. This MIB module defines textual conventions that are commonly used in modeling management information pertaining to configuration, status and activity of firewalls.

The MIB Module supports the functions of a gatekeeper. The gatekeeper is a function of the H. The gatekeeper provides address translation and controls access to the network for H. For T1 and Switched 56 kbps interfaces.

It defines the attributes of Megaco protocol. Reference: ITU H. All rights reserved. This module is a cisco-ized version of the IETF d.

This module is a cisco-ized version of the IETF dr. Version draft-ietf-mboned-msdp-mib The MIB is used to manage call service state for interfaces on media gateway. Router image MIB which identify the capabilities and characteristics of the image. It provides additional management information for sorting device interfaces. A MIB module that provides monitoring information about the transceivers plugged into interface on a system.

The MIB module for management of IP Multicast routing, but independent of the specific multicast routing protocol in use. This information can be used to manage the state of software used to collect all packets transported and received over a SS7 link.

This device could be a router or a switch. This MIB module is for monitoring of active layer 2 devices by hot standby layer 2 devices and the configuration of hot standby switch-over parameters. Interface switchport mode configuration management MIB.

This MIB is used to monitor and control configuration of interface switchport and routed mode. This MIB module is for layer 2 tunneling related configurations on a device. Tunneling allows separate local networks to be considered as a single VLAN.

These separate networks are connected via an ISP, which will tunnel the packets from one network to an. Link Error Monitoring Feature provides a mechanism to monitor a certain set of link error counters on an interface and take certain actions when the increase in the error counters betwe. MAC notification is a mechanism to inform monitoring devices when there are MAC addresses learnt or removed from the forwarding database of the monitored devices. It defines the attributes of ITU H.

This MIB module is used to monitor optical parameters of a network element. This MIB deals with the operating parameters of the optical layer.

This MIB module defines objects to monitor optical characteristics and set corresponding thresholds on the optical interfaces in a network element.

The MIB module for the management of packet capture feature. This MIB module is for providing the port monitoring information.

The MIB module is for configuration of policy and policy group. A policy group can be described as a set of entities identified by IP addresses or other means. Members of a policy group will be subjected to the same policy. In this MIB, user can apply a p. The MIB module to describe active system processes.

Virtual Machine refers to those OS which can run the code or process of a different executional model OS. Virtual P. This module defines the object identifiers that are assigned to various hardware platforms, and hence are returned as values for sysObjectID.

This interface is a switch virtual interface which does not have any physical connecto. Port binding is concerned with the security of switch ports and Fabric binding with the security of the SAN fabric as a wh.

It also introduces a table that allows configuration of dynamic learning of the physical topol. This is the MIB module for objects used to manage interface queuing in Cisco devices. This MIB module provides information about the status and configuration of links used by service control entities.

The link on a service control entity is a contained entity that joins subscriber side ports to network side ports. The MIB module that provides a simple mechanism to support firmware upgrade on Cisco low end devices. The MIB module that provides a simple configuration of management interfaces on managed devices.

For the purpose of this mib, a hub is a repeater group and stack is collection of one or more hubs interconnected via stack bus connectors. The MIB module for downloading files to the Service Modules specifically designed for an architecture containing a controller card and a group of sub- ordinate cards or service modules as in a Switch.

These files could contain information for performing. The Structure of Management Information for the Cisco enterprise. This MIB provides configuration and runtime status for chassis, modules, ports, etc.

The MIB module for managing Cisco extensions to the This module defines textual conventions used in Storage Area Network technology specific mibs. This MIB module defines textual conventions describing subscriber session identities. A subscriber session identity consists of data associated with a subscriber session serving as credentials used to determine authority, status, rights, or entitlement to.

This MIB module defines textual conventions describing subscriber sessions. Autostate feature is a mechanism to calculate the state of a SVI dynamically when some condition occurs such as a failure of a participating interface in that SVI. You can use keywords to limit the number and types of messages generated. Skip to content Skip to search Skip to footer. Book Contents Book Contents. Find Matches in This Book. PDF - Complete Book 2. Updated: January 21, If your management application requires MIBs to be loaded, and you experience problems with undefined objects, you might want to load the following MIBs in this order: 1.