MIB Specifications Guide for the Cisco 1100 Series ISR
Bias-Free Language
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
- Updated:
- March 2, 2015
Chapter: Using MIBs
Cisco Unique Device Identifier Support
The ENTITY-MIB now supports the Cisco compliance effort for a Cisco unique device identifier (UDI) standard which is stored in IDPROM.
The Cisco UDI provides a unique identity for every Cisco product. The UDI is composed of three separate data elements which must be stored in the entPhysicalTable:
- Orderable product identifier (PID)—Product Identifier (PID). PID is the alphanumeric identifier used by customers to order Cisco products. Two examples include NM-1FE-TX or CISCO3745. PID is limited to 18 characters and must be stored in the entPhysicalModelName object.
- Version identifier (VID)—Version Identifier (VID). VID is the version of the PID. The VID indicates the number of times a product has versioned in ways that are reported to a customer. For example, the product identifier NM-1FE-TX may have a VID of V04. VID is limited to three alphanumeric characters and must be stored in the entPhysicalHardwareRev object.
- Serial number (SN)—Serial number is the 11-character identifier used to identify a specific part within a product and must be stored in the entPhysicalSerialNum object. Serial number content is defined by manufacturing part number 7018060-0000. The SN is accessed at the following website by searching on the part number 701806-0000:
https://sso.cisco.com/autho/forms/MCOlogin.html
Serial number format is defined in four fields:
The SN label is represented as: LLLYYWWSSS.
Note The Version ID returns NULL for those old or existing cards whose IDPROMs do not have the Version ID field. Therefore, corresponding entPhysicalHardwareRev returns NULL for cards that do not have the Version ID field in IDPROM.
Managing Physical Entities
This section describes how to use SNMP to manage the physical entities (components) in the router by:
– Determining the ifIndex Value for a Physical Port
– Monitoring and Configuring FRU Status
The physical entity management feature of the Cisco 1100 Series ISR SNMP implementation does the following:
- Monitors and configures the status of field replaceable units (FRUs)
- Provides information about physical port to interface mappings
- Provides asset information for asset tagging
- Provides firmware and software information for chassis components
MIBs Used for Physical Entity Management
- CISCO-ENTITY-FRU-CONTROL-MIB—Contains objects used to monitor and configure the administrative and operational status of field replaceable units (FRUs), such as power supplies and line cards, that are listed in the entPhysicalTable of the ENTITY-MIB.
- CISCO-ENTITY-EXT-MIB - Contains Cisco defined extensions to the entPhysicalTable of the ENTITY-MIB to provide information for entities with an entPhysicalClass value of 'module' that have a CPU, RAM/NVRAM, and/or a configuration register.
- CISCO-ENTITY-SENSOR-MIB and ENTITY-SENSOR-MIB—Contain information about entities in the entPhysicalTable with an entPhysicalClass value of 'sensor'.
- CISCO-ENTITY-VENDORTYPE-OID-MIB—Contains the object identifiers (OIDs) for all physical entities in the router.
- ENTITY-MIB—Contains information for managing physical entities on the router. It also organizes the entities into a containment tree that depicts their hierarchy and relationship to each other. The MIB contains the following tables:
– The entPhysicalTable describes each physical component (entity) in the router. The table contains an entry for the top-level entity (the chassis) and for each entity in the chassis. Each entry provides information about that entity: its name, type, vendor, and a description, and describes how the entity fits into the hierarchy of chassis entities.
Each entity is identified by a unique index ( entPhysicalIndex ) that is used to access information about the entity in this and other MIBs.
– The entAliasMappingTable maps each physical port’s entPhysicalIndex value to its corresponding ifIndex value in the IF-MIB ifTable.
– The entPhysicalContainsTable shows the relationship between physical entities in the chassis. For each physical entity, the table lists the entPhysicalIndex for each of the entity’s child objects.
– The entPhysicalIsFRU indicates whether or not a physical entity is considered a Field Replaceable Unit (FRU). For an entity identified as FRU, the physical entity contains the following device-specific information:
- entPhysicalModelName- Product Identification (PID), same as orderable part number.
- entPhysicalHardwareRev- Version Identification (VID)
- entPhysicalSerialNum- Serial Number (SN)
- Cisco Unique Device Identifier (UDI)- Composed of PID, VID and SN, it provides a unique identity for all Cisco hardware products on which it has been enabled.
Performing Inventory Management
To obtain information about entities in the router, perform a MIB walk on the ENTITY-MIB entPhysicalTable.
As you examine sample entries in the ENTITY-MIB entPhysicalTable, consider the following:
- entPhysicalIndex—Uniquely identifies each entity in the chassis. This index is also used to access information about the entity in other MIBs.
- entPhysicalContainedIn—Indicates the entPhysicalIndex of a component’s parent entity.
- entPhysicalParentRelPos—Shows the relative position of same-type entities that have the same entPhysicalContainedIn value (for example, chassis slots, and line card ports).
Note The container is applicable if the physical entity class is capable of containing one or more removable physical entities. For example, each (empty or full) slot in a chassis is modeled as a container. All removable physical entities should be modeled within a container entity, such as field-replaceable modules, fans, or power supplies.
Sample of ENTITY-MIB entPhysicalTable Entries
The samples in this section show how information is stored in the entPhysicalTable. You can perform asset inventory by examining entPhysicalTable entries.
Note The sample outputs and values that appear throughout this chapter are examples of data you can view when using MIBs.
The following output shows the ENTITY-MIB entPhysicalTable sample entries for RP card.
where entPhysicalContainedIn indicates the entPhysicalIndex of a component’s parent entity.
where entPhysicalClass indicates the general type of hardware device.
where entPhysicalParentRelPos indicates the relative position of this child among the other entities.
where entPhysicalName provides the textual name of the physical entity.
where entPhysicalHardware provides the vendor-specific hardware revision number (string) for the physical entity.
where entPhysicalSerialNumber provides the vendor-specific serial number (string) for the physical entity.
where entPhysicalMfgName provides the manufacturer’s name for the physical component.
where entPhysicalModelName provides the vendor-specific model name string for the physical component.
where entPhysicalIsFRU indicates whether or not this physical entity is considered a field replaceable unit (FRU).
Note the following about the sample configuration:
– For chassis slots, entPhysicalContainedIn = 1 (the entPhysicalIndex of the chassis).
Determining the ifIndex Value for a Physical Port
The ENTITY-MIB entAliasMappingIdentifier maps a physical port to an interface by mapping the port’s entPhysicalIndex to its corresponding ifIndex value in the IF-MIB ifTable. The following sample shows that the physical port whose entPhysicalIndex is 35 is associated with the interface whose ifIndex value is 4. (See the MIB for detailed descriptions of possible MIB values.)
Monitoring and Configuring FRU Status
View objects in the CISCO-ENTITY-FRU-CONTROL-MIB cefcModuleTable to determine the administrative and operational status of FRUs, such as power supplies and line cards:
- cefcModuleAdminStatus—The administrative state of the FRU. Use cefcModuleAdminStatus to enable or disable the FRU.
- cefcModuleOperStatus—The current operational state of the FRU.
Figure 5-1 shows a cefcModuleTable entry for a SIP card whose entPhysicalIndex is 1000.
Figure 5-1 Sample cefcModuleTable Entry
See the “FRU Status Changes” section for information about how the router generates notifications to indicate changes in FRU status.
ENTITY-MIB
The Entity physical table contains information for managing physical entities on the router. It also organizes the entities into a containment tree that depicts their hierarchy, and relationship with each other. Refer to the “Entity Containment Tree” section for the entity hierarchy. The following sample output contains the information for the ISR 4451-X power supply in power supply bay 0:
For more information on this MIB, refer to ENTITY-MIB (RFC 4133)
CISCO-ENTITY-ALARM-MIB supports the monitoring of alarms generated by physical entities contained by the system, including chassis, slots, modules, ports, power supplies, etc. In order to monitor alarms generated by a physical entity, it must be represented by a row in the entPhysicalTable.
Alarm Description Map Table
For each type of entity (represented by entPhysicalVendorType OID), this table contains a mapping between a unique ceAlarmDescrIndex and entPhysicalvendorType OID.
The ceAlarmDescrMapEntry is indexed by the CeAlarmDescrMapEntry.
Note The mapping between the ceAlarmDescrIndex and entPhysicalvendorType OID will exist only if the type of entity supports alarms monitoring, and it is in the device since device boot-up.
The following are the sample output:
The temperature sensor in ISR 1100 modules (RP) contains cevSensorModuleDeviceTemp as entPhysicalvendorType OID. From the above sample output, the index (ceAlarmDescrIndex) 5 is mapped to the RP sensor which has the cevSensorModuleDeviceTemp as the entPhysicalVendorType.
Note The generic vendor OID, cevSenor, is used in case the ISR 4451-X snmp agent is not able to determine the sensor type.
Alarm Description Table
The Alarm Description Table contains a description for each alarm type, defined by each vendor type employed by the system. Each alarm description entry (ceAlarmDescrEntry) is indexed by ceAlarmDescrIndex and ceAlarmDescrAlarmType.
The following is the sample output for all alarm types defined for all temperature type of entity in the Cisco 1100 Series ISR modules. The index 5 is obtained from the ceAlarmDescrMapTable in the previous section:
Refer to the Bellcore Technical Reference TR-NWT-000474 Issue 4, December 1993, OTGR Section 4. Network Maintenance: Alarm and Control - Network Element. The severity is defined as follows:
The following is the list of alarms defined for the sensor:
These alarm types are defined for all sensor physical entity type. The only difference is that different sensor physical type have different ceAlarmDescrText. The temperature sensor has "TEMP" and the voltage sensor has "Volt" in the alarm description text.
Alarm Table
The Alarm Table specifies alarm control and status information related to each physical entity contained by the system. The table includes the alarms currently being asserted by each physical entity that is capable of generating alarms. Each physical entity in entity physical table that is capable of generating alarms has an entry in this table.The alarm entry (ceAlarmEntry) is indexed by the entity physical index (entPhysicalIndex). The following is a list of MIB objects in the alarm entry:
-
ceAlarmFilterProfile
The alarm filter profile object contains an integer value that uniquely identifies an alarm filter profile associated with the corresponding physical entity. An alarm filter profile controls which alarm types the agent will monitor and signal for the corresponding physical entity. The default value of this object is 0, the agent monitors and signals all alarms associated with the corresponding physical entity. -
ceAlarmSeverity
This object specifies the highest severity alarm currently being asserted by the corresponding physical entity.
A value of '0' indicates that the corresponding physical entity is not currently asserting any alarms. -
ceAlarmList
This object specifies those alarms currently being asserted by the corresponding physical entity. If an alarm is being asserted by the physical entity, then the corresponding bit in the alarm list is set to a one. The alarm list is defined as octet string and its size ranges from 0 to 32.
– If the physical entity is not currently asserting any alarms, then the list will have a length of zero, otherwise it will have a length of 32.
– An OCTET STRING represents an alarm list, in which each bit represents an alarm type:
From the entity physical table (entPhysicalTable in ENTITY-MIB), we understnd that the Cisco 1100 Series ISR AC power supply in power supply bay 0 has 4 as entPhysicalIndex .
The following are the sample output of alarm list for the power supply in PS bay 0:
Alarm History Table
The Alarm History Table, ceAlarmHistTable, contains history of alarms both asserted and cleared generated by the agent. The ceAlarmHistTableSize is used to control the size of the alarm history table. A value of 0 prevents any history from being retained in this table. If the capacity of the ceAlarmHistTable has reached the value specified by this object, then the agent deletes the oldest entity in order to accommodate a new entry.
The ceAlarmHistLastIndex object contains the last index corresponding to the last entry added to the table by the snmp agent in the device. If the management client uses notifications listed in the Appendix 5, “Alarm Notifications” defined in CISCO-ENTITY-ALARM-MIB module, then it can poll this object to determine whether it has missed a notification sent by the agent.
The following is a list of MIB objects defined in the ceAlarmHistEntry, which is indexed by the ceAlarmHistIndex:
-
ceAlarmHistIndex
This is an integer value uniquely identifying the entry in the table. The value of this object starts at '1' and monotonically increases for each alarm (asserted or cleared) added to the alarm history table. If the value of this object is '4294967295', it will be reset to '1', upon monitoring the next alarm condition transition. -
ceAlarmHistType
This object indicates that the entry is added as a result of an alarm being asserted or cleared. -
ceAlarmHistEntPhysicalIndex
This object contains the entPhysicalIndex of the physical entity that generated the alarm. -
ceAlarmHistAlarmType
This object specifies the type of alarm generated. -
ceAlarmHistSeverity
This object specifies the severity of the alarm generated. -
ceAlarmHistTimeStamp
This object specifies the value of the sysUpTime object at the time the alarm is generated.
Example 5-1 Displaying Sample Output for the Alarm History
the size of alarm history tableExample 5-2 Displaying the Last Alarm Action (asserted or cleared) Added to the Alarm History Table
alarm clearedAt this point, the EMS application should already have all information regarding the physical entity and the entity alarm type defined for the physical entity.
Example 5-3 Displaying the Physical Entity That has Value 13 as entPhysicalIndex
Alarm Notifications
CISCO-ENTITY-ALARM-MIB supports the alarm asserted (ceAlarmAsserted) and alarm cleared (ceAlarmCleared) notifications. The notification can be enabled by setting the ceAlarmNotifiesEnable object through the snmp SET. The ceAlarmNotifiesEnable contains the severity level of the alarms notification or the value 0:
The severity 4 will enable notification for all severity level.
The severity 3 will enable notifications for severity 1, 2, and 3.
The severity 2 will enable notifications for severity 1 and 2.
The severity 1 will enable notifications for severity 1 only.
The value of 0 will disable the alarm notification.
The alarm notification can be enabled or disabled via the CLI command. Use the "NO" form to disable the alarm notification:
The alarm notification contains exactly the same information described in alarm history entry. Refer to the Alarm History Table Section for the MIB objects and to interpret the alarm notifications received.
Entity Containment Tree
The following is sample entity hierarchy for a Cisco 1100 Series ISR, MIB Variables printed : <entPhysicalName entPhysicalClass>
Generating SNMP Notifications
This section provides information about the SNMP notifications generated in response to events and conditions on the router, and describes how to identify the hosts that are to receive notifications.
Identifying Hosts to Receive Notifications
You can use the CLI or SNMP to identify hosts to receive SNMP notifications and to specify the types of notifications they are to receive (notifications or informs). For CLI instructions, see the
“Enabling Notifications” section. To use SNMP to configure this information, use the following MIB objects:
Use SNMP-NOTIFICATION-MIB objects, including the following, to select target hosts and specify the types of notifications to generate for those hosts:
– snmpNotifyTag is an arbitrary octet string (a tag value) used to identify the hosts to receive SNMP notifications. Information about target hosts is defined in the snmpTargetAddrTable (SNMP-TARGET-MIB), and each host has one or more tag values associated with it. If a host in snmpTargetAddrTable has a tag value that matches this snmpNotifyTag value, the host is selected to receive the types of notifications specified by snmpNotifyType.
– snmpNotifyType is the type of SNMP notification to send: notification(1) or inform(2).
- snmpNotifyFilterProfileTable and snmpNotifyFilterTable—Use objects in these tables to create notification filters to limit the types of notifications sent to target hosts.
Use SNMP-TARGET-MIB objects to configure information about the hosts to receive notifications:
- snmpTargetAddrTable—Transport addresses of hosts to receive SNMP notifications. Each entry provides information about a host address, including a list of tag values:
– snmpTargetAddrTagList—A set of tag values associated with the host address. If a host’s tag value matches snmpNotifyTag, the host is selected to receive the types of notifications defined by snmpNotifyType.
Use the notification enable objects in appropriate MIBs to enable and disable specific SNMP notifications. For example, to generate mplsLdpSessionUp or mplsLdpSessionDown notifications, the MPLS-LDP-MIB object mplsLdpSessionUpDownTrapEnable must be set to enabled(1).
Configuration Changes
If entity notifications are enabled, the router generates an entConfigChange notification (ENTITY-MIB) when the information in any of the following tables changes (which indicates a change to the router configuration):
Note A management application that tracks configuration changes checks the value of the entLastChangeTime object to detect any entConfigChange notifications that were missed as a result of throttling or transmission loss.
Enabling notifications for Configuration Changes
To configure the router to generate an entConfigChange notification each time its configuration changes, enter the following command from the CLI. Use the no form of the command to disable the notifications.
FRU Status Changes
If FRU notifications are enabled, the router generates the following notifications in response to changes in the status of an FRU:
- cefcModuleStatusChange—The operational status (cefcModuleOperStatus) of an FRU changes.
- cefcFRUInserted—An FRU is inserted in the chassis. The notification indicates the entPhysicalIndex of the FRU and the container it was inserted in.
- cefcFRURemoved—An FRU is removed from the chassis. The notification indicates the entPhysicalIndex of the FRU and the container it was removed from.
Note See the CISCO-ENTITY-FRU-CONTROL-MIB for more information about these notifications.
To configure the router to generate notifications for FRU events, enter the following command from the CLI. Use the no form of the command to disable the notifications.
To enable FRU notifications through SNMP, set cefcMIBEnableStatusNotification to true(1). Disable the notifications by setting cefcMIBEnableStatusNotification to false(2).
Monitoring Router Interfaces
This section provides information about how to monitor the status of router interfaces to see if there is a problem or a condition that might affect service on the interface. To determine if an interface is Down or experiencing problems, you can:
Check the Interface’s Operational and Administrative Status
To check the status of an interface, view the following IF-MIB objects for the interface:
- ifAdminStatus—The administratively configured (desired) state of an interface. Use ifAdminStatus to enable or disable the interface.
- ifOperStatus—The current operational state of an interface.
Monitor linkDown and linkUp Notifications
To determine if an interface has failed, you can monitor linkDown and linkUp notifications for the interface. See the “Enabling Interface linkUp/linkDown Notifications” section for instructions on how to enable these notifications.
- linkDown—Indicates that an interface failed or is about to fail.
- linkUp—Indicates that an interface is no longer in the Down state.
Enabling Interface linkUp/linkDown Notifications
To configure SNMP to send a notification when a router interface changes state to Up (ready) or Down (not ready), perform the following steps to enable linkUp and linkDown notifications:
Step 1 Issue the following CLI command to enable linkUp and linkDown notifications for most, but not necessarily all, interfaces:
Step 2 View the setting of the ifLinkUpDownTrapEnable object (IF-MIB ifXTable) for each interface to determine if linkUp and linkDown notifications are enabled or disabled for that interface.
Step 3 To enable linkUp and linkDown notifications on an interface, set ifLinkUpDownTrapEnable to enabled(1). To configure the router to send linkDown notifications only for the lowest layer of an interface, see the “SNMP Notification Filtering for linkDown Notifications” section.
Step 4 To enable the Internet Engineering Task Force (IETF) standard for linkUp and linkDown notifications, issue the following command. (The IETF standard is based on RFC 2233.)
Step 5 To disable notifications, use the no form of the appropriate command.
SNMP Notification Filtering for linkDown Notifications
Use the SNMP notification filtering feature to filter linkDown notifications so that SNMP sends a linkDown notification only if the main interface goes down. If an interfaces goes down, all of its subinterfaces go down, which results in numerous linkDown notifications for each subinterface. This feature filters out those subinterface notifications.
This feature is turned off by default. To enable the SNMP notification filtering feature, issue the following CLI command. Use the no form of the command to disable the feature.
Billing Customers for Traffic
This section describes how to use SNMP interface counters and QoS data information to determine the amount to bill customers for traffic. It also includes a scenario for demonstrating that a QoS service policy attached to an interface is policing traffic on that interface.
This section contains the following topics:
- Input and Output Interface Counts
- Determining the Amount of Traffic to Bill to a Customer
- Scenario for Demonstrating QoS Traffic Policing
Input and Output Interface Counts
The router maintains information about the number of packets and bytes that are received on an input interface and transmitted on an output interface.
For detailed constraints about IF-MIB counter support, see the IF-MIBB (RFC 2863) section.
Read the following important information about the IF-MIB counter support:
- Unless noted, all IF-MIB counters are supported on Cisco 1100 Series ISR interfaces.
- For IF-MIB high capacity counter support, Cisco conforms to the RFC 2863 standard. The RFC 2863 standard states that for interfaces that operate:
– At 20 million bits per second or less, 32-bit byte and packet counters must be supported.
– Faster than 20 million bits per second and slower than 650,000,000 bits per second, 32-bit packet counters and 64-bit octet counters must be supported.
– At 650,000,000 bits per second or faster, 64-bit packet counters and 64-bit octet counters must be supported.
- When a QoS service policy is attached to an interface, the router applies the rules of the policy to traffic on the interface and increments the packet and bytes counts on the interface.
The following CISCO-CLASS-BASED-QOS-MIB objects provide interface counts:
- cbQosCMDropPkt and cbQosCMDropByte (cbQosCMStatsTable)—Total number of packets and bytes that were dropped because they exceeded the limits set by the service policy. These counts include only those packets and bytes that were dropped because they exceeded service policy limits. The counts do not include packets and bytes dropped for other reasons.
- cbQosPoliceConformedPkt and cbQosPoliceConformedByte (cbQosPoliceStatsTable)—Total number of packets and bytes that conformed to the limits of the service policy and were transmitted.
Determining the Amount of Traffic to Bill to a Customer
Perform these steps to determine how much traffic on an interface is billable to a particular customer:
Step 1 Determine which service policy on the interface applies to the customer.
Step 2 Determine the index values of the service policy and class map used to define the customer’s traffic. You need this information in the following steps.
Step 3 Generate traffic with the traffic generator. The data rate should be more than that is configured for Conform burst(bc)/Exceed burst(be) for the policy.
Step 4 (Optional) Access the cbQosCMDropPkt object (cbQosCMStatsTable) for the customer to determine how much of the customer’s traffic was dropped because it exceeded service policy limits.
Scenario for Demonstrating QoS Traffic Policing
This section describes a scenario that demonstrates the use of SNMP QoS statistics to determine how much traffic on an interface is billable to a particular customer. It also shows how packet counts are affected when a service policy is applied to traffic on the interface.
To create the scenario, follow these steps, each of which is described in the sections that follow:
1. Create and attach a service policy to an interface.
2. View packet counts before the service policy is applied to traffic on the interface.
3. Issue a ping command to generate traffic on the interface. Note that the service policy is applied to the traffic.
4. View packet counts after the service policy is applied to determine how much traffic to bill the customer for:
- Conformed packets—The number of packets within the range set by the service policy and for which you can charge the customer.
- Exceeded or dropped packets—The number of packets that were not transmitted because they were outside the range of the service policy. These packets are not billable to the customer.
Note In the above scenario, the Cisco 1100 Series ISR is used as an interim device (that is, traffic originates elsewhere and is destined for another device).
Service Policy Configuration
This scenario uses the following policy-map configuration. For information on how to create a policy map, see “Configuring Quality of Service” in the QoS: Classification Configuration Guide, Cisco IOS XE Release 3.9S.
Packet Counts Before the Service Policy Is Applied
The following CLI and SNMP output shows the interface’s output traffic before the service policy is applied:
Packet Counts After the Service Policy Is Applied
After you generate traffic using the traffic generator, look at the number of packets that exceeded and conformed to the committed information rate (CIR) set by the police command:
- 19351 packets conformed to the police rate and were transmitted
- 80 packets exceeded the police rate and were dropped
- 16066130 packets violated the police rate and were dropped
The following CLI and SNMP output show the counts on the interface after the service policy is applied. The object cbQosCMDropPkt refers to sum of exceeded and violated packets and cbQosCMDropByte refers to the sum of exceeded and violated bytes. (In the output, exceeded andviolated packet counts are shown in boldface.)
Using IF-MIB Counters
This section describes the IF-MIB counters and how you can use them on various interfaces and subinterfaces. The subinterface counters are specific to the protocols. This section addresses the IF-MIB counters for ATM interfaces.
The IF-MIB counters are defined with respect to lower and upper layers:
- ifInDiscards—The number of inbound packets which were discarded, even though no errors were detected to prevent their being deliverable to a higher-layer protocol. One reason for discarding such a packet could be to free up buffer space.
- IfInErrors—The number of inbound packets that contained errors preventing them from being deliverable to a higher-layer protocol for packet-oriented interfaces.
- ifInUnknownProtos—The number of packets received through the interface which were discarded because of an unknown or unsupported protocol for packet-oriented interfaces.
- ifOutDiscards—The number of outbound packets which were discarded even though no errors were detected to prevent their being transmitted. One reason for discarding such a packet is to free up buffer space.
- ififOutErrors—The number of outbound packets that could not be transmitted because of errors for packet-oriented interfaces.
The logical flow for counters works as follows:
1. When a packet arrives on an interface, check for the following:
a. Error in packet—If any errors are detected, increment ifInErrors and drop the packet.
b. Protocol errors—If any errors are detected, increment ifInUnknownProtos and drop the packet.
c. Resources (buffers)—If unable to get resources, increment ifInDiscards and drop the packet.
d. Increment ifInUcastPkts/ ifInNUcastPkts and process the packet (At this point, increment the ifInOctets with the size of packet).
2. When a packet is to be sent out of an interface:
a. Increment ifOutUcasePkts/ ifOutNUcastPkts (Here we also increment ifOutOctets with the size of packet).
b. Check for error in packet and if there are any errors in packet, increment ifOutErrors and drop the packet.
c. Check for resources (buffers) and if you cannot get resources then increment ifOutDiscards and drop packet.
This following output is an example IF-MIB entries:
Sample Counters
The high capacity counters are 64-bit versions of the basic ifTable counters. They have the same basic semantics as their 32-bit counterparts; their syntax is extended to 64 bits.
Table 5-1 lists capacity counter object identifiers (OIDs).
Related Information and Useful Links
The following URLs provide access to helpful information about Cisco IF-MIB counters:
http://www.cisco.com/en/US/customer/tech/tk648/tk362/technologies_q_and_a_item09186a00800b69ac.shtml
Displaying the Module Hardware Type
To verify the SIP hardware type that is installed in your Cisco 1100 Series ISR, you can use the show platform command. The example below shows some list of such commands.
Example 5-5 Example of the show platform command
The following example shows the output of the show platform command on the Cisco 1100 Series ISR1:
hardware Show platform hardware information
software Show platform software information
backplaneswitch-manager Backplane Switch Manager hardware
crypto-device crypto device information
interface Interface information
network-clocks Show network clock device
throughput Show throughput commands
Feedback