Hello All, First of all, forgive my English writting please! I work for an Internet Carrier in Argentina which is in process of reorganizing its regional operations. We are also serving in other countries in South America. We currently have one AS per country and we are looking forward to migrate to a unique AS for all the organizations. Could anyone describe pros and cons of having a unique AS for this kind of networks rather than having one AS for each country. Regardless of the cons, we are facing migration process anytime soon, so I would appreciate very much to get more pros than cons to include in my papers which are almost finished! I would also be glad if you share your experience about this migration process. That is the real value of your answers. Thanks for your time. Regards, Gabriel.
Adonaylo, Gabriel wrote (on Jul 14):
Could anyone describe pros and cons of having a unique AS for this kind of networks rather than having one AS for each country. Regardless of the cons, we are facing migration process anytime soon, so I would appreciate very much to get more pros than cons to include in my papers which are almost finished!
Quick off-the-cuff comments, based on the bottle of wine I just consumed and past experience. We migrated to a single ASN and kept our countries (which are autonomous companies in their own right with individual NOCs and so on) connected with a BGP confederation. - The major technical benefit we saw was better path selection, both of our view of the outside world and the worlds view of us. That is to say that across the ASN, those networks we have a direct peering relationship with saw increased traffic where before certain paths may have chosen a transit link before, particularly in the inbound direction. - It becomes easier to control path selection - MED's become transitive at confed-EBGP borders and you don't (well, can't) have to fiddle with coarse-grained AS-path stuff for control within the confed. While this works with our preffered router platform, every release of IOS I have used has always managed to break some aspect of this transitive MED (particularly if you try to alter it at the confed-ebgp border). - With well defined communities to control things, you can provide a more coherent approach to exit point control for you and your customers. - The network you control appears to be bigger. Also, this may help with peering where some networks percieve value in peering with the same ASN in multiple locations (or they want to do the early-exit thing). The downside of a confederation approach, and of others too in similar circumstances, is that if the confederation gets split (by router or line failure etc) then the two halves cannot speak to each other, regardless of how much Transit or peering you have. You won't import routes from a regular EBGP peer that have your own ASN in the path. Thus, if you do have a confed ASN per country, you need to ensure your inter-country connectivity is up to scratch to avoid this scenario. Also, peers you see in more than one country will normally handover traffic at the earliest/closest point to the origin of the traffic, which may not be entirely desirable in some cases, particularly if the "closest" decision gets warped somehow and this ends up being in a country you do not have wonderful connectivity to/from/via. Migration itself is quite easy[1]. If you keep confed-ebgp borders in the same places as your current inter-country EBGP borders, then your IGP doesn't need to be touched and careful planning and configuration will let you progressively migrate different routers in your network to the other BGP ASN over the course of the night with relatively little disruption. We had (to a degree) a "ring" of routers in some countries, and we ran around this ring sequentially migrating. We were able to do something like 200 routers across four countries in a night, and had the entire network (nine countries, some 400 routers I think it was[2]) done in two sittings, with a night apart Just In Case. Most BGP implementations these days will let you "fake" the ASN you present on a session (local-as in IOS), so you can retain backward compatibility with any peers (esp. customers) after you migrate your network, but note that this has an implicit prepending effect in the outward direction. This will also be the issue that takes longest to resolve - to this day, we still have peers that are local-as'ed - after 6 months of email and phone calls, even shutting down the session fails to evoke a response. Such are the times. So on it goes. Two years since the migration, we have a handful of peers like this. The above not meant to be exhaustive, but perhaps a useful starting point. Chris. [1] While easy, it is quite tedious and time consuming. It is also, it turns out, very very easy to screw up, though thankfully quite easy to spot when you do and, assuming you did your homework, easy to rectify. Easy to a degree here means the same thing as straighforward, but it should be said that sometimes straightforward and IOS are not words to be used in any sort of proximity. YMMV. [2] This number could be out - we've assimilated a number of other companies since (and migrated them all into the same ASN) and and have now rather a lot of BGP speaking devices across the 11 countries we now have operating networks in. :) I consequently do not recall exactly how many routers we had when. Not this this is important, though I felt it prudent to point it out. I could be wrong. -- == chrisy@flix.net
On Mon, 14 Jul 2003, Chris Luke wrote:
Adonaylo, Gabriel wrote (on Jul 14):
Could anyone describe pros and cons of having a unique AS for this kind of networks rather than having one AS for each country. Regardless of the cons, we are facing migration process anytime soon, so I would appreciate very much to get more pros than cons to include in my papers which are almost finished!
<snip>
The downside of a confederation approach, and of others too in similar circumstances, is that if the confederation gets split (by router or line failure etc) then the two halves cannot speak to each other, regardless of how much Transit or peering you have. You won't import routes from a regular EBGP peer that have your own ASN in the path. Thus, if you do have a confed ASN per country, you need to ensure your inter-country connectivity is up to scratch to avoid this scenario.
Presumably you can mitigate with allow-own-as to ensure you can connect your countries together over transits... Steve
Hola Gabriel, reading http://www.nanog.org/mtg-0302/merger.html might be very helpful. Regards, Arnold On Monday, July 14, 2003 3:47 AM, Adonaylo, Gabriel <Gabriel.Adonaylo@Comsat.com.ar> wrote:
Hello All,
First of all, forgive my English writting please!
I work for an Internet Carrier in Argentina which is in process of reorganizing its regional operations. We are also serving in other countries in South America.
We currently have one AS per country and we are looking forward to migrate to a unique AS for all the organizations.
Could anyone describe pros and cons of having a unique AS for this kind of networks rather than having one AS for each country. Regardless of the cons, we are facing migration process anytime soon, so I would appreciate very much to get more pros than cons to include in my papers which are almost finished!
I would also be glad if you share your experience about this migration process. That is the real value of your answers.
Thanks for your time.
Regards, Gabriel.
participants (4)
-
Adonaylo, Gabriel
-
Chris Luke
-
Nipper, Arnold
-
Stephen J. Wilcox