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
----- 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=48561&t=48509
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
