Do any network wizards out there know anything about netflow V9 templates?
I am writing a netflow collector in .net, which has lots of interesting challenges including reading the RFC!
However, I need a specific piece of information
Here is a link to a copy of the RFC:
https://www.ietf.org/rfc/r
From this I read this excerpt:
I cannot find any default expiry timeframe for a netflow Flowset Template.
It says it must be configurable at the exporter and the collector. When I set up a PRTG to collect netflow packets, there was not an option to specify the template expiry. I can't see any record in the RFC that the exported can use to tell the collector when to expire templates. PRTG works though.
Therefore there must be a reasonable default value for how long to keep an un-refreshed template before expiring it.
My question is, what is the default timeframe to expire a template - OR - how else can the collector learn this from the exporter? (someone manually configuring it is not the answer I want)
There must be some way in which netflow collectors work out of the box without the user specifying the template expiry. I need to do this.
However, I need a specific piece of information
Here is a link to a copy of the RFC:
https://www.ietf.org/rfc/r
From this I read this excerpt:
The life of a template at the Collector is limited to a fixed refresh
timeout. Templates not refreshed from the Exporter within the
timeout are expired at the Collector. The Collector MUST NOT attempt
to decode the Flow or Options Data Records with an expired Template.
I cannot find any default expiry timeframe for a netflow Flowset Template.
It says it must be configurable at the exporter and the collector. When I set up a PRTG to collect netflow packets, there was not an option to specify the template expiry. I can't see any record in the RFC that the exported can use to tell the collector when to expire templates. PRTG works though.
Therefore there must be a reasonable default value for how long to keep an un-refreshed template before expiring it.
My question is, what is the default timeframe to expire a template - OR - how else can the collector learn this from the exporter? (someone manually configuring it is not the answer I want)
There must be some way in which netflow collectors work out of the box without the user specifying the template expiry. I need to do this.
Hello,
I hope it's not to late for you..
There isn't really a default timeout universally but you should set one that works for you.
According to cisco:
I think in most cases it defaults to 1 minute.
Hope it helps..
Panagiotis.
I hope it's not to late for you..
There isn't really a default timeout universally but you should set one that works for you.
According to cisco:
All of the NSELs are sent via UDP. With a single Template DataSet record being sent every 30 minutes it is possible that the Template DataSet packet is dropped due to congestion and the collector is unable to understand the NetFlow data. '''flow-export template timeout-rate <time in minutes>''' can be configured to try and help overcome this.
I think in most cases it defaults to 1 minute.
Hope it helps..
Panagiotis.
I can't find any information on Netflow v9 Template Expiry, so I went for the next best.
IPFix was developed as a non-proprietry alternative. It used Netflow V9 as a base to build upon and as such, there are many similarities.
From RFC5153 in section 6.2, I find the following
So there is a vague recommended method to work out at runtime, what the expiry should be:
Use an out of band method to set the exporter refresh rate.
If such a method is not available, start at 60 mins, see how often templates are sent and adjust accordingly.
I think a strong emphasis should be on having configuration options in the collector - even if you have no access to such options in the exporter.
Exporters probably have defaults, and we could probably with time (as we try new types of equipment), populate some defaults in the collector. So if we are setting up equipment of type 'X' then we have a default value that is overridable and if we are setting up a device of type 'Y' with no default and no value is entered start at 60mins and use an algorithm to detect the frequency that templates are sent and multiply it by 3.
Just one more item to note (sarcasm intended)
How very forward thinking of the RFC authors:
IPFix was developed as a non-proprietry alternative. It used Netflow V9 as a base to build upon and as such, there are many similarities.
From RFC5153 in section 6.2, I find the following
We recommend that the Collector implements a Template Expiry of three
times the Exporter refresh rate.
However, since the IPFIX protocol doesn't provide any mechanism for
the Exporter to convey any information about the Template Expiry time
to the Collector, configuration must be done out of band.
If no out-of-band configuration is made, we recommend to initially
set a Template Expiry time at the Collector of 60 minutes. The
Collecting Process may estimate each Exporting Process's resend time
and adapt the Expiry time for the corresponding Templates
accordingly.
So there is a vague recommended method to work out at runtime, what the expiry should be:
Use an out of band method to set the exporter refresh rate.
If such a method is not available, start at 60 mins, see how often templates are sent and adjust accordingly.
I think a strong emphasis should be on having configuration options in the collector - even if you have no access to such options in the exporter.
Exporters probably have defaults, and we could probably with time (as we try new types of equipment), populate some defaults in the collector. So if we are setting up equipment of type 'X' then we have a default value that is overridable and if we are setting up a device of type 'Y' with no default and no value is entered start at 60mins and use an algorithm to detect the frequency that templates are sent and multiply it by 3.
Just one more item to note (sarcasm intended)
How very forward thinking of the RFC authors:
since the IPFIX protocol doesn't provide any mechanism forThey could have just used an options template for the exporter to specify a refresh interval for the collector to use! It wouldn't be rocket science!
the Exporter to convey any information about the Template Expiry time
to the Collector....
There is no concrete answer. After a lot of research, I had to resign myself to the 'bodge' suggested by the IPFIX author I quoted.
<Political Rant>The RFC is flawed in such a way that only manufacturers or large software outfits with the capital to collaborate with the manufacturers can create a valid solution based upon anything other than guesswork, effectively shutting the little people out of the market! </Political Rant>
<Political Rant>The RFC is flawed in such a way that only manufacturers or large software outfits with the capital to collaborate with the manufacturers can create a valid solution based upon anything other than guesswork, effectively shutting the little people out of the market! </Political Rant>
Premium Content
You need an Expert Office subscription to comment.Start Free Trial