I wrote a simple tool to figure out what kind of invalid a rpki invalid is, this can aid people in understanding the impact of "invalid == reject" routing policies. Only "invalid_unreachable" routes present an operational issue in my opinion, IP addresses covered by "notfound" or "valid" less specific routes will still be reachable. You pass it a file name (or via stdin) with one prefix and origin ASN per line (white space separated) representing your full BGP RIB, and then you can grep specific for the task at hand to extract the info you need: $ rpki-ov-checker full_rib | fgrep -f customer_prefixes | grep invalid | sort -R | head invalid_covered_by_notfound 123.101.0.0/21 4809 covering route: 123.101.0.0/16 4134 invalid_covered_by_valid 46.3.74.0/24 134121 covering route: 46.3.0.0/16 207636 invalid_unreachable 83.231.209.0/24 3949 invalid_unreachable 124.30.247.0/24 9583 invalid_covered_by_valid 125.21.232.0/24 9730 covering route: 125.21.0.0/16 9498 invalid_unreachable 120.29.92.0/24 17639 invalid_unreachable 31.40.164.0/24 200872 invalid_covered_by_notfound 45.12.139.0/24 40676 covering route: 45.12.136.0/22 35913 invalid_covered_by_valid 122.160.178.0/24 24560 covering route: 122.160.0.0/16 24560 invalid_covered_by_valid 61.90.251.0/24 21734 covering route: 61.90.192.0/18 7470 NTT is using this to figure out who we need to help fix their ROA or correct their BGP announcements. Get the goods at https://github.com/job/rpki-ov-checker Enjoy! Kind regards, Job
VERY cool job I like it a lot! This might help me make the case to push the button on dropping RPKI invalids internally even more. Thanks for the contribution as always! - mickod-2110 On Thu, Feb 06, 2020 at 12:41:33PM +0100, Job Snijders wrote:
I wrote a simple tool to figure out what kind of invalid a rpki invalid is, this can aid people in understanding the impact of "invalid == reject" routing policies. Only "invalid_unreachable" routes present an operational issue in my opinion, IP addresses covered by "notfound" or "valid" less specific routes will still be reachable.
You pass it a file name (or via stdin) with one prefix and origin ASN per line (white space separated) representing your full BGP RIB, and then you can grep specific for the task at hand to extract the info you need:
$ rpki-ov-checker full_rib | fgrep -f customer_prefixes | grep invalid | sort -R | head invalid_covered_by_notfound 123.101.0.0/21 4809 covering route: 123.101.0.0/16 4134 invalid_covered_by_valid 46.3.74.0/24 134121 covering route: 46.3.0.0/16 207636 invalid_unreachable 83.231.209.0/24 3949 invalid_unreachable 124.30.247.0/24 9583 invalid_covered_by_valid 125.21.232.0/24 9730 covering route: 125.21.0.0/16 9498 invalid_unreachable 120.29.92.0/24 17639 invalid_unreachable 31.40.164.0/24 200872 invalid_covered_by_notfound 45.12.139.0/24 40676 covering route: 45.12.136.0/22 35913 invalid_covered_by_valid 122.160.178.0/24 24560 covering route: 122.160.0.0/16 24560 invalid_covered_by_valid 61.90.251.0/24 21734 covering route: 61.90.192.0/18 7470
NTT is using this to figure out who we need to help fix their ROA or correct their BGP announcements.
Get the goods at https://github.com/job/rpki-ov-checker
Enjoy!
Kind regards,
Job
-- - MickoD <mick@mickod.ie>
On Thu, Feb 06, 2020 at 12:47:48PM +0000, Mick O'Donovan wrote:
VERY cool job I like it a lot!
This might help me make the case to push the button on dropping RPKI invalids internally even more.
What might also help is to analyse how much traffic is actually flowing towards those 'invalid_unreachable' destinations. Pmacct and kentik are tools that can help you understand this easily (they both support separately showing problematic invalids and invalids which are covered). https://mailman.nanog.org/pipermail/nanog/2019-February/099522.html https://www.kentik.com/blog/technical-guide-using-rpki-resource-public-key-i... Kind regards, Job
participants (2)
-
Job Snijders
-
Mick O'Donovan