Hello everyone!

I have a trouble using the sFlow v5 sensor with Cisco Nexus 3048 devices. So, when i just add sFlov v5 sensor, all is fine, the toplist is generating for all flows coming from nexus switch, which is normal. But, it seems that is not working well with filters.

Yes, i know that the Interface filter is accepting only the ifindex value. Here are the results of "show interface snmp-ifindex" command on nexus switch:

I have several devices monitored via sflow (some HP switches) and the Interface filter is working well. In case with Nexus switches, its not working at all (This sensor has not received any data).

I used "PRTG SFlow tester" and here are the results.

For now, i have sflow enabled for interfaces po100, po240 and ethernet 1/24. As we can see in flows, the interfaces are matching ifindex values (for example po100 = 369098851 in this flow "212.0.222.18:443->89.32.226.116:23314 P:6 IF/OF:369098991/369098851 07:53:09 3394485780480").

So the problem is that PRTG is processing well the raw flows, but when i create other sensor with Interface[369098851] filter -> no result, no data.

Any ideas?

Article Comments

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.


Feb, 2018 - Permalink

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.


Feb, 2018 - Permalink

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)?


Feb, 2018 - Permalink

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.


Feb, 2018 - Permalink

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.


Feb, 2018 - Permalink

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.


Feb, 2018 - Permalink

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.


Feb, 2018 - Permalink

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


Feb, 2018 - Permalink

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.


Mar, 2018 - Permalink