nanog mailing list archives
Re: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s)
From: Saku Ytti <saku () ytti fi>
Date: Sat, 14 May 2022 10:08:58 +0300
On Sat, 14 May 2022 at 00:17, Jakob Heitz (jheitz) <jheitz () cisco com> wrote: Hey Jakob,
'RPKI-tested-only' will store all routes that encounter a 'validation-state' test in the inbound route policy. In that case, when an RPKI server updates a VRP to the router, it can re-run the inbound policy from the stored route and not require a refresh request to be sent.
'RPKI-dropped-only' causes the dropped routes to be stored. This will prevent the unnecessary route-refreshes described above. It does not prevent all route-refreshes, but uses significantly less memory than 'RPKI-tested-only'
I'm sorry, but I am unable to reason what these answers mean in context of question that was: --- if validation-state is valid then pass else drop ---- I am assuming a) RPKI-tested-only would be same normal, and keep every single route b) RPKI-dropped-only would not keep anything (but it also might keep everything and be same as a)) That is, in this specific scenario, as far as I understand, there is no effect on the optimisations. Just to clarify why this type of policy may not be insane. IOS-XR has a 300k prefix limit for prefix-set, this limit is regularly hit by low quality as-set. By low quality I mean almost all as-set expand to unnecessarily large prefix-set, because as-set tend to be 'add only', there is no incentive to remove, so they just grow over time and do not represent in a meaningful manner the set of prefixes neighbours might advertise. And if we abstract what we the operators are actually doing, no one is doing prefix filtering, what everyone does is build AS-tree, by starting recursion from some as-set. So this AS-tree is the source of truth, no prefixes at all, prefixes are almost incentidental. After we have this AS-tree, we flatten it and for each element we ask for a route object with that origin. And then send this list to routers. Understanding what we actually do here, offers a mechanism for config size reduction as well as a standardized way to programmatically deploy those prefix-lists, by (ab)using RTR for this. We can fill all gaps from IRR data that RPKI data leaves us, then send a complete set of DFZ origins to routers, this allows us to accept only valid prefixes. Further the as-graph we created and flattened we can implement per-neighbour, which is trivial size compared to prefix-set size. Now compiling those AS path filters are regexp may not be so cheap, but some NOS offer cheap way to implement such AS filtering at scale: https://www.juniper.net/documentation/us/en/software/junos/routing-policy/topics/topic-map/Improve-as-path-lookup.html If we do this 100% complete RTR and AS-set filter per neighbor, then we actually have better routing security than we have in the most canonical way, because we are enforcing origin:prefix relation, which we are not enforcing when we dump larger and low quality prefix-sets to routers. This makes us much less vulnerable to the low quality as-set both in operational manner by not inflating config sizes and cause commits to fail and by improving routing security.
Regards, Jakob. -----Original Message----- From: Saku Ytti <saku () ytti fi> Sent: Friday, May 13, 2022 12:36 AM To: Jakob Heitz (jheitz) <jheitz () cisco com> Cc: nanog () nanog org Subject: Re: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s) On Fri, 13 May 2022 at 00:44, Jakob Heitz (jheitz) via NANOG <nanog () nanog org> wrote:RPKI-dropped-only Saves a copy of only the routes dropped by an RPKI validation-state test in neighbor-in route-policy. RPKI-tested-only Saves a copy of only the routes tested in an RPKI validation-state test in neighbor-in route-policy.What does this mean? If any term refers to validation-state, the route gets stored? Eg. if validation-state is valid then pass else drop a) Would 'RPKI-dropped-only' store everything or nothing? b) Would 'RPKI-tested-only' store everything? -- ++ytti
-- ++ytti
Current thread:
- RE: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s) Jakob Heitz (jheitz) via NANOG (May 12)
- Re: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s) Mark Tinka (May 12)
- Re: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s) Saku Ytti (May 13)
- RE: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s) Jakob Heitz (jheitz) via NANOG (May 13)
- Re: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s) Mark Tinka (May 13)
- Re: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s) Saku Ytti (May 14)
- RE: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s) Jakob Heitz (jheitz) via NANOG (May 15)
- Re: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s) Hank Nussbacher (May 14)
- Re: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s) Nick Hilliard (May 14)
- Re: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s) Max Tulyev (May 24)
- Re: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s) Saku Ytti (May 24)
- RE: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s) Jakob Heitz (jheitz) via NANOG (May 13)
- Re: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s) Randy Bush (May 14)
- <Possible follow-ups>
- RE: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s) Jakob Heitz (jheitz) via NANOG (May 24)
- Re: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s) Geoff Huston (May 24)