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

[adamv0025 at netconsultings.com]

> Job Snijders [mailto:job at ntt.net]
> Sent: Sunday, March 11, 2018 10:51 AM
> 
> On Sun, Mar 11, 2018 at 12:39:13PM +0200, Mark Tinka wrote:
> > Each major PoP has been configured with its unique, global Cluster-ID.
> >
> > This has been scaling very well for us.
> >
> > I think the Multiple Cluster-ID is overkill.
> 
> Have you considered the downsides of sharing a Cluster-ID across multiple
> boxes, and do you have any arguments to support why it is overkill?
> 
If RR1s and RR2s never talk to each to each other then it doesn't matter
whether they have common or unique Cluster-IDs
 
> > > Also if you carry a mix of full internet prefixes and VPN prefixes
> > > across your backbone, then I suggest you carve up one iBGP
> > > infrastructure for VPN prefixes and a separate one for the Internet
> > > prefixes (for stability and security reasons -and helps with scaling
> > > too if that's a concern).
> >
> > We use the same RR for all address families. Resources are plenty with
> > a VM-based RR deployment.
> 
> Are you at least using separate BGP sessions for each address families?
> 
Job is right, you should at least use separate TCP sessions for different
AFs, 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).
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.     

> > The RR's are out-of-path, so are not part of our IP/MPLS data plane.
> 
> Are you using optimal route reflection, or how have you mitigated negative
> effects caused by the lack of ORR?
> 
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. 


adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::