Is active and inactive timeout dependent on TCP flags?
Information
| Summary: |
How each type of timeout separates and terminates flow data |
| Environment: |
Product: Flowmon Version: Any Platform: Any |
| Questionn/Problem Description |
"From our understanding of flows: If it is TCP communication, it will be terminated by the active timeout or RST/FIN flag. Is this correct?" |
| Steps to Reproduce: | |
| Error Message: | |
| Defect Number: | |
| Enhancement Number: | |
| Cause: | |
| Resolution: | Firstly let's look at the user guide definition of active and inactive timeout: Active timeout ensures that the very long flows will be exported in a specified time. Timeout is checked for each incoming packet. If corresponding flow is lasting longer than specified time interval, it is deleted from the flow cache and exported to collector. The default value is 300 seconds. Inactive timeout avoids keeping old, inactive flow records in the flow cache forever. When no packets belonging to the flow are observed for the specified time interval, flow record is exported to collector. The default value is 30 seconds. It is important to note that neither of the timeouts is tied or dependent on TCP flags, so flows generated by either TCP or UDP can be terminated by either timeout. Active timeout can end flows from UDP communication too, if the communication goes on for more than 300 seconds, which is not uncommon for UDP. The active timeout is there so that flow files aren't too large. For example some communication can take hours, and exporting such large flow would create very intensive load on the device, resulting in performance issues. For this reason flows are being split up by the active timeout - active means in this case that the communication that is being monitored is still being active, so that right after the flow is terminated by the active timeout, another flow export of this communication continues right afterwards with the same parameters. Once the exporter (the software part of the appliance that exports regular network traffic into netflow) recognizes that the communication is over and there haven't been any packets from this communication for more than 30 seconds - and here is important to note that TCP flags are NOT needed for the probe to know that the communication is over. It remembers different characteristic of each communication to separate it from other communications and then looks for packets belonging to this specific communication to stop arriving - the inactive timeout will then terminate the flow and send it out to the collector. This also means that the last flows generated by both TCP and UDP communication can and eventually will be terminated by inactive timeout. |
| Workaround: | |
| Notes: |
Was this article helpful?
0 out of 0 found this helpful