IPFIX Vendors should implement RFC 5610

Michael Patterson : Advanced NetFlow Traffic Analysis
Michael Patterson
Founder and Product manager for Plixer's Scrutinizer NetFlow and sFlow Analyzer as well as Flow Analytics.

IPFIX Vendors should implement RFC 5610

This is a call to all the great companies to date that have implemented IPFIX.  It is clear that IPFIX is the next generation protocol for to be included with most network monitoring solutions and for this reason, I'd like this companies and those considering IPFIX to include support for RFC 5610 or some similar sort of technology.  Without support for this RFC, deciphering new elements is nearly impossible.  The situation IPFIX collector vendors are facing is similar to trying to look decipher traps or browse OIDs without a MIB file. 

Below is a template being received from a device where the IPFIX collector does not know how to interpret a field.  Notice the 2nd column below '13745_33071' :

IPFIX Vendor Followed By Element IDs

You can see above that the data in this field did not get translated to the proper format.  Support for RFC 5610 allows vendors to export details pertaining the element IDs contained within the templates.  If exported by each IPFIX vendor, the collector could read in the RFC 5610 template and know how to display the contents held within each vendor specific element.   BTW: those numbers in the column header stand for:
  •  13745 = plixer
  •  33071 = unique element ID

Notice that the value above shows up as a square.  This is because our IPFIX collector didn't know how to decode this data which resulted in our front end trying to display the binary information.  Without a RFC 5610 template, we have to tell another developer how to decode the value which allows the front end to display it like this:

IPFIX Vendor Followed By Element ID Translated

Notice the new column above 'object_id' (i.e. 13745_33071).  This is the ID of the object being polled.  Without RFC 5610 support we are stuck in a situation like we are with SNMP.  We have to find and compile the SNMP MIB before we can understand the OID that is in the SNMP trap.  Folks, we are repeating a not so good portion of history if we don't start implementing RFC 5610.   Right now we have to call the vendor, support doesn't know what we are talking about, they call us back, they set a meeting time with the product manager.  The product manager doesn't know what we are talking about.  The product manager reaches out to the developer who creates a file which is shared with us.  This file tells us how to hard code into our collector how to interpret the vendor specific elements.  It's tiring and unnecessary.

I really don't want to see the efforts of Boschi, Trammell, Hitachi Europe, Mark, Fraunhofer IFAM, Zseby and Fraunhofer FOKUS go in vain. Please contact us if your company would like to consider implementing RFC 5610.  We have experience with the release of IPFIXify which is a gateway for translating syslogs, event logs and SNMP traps to IPFIX. 

Related Articles to 'IPFIX Vendors should implement RFC 5610'
Inbound Using Egress
netflow Metering Ingress Only
Feedback for IPFIX Vendors should implement RFC 5610

Leave a comment

Featured Events