North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Unique AS

  • From: Chris Luke
  • Date: Sun Jul 13 22:46:50 2003

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

- 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

- 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


[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.
== [email protected]