[c-nsp] IOS-XR BGP RR MCID (Multiple Cluster ID)

[adamv0025 at netconsultings.com]

Oh I see that makes sense, if all your revenue is in Internet services then of course it’s hard to justify building separate iBGP infrastructure to protect the handful of pure VPN customers.  

 

With regards to ORR, are you using add-path already or RRs are doing all the path selection on behalf of clients please?

 

adam  

 

netconsultings.com

::carrier-class solutions for the telecommunications industry::

 

From: Mark Tinka [mailto:mark.tinka at seacom.mu] 
Sent: Monday, March 12, 2018 2:41 PM
To: adamv0025 at netconsultings.com; 'Job Snijders'
Cc: 'Curtis Piehler'; 'Cisco Network Service Providers'
Subject: Re: [c-nsp] IOS-XR BGP RR MCID (Multiple Cluster ID)

 

 

On 12/Mar/18 13:02, adamv0025 at netconsultings.com <mailto:adamv0025 at netconsultings.com>  wrote:

If RR1s and RR2s never talk to each to each other then it doesn't matter
whether they have common or unique Cluster-IDs


Agreed. But in our case, they do.





Job is right, you should at least use separate TCP sessions for different
AFs,


Which BGP Session/Policy templates lend themselves naturally to, already.





 but if you have Internet prefixes carried by VMPv4 then you're still at
danger, unless you carve up a separate BGP process or iBGP infrastructure
for Internet prefixes, yes the BGP Attribute Filter and Enhanced Attribute
Error Handling should keep you relatively safe but I wouldn't count on it
(it's still not an RFC and I haven't dig into it for years so not sure where
are vendors at with addressing all the requirements in the draft).


We don't do Internet in a VRF. 





 
Internet is a wild west with universities advertising unknown attributes and
operators prepending their AS 255+ times and you can only hope that any of
such events will bring your border PE sessions down and actually won't be
relied to your RRs which then start dropping sessions to all clients or
restarting BGP/RPD processes...
Hence my requirement for dedicated iBGP infrastructure for Internet
prefixes.     


Our main business is regular Internet. VPNv4/VPNv6 accounts for not even a rounding error in % terms on our network.

That said, it is useful to run as late as you possibly can code on your edge routers and RR's to protect yourself against dodgy attributes or unexpected NLRI behaviour.






One fact that people usually overlook with ORR in MPLS backbones is that ORR
actually requires prefixes to be the same when they arrive at the RRs so RRs
can ORR on the best and second best to a particular set of clients. 
And my experience is that usually operators are using Type 1 RDs in their
backbones (so PE's-RID:VPN-ID format) -a that was the only way how to get
ECMP or BGP-PIC/local-repair working ages before Add-Path got introduced.
And in case of Type 1 RDs the ORR is useless as RRs in this case are merely
reflecting routes and are not performing any path selection on behalf of
clients.
So the only way how to make use of ORR is to completely change your RD plan
to Type 0 RDs VPN by VPN (maybe starting with Internet VRF) and introduce
add-path as a prerequisite of course. 


We don't run Internet in a VRF, so shouldn't have that concern.

As soon as ORR is available on the CSR1000v, I'll provide some feedback on its performance in our scenario.

Mark.