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/rfc3954.txt


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.
LVL 5
JohnAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
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.

Panagiotis ToumpaniarisSystem EngineerCommented:
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:

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.
JohnAuthor Commented:
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

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 for
   the Exporter to convey any information about the Template Expiry time
   to the Collector....
They 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!

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
JohnAuthor Commented:
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>
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.