From: Volkov, Dmitry (Toronto - BCE) (dmitry_volkov@xxxxxxxxx)
Date: Tue Aug 27 2002 - 00:48:11 GMT-3
Peter,
<<have you stopped
and wondered exactly what problem using the two techniques together would
solve?
Yes ;) that we understand - what purposes do Sync (blackholing prevent) and
RR (loop avoid and full mesh scalling issues) serve (Thanks Doyle and
Halabi),
unfortunatelly I have lack of large scale real world experience..
And what is happenning in real world is not so clear.
Thanks to H.Berkowitz who pointed to some "real world" books..
So what is happenning in real world shortly ? :
Full PHYSICAL IBGP mesh , RRs, Confeds and IGP serves only propagations of
next-hops and
link routes between BGP peers ??
Dmitry
-----Original Message-----
From: Peter van Oene [mailto:pvo@usermail.com]
Sent: Monday, August 26, 2002 10:50 PM
To: ccielab@groupstudy.com
Subject: Re: Route Reflector/Sync
Synchronization has been obsolete for almost a decade. It is not supposed,
nor was ever supposed to work with route reflection. These are orthogonal
topics. How it does perform is likely more a matter a coding
fortune/misfortune rather than desired effect.
This has got to be my number one pet peeve topic and really goes to the
negative side of any cert program. People get way to focused on arcane,
core case issues and completely lose site of the real world
implication. For example, when trying to figure this out, have you stopped
and wondered exactly what problem using the two techniques together would
solve? Even one step back you'd realize that synchronization attempts to
prevent blackholing in non IBGP meshed networks whereas route reflection
ameliorates scaling issues in full mesh IBGP networks. That is to say they
are designed for use in completely different networks. Furthermore, IGPs
cannot handle transit style Internet feeds anyway, nor have they been able
to for quite some time so the use or otherwise of synchronization is a moot
point anyway.
I expect you are just prepping for a test and trying to cover all the
angles and I've had a rather challenging day and should likely just drink
some beer and ignore these threads :-)
At 07:55 PM 8/26/2002 -0400, George Spahl wrote:
>Greetings,
>
>This is similar to Dmitry's thread, but more general since it doesn't
>involve the OSPF vs. BGP router id (I don't think!), however I think it
>may be the same problem. I don't know why I haven't noticed this
>before, but when a prefix is being reflected by a RR from one RR client
>to the next RR client and the prefix isn't synchronized on the RR is it
>forbidden for it to reflect it?
>
>For example, R1 is the RR, R2 and R3 are the RR clients. A prefix is
>added to R2 with a "network" statement (and no other routing protocol
>carries this route). R2 sends it to the route reflector who refuses to
>reflect it to R3 since it's not "synchronized" on the RR. Is this
>normal or is there something else going on here?
>
>It seems like that since Route Reflection in general is supposed to
>substitute for an IBGP full mesh that even though it may not be
>"synchronized" on the RR, the RR should still reflect it to other RR
>clients, even if he doesn't enter it into his own ip routing table,
>since this is what would happen if it were an IBGP full mesh anyway. At
>least, I would think that's how you would want it to work. If this is
>really the way it works does anyone have an idea why they would want to
>work this way?
>
>By the way, this is from the interesting lab that Brian McGahan put out
>on the list for us. It's the basic BGP setup, section F.1 and F.2.
>
>Thanks,
>
>George
This archive was generated by hypermail 2.1.4 : Sat Sep 07 2002 - 19:48:39 GMT-3