add option to anonymize sflowtool output for both ipv4 and ipv6. /24 …

[loganaden]

…for ipv4 and /64 for ipv6.

[sflow]

While I recognize the value of this option in applications that consume sFlow, I do not think it belongs in sflowtool.

sflowtool is for demonstrating, understanding and troubleshooting sFlow. It is not intended as the first step in a full-blown application. However if anonymization is the only thing missing for what you are doing then I suggest you pipe the JSON output from "sflowtool -J" into a Python script and do the anonymization there. I hope that makes sense?

[loganaden]

The proposed PR was actually borne from a request from 5x IXPs that are using sflowtool to collect, and fan out sflow, to various collectors. when we discussed the various options, the IXPs themselves gravitated towards a standards-based approach that :

1. maintained the spirit of not distributing PII information
2. did not require additional development resources on the IXP side (ie. community-run IXPs with no staff)
3. an “option” to enable/disable on demand for different classes of flow collectors (ie. sflowtool -f a.b.c.d -af w.x.y.z; where the second host (w.x.y.z) sees the anonymised traffic, but the first doesn’t)

[sflow]

If you don't mind I'd like to understand the full scope of this use case better. Is this an example of an IXP sending a member's sFlow feed -- for just that member's traffic -- back to them? With/without anonymization?

And what happens next? Do the recipients use it to construct some summary dashboards (e.g. using Prometheus+Grafana), or is that part unknown/private with different recipients doing different things?

[sflow]

Sorry, but I still don't understand the use-case. When you forward sFlow using the -f option it forwards the original unmodified UDP datagram. The anonymization in this pull-request will only take effect in places where sflowtool is used to print the decoded protocol fields to ASCII or json. Is that actually the requirement here?