Avoiding Single Points of Failure

The introduction of links to multiple points of presence (POPs) of one or several ISPs can eliminate single points of failure. Such autonomous systems can provide transit services or not. The following subsections discuss several popular BGP scenarios.

Single-Homed Nontransit (Stub) Scenario with a Private AS

In a nutshell, stub and single-homed autonomous systems do not justify the assignment of a regular ASN in the eyes of Internet Assigned Numbers Authority (IANA) and company. In case of special requirements, upstream providers do assign a private ASN (64512?65534, RFC 1930); and in case of a PI block assigned to the downstream customer, upstream providers announce this network to the Internet while stripping the private AS. The first level of redundancy would be to attach this customer to two different POP of the same ISP and provide traffic granularity via BGP measures. BGP offers a clean demarcation point. I strongly advise against ISDN dial-on-demand backups in BGP scenarios.

Multi-Homed Nontransit (Stub) Scenario

Entities that require the added redundancy of two independent upstreams usually register an ASN and a PI block. Upstream ISPs/carriers announce the PI prefix, which frequently results in suboptimal utilization of one upstream link. Remember, BGP was not designed for load balancing. This situation can be improved with the cooperation of both upstreams to tune BGP's advanced capabilities, such as path prepending, MED, and community attributes, to achieve at least a better distribution of traffic. To say the least, this is a tedious task that requires strong BGP knowledge and needs to be taken care of incoming and outgoing. In general, providing transit services through a public exchange violates the policy established by the exchange managers.

Transit Services

Transit traffic usually serves topological and commercial purposes. As long as the corresponding ingress and egress traffic of two transit partners is roughly equivalent, transit AS owners tend to agree to mutually beneficial no-charge peering/transit agreements. If this is not the case, transit traffic might be subject to charge.

In fact, providing transit traffic (be it for free or not) through a public IX is a violation of policy of almost any IX in the world (of which I am aware of). What has changed over the past few years, however, is the perception of what is considered "transit traffic" by the IX operators: Because carriers and ISPs have become multinational, IXs have to deal with peering entities (in a commercial sense) that cover numerous autonomous systems (combined administratively to an AS set, or macro), so IX operators usually allow such providers to announce their entire AS set at a given (national) IX instead of only their (national) AS. So a certain AS providing transit (in the strict BGP meaning) has nothing to do with public peering in the first place, but merely with the combination of some autonomous systems under common (international) administration, or is simply necessary because a provider has customers with their own autonomous systems (which, of course, have always been permitted on the IXs).

The question of traffic symmetry is a different one that does not really touch the transit/nontransit topic. As mentioned earlier, providers were picky about this symmetry when peering privately, and some kept enforcing this policy on the public IXs. Today, however, most of them realize that the advantages of public peering easily compensate for the possible drawbacks, so most do not care about symmetry anymore, and many just do not want to go through the added accounting hassle involved.