Approximate aggregation : IP sort

[dreamkinn]

Hi, here is a modest contribution proposal to the AggregateApproxIPV4s feature.
TL;DR : In its current state, the algorithm used to heuristically aggregate IPv4s in approximate subnets gives different results depending on the order in which the addresses are provided.

The algorithm creates a new /24 subnet for each new IP address that is not already contained in a previously seen subnet, and then for each new address matching the subnet, it specializes the subnet mask. The found subnets are therefore highly dependent on the order in which the IPs were provided in the input.
Here is a short example :

~:$ cat ips_ordered
File: ips_ordered
10.10.0.1
10.10.0.2
10.10.0.255
~:$ cat ips_ordered | mapcidr -aa -silent
10.10.0.0/24                   # Expected output
~:$ cat ips
File: ips
10.10.0.1
10.10.0.255
10.10.0.2
~:$ cat ips | mapcidr -aa -silent
10.10.0.0/30                   # Misleading output

In the first case (ordered input), the algorithm first creates a /24 subnet (10.10.0.1), then specializes in /30 (10.10.0.2), and finally opens back up to /24 to match the .255. This generates a nice "guessed" /24 subnet that contains all of the input.

However, in the second case, the algorithm creates a /24 (10.10.0.1), stays at /24 (10.10.0.255), and then specializes to /30 because of the .2. The result of this is an output in /30 which misleads the user to think that no IP outside the /30 range exists in the dataset.

The contribution I propose is a sort of the input IP addresses at the start of the function which :

• Does create an overhead
• But leads to uniform output

Please let me know if this is a known/intended behaviour.

PS

The sort feature did not fix the output in my case :

~:$ cat ips | mapcidr -aa -silent -s
10.10.0.1
10.10.0.2
10.10.0.255
10.10.0.0/30

[Mzack9999]

Superseded by #223 - Opened a new PR with the content of this as I'm unable to push fixes on remote

[ehsandeep]

@dreamkinn thanks for the PR, these changes are now merged into #223