On Thu, Jul 12, 2018 at 09:44:47PM +0000, Weber, Markus wrote:
| 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.
From that perspective - yes, close to clean. But don't surprise and annoy customers without 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 the customer when he calls in the middle of the night (esp. when simple IRR filtering often causes headache).
Well - if you want to be kind to your customers, just deploy "invalid == reject" on your peering partners first. This way your customers benefit from a form of protection layer, while not being subjected to the same strictness you apply to peers. I bet you most BGP hijacks & misconfigurations come into AS 286 via the peering partners, as all customers already are filtered based on IRR data (if I am not mistaken?).
|> 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).
Ah, so we arrive at same conclusion. I misunderstood your file format. It is of paramount importance that this number is brought down, I think the only way to bring down the number is to deploy Origin Validation and create the feedback loop that 'wrong roa == poor connectivity'. Kind regards, Job