Cisco Nexus 3048, Sflow V5 vsensor and the Interface filter

Hello,

Thank you very much for the KB-Post. Please run one Sflow-Sensor without any interface-filters first, and in it's settings, please enable the "Log Stream Data to Disk (for Debugging)"-option for all stream data.
The CSV which is generated by this then should show the interface numbers as well. Does it show the same numbers?

best regards.

Thank you for quick reply!

Your advice is very helpful. Yes, in the CSV file i see other InboundInterface and OutboundInterface values, like 99, 239, 28672 and so on. So now i must somehow discover "true" ifIndex values in the NX-OS software. Any guidance? I think i'll also visit Cisco support forums and ask about that there.

Thank you for the response. I'm afraid I don't have advice how to relate the interface numbers now. Can you do it with the traffic passing through (for example certain traffic that can only pass through certain interfaces)?

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. Overall, the problem is spotted. Thank you Torsten for support! I will continue my research.

OK, so now i arrived at point where i think that the problem is in the PRTG, and here is why i think so: Take a look at this table: https://pastebin.com/WYPmE3Sr

As i mentioned before, i tested individual interfaces and analyzed the results from CSV generated by PRTG. So what i did, i took the "show interface snmp-ifindex" table from nexus switch and took last 4 integers from hexadecimal ifindex values. I converted them to decimal numbers, and the results matched perfectly all interface indexes from CSV file (look at last last column).

Remember the thing with 1/25 where i said that it must appear with 32768? In fact, it was already with this index, I just not checked it since it is part of port channel and while member of portchannel it cant be monitored as individual interface - the nexus switch limitation. But 1/41 is also appearing with that index, as well as eth 1/9. More than that, 1/33 and portchannel1 both appear with interface index 0 in PRTG. And so on. This proves my theory right.

As the Nexus switch is sending flows with it's original indexes (for example InboundInterface 436310016), seems like the PRTG have trouble in interpreting those indexes in right way, making those appear as several ranges of similar indexes.

There isn't a real hard defined relation between ifindex-numbers and the interface numbers in flow packets, they may follow a certain rhythm, but don't have to. The flow - sensors don't even know the ifindex numbers. They just follow what ever is in the flow packets.

But how the flow sensors react to "Interface" filter? Other netflow and sflow sensors i have configured are filtered using ifindex values.

For me, it looks like the datatype for interface filter is defined as 0 through 65,535 (unsigned), like for example UShort in Visual Basic. I don't try to say that i'm right, just my thoughts.

Overall, i'm using the resulted values. Mainly i'm monitoring Portchannel interfaces and a couple of individual interfaces. For now, it's enough for me. I don't know what will happen if i will have two interface with same value filtered. I suppose that both flows will be combined.

Hey Kiryll,

we've reviewed your findings and found a bug. We filed a bug report and will review the problem.

Thanks for your deep insights in the problem, it was a great help.

best regards,

Eugen

Hi guys! I was recently contacted by Paessler support team with a respectful request to provide a wireshark capture. Of course i did that, hope this will help to fix the bug.

If you need anything else from me, I will help.