I still have had no time to study the code to look for the bug, but I wanted to warn you of this behaviour. The way I understand it 129.134.0.0/16 should be the only one left in the output
Thank you for the report.
It is example of situation when one subnet is fully included in another. I do not look for such optimization … yet
IMHO it is not “a bug” .. output is fully valid however not optimized to “deep roots”.
Depends on how IPv4 is divided to subnets. Theoretical that’s 2^32 addresses (slightly less than 4.210^9). Some are used for network addresses (and same number for broadcast addresses) - exact number depends on sizes of subnets and with CIDR addressing you can’t know how some particular address range might be divided into subnets just by look of it. Some addresses are private (10/8, 172.16/12, 192.168/16) and don’t really count. Some addresses are used for multicasts (224/4) and don’t count either. My guess is that realistic number is around 3.9 billion (3.910^9) of IPv4 host addresses. Give or take a few millions.
Here I’m using JSON output format so that I can have access to a prefix-length range, but you could equally use
bgpq3 -A -4 AS-FACEBOOK
and get a Cisco-style output:
ip prefix-list NN permit 31.13.24.0/21
ip prefix-list NN permit 31.13.64.0/18 le 19
ip prefix-list NN permit 31.13.64.0/19 ge 24 le 24
ip prefix-list NN permit 45.64.40.0/22
ip prefix-list NN permit 66.111.48.0/22
ip prefix-list NN permit 66.111.48.0/23 ge 24 le 24
…snip…
ip prefix-list NN permit 199.201.64.0/22
ip prefix-list NN permit 199.201.64.0/22 ge 24 le 24
ip prefix-list NN permit 204.15.20.0/22