[c-nsp] Peering between route reflectors

[JC Cockburn]

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/