Are you sure? RR should just distribute routes.
RR do not make any route decisions, and (btw) iBGP do not make route
decisions - they are mostly based on IGP routing. All iBGP + RR are doing
is:
- tie external routes to internal IP;
- distribute this information using iBGP mesh, RR's etc.
-
On 12-jan-05, at 9:06, Alexei Roudnev wrote:
Are you sure? RR should just distribute routes.
RR do not make any route decisions, and (btw) iBGP do not make route
decisions - they are mostly based on IGP routing.
Route reflectors only propagate their idea of the best route for a
destination. If
--- Alexei Roudnev [EMAIL PROTECTED] wrote:
Are you sure? RR should just distribute routes.
RR do not make any route decisions, and (btw) iBGP
do not make route
decisions - they are mostly based on IGP routing.
All iBGP + RR are doing
is:
- tie external routes to internal IP;
-
On Wed, 2005-01-12 at 12:20, Iljitsch van Beijnum wrote:
(Obviously the IGP metric will be different at the client, but the
client doesn't see the other routes, so it can't make a different
decision. The real fun starts when the next (intra-AS) hop isn't a
reflector client and the packet
It is correct more or less (I prefer to say that RR reflects only the best
routes... through I am not sure, is it
theoretical limitation or just implementation - RR can in theory reflect ALL
routes).
Anyway, usual usage of RR is _RR on backbone, and clients in the branches_,
which eliminate this
On Tue, 2005-01-11 at 02:03, Eric Kagan wrote:
Does anyone have any input on when this does make sense ? We have 3 Main IP
pops with upstream BGP at each and 4 internal BGP sessions. I am looking to
add 2 new routers so there will be about 7 sessions on each border router.
This seems to
Hi Eric,
Eric Kagan said the following on 11/01/2005 11:03:
Correct, route reflector's main advantage is scalability and
if you're thinking to evolve into a larger network with
dedicated access and core routers, route reflectors are a far
better option than full mesh, though perhaps not from
On Tue, Jan 11, 2005 at 09:51:36PM +1000, Philip Smith wrote:
Many of the ISPs I've worked with around the world have followed this
path - and they are quite happy. I really think there is absolutely no
need to consider full mesh iBGP any more. I wouldn't go as far as saying
it's history,
On Tue, 2005-01-11 at 13:09, Daniel Roesen wrote:
One of the main problems of route reflection is that the best path
decision is done centrally. The best route is not seen as from the
router making the forwarding decision, but from the route reflector's
point of view. Depending on network
On 11-jan-05, at 12:51, Philip Smith wrote:
Well, my preference is to start with route reflectors pretty much from
day one. Let's face it, one day you will have to migrate that full
mesh iBGP to route reflector. Why do the work of migration when you
can start off at the beginning using route
Correct, route reflector's main advantage is scalability and
if you're thinking to evolve into a larger network with
dedicated access and core routers, route reflectors are a far
better option than full mesh, though perhaps not from the start.
Does anyone have any input on when this does
hello,
I have a ibgp question?
There is a Diagram at http://erik.appscorp.net/bgp/
Which Setup is better, the Router Reflector or the ibgp meshed?
What are the positive and negitive to each setup.
Which Setup is commonly used / best pratice / More stable
Diagram at
On Sat, 2005-01-08 at 00:20, Robert Crowe wrote:
Yes, an iBGP session is possible between A C. Route Reflectors
main purpose was to reduce the iBGP full mesh requirement, thus
providing for BGP scalability. If you only have 3 BGP speakers then
there is no need, unless you are expecting
13 matches
Mail list logo
