Re: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s)
> On 25 May 2022, at 5:45 am, Jakob Heitz (jheitz) via NANOG > wrote: > > This attack will work very well until the victim starts advertising > its prefix. The victim may not notice the fake advertisement because the fake > advertisement will not reach the victim AS due to AS-path loop checking. Often the best forms of attack are ones that are scoped in locality. Advertising the same prefix from a different location in BGP may create a localised preference to follow the synthesised route which is not visible everywhere. Sometimes this is exactly what the attacker wants to achieve. Geoff
RE: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s)
This attack will work very well until the victim starts advertising its prefix. The victim may not notice the fake advertisement because the fake advertisement will not reach the victim AS due to AS-path loop checking. So potential victims must advertise all prefixes that they register in RPKI or subscribe to an Internet monitoring service to detect the fake advertisements. And don't forget maxlen. You must advertise in BGP every prefix covered by maxlen. Regards, Jakob. -Original Message- From: Saku Ytti On Tue, 24 May 2022 at 11:23, Max Tulyev wrote: > To make a working hijack of the routed prefix (for sniffing traffic, > DDoS or something similar), you have to announce a more specific > prefix(es). It can be denied by RPKI. > > If you signed RPKI prefix is still unannounced - yes, somebody can > hijack it by forging the origin ASN - that's quite easy. This axiomatically assumes first come, first serve, which is obviously not complete understanding of BGP best path algorithm. -- ++ytti
Re: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s)
On Tue, 24 May 2022 at 11:23, Max Tulyev wrote: > To make a working hijack of the routed prefix (for sniffing traffic, > DDoS or something similar), you have to announce a more specific > prefix(es). It can be denied by RPKI. > > If you signed RPKI prefix is still unannounced - yes, somebody can > hijack it by forging the origin ASN - that's quite easy. This axiomatically assumes first come, first serve, which is obviously not complete understanding of BGP best path algorithm. -- ++ytti
Re: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s)
15.05.22 00:19, Nick Hilliard пише: a malicious actor will spoof the origin AS. The aim of RPKI to help stop mis-origination of prefixes, and the root cause of most of this is accidental. To make a working hijack of the routed prefix (for sniffing traffic, DDoS or something similar), you have to announce a more specific prefix(es). It can be denied by RPKI. If you signed RPKI prefix is still unannounced - yes, somebody can hijack it by forging the origin ASN - that's quite easy.
RE: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s)
Saku, You have two questions. I'll address the second one first. Beginning in IOS-XR 7.3.1, there is a new O(log n) scalable way to test for autonomous system numbers (ASN) in route-policy. ASNs can be grouped into an as-set as follows: as-set foo 64496, 64497 end-set ! route-policy bar if not as-path originates-from foo then drop endif pass end-policy The first question: If you use several tests in your route-policy and put the validation-state test last, then any route that gets dropped before the validation-state test is reached will not be saved with "soft-reconfiguration inbound RPKI-tested-only". For example: route-policy bar if not as-path originates-from foo then drop endif if validation-state is invalid then drop endif pass end-policy Regards, Jakob. -Original Message- From: Saku Ytti Sent: Saturday, May 14, 2022 12:09 AM To: Jakob Heitz (jheitz) Cc: nanog@nanog.org Subject: Re: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s) On Sat, 14 May 2022 at 00:17, Jakob Heitz (jheitz) 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 > Sent: Friday, May 13, 2022 12:36 AM > To: Jakob Heitz (jheitz) > 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 > 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
Re: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s)
> In the end, the reason for all this RPKI-thingy is to prevent route > spoofing by malicious actors. sigh. for my quarterly posting of the same many year old text To be clear, as people keep calling BGP security 'RPKI', RPKI The RPKI is an X.509 based hierarchy [RFC 6481] which is congruent with the internet IP address allocation administration, the IANA, RIRs, ISPs, ... It is just a database, but is the substrate on which the next two mechanisms are based. It is currently deployed in all five administrative regions. RPKI-based Origin Validation (ROV) RPKI-based Origin Validation [RFC 6811] uses some of the RPKI data to allow a router to verify that the autonomous system originating an IP address prefix is in fact authorized to do so. This is not crypto checked so can be violated. But it should prevent the vast majority of accidental 'hijackings' on the internet today, e.g. the famous Pakistani accidental announcement of YouTube's address space. RPKI-based origin validation is in shipping code from AlcaLu, Cisco, Juniper, and possibly others. BGPsec RPKI-based Path Validation, AKA BGPsec, a future technology still being designed [draft-ietf-sidr-bgpsec-overview], uses the full crypto information of the RPKI to make up for the embarrassing mistake that, like much of the internet BGP was designed with no thought to securing the BGP protocol itself from being gamed/violated. It allows a receiver of a BGP announcement to cryptographically validate that the autonomous systems through which the announcement passed were indeed those which the sender/forwarder at each hop intended. Sorry to drone on, but these three really need to be differentiated.
Re: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s)
Hank Nussbacher wrote on 14/05/2022 19:15: In the end, the reason for all this RPKI-thingy is to prevent route spoofing by malicious actors. a malicious actor will spoof the origin AS. The aim of RPKI to help stop mis-origination of prefixes, and the root cause of most of this is accidental. Nick
Re: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s)
On 14/05/2022 00:16, Jakob Heitz (jheitz) via NANOG wrote: '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' Regards, Jakob. In the end, the reason for all this RPKI-thingy is to prevent route spoofing by malicious actors. It sure would be nice if someone from the top 20: https://asrank.caida.org/ would be able to have an auto-updated site that showed all RPKI dropped from their end. This would complement https://bgpstream.crosswork.cisco.com/ for those of us who want to know who is trying to hijack our routes at the core. Regards, Hank
Re: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s)
On Sat, 14 May 2022 at 00:17, Jakob Heitz (jheitz) 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 > Sent: Friday, May 13, 2022 12:36 AM > To: Jakob Heitz (jheitz) > 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 > 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
Re: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s)
On 5/13/22 23:16, Jakob Heitz (jheitz) via NANOG wrote: '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. This option saves memory if you use a coarse filter in the route-policy before the validation test. For example, you use a peer-locking filter to drop peer routes from your customers before they hit the validation-state test. Then a massive route leak won't chew up soft-reconfiguration memory. If a validation-state test drops a route and that route is not stored by soft-reconfiguration, then when the RPKI server updates any VRP, the router needs to send a route-refresh request. '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' Jakob, thank you and your team for quickly implementing this. It is most appreciated. I hope someone from the IOS XE team is working on it, too :-). Mark.
RE: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s)
'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. This option saves memory if you use a coarse filter in the route-policy before the validation test. For example, you use a peer-locking filter to drop peer routes from your customers before they hit the validation-state test. Then a massive route leak won't chew up soft-reconfiguration memory. If a validation-state test drops a route and that route is not stored by soft-reconfiguration, then when the RPKI server updates any VRP, the router needs to send a route-refresh request. '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' Regards, Jakob. -Original Message- From: Saku Ytti Sent: Friday, May 13, 2022 12:36 AM To: Jakob Heitz (jheitz) 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 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
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 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
Re: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s)
On 5/12/22 23:40, Jakob Heitz (jheitz) via NANOG wrote: To address the risk of somebody exhausting your memory by dumping a ton of routes on you, we added two new options to "soft-reconfiguration inbound" in IOS-XR. 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. This was released in 7.3.1 in Feb 2021. The bug CSCwb17937 was fixed in 7.5.2, just released. Fixed a few other things in 7.5.2 also. Tomoya, apologies that you had a terrible time with it. Awesome! Mark.
RE: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s)
To address the risk of somebody exhausting your memory by dumping a ton of routes on you, we added two new options to "soft-reconfiguration inbound" in IOS-XR. 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. This was released in 7.3.1 in Feb 2021. The bug CSCwb17937 was fixed in 7.5.2, just released. Fixed a few other things in 7.5.2 also. Tomoya, apologies that you had a terrible time with it. Regards, Jakob. -Original Message- Date: Wed, 11 May 2022 14:31:28 -0700 From: Randy Bush To: Pirawat WATANAPONGSE via NANOG Subject: Re: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s) and upstream(s) Message-ID: Content-Type: text/plain; charset=US-ASCII > Is setting 'Soft Reconfiguration' enough for me to keep ROV running? yes, should be. > If not, is there any other solution? yes. jakob says he has implemented https://datatracker.ietf.org/doc/draft-ietf-sidrops-rov-no-rr/, though i do not known in what xr image(s) randy
Re: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s) and upstream(s)
> Is setting 'Soft Reconfiguration' enough for me to keep ROV running? yes, should be. > If not, is there any other solution? yes. jakob says he has implemented https://datatracker.ietf.org/doc/draft-ietf-sidrops-rov-no-rr/, though i do not known in what xr image(s) randy
Re: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s) and upstream(s)
Wed, May 11, 2022 at 09:36:36PM +0200, Lukas Tribus: > True and the amount of memory used per prefix also depends on things > like BGP communities. > > When I tested this, on 32 bit XR I had a memory increase of about 400 > MB for a full feed 2 years ago. it depends on the architechture, the variance in paths and attributes, and how much your policy alters those, what is being sent vs filtered, AND the number of peers and add-path, etc etc. eg: if your policy alters attributes, space for both the old and new attributes is needed. Whether you need 64bit depends on the total memory usage exceeding, iirc, 3.2GB.
Re: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s) and upstream(s)
On Wed, 11 May 2022 at 21:22, Grant Taylor via NANOG wrote: > > On 5/11/22 10:53 AM, Job Snijders via NANOG wrote: > > This knob slightly increase your own memory consumption, but makes your > > router more “neighbourly”! :-) > > I question how accurate "slightly" is. > > My understanding is that soft reconfiguration inbound (whatever the > syntax for a given IOS is) causes a full copy of the received prefix > list to be retained in memory for each of the peers with soft > reconfiguration enabled. > > So, to me, the amount of impact to memory will be based on both the > number of prefixes advertised and the number of peers that soft > reconfiguration is enabled on. > > Please enlighten me if I'm wrong / misunderstanding something. True and the amount of memory used per prefix also depends on things like BGP communities. When I tested this, on 32 bit XR I had a memory increase of about 400 MB for a full feed 2 years ago. But with or without soft-reconfig inbound always, your memory usage increases with more prefixes. I don't see any drastic change in scaling numbers because of this on today's HW. Lukas
Re: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s) and upstream(s)
On Wed, May 11, 2022 at 01:22:32PM -0600, Grant Taylor via NANOG wrote: > On 5/11/22 10:53 AM, Job Snijders via NANOG wrote: > > This knob slightly increase your own memory consumption, but makes your > > router more “neighbourly”! :-) > > I question how accurate "slightly" is. > > My understanding is that soft reconfiguration inbound (whatever the syntax > for a given IOS is) causes a full copy of the received prefix list to be > retained in memory for each of the peers with soft reconfiguration enabled. > > So, to me, the amount of impact to memory will be based on both the number > of prefixes advertised and the number of peers that soft reconfiguration is > enabled on. > > Please enlighten me if I'm wrong / misunderstanding something. How much memory exactly is consumed, will depend on the architecture of the application (whether duplicity of information such as path attributes is avoided as much as possible). Indeed, YMMV. >From experience at a previous employer I recall that 'soft-reconfiguration inbound' on routers (with multiple full routing tables) was problematic on 32-bit versions of the operating system; but not an issue on 64-bit. If unsure, test on a few peers and monitor memory usage! Its also a valid question to the Technical Assistance Center "hey, will enabling this soft-reconfiguration feature land me in hot water?" Kind regards, Job
Re: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s) and upstream(s)
On 5/11/22 10:53 AM, Job Snijders via NANOG wrote: This knob slightly increase your own memory consumption, but makes your router more “neighbourly”! :-) I question how accurate "slightly" is. My understanding is that soft reconfiguration inbound (whatever the syntax for a given IOS is) causes a full copy of the received prefix list to be retained in memory for each of the peers with soft reconfiguration enabled. So, to me, the amount of impact to memory will be based on both the number of prefixes advertised and the number of peers that soft reconfiguration is enabled on. Please enlighten me if I'm wrong / misunderstanding something. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
Re: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s) and upstream(s)
Wed, May 11, 2022 at 07:29:04PM +0200, Mark Tinka: > On 5/11/22 18:53, Job Snijders via NANOG wrote: > > In current versions I think enabling “soft-reconfiguration-inbound > > always” (also described at > > https://bgpfilterguide.nlnog.net/guides/reject_invalids/#cisco-ios-xr > > ) should be enough. > > > > Make sure to enable it on every EBGP peer you apply ROV to, or just > > all EBGP peers. > > > > This knob slightly increase your own memory consumption, but makes > > your router more “neighbourly”! :-) > > Just to add that this is useful on all eBGP speakers based on IOS XR. any IOS, not just XR.
Re: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s) and upstream(s)
Hi, If you are running "soft-reconfiguration inbound rpki-droppped-only" on IOS-XR7, please note CSCwb17937. We had a terrible time with this. Best regards, takez > 2022/05/12 1:43、Pirawat WATANAPONGSE via NANOG のメール: > > Dear Guru(s), > > > We used to run our ‘Gateway Router’ with ROV turned on. > Then, we “upgraded” it to a Cisco NCS-55A1 (5500 Series) running IOS-XR just > a few weeks ago. > > Consequently, during my rummage through Google for a (the?) best (ROV) > configuration template for the new router, > I found a tutorial by Philip Smith > [Reference: https://www.bgp4all.com/pfs/_media/workshops/02-rpki.pdf, Slide > #55] > which cautioned me of Cisco IOS-XR essentially “harassing” all peers and > upstreams with ‘Route Refresh’ whenever there is a VRP change. > The tutorial advised turning on ‘Soft Reconfiguration’ to help with the > problem. > > On the one hand, we have a very special relationship with our upstream > [they’re kind of community transit provider; we have an in-kind stake in them > as well], so we obviously don’t want to cause them grievances [their > grievance is our grievance]. > On the other hand, we can't afford to just throw away a newly bought gateway > and buy a new one. > > So, here goes the question: > Is setting 'Soft Reconfiguration' enough for me to keep ROV running? > If not, is there any other solution? > Or am I screwed anyway? > > I would very much appreciate clarification and pointer(s) to the solution(s). > > > Thank you in advance for the help, > > Pirawat. >
Re: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s) and upstream(s)
On 5/11/22 18:53, Job Snijders via NANOG wrote: Hi! In current versions I think enabling “soft-reconfiguration-inbound always” (also described at https://bgpfilterguide.nlnog.net/guides/reject_invalids/#cisco-ios-xr ) should be enough. Make sure to enable it on every EBGP peer you apply ROV to, or just all EBGP peers. This knob slightly increase your own memory consumption, but makes your router more “neighbourly”! :-) Just to add that this is useful on all eBGP speakers based on IOS XR. It's not required in Junos, because Junos does this implicitly. A draft RFC we co-authored attempts to offer a solution: https://www.ietf.org/archive/id/draft-ietf-sidrops-rov-no-rr-01.txt Mark.
Re: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s) and upstream(s)
Hi! In current versions I think enabling “soft-reconfiguration-inbound always” (also described at https://bgpfilterguide.nlnog.net/guides/reject_invalids/#cisco-ios-xr ) should be enough. Make sure to enable it on every EBGP peer you apply ROV to, or just all EBGP peers. This knob slightly increase your own memory consumption, but makes your router more “neighbourly”! :-) Kind regards, Job On Wed, 11 May 2022 at 18:44, Pirawat WATANAPONGSE via NANOG < nanog@nanog.org> wrote: > Dear Guru(s), > > > We used to run our ‘Gateway Router’ with ROV turned on. > Then, we “upgraded” it to a Cisco NCS-55A1 (5500 Series) running IOS-XR > just a few weeks ago. > > Consequently, during my rummage through Google for a (the?) best (ROV) > configuration template for the new router, > I found a tutorial by Philip Smith > [Reference: https://www.bgp4all.com/pfs/_media/workshops/02-rpki.pdf, > Slide #55] > which cautioned me of Cisco IOS-XR essentially “harassing” all peers and > upstreams with ‘Route Refresh’ whenever there is a VRP change. > The tutorial advised turning on ‘Soft Reconfiguration’ to help with the > problem. > > On the one hand, we have a very special relationship with our upstream > [they’re kind of community transit provider; we have an in-kind stake in > them as well], so we obviously don’t want to cause them grievances [their > grievance is our grievance]. > On the other hand, we can't afford to just throw away a newly bought > gateway and buy a new one. > > So, here goes the question: > Is setting 'Soft Reconfiguration' enough for me to keep ROV running? > If not, is there any other solution? > Or am I screwed anyway? > > I would very much appreciate clarification and pointer(s) to the > solution(s). > > > Thank you in advance for the help, > > Pirawat. > >
