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:
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.
]]>