I see that you made good investigation here and it would be much easier for us to track this issue. Let me take care of that now.
Thanks for that good post!
I checked our parser for v5, and as you said interface index is represented by 2 bytes. From my tests and analyses there's no way to have bigger value than 0xFFFF. I didn't test it on nProbe, because I don't have it, but I used our own generator, so the situation can be diferent and depends on some fields, but .....
To be more specific, can you post here short suspect pcap, please?
Your comment about value 196612 in second paragraph, you expected 4 and in nta event is mentioned, that interface with index 4 is not managed by orion. It seems correct to me. NTA always map interface index to interfaceID (interface managed by orion), if we can't find this match, we discard traffic. In NTA v3.5 is new possibility in Admin page to store also traffic from unmanaged interfaces, but anyway at least one interface must be managed.
Thanks for possible pcap
I may have been too hasty in my report... I cycled the interface index number on the Windows server by disabling and enabling it. I was hoping it would cycle back over to a lower number, but it kept growing. It is currently at 0x110004 (1114116 in decimal.) Out of curiosity I set the nProbe flags to those values and NTA did accept the traffic. Looking at a capture, the NetFlow SNMP index is 0x0040 for both the input and output interfaces. So it does appear that NTA calculates the overflow in the same way as nProbe does. I'm not sure why it wasn't working when the interface was 0x30004 - I can't rule out a screw up on my part If I manage to find another server at 0x30004 I'll test it again.
I'll attach a pcap if you are still interested.
Thanks for looking into this!
NTA_Netflow_Index.zip 1.3 KB