From: James (james@towardex.com)
Date: Fri Jul 02 2004 - 19:31:24 GMT-3
Hi Howard,
By "backbones" I meant transit ISP backbones. Not enterprises..
>
> In the real world, I find confederations most useful to build a
> complex backbone-of-backbones for enterprises. They let you split
> IGP domains, and also let you implement complex enterprise (or
> extranet) interdomain policies.
I would agree to some extent in this.
>
> Splitting IGP domains can be useful in several ways. The most obvious
> is scalability by restricting the number of routes and routers in
> each domian.
IGP domains are usually not a scalability issue on most transit backbones
(e.g. AS209, AS7018, AS1668) as they carry only infrastructure next-hops
required by BGP to make routing decisions, in IGP. Almost everything else is
carried in IBGP with appropriate community (i.e. no-export or their own version
of no-export) to prevent leak to outside. Most of their scalability issues come
from edge router peerings into the core, which is alleaveated easily by
route-reflectors going down from core->edge.
AS209 and 1668 use exclusively ISIS on their entire international network,
carrying only TLVs necessary to carry needed next-hops and perform BGP
traffic engineering by modifying IGP cost of a peering circuit.
> Next, sometimes a topology that would be quite awkward
> with OSPF or ISIS backbone rules becomes much easier when you have a
> limited number of interdomain connections, which don't need to follow
> strict hierarchy.
It's not always about the hierarchy these days with these backbones. They want
something simple for overall peering topology and be able to TE the peering
routes by simple modification of IGP cost in multi-location peering sessions.
A flat-IGP network is the best for this type of scenario.
> If you are a multinational enterprise, the
> bandwidths available in continents or regions often tend to differ.
That's totally dependent of your IGP engineering.
> Routing performance tends to be most predictable when there isn't a
> huge range of bandwidths in the same IGP domain.
> these are apt to be traffic-engineered, using at least RSVP and
> probably MPLS. ISP backbones tend to be fairly flat. POPs feed into
> the edges of these backbones, and the POPs usually involve route
> reflectors, often fully meshed within the cluster to avoid some of
> the oscillation conditions described in RFC 3345. I suspect the CCIE
> lab does not consider 3345 issues.
I fully agree with this.
-J
>
> >
> >-J
> >
> >On Fri, Jul 02, 2004 at 04:19:33PM -0400, Tom Martin wrote:
> >> It is tough to follow Howard and offer any kind of practical advice on
> >> BGP... But I will throw my idea out on the assumption that you're
> >> studying for the lab and just looking for options for "what if"
> >> scenarios...
> >>
> >> You could configure the existing AS 100 as a confederation AS within AS
> >> 200 by adding a single line:
> >>
> >> router bgp 100
> >> bgp confederation identifier 200
> >>
> >> That would also have the effect of advertising AS 200 to EBGP peers,
> >> without reconfiguration of any existing neighbors. That assumes that you
> >> aren't going to have new neighbors, that your neighbors will be
> >> correctly configured for your "new" AS, etc.
> >>
> >> -- Tom
> >>
> >> -----Original Message-----
> >> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> >> ccienj
> >> Sent: Friday, July 02, 2004 2:54 PM
> >> To: ccielab@groupstudy.com
> >> Subject: BGP AS-Migration
> >>
> >> An ISP currently on AS 100 will move to AS 200 next year, to avoid
> >> reconfiguration for this year's customer's what would be best solution
> >> to
> >> minimize reconfiguration.
> >>
> >> I think BGP Local-as would be the best way to handle this any other
> >> ideas ?
> >>
> >> thanks,
> >>
> >> _______________________________________________________________________
> >> Please help support GroupStudy by purchasing your study materials from:
> >> http://shop.groupstudy.com
> >>
> >> Subscription information may be found at:
> >> http://www.groupstudy.com/list/CCIELab.html
> >>
> >> _______________________________________________________________________
> >> Please help support GroupStudy by purchasing your study materials from:
> >> http://shop.groupstudy.com
> >>
> >> Subscription information may be found at:
> >> http://www.groupstudy.com/list/CCIELab.html
> >
> >--
> >James Jun TowardEX
> >Technologies, Inc.
> >Technical Lead Network Design, Consulting, IT
> >Outsourcing
> >james@towardex.com Boston-based Colocation &
> >Bandwidth Services
> >cell: 1(978)-394-2867 web: http://www.towardex.com , noc:
> >www.twdx.net
> >
> >_______________________________________________________________________
> >Please help support GroupStudy by purchasing your study materials from:
> >http://shop.groupstudy.com
> >
> >Subscription information may be found at:
> >http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Please help support GroupStudy by purchasing your study materials from:
> http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
-- James Jun TowardEX Technologies, Inc. Technical Lead Network Design, Consulting, IT Outsourcing james@towardex.com Boston-based Colocation & Bandwidth Services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net
This archive was generated by hypermail 2.1.4 : Sun Aug 01 2004 - 10:11:46 GMT-3