Perhaps this is just a small error that has to be accepted in your measurements, but we are dual homed and require both the aggregate and the specific.
2) When an AS advertises both an aggregate and a specific, the specific is 'dropped' by the aggregator. If the input is: {205.89.10.128/17, 205.89.10.130}, the output will be: {205.89.10.128/17} (205.89.10.130 will be dropped).
The 205.88.10.128 was a random example. I hope that's not you :) There are no "value" judgements made by the tool - it's just suggesting aggregates. And if we see an aggregate and a specific, both set to the same next-hop, it's quite likely that it's the same AS announcing both routes, and that they (your transit provider(s)) could do the aggregation themselves - but the tool *is* deficient in that right now it doesn't consider AS-paths. As an example, picking an IP for branch.com (198.111.253.37): Our route table has: *> 198.111.252.0 192.41.177.145 <--- agis *> 198.111.252.0/22 192.41.177.181 <--- mci *> 198.111.253.0 192.41.177.145 <--- agis *> 198.111.255.0 192.41.177.145 <--- agis So if 198.111.252/23 is suggested as an aggregate for the 192.41.177.145 (AGIS) target, that's because it looks like AGIS could in fact announce 198.111.22.0/23 instead of 198.111.252/0 and 198.111.253.0. Avi