hey justin, Collapsing AS'es has its technical benefits, ultimately resulting in financial benefits. For starters, you'll be able to manage your transit traffic better (and thus grow your pipes in a more sane manner). You'll also be able to control your inter-AS traffic much better (especially if you plan to eventually collapse and use common servers/services across AS'es). An example of this is consolidating your news server farms or mail server farms. One approach on the BGP front 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. On the IGP front, make sure that your private networks are distinct among AS'es. Once you merge OSPF entities, you could have duplicate 192.168.x.x spaces. That's a start. my 0.02 cents worth. Btw, if you make it to nanog, make sure to grab josh fleishman/jeb linton of mindspring/earthlink a line. They also went through a big AS consolidation a few months ago. Miguel de Leon Dimayuga God does not ask us to be successful, Networks & Technologies only to be faithful. Cbeyond Communications -Mother Teresa of Calcutta
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. 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 :). Backdoor routes based on the integrated AS's, if currently used, become obsolete. A minor detail. 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. 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. 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.) 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. This is only a start.. It's not overly difficult, and depending on the size of your network (and staff), probably worth it. Justin, I'd be happy to share our experiences with you sometime at NANOG. Thanks, Josh Fleishman Sr. Network Engineer/Peering Coordinator Earthlink
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
participants (3)
-
Josh Fleishman -
Justin M. Streiner -
Miguel de Leon Dimayuga