[c-nsp] Peering between route reflectors
JC Cockburn
ccie15385 at gmail.com
Mon Apr 7 16:37:29 EDT 2014
Hi,
What about building RR trees...
Parent RRs serving some child RRs?
I think I heard something like this sometime...
Ciao
JC
-----Original Message-----
From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Lee
Clark
Sent: Monday, April 07, 2014 10:12 PM
To: mark.tinka at seacom.mu; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Peering between route reflectors
For sure, minimum 2 sessions to 2 different RRs per client. I may have
over-simplified the example to show why the IBGP session between RRs is
needed. A more realistic example would have been 10 RRs, 100s of clients. In
that case peering each client with all 10 RRs in the absence of an RR full
mesh wouldn't be scalable.
Lee
-----Original Message-----
From: Mark Tinka [mailto:mark.tinka at seacom.mu]
Sent: Monday, April 07, 2014 1:54 PM
To: cisco-nsp at puck.nether.net
Cc: Lee Clark; Cydon Satyr
Subject: Re: [c-nsp] Peering between route reflectors
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 cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
More information about the cisco-nsp
mailing list