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.
Asked:
Who is Participating?
Experts Exchange Solution brought to you by
Enjoy your complimentary solution view.
Get this solution by purchasing an Individual license!
Start your 7-day free trial.
I wear a lot of hats...
"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.
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....
Experts Exchange Solution brought to you by
Your issues matter to us.
Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.
Start your 7-day free trial
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>
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
.NET Programming
From novice to tech pro — start learning today.
Experts Exchange Solution brought to you by
Enjoy your complimentary solution view.
Get this solution by purchasing an Individual license!
Start your 7-day free trial.
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.