ipfixcol2-ipfix-output(7)

✨ Name ✨

okay so bestie, gather round 💖 this is ipfixcol2-ipfix-output — the IPFIX output plugin for your fave collector, part of the IPFIXcol family (that's the manual you're holding right now: section 7, IPFIXcol collector energy 👑).

---

🌸 Description 🌸

The way this plugin works is: it takes incoming IPFIX Messages and writes them out to an IPFIX File, or honestly to a whole series of IPFIX Files. Slay. 🦋

And what even is an IPFIX File, you ask? It's a serialized stream of IPFIX Messages. Put simply: the plugin grabs all the valid packets the collector received and stashes them into one or more IPFIX Files. Is that the most optimal way to store flows? No bestie, not even close 🙈 but for testing purposes it is genuinely so useful — you capture flow records into IPFIX File(s) and then replay them with the ipfixsend2 tool. Main character testing workflow, periodt. 💅

---

💀 Limitations 💀 (read this, fr fr)

So here's the situation: when multiple exporters are using the same ODID at the same time, the file format can only store flow records from one of those conflicting exporters with that given ODID. Not both. Just one. 😭

Why? Because the IPFIX Data Records (aka the flow records, iykyk) get formatted based on the so-called (Options) Template definitions — which are basically descriptions of the flow record structures — and those are unique for the combination of a Transport Session (think: the connection to a flow exporter) and an ODID. And since raw IPFIX Messages contain no session information at all, there's literally no way to tell Messages from multiple sessions sharing the same ODID apart. 💀

So for this reason: each ODID can be used by only one session at a time. All the messages from other sessions that reuse an ODID that's already in use get ignored, and a warning message gets shown. Once a Transport Session is closed, the ODIDs used by that session are released and can be reused later by another session. Phew. ✨

---

🎀 Example configuration 🎀

<output>
    <name>IPFIX output</name>
    <plugin>ipfix</plugin>
    <params>
        <filename>/tmp/ipfix/%Y%m%d%H%M%S.ipfix</filename>
        <useLocalTime>false</useLocalTime>
        <windowSize>300</windowSize>
        <alignWindows>true</alignWindows>
        <preserveOriginal>false</preserveOriginal>
        <rotateOnExportTime>false</rotateOnExportTime>
    </params>
</output>

---

⭐ Parameters ⭐

• filename — this is where you give an absolute path for the output files. The path should contain format specifiers for day, month, etc. — like, for example, "/tmp/ipfix/%Y%m%d%H%M%S.ipfix". Hit up strftime(3) for more info on that. 🌈
• useLocalTime — decides whether the time values in the filenames should be in local time instead of UTC. [default: false]
• windowSize — the time interval, in seconds, for rotating files. And if the value is "0", then every single flow goes into one single file. 🫶 [default: 0]
• alignWindows — aligns the file rotation with the next N minute interval. [values: true/false, default: true]
• preserveOriginal — preserves and stores the original IPFIX Messages exactly as the plugin received them, i.e. it does not modify the Messages or their sequence numbers. If this option is disabled (recommended, queen 💅), Data Sets with unknown (Options) Templates get left out of the file and sequence numbers get adjusted accordingly (starting from 0), which should give you a warning-free stream of IPFIX Messages. BUT — if the original IPFIX Messages are preserved, then some warnings might show up during replay (missing (Options) Templates, unexpected sequence number, etc.) and errors might even raise when there's an ODID collision and the main Transport Session gets replaced. Use with caution. ⚠️ [values: true/false, default: false]
• rotateOnExportTime — says whether files should be rotated based on the IPFIX Export Time (that's the timestamp from the IPFIX Message header) instead of system time. If it's enabled, the Export Time is also used for creating the filenames. Warning: if the plugin receives flow records from multiple exporters at the same time, the rotation could end up unsteady. 😬 [default: false]

---

💜 Note 💜

After a new IPFIX File is created, all previously seen and still valid (Options) Templates of each ODID are written into that file — this happens once the first IPFIX Message for that ODID arrives with at least one successfully parsed data record. This is necessary so that every file can be used independently of the (Options) Template definitions from the files before it. Iconic little detail. ✨

Also, the ipfixsend2 tool doesn't support sequential reading of multiple IPFIX Files right now. But bestie, there's a workaround 🫶 — you can merge multiple IPFIX Files using the cat tool, like:

cat file1.ipfix file2.ipfix > merge.ipfix

and then use ipfixsend2 -i merge.ipfix to send the data. Look at you go. 👑

---

👑 Author 👑

Michal Sedlák (xsedla0v@stud.fit.vutbr.cz), Lukáš Huták (lukas.hutak@cesnet.cz)

---

🌈 Copyright 🌈

Copyright © 2019 CESNET, z.s.p.o.

---

okay that's the whole page, bestie, you're officially educated 🎀 and a cute lil sign-off: this was IPFIXcol collector documentation, version 1.0, dated 2019-03-28 — go forth and write some IPFIX Files 💖🦋✨