how does samplicator.netflow get processed?

[topshelfjeff]

i've seen two behaviors. When sending flow to mulitple collects i've experienced where samplicate will process the flow from one rule then stop. I've also seen it where it will process two rules.

Use case:

I have a rule for 192.168.10.0/255.255.255.0: 10.1.1.1/2055
I have a rule 0.0.0.0/0.0.0.0: 10.1.1.2/2055

some times when samplicate is running and a flow comes in for a device in 192.168.10.0/24 subnet it will just be sent to 10.1.1.1. then i'll restart the samplicate process and it will go to both destinations.

Can I get clarity on how the list is processed?

[sleinen]

The code goes through the configured source prefixes (ctx->sources), and when it finds a match, it sends to the corresponding destination and considers its work done for this packet. So it's "first match"—where I'm not sure how the ordering of the prefixes inside the program comes about... maybe it's not well defined at all.

It would be nicer if the code did "longest-prefix match", or maybe (optionally) "match-all". Longest-prefix match could be achieved relatively easily by sorting ctx->sources by decreasing prefix length. Could you give that a try?

[mikearagonhub]

I recently configured a /32 that was part of a /16 network that was also configured to go to a different destination and found that when adding /32 entries, it didn't matter where I put them in the file (top/bottom) it preferred the /16 entries even though the /32 was more specific (longest-prefix). Use case was that we needed to move a device to a different collector server due to it's high FPS to distribute the load better. It was originally part of a /16 network, when I added the /32 entry, flow packets continues to prefer the /16 destination.