More and more flow exporting vendors are making the move to IPFIX and at Plixer, we feel that implementing RFC 5610 should be part of the decision. The reason for this is because IPFIX is capable of exporting everything in NetFlow v5 as well as additional fields such as top multicast addresses, IPv6 addresses, packet lengths, MPLS labels, VLANs, MAC addresses and several other details and performance metrics that the vendor can decide on and even make up. Without RFC 5610, the IPFIX collector doesn’t know how to decipher these sometimes proprietary elements.
Exporting IPFIX
IPFIX is capable of exporting unique flow details called Information Elements (IEs) depending on the configuration of the flow cache. IEs are be used by vendors to export specific pieces of information. These details allow vendors to differentiate themselves. Think of an IE as similar to an enterprise OID defined in a SNMP MIB.
Defining IPFIX Templates
Because IPFIX allows the export to be à la carte, the concept of a template had to be introduced. Most flow developers understand this however, on the reporting end there is an emerging dilemma: how do we decode your stuff? In short, without an RFC 5610 compliant template, we are stuck back with the same issue we have when someone sends us a packet capture and we don’t have the decodes loaded in Wireshark. In other words, it’s garbage and we can’t look at it.
Implementing RFC 5610
This is a call for RFC 5610 to make deciphering an Element ID in IPFIX templates much easier. By exporting the RFC 5610 template in IPFIX, the flow collector is told how to decipher the elements being exported. Without something like RFC 5610, new IEs are typically ignored and unavailable for reporting until the collector is updated. IPFIXify, a free utility used to export any type of record in IPFIX has implemented this RFC.
To make a RFC 5610 template useful, it must contain the ID, Name, Length and Data Type semantics. These all need to be defined and probably should be exported in a separate IPFIX template to make the adoption by 3rd party vendors easier. Before defining additional elements, developers should check with IANA to see if an element for what they want to export has already been defined.
Below is the structure of an RFC 5610 template with defined IEs:
- 400.32473 CallerID, 8, integer, identifier
- 401.32473 Codec, 65535, string, identifier
- 402.32473 Jitter, 4, integer, quantity
- 403.32473 PacketLoss, 4, integer, deltaCounter
- 501.32473 Round Trip Time, 4, integer, quantity
- 503.32473 URL, 65535, string, default
- 82.32473 ifSpeed, 4, integer, quantity
- 700.32473 Facility, 10, string, identifier
- 701.32473 Severity, 10, string, default
- 704.32473 Message, 65535, string, default
Below you can see an actual example of leveraging IPFIXify to export an RFC 5610 template with all of the details involved with exporting a Microsoft server event log as IPFIX.
Improve your IPFIX Export
If vendors don’t implement RFC 5610 or something similar, we are going back to the days of not being able to understand SNMP traps until we ‘successfully’ compile the vendors MIB file. Without the MIB file compiled into your local trap collector, the SNMP trap is garbage and frustration ensues. The world of IPFIX is facing the same dilemma today.
If vendors can’t be bothered with RFC 5610, they should consider providing a XML file with their IE details. The IANA page for example is generated from XML. We use this XML to import new standard IEs into our collector. At the very least, a XML file allows reporting vendors to quickly add support for proprietary IEs. This doesn’t help at runtime like RFC 5610, but it is one more way to share IE information more efficiently.
The Bottom Line on RFC 5610
Implementing RFC 5610 can save time for both the exporting and collecting vendors plus, it can earn IPFIX developers additional accolades.