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

[adamv0025 at netconsultings.com]

> Curtis Piehler
> Sent: Saturday, March 03, 2018 3:51 AM
> 
> I presume this is supported in IOS-XR but just making sure.
> 
> A network across the country is split up into multiple regions.  Each
region
> housing two RRs where the local region clients peer with them.
> Instead of full meshing all of the regional RR consider a tiered topology.
> 3-4 of the regional RR are designated Super-RR where they full mesh with
> each other on a global cluster ID.  The rest of the regional RR peer with
each
> of the Super-RR and with each other for regions with no super-RR.
> 
> The Super-RR areconfigured for the global cluster ID The Regional-RR are
> configured for the regional cluster ID The Super-RR also peer with the
> regional clients on a per neighbor cluster ID basis for the local region
(set for
> the Regional cluster ID) The Regional-RR peer with the Super RR on a per
> neighbor cluster ID (set for the Global cluster ID)
> 
> The Super-RR end up straddling the fence between the global cluster ID and
> the regional cluster ID The redundant Regional RR also end up straddling
the
> fence between the global cluster ID and the regional cluster ID but it's
main
> purpose is to be a redundant RR within the region The local region clients
> peer with the Super-RR in that region and also with the redundant regional
> RR.
> 
No, hierarchical RR infrastructure is a bad idea altogether. It was not
needed way back with c7200 as RRs in Tier1 SPs backbones and its certainly
not needed now.  
Just keep it simple. 
You don't need full mesh between all your regional RRs. 

Think of it as two separate iBGP infrastructures: 
1) 
Clients within a region peer with a particular Regional-RR-1 (to disseminate
prefixes within a single region). 
And all Regional-RR-1s peer with each other, i.e. full-mesh between RR-1s
(to disseminate prefixes between all regions). 
2) 
A completely separate infrastructure using the same model as the above, just
built using Regional-RR-2s (this is for redundancy purposes). 


If you run out of memory or CPU cycles on RRs, then I'd say migrate to vRR
solution.
Or if you insist on physical boxes (or don't want to have all eggs in one
basket -region wise), then you can scale out by dividing regions into
smaller pieces (addressing CPU/Session limit per RR) and by adding planes to
the above simple 1) and 2) infrastructure (addressing memory/prefix limit
per RR).  


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). 


adam

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