cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

This product reached the end of support date on March 31, 2021.

Netflow Granularity - DCRUM 12.2.2

matthew_eisengr
Inactive

Hello,

I have a question in regards to Netflow granularity

While I know the CAS processes zdata, kdata, etc in 5 min intervals, does the same apply for Netflow?

We have a scenario where the flows are being sent every minute to a different collector that supports 1min polls but they are looking to redirect those to the AMD while maintaining that 1min granularity

Is this supported?

Thanks in advance!

 

Matt Eisengruber

4 REPLIES 4

adam_piotrowicz
Dynatrace Pro
Dynatrace Pro

RTM and NFC processes on AMD produce two sets of zdatas and their intervals must be the same as it would be not compatible with CAS that expects zdata files from all data sources to be in the same interval.

The only way is to change monitoring interval to 1 minute that is not recommended due to performance reasons.

mike_hicks
Inactive

Just adding to Adams response. It is important to remember that NetFlow export, unlike SNMP polling, pushes information periodically to the DC RUM NetFlow collector. In general, the NetFlow cache is constantly filling with flows and software in the router or switch is searching the cache for flows that have terminated or expired and these flows are exported to the DC RUM NetFlow collector. Flows are terminated when the network communication has ended (ie: a packet contains the TCP FIN flag). A flow is ready for export when it is inactive for a certain time (ie: no new packets received for the flow); or if the flow is long lived (active) and lasts greater than the active timer (ie: long FTP download). Also, the flow is ready for export when a TCP flag indicates the flow is terminated (i.e. FIN, RST flag). There are timers to determine if a flow is inactive or if a flow is long lived and the default for the inactive flow timer is 15 seconds and the active flow timer is 30 minutes. All the timers for export are configurable but the defaults are used in most cases. So you have to be aware that the rate of flow sets hitting the flow collectors is determined not by a poll, but by the expiration of the timers on the source device, as mentioned there are three of those different criteria, like finished conversations, aged conversations and buffer full, and the expiration of any one will cause a flow to be sent, however normally these are not sent as individual flows but as flow sets with multiple flows in the flow set. So the point is that whilst the 1 minute will may be perceived to give you better reporting granularity,  but will make no difference to the rate of flows/data hitting the flow collector (if that makes sense).

 

 Mike

Mike,

Apologies for the super long delay on the reply to this but going on what you are saying... is there a recommendation for those timers on the routers? I've been reading on some forums and they all seem to recommend this setting:

ip flow-cache timeout active 1

ip flow-cache timeout inactive 15

The reasoning behind it being you are forcing it to export every 1min and not build up a big cache then bombard the collector, so I'm assuming on a chart this would look less like a jagged JVM memory saw tooth pattern and more like a constant straight line with little variation. Also, they are saying it reports the utilisation of the interface more accurately?

Just wondering your thoughts on this?

mike_hicks
Inactive

Hi Matthew,

It actually depends on the mix of traffic your device, what you tend to find is between the three timers you will actually get something of a constant flow of flow sets coming to the collector. Having said that setting the ip flow-cache active timeout to 1 is not a bad idea, but remember this is specifically designed to break up long active connections, and what it will do is reduce the timeout on running connections to one minute., so of you have an environment that has a lot of long running connections it will give you better flow to the device. But the ip flow-cache inactive timer should already be set at a default of 15 so i wouldn't be altering that.

In terms of utilization it depends on what you're working out, a lot of the competitive collectors can only use the flow set data to give them an indication of utilization , whereas DC RUM will also use SNMP MIB to provide utilization stats direct form the interface itself.