> From: Alexander Marhold [mailto:alexander.marh...@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:: _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp