Hi Guy, As others have pointed out, it is not necessary, nor usually desirable, to run separate IGPs in your AS assuming you use your IGP properly. A properly utilized ISP IGP should carry only link and loopback addresses and thus be reasonably small. Use of hierarchy can also help larger domains scale, though modern IGP implementations on reasonably powered routers should be able to handle rather large single areas.
BGP never runs entirely on its own as one always requires some method of resolving BGP Next-Hops to forwarding next hops. Static routes can work here to connect otherwise disconnected IGP domains, or, separate IGP domains can be used for this purpose as well. At 06:19 PM 7/10/2002 -0400, Lupi, Guy wrote: >I know that you can run confederations and reflectors, and seperate levels >of reflection, which Cisco refers to as "nested reflection". Now my >question is, how would you set up your bgp peering? Due to financial >constraints I would imagine that the best thing to do would be to have one >circuit from POP router 1 to core router 1, and another circuit from POP >router 2 to core router 2. Assuming that you are only running BGP in the >core, and that the clients have to have a session with each reflector, how >would you communicate the loopback addresses of all the routers to each >other? Are static routes used in this situation? Thanks to all of the >people who responded by the way, I appreciate the direction. Ever feel like >you know so much, only to read a book and find out that you know so little >:)? > >*-----Original Message----- >*From: Peter van Oene [mailto:[EMAIL PROTECTED]] >*Sent: Wednesday, July 10, 2002 3:00 PM >*To: [EMAIL PROTECTED] >*Subject: Re: Route Reflection with Multiple POPs [7:48509] >* >* >*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=48579&t=48509 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
