Add IPFIX support, including OpenBSD pflow(4)#162
Open
drkhsh wants to merge 1 commit into
Open
Conversation
Adds an `ipfix:` section to mapping.yaml so v10 packets fill the custom InBytes/InPackets/OutBytes/OutPackets fields, the same way netflowv9 already did. goflow2's NetFlowPipe already dispatches v10, so no decoder changes are needed -- the producer just had no remap for IPFIX field IDs and counters were always zero. Tested with OpenBSD pflow(4) pflowproto 10 (unidirectional, fields 1+2 only). Bidirectional exporters that also set 23/24 work too. Drops the README disclaimer about IPFIX not being supported.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes the gap noted in the README (& closes #60)
I have hardware (OpenBSD
pflow(4)withpflowproto 10)The change
goflow2's
NewNetFlowPipealready dispatches v5/v9/v10 by header version, so IPFIX packets have always reached the producer. The gap was thatformatter/mapping.yamlonly declared anetflowv9:section, so for v10 packets the customInBytes/InPackets/OutBytes/OutPacketsfields stayed at zero and ntopng saw flows with 0-byte counters.Fix: add an
ipfix:block inmapping.yamlmirroringnetflowv9:(IANA IEs 1, 2, 23, 24 are identical between the two protocols). No code changes, no new flags, no new deps.Tested
pflow(4)pflowproto 10(unidirectional, IEs 1+2) → ntopng shows non-zero in_bytes/in_packets