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 problem (if client / client packets are going thru the reflector, then reflector's decition makes more sense). Do not forget that routing must be consistant - different nodes can not use very different alghoritms to select routes (else you will have routing loops easily), so problem is not so strong as it seems initially. You can always add direct iBGP connections between 2 RR clients, if they have direct IP connection and you suspect suboptimal routing thru RR's. If we want to continue (I am not 100% sure in this problem), let's drow pictures first.
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 this decision is based on eBGP-learned information such as the AS path this doesn't matter because all routers in the AS would make the same decision anyway, but if the IGP metric comes into play (which invariably happens in large networks) then all the reflector clients only see the route that is best based on the IGP metrics the reflector sees.
(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 now takes a different path than the reflector client thought it would take.)