>All, > Being one of the folks currently reading Howard's most recent book >titled - Building Service Provider Networks, I must say that I'm enjoying >the various points being addressed by this thread. > >Also, this does remind me of an article in the 2nd Qtr edition >of "Packet Magazine" titled, ISP Dial Network Design using BGP. >http://www.cisco.com/warp/public/784/packet/techtips.html#1 >Good article! > >Howard, I just wanted to be sure that I didn't misunderstand what you >said... > >> Could very well be. Remember, the core IGP routers are only >> interested in infrastructure, and, in a carrier environment, there is >> no excuse for having a very clean hierarchical addressing structure. > >Did you mean "there is no excuse for [not] having a very clean >hierarchical addressing structure or I'm I missing something, as always..:-> > >TIA >Nigel
You've got me. A "dirty" infrastructure addressing system is a sin beyond redemption. > > >----- Original Message ----- >From: "Howard C. Berkowitz" >To: >Sent: Wednesday, July 10, 2002 7:22 PM >Subject: RE: Route Reflection with Multiple POPs [7:48509] > > >> At 10:27 PM +0000 7/10/02, 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. >> >> Not sure what you are picturing as POP router. If you mean POP >> aggregation router, yes. There might be an "outer core" of reflectors >> connected to multiple POPs, and then a full iBGP mesh among the >> reflectors in the "inner core." >> >> >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? >> >> I tend to take the opposite view. In a network not using QoS, the >> core may or may not need to run BGP at all, or a relatively small >> number of BGP routes (e.g., the aggregate addresses for POPs). The >> critical thing to realize is the core is infrastructure, and its job >> is internal interconnection. >> >> >Are static routes used in this situation? >> >> Could very well be. Remember, the core IGP routers are only >> interested in infrastructure, and, in a carrier environment, there is >> no excuse for having a very clean hierarchical addressing structure. >> >> >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 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=48562&t=48509 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
