cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1240
Views
10
Helpful
4
Replies

Nexus 6000 ifindex value is different comparing to Other Cisco device Ifindex, what is the reason??

Hi,

Why there is a change and what it represents??

 

Anyone pls explain.

 

Sample ifindex out put from nexus 6000:

 

IF-MIB::ifName.436207616 = STRING: Ethernet1/1
IF-MIB::ifName.436211712 = STRING: Ethernet1/2
IF-MIB::ifName.436215808 = STRING: Ethernet1/3
IF-MIB::ifName.436219904 = STRING: Ethernet1/4
IF-MIB::ifName.436224000 = STRING: Ethernet1/5
IF-MIB::ifName.436228096 = STRING: Ethernet1/6
IF-MIB::ifName.436232192 = STRING: Ethernet1/7

 

Cisco ASR1000 Ifindex values:

IF-MIB::ifName.1 = STRING: Em0/0
IF-MIB::ifName.2 = STRING: Gi0/0
IF-MIB::ifName.3 = STRING: Gi0/1
IF-MIB::ifName.4 = STRING: Gi0/2
IF-MIB::ifName.5 = STRING: Ba0/3
IF-MIB::ifName.6 = STRING: Nu0
IF-MIB::ifName.7 = STRING: Lo0
IF-MIB::ifName.9 = STRING: Lo20

 

4 Replies 4

Peter Paluch
Cisco Employee
Cisco Employee

Hello,

On Nexus switches, the SNMP ifIndex numbering is equal to an internal numbering scheme used by the switch. Nexus switches use predefined ranges of internal interface indexes for different types of interfaces (physical interfaces, port-channels, virtual interfaces, ports on fabric extenders, etc.), and they use the same numbering for the SNMP ifIndex, too. On other platforms, the numbering is obviously different.

Either way, the ifIndex number must be treated as specific to a particular device only, and there must not be any specific scheme assumed by the application that uses the ifIndex value. In other words, the only requirement for the ifIndex value is that it is unique for individual interfaces on the device - and that's it. No other assumptions about the ifIndex may be made.

Best regards,
Peter

 

Hi,

 

Thanks for the reply.

 

Can I get a reference document for Nexus devices on how the ifindex varies based on different types of interfaces (physical interfaces, port-channels, virtual interfaces, ports on fabric extenders, etc.)

 

The reason is we are mapping a CDP MIB OID to get the connectivity of neighbor devices.

 

In switch or orther cisco devices directly i can check the current device Ifindex and Remote device Ifndex to map the connectivity. But When i refer to the Nexus device CDP SNMPwalk, unable to map the connectivity due to different ifindex value.

 

For example:

Below is the SNMP walk output from a Switch Where at the last value 4 represent the remote Device ifndex value and 2 represent the current device ifindex value. 

SNMPv2-SMI::enterprises.9.9.23.1.2.1.1.6.2.4 = STRING: "Device_A"

SNMPv2-SMI::enterprises.9.9.23.1.2.1.1.7.2.4 = STRING: "Ethernet1/42"

 

Below output is from Nexus device SNMPwalk for CDP OID:

SNMPv2-SMI::enterprises.9.9.23.1.2.1.1.6.436375552.2031617 = STRING: "Device_B"

SNMPv2-SMI::enterprises.9.9.23.1.2.1.1.7.436375552.2031617 = STRING: "GigabitEthernet0/0"

 

Other than Nexus device, I am able to map it, With respect to Nexus unable to map Ifindex value.

 

Please kindly help me.

 

Thanks in advance.

Sujith

Hi Sujith,

I am sorry to be responding so late.

Below is the SNMP walk output from a Switch Where at the last value 4 represent the remote Device ifndex value and 2 represent the current device ifindex value. 

I am afraid that you are not interpreting the OIDs correctly. A particular device has absolutely no knowledge about the ifIndex values used by a different device. This information is not exchanged between the devices, and so your Device_A cannot know anything about the ifIndex values used by Device_B, and vice versa.

In the output below, the value "2" is the local ifIndex, while the value "4" is an internal number assigned to a particular CDP neighbor, in this case, "Device_A":

SNMPv2-SMI::enterprises.9.9.23.1.2.1.1.6.2.4 = STRING: "Device_A"
SNMPv2-SMI::enterprises.9.9.23.1.2.1.1.7.2.4 = STRING: "Ethernet1/42"

Similarly, in the output below, the value "436375552" is the local ifIndex , while the value "2031617" is an internal number assigned to the CDP neighbor "Device_B":

SNMPv2-SMI::enterprises.9.9.23.1.2.1.1.6.436375552.2031617 = STRING: "Device_B"
SNMPv2-SMI::enterprises.9.9.23.1.2.1.1.7.436375552.2031617 = STRING: "GigabitEthernet0/0"

Therefore, from the SNMP walk of the CDP MIB on one device, you cannot deduce the ifIndex values of the neighboring devices. The correct approach would be to walk the 1.3.6.1.2.1.2.2.1.2 table that contains the mappings of the local interface names to local interface ifIndexes, and use the data from there to associate the local interface name with the CDP neighbor's interface name discovered through enterprises.9.9.23.1.2.1.1.7.<local-ifIndex>.<neighbor-CDP-ID>.

Best regards,
Peter

Consider a situation where a monitoring software is polling the interface statistics of the serial interface going to the Internet. For example, you could have these conditions prior to re-initialization:

An ifindex value of Ethernet port 1
An ifindex value of Token Ring port 2
An ifindex value of Serial port 3
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. The ifindex value of Ethernet port becomes 3, and ifindex value of Token Ring port to be 1and that of Serial port to be 2. The management application continues polling the ifIndex 3, which now corresponds to the Ethernet port. Therefore, if the management application is not warned by a trap that the router has been rebooted, the statistics polled could be completely wrong.

Cisco IOS  Software 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 Simple Network Management Protocol (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.

To globally enable ifindex values that are maintained across reboots, issue the snmp-server ifindex persist command in global configuration mode. The same command can be issued to enable ifIndex persistence only on a specific interface in the interface configuration mode.

The interface-specific ifindex persistence command no snmp ifindex persist can not be used on subinterfaces. A command applied to an interface is automatically applied to all the subinterfaces associated with that interface.

Review Cisco Networking for a $25 gift card