[j-nsp] [c-nsp] BGP-ORR Scaling on vRR

[adamv0025 at netconsultings.com]

> Dhamija Amit via cisco-nsp
> Sent: Friday, April 28, 2017 3:55 PM
> 
>   Hi
> I am testing  the feature BGP-ORR to have a centralized Route 
> Reflectors in our network.
> The feature works well and it ensures optimal routing to the nearest
clients.
> I have some concerns on the scaling of this feature, with around 150 
> ORR Clients/Groups in one RR and with scale of Internet Prefixes
> 
> around 650K Prefixes with 10M Paths it takes around hours to converge 
> the prefixes to the rest of the client routers.
That's way too long I think, what CPU/RAM/vRR are you using? 

> I understand vRR should perform best path computation per update-group 
> and each ORR client is one update group, so with around 150 update 
> groups each prefix needs to be updated per group.
Depends.   
If the update groups are based on egress policy commonalities and PEs in a
given POP (behind same couple of CRs) would share a common view, the you
have one update group per POP.   
So I think it actually depends on BGP implementation and your backbone
topology. 

> Can someone give insights on how many ORR clients do we need to 
> configure in one vRR to have optimal convergence in network.
>
Again, depends on the CPU/RAM/vRR you're using and what is an acceptable BGP
convergence time for you (if you're using PIC you don't care much about the
BGP convergence time -other than for how long you need to hold stale labels
for -which in your case would be for around hours , as opposed to usual
minutes:) ). 


adam

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