-1

How netflow defines the end of the udp session. That is, as I understand, there must be some timeout in the absence of requests from the dynamic port with the passage of time after which a new session for this port is formed. If yes, how it is implemented, and if there is a timeout how long it lasts

egor
  • 3
  • 2
  • 1
    Cisco netflow, mikrotik netflow or maybe solarwinds netflow? – Anubioz Apr 08 '17 at 16:53
  • I apologize, I do not really understand this. It is necessary to understand the very principle. In each program in different ways? Could you please tell us how this is implemented in general. Thanks – egor Apr 08 '17 at 16:59
  • There is a timeout for UDP sessions, it lasts as long as you set it in your router settings. Netflow on the other hand is a network monitoring technology (developed by Cisco), which just stores info about various connections. So if there is a router, which has UDP timeout set to 10 sec, netflow will detect and report UDP streams whos packets are transmitted at least once every 10 seconds. – Anubioz Apr 08 '17 at 18:03
  • @egor, it is easier to answer questions that are [well asked](https://serverfault.com/help/how-to-ask). Currently, it isn't obvious what you are really asking (about the principle? the implentation(s)? best-practice?). You might also find the [Network Engineering SE](https://networkengineering.stackexchange.com/) a better place to ask about this. – iwaseatenbyagrue Apr 20 '17 at 16:45

1 Answers1

0

This is an area that could have a huge amount written but here are some quick points:

1.) There are a series of timers with any Netflow implementation that, when exceeded, cause a flow record to be exported and flushed from the cache.

2.) One of these timers it the max timer. The idea here is that even an ongoing flow will cause a record to be generated. A long-lived flow might actually generate dozens (or hundreds) of sequential records. A good example of this would be a TCP flow lasting, say, 60 minutes on an implementation with a max timer of 5 minutes. That flow might actually be represented by 12 (+/-) records. Put another way, records are being generated even without a FIN (or without the session ending at all).

3.) Another timer is the inactive/idle timer. In this case if traffic isn't seen for a given flow within x seconds then the cache entry is timed out and the record exported. This is how Netflow identifies the end of any non-TCP flow (hint: not all implementations handle TCP FIN as a close-out method correctly either). There's a key point to consider here: if this timer is very long then you may not have a very accurate view of exactly when a given flow actually ended.

4.) To make things more interesting - if there's enough traffic to be overrunning the cache on the Netflow collector then many implementations will actually age out flows early to make room. Ideally it's flows with longer idle timers that are selected but if the cache exhaustion gets bad enough we can actually reach a degenerate condition where literally each packet generates a new flow. As an aside, this is why full (i.e un-sampled) Netflow is pretty much a thing of the past in most modern DC switches, as the sheer size of the flow cache becomes completely untenable.

So, as always, the Devil is in the details. Netflow implementations vary in terms of size of cache and sample rate, how low (or high) these timers (and a few others) can be set, whether or not they correctly track on TCP flags, etc. It gets a lot more involved when figuring in IPFIX/v9 where locally programmable aggregation adds another level of intermediation in flow collection, etc.

rnxrx
  • 8,143
  • 3
  • 22
  • 31