[nsp] route-reflector setup questoins
Danny McPherson
danny at tcb.net
Tue May 18 23:33:11 EDT 2004
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
More information about the cisco-nsp
mailing list