AS migration

Wed Jan 23 18:21:25 UTC 2002

On Tue, 22 Jan 2002, Josh Fleishman wrote:

> Beer?  Sushi?  Beer?  I'm in.
> 
> As Miguel noted, we at Earthlink/Mindspring/OneMain continue our ongoing
> AS integrations(we have over 30).  A few additional gotcha's and
> benefits that come to mind you might want to consider include better IP
> space utilization, elimination of backdoor routes, radb updates, use of
> NSSA/TSA, peering benefits, and the use of 'local-as' options.

The more efficient use of IP space and peering benefits were some of the
technical drivers behind my desire to take on this project.  I hadn't
really looked too closely at the local-as options, but I will certainly do
some more research...

> IP space utilization can be benefited by consolidating IP space into
> larger and more useful aggregates.  Which also results in better
> announcements, and a happier NANOG community :).

I've been doing this in the AS that would be kept after the migration for
some time.  ARIN has been receptive to my requests to keep future
allocations contiguous where possible to make my announcements as
efficient as they can be.  Most of the IP space in the other networks is
provider-assigned in bite-sized pieces.  I plan to replace that with CIDR
space as the opportunity permits itself.

> Backdoor routes based on the integrated AS's, if currently used, become
> obsolete.  A minor detail.

We're using backdoor routes only as short-term fixes in specific
circumstances at the moment.  For the most part, each of the separate
networks is still completely self-standing.

> RADB updates should be made so that your IP space is correctly
> registered to the kept AS#.  Particularly important if any of your
> transits/peers base their filters on such a database.

IP space and related policies for the AS we're keeping are registered in
the RADB now and I update them as needed.

> Not-so-stubby and totally stubby areas, if they fit your design, are a
> good way to prevent over-load of your smaller routers with an increased
> LSDB size, and especially if you have a lot of redistribution going on
> in your network.

Yes, redistribution and controlling LSA floods are a substantial concern.

> If you are interested in peering, presenting your network as a single AS
> where you can advertise routes consistently in multiple locations is
> another great benefit and helps meet some of the more stringent peering
> requirements.  Without going too much into the value of peering, if done
> correctly your overall transit costs can be significantly reduced as
> well as better latency for your users.  (This is a good way to impress
> the boss.)

My experiences in the past with presenting a loose cobble of ASes to a
peer were less than favorable ;-)

> By specifying the local as, you can integrate IGPs and build your
> confederation completely transparent to the outside world.  Junipers and
> Cisco's, among others, both support this option.  Note, the last I
> checked you can't specify different local AS#s for peers within a Cisco
> peer group.

I'm not using peer-groups at this time, so that shouldn't cause an issue.

> This is only a start..  It's not overly difficult, and depending on the
> size of your network (and staff), probably worth it.  

The combined network services around 85,000 residential and commercial
users (dialup/ISDN, DSL, T1, DS3, colo...) and managed services clients.
Staff levels are sufficient to manage a network of this size.

> Justin, I'd be happy to share our experiences with you sometime at
> NANOG.

Much appreciated.  If it's at all possible for me to make it to NANOG 24,
I will certainly take you up on it.

jms