From: omoruyi usuanlele (omo_u@xxxxxxxxx)
Date: Fri Jan 19 2001 - 20:45:41 GMT-3
Ronnie,
You are very correct, RR is required only in iBGP;
your analysis of the scenario is also correct but the
benefits of cluster IDs will NOT be clear in this
simple scenario.
Suppose we added another cluster to AS2, and a third
cluster, so we have 3 clusters and some other
non-client routers within this same AS, then cluster
IDs will be necessary. Duplicate updates will be
recieved by a router and by checking the 4-byte
cluster ID, it can ignore the update if it is from
it`s own cluster or accept if from a different
cluster.
You require a few more routers ( the real world has
more than 6 routers :) ) to test this successfully,
but take another look at the CCO - BGP case studies 4,
the explanation is clear enough.
http://www.cisco.com/warp/public/459/16.html
Rgds// Omoruyi
--- Ronnie Royston <RonnieR@globaldatasys.com> wrote:
> Route reflectors are an add on to BGP to address the
> issue of iBGP peering
> sessions. What do they have to do with eBGP, i.e.,
> RR servers and clients
> are always going to be in the same AS, right?
>
> backbone router
> \ AS 1
> - - -\ - - - - - - - - - - - - -
> R1-------R2 AS 2
> \ |
> \ |
> R3----R4
>
> Can't I simply configure R2 and R3 to RR for R4 with
> no cluster ID's in the
> configs? If R3 fails to reflect, R2 keeps on
> reflecting. Assuming I put a
> next-hop-self on R1 for R2 and R3, R4 would see the
> BB routes as having a
> next hop of R1, and ping would be successful. Can
> someone explain when I
> would ever use clusters?
>
> -----Original Message-----
> From: omoruyi usuanlele [mailto:omo_u@yahoo.com]
> Sent: Friday, January 19, 2001 1:06 PM
> To: Padhu (LFG); 'ccielab@groupstudy.com'
> Subject: Re: Technical questions - BGP - QOS etc
>
>
> Hi Padhu,
>
> 1. Route Reflectors - I believe you are right in
> your
> interpretation of that ..... the cluster ID should
> be
> the same within the same AS.
>
> 2. Client-to-Client Reflection: I also will like to
> know why but I suppose that`s how it works -
> probably
> for added flexibility. I agree that this defeats the
> initial purpose of using RR (i.e scalabe and NOT
> meshed)... will appreciate thoughts from others.
>
> 3. GTS - In addition to the CD, check out the below
> link from Dr Peter Welcher :
>
>
http://www.mentortech.com/learn/welcher/papers/qos3.html
>
> Try out some GTS configuration on your own and
> monitor
> the results using the SHOW TRAFFIC-SHAPE command,
> that
> will also help you get abetter feel of this feature.
>
> Cheers n Goodluck // Omoruyi
> --- "Padhu (LFG)" <padhu@steinroe.com> wrote:
> > ...Let me see if the subject draws any attention
> or
> > the scope of the list
> > has changed ... -)
> >
> > 1. Route Reflectors - Is my understanding that
> > within a AS if i have
> > multiple RR Servers
> > peering each other, then the cluster ID has to
> be
> > the same is correct ?
> >
> > 2. From Halabi - The RR Clients should not be
> fully
> > meshed ...( makes sense
> > )...however if they are
> > then Client to client reflection should be
> > disabled on the RR server
> > ...Here is my confusion...
> > If clients are fully meshed why configure RR in
> > the first place and then
> > disable client to client
> > reflection ?
> >
> > 3. I have searched all over CCO for info on GTS
> > trying to understand that
> > math part of understanding the
> > sampling intervals etc to no avail...anyone can
> > point me to some white
> > papers or something ..The doc
> > CD has one example on the ethernet ...
> >
> > Appreciate any inputs .
> >
> > Cheers,Padhu
> >
> >
>
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:27:36 GMT-3