Please also keep in mind that my generalizations of the solutions in the book may leave something to be desired, and the solutions that I pointed out were certainly not the only ones presented.
*-----Original Message----- *From: Howard C. Berkowitz [mailto:[EMAIL PROTECTED]] *Sent: Wednesday, July 10, 2002 4:10 PM *To: [EMAIL PROTECTED] *Subject: Re: Route Reflection with Multiple POPs [7:48509] * * *At 7:17 PM +0000 7/10/02, Phillip Heller wrote: *>On Wed, Jul 10, 2002 at 04:42:25PM +0000, Lupi, Guy wrote: *> Let me preface this by saying that I am trying to learn *more about large *> scale BGP design and operation. This question is on route *reflectors *when *> you have multiple POPs in seperate IGP domains. If you *currently have *one *> POP and are going to move to 2 within the same AS, you can *either run *full *> mesh (doesn't scale), reflectors, or confederations. *Assuming you don't *> currently have a central core that the POPs connect back *to, how well *does *> reflection scale? I was reading Building Service Provider Networks *> [Berkowitz], and it states that iBGP doesn't scale well *once you go above *> 15-20 sessions per router. It also states that most ISPs *run reflectors *> instead of confederations, but I believe that statement is *being made *under *> the assumption that the ISP will have a central core to *which the POPs *will *> connect. This would indicate to me that assuming you don't have a *central *> core, one could only connect 6 or 7 POPs (dual reflectors *for redundancy) *> together using reflection before you would have to either create a *central *> core to reduce the amount of iBGP sessions, or turn to *confederations. *> Perhaps the best way to accomplish this would be to *establish a "core" in *> one of the POPs and run reflection from there, which is *also presented *as a *> solution in the book? Any opinions? I have made an *attempt at ASCII *> drawing below, to me the central core solution makes more sense. *> *>In my experience, a core ibgp mesh will scale to at least 70 sessions *>per device. I would suggest that route reflection certainly be done *>between core and aggregation devices per pop. * *With more modern routers, I certainly can see that working, *especially depending on how well you dampen flap and generally *control the churn rate. One also has to be careful about all the *issues evolving in the permanent oscillation drafts and discussion in *the IDR WG. * *15-20 is an old Cisco recommendation that, like the number of areas *per OSPF ABR, certainly can be exceeded when you understand the *issues. * *> *>Central reflection may be prone to failure depending on the design of *>the network. * *I certainly didn't mean to imply that there is a single reflector. My *book examples typically show dual reflectors in an important cluster. * *One of the questions, of course, is the extent to which you use *(G)MPLS in the core. There are traffic engineering, shared risk group *management, and other issues that can make a non-traditional, largely *BGP-free core attractive. The BGP intelligence lies in the edge and *aggregation routers, which inherently distribute control plane *workload. * *> *>Also, when you mention seperate igp domains, are you referring to *>areas/levels, or instances? Both OSPF and ISIS scale quite well using *>area or level hierarchy, which mostly mitigates the necessity for *>seperate igp instances. * *Agreed. Indeed, there are many operational carriers that have 1000+ *routers in a single area, albeit with some tuning and stable *facilities. * * * * Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=48535&t=48509 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
