When you say that OSPF scales very well in a heirarchy, I realize that there
are a lot of factors involved.  Let's assume that all routers in each POP
with the exception of aggregation and core are in NSSA areas to control
LSA's but still be allowed to insert external routes, but obviously the
routers in the core would have to maintain all of the information.  How
large can you scale a topology like this?  I am not concerned so much with
the number of routers, but with the number of routes.  Are we talking about
8000, 16000, 24000, 40000 routes?  I also realize the types of LSA's play a
big part in OSPF, but assuming that your aggregation and core routers were
very high end Juniper or Cisco routers, what would be a general number using
OSPF?  ISIS?  

*-----Original Message-----
*From: Phillip Heller [mailto:[EMAIL PROTECTED]]
*Sent: Wednesday, July 10, 2002 3:17 PM
*To: [EMAIL PROTECTED]
*Subject: Re: Route Reflection with Multiple POPs [7:48509]
*
*
*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.
*
*Central reflection may be prone to failure depending on the design of
*the network. 
*
*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.
*
*Regards,
*
*  --phil
*
*
*
*
*Report misconduct 
*and Nondisclosure violations to [EMAIL PROTECTED]
*




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=48533&t=48509
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Reply via email to