|
<- Previous Message | Next Message -> Thread Index [isp-bgp] Re: Zebra as Route Reflector
Pedro, From: "Pedro R Marques" <roque@...> > Possible it is. > It is also possible to mess it up :-) And i just wanted to point that > out. For instance if the IGP distances above all are the same, the RR > will perform path selection based on say router-id... However if B is > closer to C than to A (that is how i interpret your diagram) this may > not be the desired result. Right. Not only this. YOu could have A and B equidistant from C. In that C would want to split the load across A and B. > > I guess the answer to your question depends on topology, metrics, etc. > > > This is then a limitation of the RR. Shouldn't we be addressing it? Lately there have been some > > proposals in the IETF to advertise multiple BGP routes. Will that not help here? > > The original purpose of RRs is to aggregate routing information. If you > do not aggregate information (via selecting a subset of available > paths), then you defeat the purpose. I think and i still hold my opinion that RRs are used (mostly) for reducing the total mesh. Yes, i have seen several 100s of routers in IBGP mesh and i know the pain involved in configuring, maintaining and debugging them if something/anything goes wrong. > > In reality, it seems to me that often people use reflection more as a > configuration aid. But that is probably the wrong tool for the job. I knew this was coming. Well not really, but yes it does definitely help when you have a core of 50+ routers (which is a very modest number!) > > It was originally thought that the number of TCP sessions in a mesh > could be a problem. My opinion is that this is not really an issue. iBGP > meshes w/ several hundreds of routes work just fine. I beg to differ on this one. I would like to know what others feel on this issue. If you need RRs to only do you aggregation then i think one can use the 'aggregate' command pretty well. The problem in assuming that RRs will be used for what you advocate is that you need to ensure that the RR then lies in your forwarding path - thereby putting some severe network design constraints! > > One could think of a route reflector-like box that doesn't always > advertise just one path and doesn't always advertise all. > But that is a very significant change from the current model. There is nothing which says that we should not be looking at something which is significantaly different from existing current models. How else do you want to evolve? Just my $0.2 Rasputin ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca ------------------------ANNOUNCEMENT--------------------------------- --------------------------------------------------------------------- ISPCON FALL 2003 - Santa Clara Convention Center October 20-22 - The Definitive Event Wired and Wireless ISPs www.ispcon.com ---------------------------------------------------------------------- ----------------------------------------------------------------------
Thread Index |