From that perspective - yes, close to clean. But don't surprise and annoy customerswithout warning them upfront that eventually their or their customer's (TE) announcement suddently stop to work ... esp. don't give your (my) 1st line NOC a very hard time then in the need to explain it to
Hi Job, | From my perspective you are almost squacky clean! I see two invalids | 88.159.27.0/24 (invalid, but covered by valid route 88.159.0.0/16) and | 94.103.31.0/24 (also covered by valid 94.103.16.0/20). I'm sure there | are more, but if you drop these two prefixes it shouldn't result in loss | of connectivity because there are covering valid routes. the customer when he calls in the middle of the night (esp. when simple IRR filtering often causes headache). |> Yes, there are some (not just a few) invalids out there, not covered |> by not-invalid less specifics: https://as286.net/data/ana-invalids.txt |> (note: not a perfect report, limited to AS286 peer routes, downstream |> routes excluded, potential wrong altpfx for <12 prefixes [...]) | We should compare notes on how you generate this. I looked today and | only 2,200 prefixes become unreachable due to misconfigured RPKI ROAs. | http://instituut.net/~job/rpki-report-2018.07.12.txt - I think the | majority of invalid more-specifics simply are attempts at | traffic-engineering and not critical. Take invalids received from eBGP peers on every PE, note prefix and path. Take "clean" (without invalids) table of DFZ. For every invalid lookup in the invalid free DFZ table if there's a valid same or a less specific. If not, altpfx=NONE and expect connectivity issue. Your 2200 are more or less the 2277 ones in my list with altpfx=NONE Aggregated ~876 ;-) (#of IPs remain the same). Cheers, Markus