[nsp] route-reflector setup questoins

[Lucas Iglesias]

I completelly agree with that, and let me add something:
As I see in the layout, Router C is a normal IBGP router as well as the
other internal routers (not shown in the layout), so there is actually no
need of making it or any of them RR-Clients of Router B (since they are
fully mesh).
If you make RouterA a RR-Client of router B should work. 

Regards, luckas. 

-----Mensaje original-----
De: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net]En nombre de
Even_Glemmestad at Dell.com
Enviado el: Miércoles, 19 de Mayo de 2004 02:44 p.m.
Para: danny at tcb.net; cisco-nsp at puck.nether.net
Asunto: RE: [nsp] route-reflector setup questoins


I agree. With the current physical layout, I would recomend to keep it
simple.
Fully mesh all routers except RouterA (as per today), and set up RouterA
as the RR-client of RouterB.
Why? Because what will the value of RR'ing from RouterC to RouterA, if
RouterB goes down (or the link between RouterA and RouterB)? If RouterB
is down you cannot get updates from RouterC to RouterA anyway, so there
would be no real redundancy.

Rgds // Even G

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net]On Behalf Of Danny McPherson
Sent: 19. mai 2004 04:33
To: 'cisco-nsp at puck.nether.net'
Subject: Re: [nsp] route-reflector setup questoins



On May 18, 2004, at 1:39 PM, matthew zeier wrote:
>
> RouterB:
> router bgp 65444
>  bgp cluster-id 65444
>  nei RouterA route-reflector-client
>  nei RouterC ...
>  <other ibgp peers>
>
> RouterC:
> router bgp 65444
>  bgp cluster-id 65444
>  nei RouterB ...
>  <other ibgp peers>
>
> RouterA:
> router bgp 65444
>  nei RouterB ...

RouterB is probably passing (reflecting) the routes learned from RouterA
to RouterC, the problem is likely that RouterC is discarding the routes
per the cluster ID value 65444 contained in the received cluster list
from the reflected routes matches that of the locally configured cluster
ID value.

I see no reason why C has a configured cluster ID at all.  In the
configuration you've got why not just make RouterA & RouterC clients of
RouterB (i.e, RouterB defines RouterC & RouterA as clients and no 
additional
configuration is required on RouterA or RouterC beyond setting up the
normal IBGP stuff) and do the "default" client-to-client reflection, 
with all
the routers comprising a single cluster?

So long as the topology remains as illustrated in your diagram RouterB 
is
no more of a single point of failure than physical topology dictates.
Alternatively, fully IBGP mesh all the routers without route reflection 
or
disable client-to-client reflection and configure a normal IBGP peering 
session
between RouterA & RouterC (i.e., have a full mesh of peering between
clients).

If you've only got one route reflector you could remove the "bgp
cluster-id ..." statements from all routers and employ the default "use
Router ID as cluster ID" behavior and that'd fix the problem as well.

If at some point you have more than one route reflector for a single
cluster I like the inherent path compression provided by using the same
cluster ID on all the route reflectors and a client base that's fully
meshed with all the route reflectors for the cluster, with 
client-to-client
reflection to reduce the number of available BGP paths further.

HTH,

-danny

_______________________________________________
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/

_______________________________________________
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/