Ok. I'm even more confused now. So you guys are saying that IBGP peers will never
progragated its route to other IBGP peers by "no synchronization" - if no IGP is
running, except by Route Reflectors?? So what's "no synchronization" used for?
I have one more question: Is it true that routes injected into BGP within an AS carry
a
next hop attribute of the BGP router that first advertised the route? Please explain.
Regards,
Hunt Lee
Howard C. Berkowitz wrote:
> >No worries John. It was I who mentioned the devious nature of
> >classless and synch as well :)
>
> Always remember that the best ISPs have no class.
>
> >
> >Keep in mind that synch was designed for transit networks that have
> >transit providing routers which do not run BGP. Back when the
> >internet was smaller I expect some designs had the IGP in an AS
> >carry the full table, or parts of it and hence it was relevant to
> >make sure your BGP and IGP were synchronized to ensure you didn't
> >blackhole routes.
>
> Precisely. I don't have the document number in front of me, but the
> old RFC on BGP/OSPF interaction, which assumed this model, has been
> recategorized as Historic (i.e., nobody does this, don't try it, it
> was a blind alley)
>
> >Today, BGP is run fully meshed with all transit providing routers in
> >an AS peering with IBGP and hence synch is a complete non issue.
>
> Full mesh, of course, has its scalability issues, and we deal with
> iBGP scalability measures such as route reflectors. There is a trend
> to have the main BGP at the edge, and to have principally an IGP in
> the provider core. The core is stupid, and is traversed by MPLS
> tunnels -- the role of the IGP is to establish reachability for these
> LSPs, which run between BGP speakers on the edges.
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
