[j-nsp] router reflector clients and non-clients

[adamv0025 at netconsultings.com]

> From: Alexander Marhold [mailto:alexander.marhold at gmx.at]
> Sent: Wednesday, May 30, 2018 8:42 AM
> 
> >Instead you should not even connect RR1 and RR2 together And treat RR
> >infrastructure built from RR1s I their respective clusters as
> a
> >separate infrastructure to RR2s.
> >This is the proper way
> 
> NO,NO,NO
> This was the proper way in 1995, but not actual as...
> (Unfortunately most BGP books have been written at that time and are still
> sold...)
> 
> Never do this as it can lead to missing routing updates if a client A is
> connected to RR-1 only and Client B connected to RR-2 only ( because of
link
> outages) then A does not get the routes from B and vice versa
> 
> Therefore---- make each RR with a unique cluster-id ( recommended
> identical to router-id ) and then you can either make a normal ibgp
> connection between both RRs or each one is the client of the other one
> 
> There are nice explanations on the Internet backing me up ( Ivan Peplnjak,
> http://packetpushers.net/bgp-rr-design-part-1/
> http://orhanergun.net/2015/02/bgp-route-reflector-clusters/
> )
> 
Well unfortunately Ivan got couple details not quite right in the article
you referenced.
4. RRs per service (dedicated clusters for Internet) is mainly for security
purposes, flexibility/scalability is just a by-product.

The example Acme ISP has OOB-RRs and consist of 100 of core routers (2 CRs
per POP) -now what are the odds of one PE loosing session to RR1 while other
PE loosing session to RR2 -if these BGP TCP/IP sessions can be rerouted
across any of the 100s of core links -other than on purpose i.e. someone
shutting down the sessions in a particular order?
 
Also in large networks like these there's the topology based RRs with
multiple clusters interconnected (full mesh of RR1s and full mesh of RR2s)
and usually networks of these sizes carry several millions of prefixes and
there's a real scaling risk in duplicating that state on each of the RRs -by
letting them exchange prefixes with each other. (at least that's my own
experience dealing with bug SP networks). 

adam

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