- What is ifIndex persistence?
- What causes index reassignment?
- What are the impacts of index reassignment?
- Managing index reassignment
What is ifIndex persistence?
Network monitoring requires that the monitoring system be able to uniquely identify the interfaces being monitored on a device, and SNMP monitoring typically relies on the interface’s ifIndex for this. With ifIndex tying polled data to a known entity, it is simple to collect and collate interface-specific data which can then be leveraged for a range of business outcomes such as customer billing and capacity planning, as well as fault and issue tracking.
According to RFC1213, ifIndex is: “A unique value for each interface. 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.” And therein lies our issue, “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.” What about across initializations?
What causes index reassignment?
A device reboot is one of the instances where the ifIndex assigned the interfaces on the device can be shuffled. This reassigning of ifIndex can also occur when adding or removing physical interfaces or provisioning logical interfaces. Essentially, any process that changes the number, or order, of Interface Descriptor Block (IDB) entries will potentially result in new ifIndex assignations.
What are the impacts of index reassignment?
When ifIndex assignments change, any functionality relying on the index to identify the interface continues on ignorant of the change. The interface-specific data a network monitoring solution, such as Statseeker, collects continues to be collected, but is now attributed to a different interface on the device. Alerts continue to be triggered but potentially against the incorrect interface, or do not trigger in response to events where they otherwise would.
There is also a range of secondary impacts, which are potentially more disruptive, to your network performance. Netflow and NBAR rely on ifIndex to identify the interfaces participating in network communications. Communications which, in light of the network’s historical data, may now be incorrectly attributed to the announced source or destination. In addition, these communications can be adversely affected by the network’s QoS implementation, which again, relies on ifIndex to identify participants.
Managing index reassignment
The concept of IfIndex persistence has been supported by various vendor operating systems for over 20years, so today most conventional industry-grade networking will allow you to take advantage of the feature. A number of major hardware vendors enable ifIndex persistence by default, Junos for example, has had ifIndex persistence enabled by default since mid-2010. For devices where this feature is not enabled by default, ifIndex persistence can usually be set on both an individual interface basis, as well as assigned globally, to all interfaces on the device. Once set the index is maintained, and the issues associated with ifIndex changes are avoided.
But what if your device does not support, or you do not have the access required to apply, ifIndex persistence? There are no enforced requirements around which features manufacturers of networking hardware support, vendors are free to support features such as ifIndex persistence, or not, as they see fit. The range of networked devices is expanding at an ever-increasing rate as is the number of vendors supplying these devices. Simply compare the range of wireless access points available today to that from just a few years ago. So, what are your options when you encounter hardware that does not fully support ifIndex persistence?
Statseeker collects device configuration data, such as ifIndex as part of the Device Discovery process when working with newly introduced elements of your network. It then updates this data daily as part of the default Daily Rewalk process. Statseeker also manages an entity mapping database and when changes to ifIndex are detected, will remap any internal references to the new ifIndex assignments.
By default, Statseeker’s Daily Rewalk, is just that, a daily process. This means that any event causing ifIndex reassignment might result in misaligned Statseeker data for up to 24 hours prior to the issue being addressed. This deficit can be addressed by simply running a discovery against the device after the event. This discovery process can be tailored to target an individual device or directed to target multiple devices via specified IP ranges or a modified Statseeker hosts file. For details on tailoring a discovery process, see SNMP Discovery, and if you require any assistance please contact Statseeker Technical Support.