Stemming from a Support Case I had on netflow data collected from a cisco ASR 1001-x, it was noted that NTA treats packets sourced from SNMP Index=0 as 'invalid'. In Cisco's case at least, (and i'd imagine other devices as well), they source router 'self'-generated packets (not ones sourced from an interface with the Router's IP, but ones created by the router and send out as parts of other connections) as sourced from interface index=0, as the packets don't have any other valid 'source' (ingress) interface, just an egress (destination) interface. In our case, since we're capturing Egress netflow. In our case the majority of the packets I was seeing with Source index=0 were RST packets generated by the firewall, when it idle-closed a TCP session. The firewall components notify either end of the TCP session with a RST. Not only can this help prevent an application that expected the idle TCP session to still exist from hanging once it tries to use the connection again, but this also helps potential NAT devices along the path to see the TCP connection was closed and free resources from it. We had a very large amount of these idle aged-out TCP connections in a wireless environment where the clients are always 'disappearing' from the network before their applications close the TCP connections, and if they reconnect it's frequently in a new location with alternate IP addressing.
As it is now, NTA drops/ignores these RST packets (and any other packets with interface index=0). It might even throw an alert about receiving bad netflow data from the device.
I was thinking it might make more sense to capture the RST packets even if it’s probably statistically insignificant in the overall netflow traffic analysis, because it seems like something that could be helpful if identified/surfaced as a ‘firewall idle session termination count’ or something? While it's possible that it could become a significant source of data, I could also see how it might be important if a network admin saw a spike in those session closures or some sort of tracking of the rate of RST packets injected by the router were kept? Especially charting a large number of session closures suddenly could be indicative of a DoS attack of some sort blocked by the firewall configured to cleanly close connections -- By default Cisco Firewall generates RST packets not only for closed idle-timeout TCP sessions, but also incomplete (sessions which don't complete the 3-way handshake) and other reasons it has to close a TCP session. It could even be linked to a session as an identifier that a flow was terminated by firewall/router-generated-packet as opposed to one of the ends. I think it would make troubleshooting long-running session termination issues easier if solarwinds had such a function. (For example if the firewall were closing idle TCP sessions after 30 minutes, but an application expected an hour between keepalives or potential traffic. I know some voice applications via TCP and Exchange/Outlook connections have been notorious for these issues in the past.
The Feature Request Case ID for this topic is 1206897.
