cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1527
Views
0
Helpful
1
Replies

Cisco Nexus 3048, sFlow and ifIndex values.

theamberlion
Level 1
Level 1

Hello everyone.

I got a couple of Nexus 3048 switches, with LAN enterprise licenses. Also i got the PRTG network monitor.

Now, i configured the sFlow agent and interfaces on N3K and sFlow collector on PRTG. All good until i tried to create individial sFlow sensors for each monitored interface. In PRTG, you have to filter all flows coming from switch using Interface[ifIndex]. ifIndex - is a numerical interface index. Those indexes usually can be found using "show snmp mib ifmib ifindex" command on Catalyst series switches. The alternative command for Nexus switches is "show interface snmp-ifindex".
Those indexes i've got on one of our Nexus switch: https://pastebin.com/EGGnyNgp


I got the trouble in that way: when PRTG receives raw flow, it creates toplists and all is fine. But i need toplists for every interface. So now when i'm creating another sflow sensor and use filter, for example Interface[369098851], no result, the sensor show that no valid data is received (because of filter obviously).

I checked the flows coming from switch, using PRTG sflow tester: https://pastebin.com/XzKB8Wt0

Seems that interface index values are matching.

I visited PRTG forums, and asked for advice there, and got one. In sFlow sensor settings, there is a option to log stream data to disk in CSV format (mainly for debugging purposes). In that CSV, in the Inbound and Outbound interface columns, were different interface indexes, like 99, 239, 28672 and so on.

So my question is: how do i find those "true" ifIndex values on our Nexus 3048 switches?

1 Reply 1

theamberlion
Level 1
Level 1

Now, what i've discovered is that Portchannel interface indexes are equal to port channel number -1.
Like if portchannel number is 240, the index is 239.

But more mysterious are physical interfaces. the indexes differs by a step of 4096, but seems like are applied by random order.
For example:
eth 1/15 = index 57344
eth 1/16 = index 61440 (57344 + 4096)
 but!
eth 1/23  = 24576
eth 1/24 = 28672
logically, now eth 1/25 must be 32768 (28672+4096)... but this index is found at 1/41. (O.o)
and still eth 1/27 is found with 40960 index (if we increase from eth 1/24 three times with 4096 step - it's matching.)

The nexus switch is attaching such indexes to physical interfaces in a strange manner. Sad story.

Any ideas anyone?

Review Cisco Networking for a $25 gift card