Hi All, So the idea of having a RR is to avoid having full mesh between ALL iBGP routers (as already mentioned)...and this stems from the way BGP operates: BGP rule says it will not readvertise any prefix learned from another BGP peer in same AS (iBGP).
The reason for 2 or more RRs is for redundancy. If your lone RR fails your whole network will die...doesn't matter if this is in forwarding path or not. And, in some weird scenario (several link failures perhaps...) where one RR-client is only connected to RR1 and another RR-Client is only connected to RR2 you will lose connectivity if the RRs are not peered... So you can either peer them as per normal fashion or create them as RR-clients for each other as well.... My 2c for tonight... Ciao JC -----Original Message----- From: cisco-nsp [mailto:[email protected]] On Behalf Of Cydon Satyr Sent: Monday, April 07, 2014 10:03 PM To: [email protected] Cc: [email protected] Subject: Re: [c-nsp] Peering between route reflectors Guys, Thanks all for quick reply. When I asked the question I was following an idea where ALL PE routers peer with EACH RR. Because in any other case, my question wouldn't make sense. So with this in mind, if all PE routers peer with ALL RR, why should RRs peer between themselves, IF none of RRs are in forwarding path? Regards On Mon, Apr 7, 2014 at 9:54 PM, Mark Tinka <[email protected]> wrote: > On Monday, April 07, 2014 09:43:05 PM Lee Clark wrote: > > > Without the RR/RR peering there is no way to propagate routes > > between clients A and B. Peering both clients to both RRs that would > > solve the problem but is not scalable in a large network where there > > are many RRs and significant # of clients. > > Agree that having 2x iBGP sessions per client scales poorer than one, > but it scales better than a full mesh between routers, which is the > problem route reflectors solve. > > As you rightly point out, YMMV, but from where I'm standing, 2x iBGP > sessions per client to 2x different route reflectors is fine for us. > It's a reasonable compromise between redundancy and administration. > > Mar. > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
