comments inline,

At 01:28 AM 7/11/2002 +0000, Lupi, Guy wrote:
>I had a feeling that would happen, I will try to clarify.  I was not trying
>to say that there should be a central core site for the ISP's entire
>network, but for pieces of it.  Lets take a state like New York, within it
>you have 3 POPs, each is in it's own AS and runs an IGP

I'm not sure why you would have 3 pops all in different AS's assuming they 
are all yours?  If you just bought three companies, lets suggest that you'd 
work toward merging those at your earliest convenience.


>.  In each POP you
>have 2 core routers and 3 aggregation routers, the 2 core routers have EBGP
>connections and are reflectors for the 3 aggregation routers.  Now you want
>all 4 POPs to be in the same AS, and they have to have direct connectivity
>to your 3 New Jersey POPs which should also be in the same AS.  In that
>case, would it make sense to choose a NY POP and a NJ POP, install 2 core or
>backbone routers that do not participate in any IGP, use those to peer with
>the POPs in that state and in turn peer with the other state's core or
>backbone routers?  This would significantly reduce the amount of peering
>that would be required. Hopefully the drawing won't be a disaster.

If this was my entire network, I'd likely peer all the core routers one 
with each other, and reflect from each pop core router downward into the 
pops (ensuring that cisco's bgp-deterministic-med is on!).  Alternatively, 
you could pick two to four routers which are maximally resilient and mesh 
them, with hierarchical reflection outward toward the rest of your routers.

Again, running isolated IGP's in this network, or most others does more 
harm then good.  As Phillip and Howard have pointed out, keep everything 
customer oriented in BGP and keep your IGP nice and small.  If its small, 
you can get away with flooding your reachability information unconstrained 
throughout the network which will allow all your routers to make informed 
forwarding decisions.  This assumes no usage of MPLS style TE however.



>           NY POP 1                               NJ POP 1
>             o  o                                   o  o
>             o                                         o
>             o  o                                   o  o
>
>           NY POP 2                               NJ POP 2
>             o  o       o-------------------o       o  o
>             o                   \ /                   o
>             o  o                / \                o  o
>                        o-------------------o
>
>           NY POP 3                               NJ POP 3
>             o  o                                   o  o
>             o                                         o
>             o  o                                   o  o
>
>
>
>
>
>
>
>
>
>
>-----Original Message-----
>From: Phillip Heller
>To: [EMAIL PROTECTED]
>Sent: 7/10/2002 7:33 PM
>Subject: Re: Route Reflection with Multiple POPs [7:48509]
>
>On Wed, Jul 10, 2002 at 10:27:08PM +0000, 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
>   :)?
>
>
>I hate to say it, but the question is somewhat ambiguous and
>confusing...
>
>First and foremost, what is the physical topology of your backbone?  How
>many devices are you dealing with?
>
>These days, most large service provider networks are of a partial mesh
>(physical) design.  There is no central "core" site.  Each pop has
>several aggregation boxes and several "core" boxes.  The core boxes
>connect to each other and to other pop's core boxes.  Also, the core
>boxes provide connections for the aggregation boxes.
>
>While it's common to see route-reflection from the core to aggregation
>boxes, it's less common to see route-reflection from one pop to other
>*multihomed* pops.
>
>Generally, customers maintain one bgp session per physical connection to
>the network; further, the bgp sessions are generally between the
>directly connected devices.  Sometimes customers will want to bond
>multiple equal bandwidth paths.  In this instance, customers generally
>have less than one bgp session per physical connection (ie:
>ebgp-multihop
>with static routes and cef, or Multilink PPP).
>
>--phil




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=48580&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