AS migration

Miguel de Leon Dimayuga miguel.dimayuga at
Tue Jan 22 22:20:15 UTC 2002

> I'm also looking at it from the perspective of making peering 
> with various
> providers or in various exchanges a more compelling business 
> driver, as
> opposed to putting all of the $$ into transit.

Yes, definitely.  That's one of the main drivers 
to merge AS'es as well.  Consolidating AS'es means
aggregating the traffic in a single AS.  That's 
a "GoodThing"TM as far as maintaining and establishing
peering sessions.   

On the transit side, consolidating AS'es allows you to
rationalize your transit connections and take out
redundant links in a market to the same provider and 
maybe even afford a distinct backup provider for each market.

> Most of the service/server consolidation has already been done.

I assume, then, that connectivity between your AS'es
are via private lines and not through common
transit providers.  That's usually one of the other 
things that is necessary to start on this project.

make sure your AS'es are well connected to your
chosen surviving AS....  and of course, 
convert one AS at a time ;) heehhe

> > One approach we took before merging AS'es is to make 
> > sure you have a common local pref and community 
> > infrastructure among the AS'es you want to merge.
> > attempting to go confeds with mismatching local pref
> > and community based policies might be a headache.
> I designed both for all of the other ASes so they're all similar in
> design.

awesome! =) you should then be able to set the proper
communities and route-maps between your confederations 
to make sure that you spill routes across your own AS'es 
in a controlled manner.

Through prepending and local pref tweaks, you should
have the ability to make sure you don't overwhelm
that DS-3 vs OC-3 to upstream A when you start 
merging networks.

The more automated you make the ability to prepend or
change local prefs or filter announcements to peers
on a per route basis, the easier the migration will be. 

You can "automate" this process by having the necessary
communities, community-lists and route-maps already in
place.  Once done, all you need to change the way a network
is announced is by attaching a community to it.  this
is "automation" is necessary to ease control.

> My big concern is controlling IGP growth as a whole.  Each of the ASes
> is running their own independent OSPF implementation.  
> Dealing with all of
> those disjoint backbone areas and rolling them into one AS while
> minimizing/eliminating service disruptions for my customers has been a
> source of constant brow-beating.

Start to look deep into your OSPF implementation and
try to minimize the routes in your area 0 via summarization.
you can also look into what's in area 0 now in your
AS'es.  do all the devices in area 0 now have to remain
in area 0?  can you some of these devices live in 
a new stubby or even NSSA area?

The less routes in area 0, the smaller the number of 
routers in area 0, the more conceptually and
practically easy it is to follow/monitor/verify when 
you merge backbone areas.  Not to mention that its 
probably good practice.

Hope this helps =)

Miguel =)

Miguel de Leon Dimayuga     God does not ask us to be successful,
Networks & Technologies                      only to be faithful.
Cbeyond Communications                 -Mother Teresa of Calcutta

More information about the NANOG mailing list