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.
One of the most commonly used identifiers in SNMP-based network management applications is the Interface Index (ifIndex) value. IfIndex is a unique identifying number associated with a physical or logical interface. For most software, the ifIndex is the name of the interface. Although relevant RFCs do not require that the correspondence between particular ifIndex values and their interfaces be maintained across reboots, applications such as device inventory, billing, and fault detection depend on this correspondence.
The RFC1213 (MIB2) defines an initial ifIndex as follows:
“Each interface is identified by a unique value of the ifIndex object, and the description of ifIndex constrains its value as follows: Its value ranges between 1 and the value of ifNumber. The value for each interface must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization."
However, according to the latest IETF RFC 2863 (The Interfaces Group MIB), the ifIndex definition has been changed to accommodate the increased number of devices that allow the dynamic addition or removal of network interfaces. The solution adopted in RFC 2863 is to delete the requirement that the value of ifIndex be less than the value of ifNumber, and to retain ifNumber with its current definition.
There are no specific prerequisites for this document.
For most up-to-date support information for this feature by IOS platforms and images, you can search for Interface Index Persistence in the Feature Navigator Tool.
Support for this feature started from Cisco IOS release 12.1(5)T on the following platforms (later included in Cisco IOS release 12.2):
Cisco 800 series
Cisco 1400 series
Cisco 1600 series (including the 1600R series)
Cisco 1700 series
Cisco 2500 series
Cisco 2600 series
Cisco 2800 series
Cisco 3600 series (including the Cisco 3620, 3640, and 3660)
Cisco 3800 series
Cisco 4500 series
Cisco 7100 series
Cisco 7200 series (including the Cisco 7202, 7204, and 7206)
Cisco 7500 series (including the Cisco RSP7000)
In Cisco IOS release 12.0S, interface index persistence support started from Cisco IOS release 12.0(11)S on the following platforms:
Cisco 7200 Series
Cisco 7500 Series
Cisco 12000 GSR Family
Note: For CatOS devices, ifIndex does persist automatically for physical and VLAN interfaces, but not for EtherChannel interfaces. This feature is on by default and there is no way to turn it off. The IOS software on the MSFC does not support the ifIndex persistence. Catalyst 6000 IOS (also called native mode) supports ifIndex persistence starting from 12.1(13)E.
The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are working in a live network, ensure that you understand the potential impact of any command before using it.
Consider a situation where a simple monitoring software (like MRTG) is polling the interface statistics of the router specific serial interface going to the internet.
As an example, you could have these conditions prior to re-initialization:
Therefore, the management application is polling the ifIndex 3, which corresponds to the serial port.
After the router re-initialization (reboot, reload and so on) the conditions change to something similar to this:
The management application continues polling the ifIndex 3, which corresponds now to the ethernet port. Therefore, if the management application is not warned by a trap, for example, that the router has been rebooted, the statistics polled could be completely wrong.
The ifIndex Persistence Overview
Cisco IOS Release adds support for an ifIndex value that can persist across reboots. The Interface Index Persistence feature allows for greater accuracy when it collects and processes network management data by uniquely identifying input and output interfaces for traffic flows and SNMP statistics. As it relates each interface to a known entity (such as an ISP customer), the Interface Index Persistence feature allows network management data to be more effectively utilized.
IfIndex persistence means that the mapping between the ifDescr (or ifName) object values and the ifIndex object values generated from the IF-MIB is retained across reboots.
This feature is particularly useful for:
SNMP: monitoring the interfaces counters
Netflow: reporting of the interface ifIndex
RMON: events/alarms based on specific interfaces
EXPRESSION/EVENT MIB: creation of a new MIB variable based on interface counters
The interface-specific ifIndex persistence command ([no] snmp ifindex persistence) can not be used on subinterfaces. A command applied to an interface is automatically applied to all the subinterfaces associated with that interface.
Verifying the IfIndex Persistence
To verify that the ifIndex is correctly enabled, you can view the content of ifIndex-table in the nvram.
Router # dir nvram:ifIndex-table
Directory of nvram:/ifIndex-table
2 -rw- 0 <no date> ifIndex-table
126968 bytes total (114116 bytes free)
If the length is 0, then you omitted to execute copy running starting, which copies the ifIndexes allocation into the nvram. After doing so, you see the following:
Router # dir nvram:ifIndex-table
Directory of nvram:/ifIndex-table
2 -rw- 283 <no date> ifIndex-table
126968 bytes total (114088 bytes free)
The format of the file is:
The size of this row
This interface's ifIndex
1 if persistence is enabled
The interface description
You can copy the file to an ftp server and view the content of the binary file. But do not edit that file: all changes are unsupported. On some platforms the file may be kept in compressed format.
Online Insertion and Removal
This is a list of examples of inserting and removing Ethernet cards.
1. Remove a card and replace it with the same card type.
The same ifIndexes is allocated for the new card, as long as the ifDescr’s on the new hardware match the old one
2. Remove a card and replace it with almost the same card type.
If you replace an four port Ethernet card with an eight port Ethernet card, the first four ports on the eight port card has the same ifIndex values as the four port Ethernet interfaces. The other four ports receive new ifIndex values.
3. Remove a card and replace it with a different card type.
When you install a new card type, such as a new ifDescr, you receive new ifIndex values. The previous ifIndex is not used and creates a gap in the ifIndex allocation.
4. Remove a card and place it in a different slot of the same router.
When you place a card in a different slot, there is a new ifDescr, so you receive new ifIndex values. The previous ifIndex is not used and creates a gap in the ifIndex allocation.
Note: You must perform a copy running starting command to persist the newly assigned ifIndex values for examples 2, 3, and 4.