Previous Table of Contents Next


Segregating the World into Administrations

Exterior routing protocols were created to control the expansion of routing tables and to provide a more structured view of the Internet by segregating routing domains into separate administrations, called autonomous systems (AS) that each have their own independent routing policies.

During the early days of the Internet, an exterior gateway protocol called EGP[3] (not to be confused with Exterior Gateway Protocols in general) was used. The NSFNET used EGP to exchange reachability information between the backbone and the regional networks. Although the use of EGP was widely deployed, its topology restrictions and inefficiency in dealing with routing loops and setting routing policies created a need for a new and more robust protocol. Currently, BGP4 [4] is the de facto standard for Internet routing; it is an advanced exterior protocol that is providing the Internet with a controlled and loop-free topology.

Static Routing, Default Routing, and Dynamic Routing

Before introducing and looking at the basic ways in which autonomous systems can be connected to ISPs, we need to establish some basic terminology and concepts of routing. Static routing refers to routes to destinations being listed manually in the router. Network reachability in this case is not dependent on the existence and state of the network itself. Whether a destination is up or down, the static routes would remain in the routing table, and traffic would still be sent toward that destination. Default routing refers to a "last resort" outlet—traffic to destinations that are unknown to the router will be sent to that default outlet. Default routing is the easiest form of routing for a domain connected to a single exit point.

Dynamic routing refers to routes being learned via an internal or external routing protocol. Network reachability is dependent on the existence and state of the network. If a destination is down, the route would disappear from the routing table, and traffic would not be sent toward that destination.

These three routing approaches are possibilities for all the AS configurations considered in forthcoming sections, but usually there is an optimal approach. Thus, in illustrating different autonomous systems, this chapter considers whether static, dynamic, default, or some combination of these is optimal. This chapter also considers whether interior or exterior routing protocols are appropriate. A more detailed exploration of routing choices for different AS topologies, however, must wait until Chapter 5 "Tuning BGP Capabilities."

Always remember, static and default routing are not your enemy. The most stable (but not so flexible) configurations are the ones based on static routing. Many people feel that they are not technologically up-to-date just because they are not running dynamic routing. Trying to force dynamic routing on situations that do not really need it is just a waste of bandwidth, effort, and money.

Autonomous Systems

An autonomous system (AS) is a set of routers having a single routing policy, running under a single technical administration. The AS could be a collection of IGPs working together to provide interior routing. To the outside world, the whole AS is viewed as one single entity. Each AS has an identifying number, which is assigned to it by an Internet Registry or a provider. Routing information between ASs is exchanged via an exterior gateway protocol such as BGP4, as illustrated in figure 4-2.


Figure 4-2  General illustration of AS relationships.

What we have gained by segregating the world into administrations is the capability to have one large network—in the sense that the Internet could have been one huge OSPF or ISIS network—divided into smaller and more manageable networks. These smaller networks, called ASs, can now have their own set of rules and policies that will uniquely distinguish them from other ASs. Each AS can now run its own set of IGPs, independent of IGPs in other ASs.

Stub ASs

An AS is considered to be stub when it reaches networks outside its domain via a single exit point. These ASs are also called single-homed with respect to another provider. Figure 4-3 illustrates a single-homed or stub AS.


Figure 4-3  Single-homed stub AS.

A single-homed AS does not really have to learn Internet routes from its provider. Because there is a single way out, all traffic can default to the provider. On the other hand, there are different methods for the provider to advertise the customer's routes. One possibility is for the provider to list the customer's subnets as static entries in its router. The provider would then advertise these static entries toward the Internet. This method would scale very well if the customer's routes can be represented by a small set of aggregate routes. When the customer has too many discontiguous subnets, listing all these subnets via static routes becomes inefficient.

Alternatively, IGPs can be used for the purpose of advertising the customer's networks. An IGP can be used between the customer and provider for the customer to advertise its routes. This has all the benefits of dynamic routing where network information and changes are dynamically sent to the provider.

The third method by which the ISP can learn and advertise the customer's routes is to use BGP between the customer and the provider. In the stub AS situation, it is hard to get a registered AS number from the InterNIC because the customer's routing policies are an extension of the policies of the provider. Instead, the provider will give the customer an AS number from the private pool of ASs (65412-65535).

Quite a few combinations of protocols can be used between the ISP and the customer. Figure 4-4 illustrates some of the possible configurations, taking just stub ASs as an example. (The meaning of EBGP and IBGP will be discussed in the upcoming sections.) Providers might extend customer routers to their POPs or providers might extend their routers to the customer's network. Note that not every situation requires that a customer run BGP with its provider, as mentioned earlier.


Figure 4-4  Example protocol implementation variations.


Previous Table of Contents Next