Re: BGP AS-Migration

From: Howard C. Berkowitz (hcb@gettcomm.com)
Date: Fri Jul 02 2004 - 19:02:18 GMT-3


At 5:49 PM -0400 7/2/04, James wrote:
>The easiest way to migrate an AS is to use local-as on peering and customer
>sessions first, then start planning maintenance for global network reload with
>new configs. This is how some of the major backbones have migrated their
>networks today.
>
>Most backbones I've seen don't seem to like using confederations if at all
>possible.

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.

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. 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. If you are a multinational enterprise, the
bandwidths available in continents or regions often tend to differ.
Routing performance tends to be most predictable when there isn't a
huge range of bandwidths in the same IGP domain.

ISPs, however, tend not to have complex IGP policies. When they do,
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.

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



This archive was generated by hypermail 2.1.4 : Sun Aug 01 2004 - 10:11:46 GMT-3