-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error message when key/nonkey configuration doesn't match actual behaviour #114
Conversation
I'll hopefully have a followup Pull Request that enhances the aggregator so it respects the configuration (by having the default aggregation behaviour for non-keys be 'first flow', as is commonly done on pretty much all other netflow probes) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Will merge after minor changes are applied.
…viour Using a 'traditional' flow definition like that below will result in: vermont[4729]: Field bgpDestinationAsNumber configured as nonFlowKey will not be Aggregated vermont[4729]: Field bgpSourceAsNumber configured as nonFlowKey will not be Aggregated vermont[4729]: Field destinationIPv4PrefixLength configured as nonFlowKey will not be Aggregated vermont[4729]: Field egressInterface configured as nonFlowKey will not be Aggregated vermont[4729]: Field ipNextHopIPv4Address configured as nonFlowKey will not be Aggregated vermont[4729]: Field sourceIPv4PrefixLength configured as nonFlowKey will not be Aggregated <rule> <flowKey> <ieName>destinationIPv4Address</ieName> <autoAddV4PrefixLength>false</autoAddV4PrefixLength> </flowKey> <flowKey> <ieName>destinationTransportPort</ieName> </flowKey> <flowKey> <ieName>ingressInterface</ieName> </flowKey> <flowKey> <ieName>ipClassOfService</ieName> </flowKey> <flowKey> <ieName>protocolIdentifier</ieName> </flowKey> <flowKey> <ieName>sourceIPv4Address</ieName> <autoAddV4PrefixLength>false</autoAddV4PrefixLength> </flowKey> <flowKey> <ieName>sourceTransportPort</ieName> </flowKey> <nonFlowKey> <ieName>bgpDestinationAsNumber</ieName> </nonFlowKey> <nonFlowKey> <ieName>bgpSourceAsNumber</ieName> </nonFlowKey> <nonFlowKey> <ieName>destinationIPv4PrefixLength</ieName> </nonFlowKey> <nonFlowKey> <ieName>egressInterface</ieName> </nonFlowKey> <nonFlowKey> <ieName>flowEndMilliseconds</ieName> </nonFlowKey> <nonFlowKey> <ieName>flowStartMilliseconds</ieName> </nonFlowKey> <nonFlowKey> <ieName>ipNextHopIPv4Address</ieName> </nonFlowKey> <nonFlowKey> <ieName>octetDeltaCount</ieName> </nonFlowKey> <nonFlowKey> <ieName>packetDeltaCount</ieName> </nonFlowKey> <nonFlowKey> <ieName>sourceIPv4PrefixLength</ieName> </nonFlowKey> <nonFlowKey> <ieName>tcpControlBits</ieName> </nonFlowKey> </rule>
34f85e2
to
9f2b3eb
Compare
Thanks for the PR and the changes! |
Add an error message when key/nonkey configuration doesn't match actual behaviour (as reported in #112).
Using a 'traditional' flow definition like that below will result in:
vermont[4729]: Field bgpDestinationAsNumber configured as nonFlowKey will not be Aggregated
destinationIPv4Address false destinationTransportPort ingressInterface ipClassOfService protocolIdentifier sourceIPv4Address false sourceTransportPort bgpDestinationAsNumber bgpSourceAsNumber destinationIPv4PrefixLength egressInterface flowEndMilliseconds flowStartMilliseconds ipNextHopIPv4Address octetDeltaCount packetDeltaCount sourceIPv4PrefixLength tcpControlBitsvermont[4729]: Field bgpSourceAsNumber configured as nonFlowKey will not be Aggregated
vermont[4729]: Field destinationIPv4PrefixLength configured as nonFlowKey will not be Aggregated
vermont[4729]: Field egressInterface configured as nonFlowKey will not be Aggregated
vermont[4729]: Field ipNextHopIPv4Address configured as nonFlowKey will not be Aggregated
vermont[4729]: Field sourceIPv4PrefixLength configured as nonFlowKey will not be Aggregated