Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials

NTA handles one-time overflows in NetFlow v5 interface index fields?

Hello, I'm having an issue with NTA matching flows from a server using nProbe on an interface with a high index number (0x30004 in this case.) It seems to me like there might be an overflow (or looping, or rolling over of the field – not sure the correct terminology) calculation problem.

NetFlow v5 has a two byte field for the interface index number (0x0000-0xffff, or 0-65535 in decimal.) Most windows interfaces start at 0x10001 (65537 in decimal.) When you enter that number in nProbe for the -u and -Q switches (which tells nProbe to set the NetFlow index field to that value), nProbe rolls it into 0x0001 (1 in decimal) for the NetFlow packet (I verified this by packet capture.) SolarWinds seems to recognize this fine and matches it up to the interface with the index of 65537 on that node.

However, I have one server with an interface index number of 0x30004 (196612 in decimal.) When I enter that number as the -u and -Q switch in nProbe, it "rolls" the number to 0x0004 as I would expect (196612 - 65536 x 3 = 4.) When SolarWinds NTA receives the packet, I receive the following error: "NetFlow Receiver Service is receiving a NetFlow data stream from an unmanaged interface on xxxxxx. The NetFlow data stream will be discarded. Please follow the link xxxxxx or use the Orion System Manager to add Interface '#4' in order to process this NetFlow data stream."

My theory is that NTA can recognize a one-time "rolled" index field, but not a three-time "rolled" index field value. Can a moderator run this theory past a dev? Ideally it would be able to recognize an unlimited (or extremely high) number of "rolled" index fields. For example an interface with an index of 4, 65540, 131076, 196612, 262148, 327684, Etc, would all identify with a NetFlow packet with an index field value of 0x0004.

Any thoughts?

Neil

Find more posts tagged with

Accepted answers

All comments

GZhytar

Neil,

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!

Hi Neil,

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

neilkauffman

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!

Neil

NTA_Netflow_Index.zip