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.  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.

          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=48565&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