In Chapter 2, we learned that hosts communicate directly only with other computers connected to the same network. Gateways are needed to communicate with systems on other networks. If the hosts on your network need to communicate with computers on other networks, a route through a gateway must be defined. There are two ways to do this:
Routing can be handled by a static routing table built by the system administrator. Static routing tables are most useful when the number of gateways is limited. Static tables do not dynamically adjust to changing network conditions, so each change in the table is made manually by the network administrator. Complex environments require a more flexible approach to routing than a static routing table provides.
Routing can be handled by a dynamic routing table that responds to changing network conditions. Dynamic routing tables are built by routing protocols. Routing protocols exchange routing information that is used to update the routing table. Dynamic routing is used when there are multiple gateways on a network; it's essential when more than one gateway can reach the same destination.
Many networks use a combination of both static and dynamic routing. Some systems on the network use static routing tables while others run routing protocols and have dynamic tables. While it is often appropriate for hosts to use static routing tables, gateways usually run routing protocols.
The network administrator is responsible for deciding what type of routing to use and for choosing the default gateway for each host. Make these decisions before you start to configure your system.
Here are a few guidelines to help you plan routing. If you have:
No special routing configuration is required in this case. The gateways referred to in this discussion are IP routers that interconnect TCP/IP networks. If you are not interconnecting TCP/IP networks, you do not need an IP router. Neither a default gateway nor a routing protocol needs to be specified.
If you have only one gateway, don't run any routing protocols. Specify the single gateway as the default gateway in a static routing table.
Here, there is a real choice. You can statically specify each subnet route and make the gateway to the world your default route, or you can run a routing protocol. Decide which you want to do based on the effort involved in maintaining a static table versus the slight overhead of running a routing protocol on your hosts and networks. If you have more than a few hosts, running a routing protocol is probably easiest.
If you have multiple gateways that can reach the same destination, use a routing protocol. This allows the gateways to adapt to network changes, giving you redundant access to the remote networks.
Figure 4-1 shows a subnetted network with five gateways identified as A through E. A central subnet (172.16.1.0) interconnects five other subnets. One of the subnets has a gateway to an external network. The network administrator would probably choose to run a routing protocol on the central subnet (172.16.1.0) and perhaps on subnet 172.16.12.0, which is attached to an external network. Dynamic routing is appropriate on these subnets because they have multiple gateways. Without dynamic routing, the administrator would need to update every one of these gateways manually whenever any change occurred in the networkfor example, whenever a new subnet was added. A mistake during the manual update could disrupt network service. Running a routing protocol on these two subnets is simpler and more reliable.
On the other hand, the administrator would probably choose static routing for the other subnets (172.16.3.0, 172.16.6.0, and 172.16.9.0). These subnets each use only one gateway to reach all destinations. Changes external to the subnets, such as the addition of a new subnet, do not change the fact that these three subnets still have only one routing choice. Newly added networks are still reached through the same gateway. The hosts on these subnets specify the subnet's gateway as their default route. In other words, the hosts on subnet 172.16.3.0 specify B as the default gateway, while the hosts on subnet 172.16.9.0 specify D as the default, no matter what happens on the external networks.
Some routing decisions are thrust upon you by the external networks to which you connect. In Figure 4-1, the local network connects to an external network that requires that Border Gateway Protocol (BGP) be used for routing. Therefore, gateway E has to run BGP to exchange routes with the external network.
The Border Gateway Protocol (BGP) requires that gateways have a special identifier called an autonomous system number (ASN). Most sites do not need to run BGP. Even when a site does run BGP, it usually runs it using the ASN of its ISP or one of the ASNs that have been set aside for private use, which are the numbers from 64512 to 65535. Coordinate your ASN selection with your border gateway peers to avoid any possible conflicts. If you connect to the Internet through a single ISP, you almost certainly do not need an official ASN. If after discussions with your service provider you find that you must obtain an official ASN, obtain the application from the Regional Internet Registry that services your country.
 Refer to the section Section 2.3 for a discussion of autonomous systems.
If you're in the Asia and Pacific region, served by APNIC, you should use the application form at http://ftp.apnic.net/apnic/docs/asn-request and mail the completed form to email@example.com.
If you're in the Americas, served by ARIN, you should use the application form at http://www.arin.net/templates/asntemplate.txt and mail the completed form to firstname.lastname@example.org.
If you're in Europe, served by RIPE, you should use the application form at ftp://ftp.ripe.net/ripe/docs/ripe-147.txt and mail the completed form to email@example.com.
If you submit an application, you are asked to explain why you need a unique autonomous system number. Unless you are an ISP, probably the only reason to obtain an ASN is that you are a multi-homed site. A multi-homed site is any site that connects to more than one ISP. Reachability information for the site may be advertised by both ISPs, confusing the routing policy. Assigning the site an ASN gives it direct responsibility for setting its own routing policy and advertising its own reachability information. This doesn't prevent the site from advertising bad routes, but it makes the advertisement traceable back to one site and ultimately to one technical contact. (Once you submit an ASN application, you have no one to blame but yourself!)
If you obtain an official ASN, you must decide whether you need to register in a routing database. If you got your ASN because you're multi-homed, you should register with a routing database. Section 2.3 explains that routing databases are used to validate routing in the new Internet because there is no longer a central core that can be relied on to determine "best" routes. When you obtain an official ASN, you become part of the structure of co-equal routing domains. You assume responsibility for a small portion of the routing burden and you declare that responsibility by registering in a routing database.
There are several different databases that make up the Internet Routing Registry (IRR). In addition to the Routing Arbiter Database (RADB) mentioned in Chapter 2, RIPE, ANS, Bell Canada, and Cable & Wireless all maintain databases. RIPE serves customers in the RIPE region. ANS, Bell Canada, and Cable & Wireless register only their paying customers. RADB is available to anyone.
To register in the RADB, first register a maintainer object. Maintainer objects identify the person who will be responsible for maintaining your database entries. Provide the required information, and pay the $200 fee. You must then register the autonomous system as an AS object. Finally, you create a Route object for each route your system will advertise. See http:/http://www.radb.net for detailed information about registering these database objects.
All of the items discussed so far (addressing, subnetting, and routing) are required to configure the basic physical network on top of which the applications and services run. Now we begin planning the services that make the network useful and usable.