Couple thoughts. First off, one can confederate and reflect at the same time (ie rr clusters inside sub-as's). Also, keep in mind that these techniques deal with control, not forwarding and thus it is possible, and somewhat common, to have a RR hierarchy that does not map directly to the physical topology. I tend to see an arbitrary set of core routers (from 2-20ish) that form the central IBGP mesh with the second level of the hierarchy being formed by lead major pop routers, or dedicated route servers (ie one armed routers that simply reflect routes). I personally try to keep the topology as flat as possible (ie less than 4 levels in the hierarchy) but I don't have any particular technical driver for that other than to minimize complexity and aid troubleshooting.
Of note, this assumes you are reflecting full routes throughout your backbone. I've seen providers try and reflect partial routes to areas of their backbone to allow for smaller routers where RR topologies can lead to blackholes. In general, if you are reflecting all routes, you shouldn't run into issues here. I At 04:42 PM 7/10/2002 +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. > > First Scenario, no central core > > POP 1 POP 2 > Cluster Cluster > o---------------o > Full Mesh Between Reflectors > o---------------o > > Second Scenario, central core establised at one of the POPs > > POP 1 POP 2 > Core Reflectors > Clients o----- -----o Clients > o----- \ / -----o > o o > POP 3 / \ POP 4 > Clients o----- -----o Clients > o----- -----o > > >Guy H. Lupi >CCIE No. 9275 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=48520&t=48509 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
