Display Output has <unkown>:<unknown> in it

[vs0t]

I am new to ipfixcol2 and the genre as a whole, I am an intern and trying to complete a project where I utilize my ubuntu cli server to collect IPFIX TCP data, running the collector returns the values with ...

IPFIX Message header:
Version: 10
Length: 88
Export time: 1691092694
Sequence no.: 0
ODID: 0

Set Header:
Set ID: 2 (Template Set)
Length: 72

• Template Record (Kafka output plugin and distributed architecture #1)
  Template ID: x
  Field Count: 8
  EN: x ID: x Size: 8 | ":"
  EN: x ID: x Size: 1 | ":"
  EN: x ID: x Size: var. | ":"
  EN: x ID: x Size: var. | ":"
  EN: x ID: x Size: var. | ":"
  EN: x ID: x Size: var. | ":"
  EN: x ID: x Size: 8 | ":"
  EN: x ID: x Size: 1 | ":"

I've replaced the numbers with X's for privacy although I don't know if this would matter lol. Is this an issue in how I have it set up or is this due to the IPFIX packets being encrypted before being sent?

[sedmicha]

This means that the collector doesn't have the definitions for those fields.

The EN and ID numbers of a field point to a table of "information element" definitions, which is how the collector figures out what the name, data type, semantic meaning etc. of that particular field is. <unknown>:<unknown> means that no definition was found for that particular EN:ID combination.

These definitions are stored locally in a .XML file (see https://github.com/CESNET/libfds/tree/master/config/system/elements). Definitions of all the standard IANA elements (signified by EN=0) are supplied, but if your IPFIX records contain any custom ones, you have to supply definitions for those yourself.

Regarding encryption, I'm not exactly sure what you mean. The iPFIX protocol doesn't directly support encryption as far as I know, and neither does our collector as of now. If you're somehow encrypting the data, then yes, that could be the cause of the issue as well.