In this chapter, our emphasis shifts from how TCP/IP functions to how it is configured. While Chapters Chapter 1 through Chapter 3 described the TCP/IP protocols and how they work, now we begin to explore the network configuration process. The first step in this process is planning. Before configuring a host to run TCP/IP, you must have certain information. At the very least, every host must have a unique IP address and hostname. You should also resolve the following issues before configuring a system:
- Default gateway address
If the system communicates with TCP/IP hosts that are not on its local network, a default gateway address may be needed. Alternatively, if a routing protocol is used on the network, each device needs to know that protocol.
- Name server addresses
To resolve hostnames into IP addresses, each host needs to know the addresses of the domain name servers.
- Domain name
Hosts using the domain name system must know their correct domain name.
- Subnet mask
To communicate properly, each system on a network must use the same subnet mask.
If you’re adding a system to an existing network, make sure you find out the answers from your network administrator before putting the system online. The network administrator is responsible for making and communicating decisions about overall network configuration. If you have an established TCP/IP network, you can skip several sections in this chapter, but you may still want to read about selecting hostnames, planning mail systems, and other topics that affect mature networks as much as they do new networks.
If you are creating a new TCP/IP network, you will have to make some basic decisions. Will the new network connect to the Internet? If so, how will the connection be made? How should the network number be chosen? How do I register a domain name? How do I choose hostnames? In the following sections, we cover the information you need to make these decisions.
First, you must decide whether your new network will be fully connected to the Internet. A connected network is directly attached to the Internet and is fully accessible to other networks on the Internet. A non-connected network is not directly attached to the Internet, and its access to Internet networks is limited. An example of a non-connected network is a TCP/IP network that attaches to the outside world via a network address translation (NAT) box or a proxy server. Users on the non-connected network can access remote Internet hosts, but remote users cannot directly access hosts on the non-connected network. Because non-connected networks do not provide services to the outside world, they are also known as private networks.
Private networks that interconnect the various parts of an organization are often called enterprise networks. When those private networks use the information services applications that are built on top of TCP/IP, particularly web servers and browsers, to distribute internal information, those networks are called intranets.
There are a few basic reasons why many sites do not fully connect to the Internet. One reason is security. Connecting to any network gives more people access to your system. Connecting to a global network with millions of users is enough to scare any security expert. There is no doubt about it: connecting to the Internet increases the security risks for your network. Chapter 12 covers some techniques for reducing this risk.
Cost is another consideration. Many organizations do not see sufficient value in a full Internet connection for every desktop. For some organizations, low use or limited requirements, such as needing only email access, make the cost of connecting the entire network to the Internet exceed the benefit. For others, the primary reason for an Internet connection is to provide information about their products. It is not necessary to connect the entire enterprise network to the Internet to do this. It is often sufficient to connect a single web server to the local Internet Service Provider (ISP) or to work with a web hosting company to provide information to your customers.
Other organizations consider an Internet connection an essential requirement. Educational and research institutions depend on the Internet as a source of information, and many companies use it as a means of delivering service and support to their customers.
You may have both types of networks: a non-connected enterprise network sitting behind a security firewall, and a small connected network that provides services to your external customers and proxy service for your internal users.
Unless you have carefully determined what your needs are and what an Internet connection will cost, you cannot know whether connecting your entire network to the Internet is right for your organization. Your local ISPs can give you the various cost and performance alternatives. Ask them about services as well as prices. Some ISPs specialize in providing low-cost service to home users. They emphasize price. However, if you are connecting a full network to the Internet, you may want an ISP that can provide network addresses, name service, web hosting, and other features that your network might need.
Regardless of whether you decide to connect your network to the Internet, one thing is certain: you will build your enterprise network using the TCP/IP protocols. All TCP/IP networks, whether or not they connect to the Internet, require the same basic information to configure the physical network interface. As we will see in Chapter 6, the network interface needs an IP address and may also need a subnet mask and broadcast address. The decision of whether to connect to the Internet affects how you obtain the values needed to configure the interface. In this section, we look at how the network administrator arrives at each of the required values.
Every interface on a TCP/IP network must have a unique IP address. If a host is part of the Internet, its IP address must be unique within the entire Internet. If a host’s TCP/IP communications are limited to a local network, its IP address only needs to be unique locally. Administrators whose networks will not be connected to the Internet can select an address from RFC 1918, Address Allocation for Private Intranets, which lists network numbers that are reserved for private use.[34] The private network numbers are:
Network 10.0.0.0 (10/8 prefix) is a 24-bit block of addresses.
Networks 172.16.0.0 to 172.31.0.0 (172.16/12 prefix) is a 20-bit block of addresses.
Networks 192.168.0.0 to 192.168.255.0 (192.168/16 prefix) is a 16-bit block of addresses.
The disadvantage of using a network address from RFC 1918 is that you may have to change your address in the future if you connect your full network to the Internet. The advantages to choosing a private network address are:
It’s easy. You do not have to apply for an official address or get anyone’s approval.
It’s friendly. You save address space for those who need to connect to the Internet.
It’s free. RFC 1918 addresses cost nothing—official addresses cost money.
If you do choose an address from RFC 1918, the hosts on your network can still have access to systems on the Internet. But it will take some effort. You’ll need a network address translation (NAT) box or a proxy server. NAT is available as a separate piece of hardware or as an optional piece of software in some routers and firewalls. It works by converting the source address of datagrams leaving your network from your private address to your official address. Address translation has several advantages:
It conserves IP addresses. Most network connections are between systems on the same enterprise network. Only a small percentage of systems need to connect to the Internet at any one time. Therefore, far fewer official IP addresses are needed than the total number of systems on an enterprise network. NAT makes it possible for you to use a large address space from RFC 1918 for configuring your enterprise network while using only a small official address space for Internet connections.
It reduces address spoofing, a security attack in which a remote system pretends to be a local system. The addresses in RFC 1918 cannot be routed over the Internet. Therefore, even if a datagram is routed off your network toward the remote system, the fact that the datagram contains an RFC 1918 destination address means that the routers in the Internet will discard the datagram as a martian .[35]
It eliminates the need to renumber your hosts when you connect to the Internet.
Network address translation also has disadvantages:
- Cost
NAT may add cost for new hardware or optional software. However, these costs tend to be very low.
- Performance
Address translation adds overhead to the processing of every datagram. When the address is changed, the checksum must be recalculated. Furthermore, some upper-layer protocols carry a copy of the IP address that also must be converted.
- Reliability
Routers never modify the addresses in a datagram header, but NAT does. This might introduce some instability. Additionally, protocols and applications that embed addresses in their data may not function correctly with NAT.
- Security
NAT limits the use of end-to-end encryption and authentication. Authentication schemes that include the header within the calculation do not work because the router changes the addresses in the header. Encryption does not work if the encrypted data includes the source address.
Proxy servers provide many of the same advantages as NAT boxes. In fact, these terms are often used interchangeably. But there are differences. Proxy servers are application gateways originally created as part of firewall systems to improve security. Internal systems connect to the outside world through the proxy server, and external systems respond to the proxy server. Proxy servers are application-specific. A network might have one proxy web server and another proxy FTP server—each server dedicated to serving connections for one type of application. Therefore, the difference between NAT boxes and proxy servers is that NAT maps IP addresses regardless of the application; the true proxy server focuses on one application.
Proxy servers often have added security features. Address translation can be done at the IP layer. Proxy services require the server to handle data up to the application layer. Security filters can be put in proxy servers that filter data at all layers of the protocol stack.
Given the differences discussed here, network address translation servers should scale better than proxy servers, and proxy servers should provide better security. However, over time these technologies have merged and are now largely indistinguishable. Before you decide to use either NAT or proxy services, make sure they are suitable for your network needs.
Combining NAT with a private network address gives every host on your network access to the outside world, but it does not allow outside users access into your network. For that, you need to obtain an official IP address.
Networks that are fully connected to the Internet must obtain official network addresses. An official address is needed for every system on your network that is directly accessible to remote Internet hosts. Every network that communicates with the Internet, even those that use NAT, have at least one official address, although that address may not be permanently assigned. The first step toward obtaining a block of addresses is to determine how many addresses you need.
Determining your “organizational type” helps you assess your address needs and how you should satisfy those needs. RFC 2901, Administrative Internet Infrastructure Guide, describes four different organizational types:
- Internet end user
A small- to medium-sized organization focused on connecting itself to the Internet. This could be as small as a single user connecting to the Internet with a dynamic address assigned by the ISP’s DHCP server, or as large as a network of thousands of hosts using NAT on the enterprise network and official addresses on a limited number of publicly accessible systems. What categorizes this organizational type is that it wants to use the Internet while limiting the number of systems it makes available to remote users. “Internet end user” organizations obtain official addresses from their ISP. From the point of view of the Internet, all Internet end user organizations appear small because they use only a limited number of official addresses.
- High-volume end user
A medium-sized to large organization that distributes official addresses to systems throughout its network. This type of organization tends to have a distributed management under which divisions within the overall organization are allowed to make systems remotely accessible. “High-volume end user” organizations usually satisfy their address requirements through their ISP or a Local Internet Registry. If the organization needs more than 8,000 addresses, it may go directly to a Regional Internet Registry. While in reality a high-volume end user organization may not be any larger than an Internet end user organization, it appears to be larger from the point of view of the Internet because it exposes more systems to the Internet.
- Internet Service Provider
An organization that provides Internet connection services to other organizations and provides those organizations with official addresses. Even an ISP connects to the Internet in some way. If it connects through another ISP, that ISP is its upstream provider. The upstream provider assigns addresses to the ISP. If it connects directly to a network access point (NAP), as described in Chapter 2, the ISP requests addresses from the Local Internet Registry or the Regional Internet Registry.
- Local Internet Registry
An organization that provides addresses to ISPs. In effect, a Local Internet Registry is an organization that provides addresses to other organizations that provide addresses. A Local Internet Registry must obtain its addresses from a Regional Internet Registry.
RFC 2901 lists four organizational types in order to be thorough, but most organizations are either Internet end users or high-volume end users. In all likelihood, your organization is one of these, and you will obtain all of your addresses from your ISP.
Your ISP has been delegated authority over a group of network addresses and should be able to assign you a network number. If your local ISP cannot meet your needs, perhaps the ISP’s upstream provider can. Ask your local ISP who it receives service from and ask that organization for an address. If all else fails, you may be forced to go directly to an Internet registry. If you are forced to take your request to a registry, you will need to take certain steps before you make the application.
You need to prepare a detailed network topology. The topology must include a diagram that shows the physical layout of your network and highlights its connections to the Internet. You should include network engineering plans that, in addition to diagramming the topology, describe:
Your routing plans, including the protocols you will use and any constraints that forced your routing decisions.
Your subnetting plans, including the mask you will use and the number of networks and hosts you will have connected during the next year. RFC 2050, Internet Registry IP Allocation Guidelines, suggests the following details in your subnet plan:
A table listing all subnets.
The mask for each subnet. The use of variable-length subnet masks (VLSMs) is strongly encouraged. VLSMs are described later in this chapter under “Defining a Subnet Mask.”
The estimated number of hosts.
A descriptive remark explaining the purpose of each subnet.
The biggest challenge is accurately predicting your future requirements for addresses. If you have previously been assigned an address block, you may be required to provide a history of how that address block was used. Even if it is not requested by the Internet registry, a history can be a helpful tool for your own planning. Additionally, you will be asked to prepare a network deployment plan. This plan typically shows the number of hosts you currently have that need official addresses and the number you expect to have in six months, one year, and two years.
One factor used to determine how much address space is needed is the expected utilization rate. The expected utilization rate is the number of hosts assigned official addresses divided by the total number of hosts possible for the network. The deployment plans must show the number of hosts that will be assigned addresses over a two-year period. The total number of possible hosts can be estimated from the total number of employees in your organization and the number of systems that have been traditionally deployed per employee. Clearly you need to have a global knowledge of your organization and its needs before applying for an official address assignment.
In addition to providing documentation that justifies the address request, obtaining an official address requires a formal commitment of resources. Most address applications require at least two contacts: an administrative contact and a technical contact. The administrative contact should have the authority to deal with administrative issues ranging from policy violations to billing disputes. The technical contact must be a skilled technical person who can deal with technical problems and answer technical questions. The registries require that these contacts live in the same country as the organization that they represent. You must provide the names, addresses, telephone numbers, and email addresses of these people. Don’t kid yourself—these are not honorary positions. These people have targets on their backs when things go wrong.
The registry includes this contact information in the whois database, which provides publicly available contact
information about the people responsible for networks. Once your
name is in the whois database,
you’re given a NIC handle, which is a unique identifier linked to
your whois database record. For
example, my NIC handle is cwh3.
Many official applications request your NIC handle.
In addition to human resources, you need to commit computer resources. You should have systems set up, running, and ready to accept the new addresses before you apply for official addresses.
When all of the background work is done, you’re ready to present your case to an Internet registry. A three-level bureaucracy controls the allocation of IP addresses:
- IANA
The Internet Assigned Numbers Authority allocates large blocks of addresses to regional Internet registries.
- Regional Internet Registry
Regional Internet Registries (IRs) have been given authority by the IANA to allocate addresses within a large region of the world. There are three IRs:
- Local Internet Registry
Local IRs are given authority, either by IANA or by a regional IR, to allocate addresses within a specific area. An example might be a national registry or a registry created by a consortium of ISPs.
Regardless of how much address space you need, you should start at the bottom of the hierarchy and work your way up. Always start with your local ISP. If they cannot handle your needs, ask them if there is a local IR that can help you. As a last resort, take your request to the regional IR that serves your part of the world.
If you’re in the APNIC region, first fill out the membership application. The APNIC membership application is available at http://www.apnic.net/member/application.html. Once you become a member of APNIC, you can request an address.
ARIN does not require that you become a member before applying for an address. If you’re a high-volume end user, use the application form at http://www.arin.net/templates/networktemplate.txt to apply for an address. If you’re an ISP, use http://www.arin.net/templates/isptemplate.txt. In either case, send the completed application to hostmaster@arin.net.
End user organization in the RIPE region must use a local IR. RIPE only allocates addresses to local IRs that are members of RIPE. End user organizations cannot apply to RIPE for address allocations. See the document ftp://ftp.ripe.net/ripe/docs/ripe-159.txt for more information.
Regardless of where your network is located, the most important thing to remember is that most organizations never have to go through this process because they do not want to expose the bulk of their computers to the Internet. For security reasons, they use private address numbers for most systems and have only a limited number of official IP addresses. That limited number of addresses can usually be provided by a local ISP.
When you obtain an official IP address, you should also apply for an in-addr.arpa domain. This special domain is sometimes called a reverse domain. Chapter 8 contains more information about how the in-addr.arpa domain is set up and used, but basically the reverse domain maps numeric IP addresses into domain names. This is the reverse of the normal domain name lookup process, which converts domain names to addresses. If your ISP provides your name service or assigned you an address from a block of its own addresses, you may not need to apply for an in-addr.arpa domain on your own. Check with your ISP before applying. If, however, you obtain a block of addresses from a Regional Internet Registry, you probably need to get your own in-addr.arpa domain. If you do need to get a reverse domain, you will register it with the same organization from which you obtained your address assignment.
For address blocks obtained from APNIC, use the form ftp://ftp.apnic.net/apnic/docs/in-addr-request and mail the completed form to domreg@rs.apnic.net.
For address blocks obtained from ARIN, use the form http://www.arin.net/templates/modifytemplate.txt and mail the completed form to hostmaster@arin.net.
For address blocks obtained from RIPE, a domain object needs to be entered into the RIPE database. Mail the completed object to auto-inaddr@ripe.net.
As an example, assume that your network is located in the RIPE region. You would need to provide the information needed to create a RIPE domain object for your network. The domain object for the RIPE database illustrates the type of information that is required to register a reverse domain. The RIPE database object has ten fields:
- domain:
This is the domain name. How reverse domain names are derived is described in detail in Chapter 8, but the name is essentially the address reversed with in-addr.arpa added to the end. For our 172.16/16 address allocation, the reverse domain name is 16.172.in-addr.arpa.
- descr:
A text description of the domain. For example, “The address allocation for wrotethebook.com.”
- admin-c:
- tech-c:
- zone-c:
The NIC handle of the domain administrator, also called the zone contact.
- nserver:
- nserver:
The name or address of a slave server for this domain.
- nserver:
For RIPE, this third server is always ns.ripe.net.
- changed:
The email address of the maintainer who submitted this database object and the date it was submitted.
- source:
For addresses allocated by RIPE, the value of this field is always RIPE.
Again, the most important thing to note about reverse address registration is that most organizations don’t have to do this. If you obtain your address from your ISP, you probably do not have to take care of this paperwork yourself. These services are one of the reasons you pay your ISP.
So far we have been discussing network numbers. Our imaginary company’s network was assigned network number 172.16.0.0/16. The network administrator assigns individual host addresses within the range of IP addresses available to the network address; i.e., our administrator assigns the last two bytes of the four-byte address.[36] The portion of the address assigned by the administrator cannot have all bits 0 or all bits 1; i.e., 172.16.0.0 and 172.16.255.255 are not valid host addresses. Beyond these two restrictions, you’re free to assign host addresses in any way that seems reasonable to you.
Network administrators usually assign host addresses in one of two ways:
- One address at a time
Each individual host is assigned an address, perhaps in sequential order, through the address range.
- Groups of addresses
Blocks of addresses are delegated to departments within the organization, which then assign the individual host addresses.
The assignment of groups of addresses is most common when the network is subnetted and the address groups are divided along subnet boundaries. But assigning blocks of addresses does not require subnetting. It can be just an organizational device for delegating authority. Delegating authority for groups of addresses is often very convenient for large networks, while small networks tend to assign host addresses one at a time. No matter how addresses are assigned, someone must retain sufficient central control to prevent duplication and to ensure that the addresses are recorded correctly on the domain name servers.
Addresses can be assigned statically or dynamically. Static assignment is handled through manually configuring the boot file on the host computer. Dynamic address assignment is always handled by a server, such as a DHCP server. One advantage of dynamic address assignment is that the server will not accidentally assign duplicate addresses. Thus, dynamic address assignment is desirable not only because it reduces the administrator’s workload but also because it reduces errors.
Before installing a server for dynamic addressing, make sure it is useful for your purposes. Dynamic PPP addressing is useful for servers that handle many remote dial-in clients that connect for a short duration. If the PPP server is used to connect various parts of the enterprise network and has long-lived connections, dynamic addressing is probably unnecessary. Likewise, the dynamic address assignment features of DHCP are of most use if you have mobile systems in your network that move between subnets and therefore need to change addresses frequently. See Chapter 6 for information on PPP, and Chapter 3 and Chapter 9 for details about DHCP.
Clearly, you must make several decisions about obtaining and assigning addresses. You also need to decide what bit mask will be used with the address. In the next section we look at the subnet mask, which changes how the address is interpreted.
As the prefix number indicates, a network address is assigned with a specific address mask. For example, the prefix of 16 in the network address 172.16.0.0/16 means that ARIN assigned our imaginary network the block of addresses defined by the address 172.16.0.0 and the 16-bit mask 255.255.0.0.[37] Unless you have a reason to change the interpretation of your assigned network number, you do not have to define a subnet mask. Chapter 2 described the structure of IP addresses and touched upon the reasons for subnetting. The decision to subnet is commonly driven by topological or organizational considerations.
The topological reasons for subnetting include:
- Overcoming distance limitations
Some network hardware has very strict distance limitations. The original 10 Mbps Ethernet is the most common example. The maximum length of a “thick” Ethernet cable is 500 meters; the maximum length of a “thin” cable is 300 meters; the total length of a 10 Mbps Ethernet, called the maximum diameter, is 2500 meters.[38] If you need to cover a greater distance, you can use IP routers to link a series of Ethernet cables. Individual cable still must not exceed the maximum allowable length, but using this approach, every cable is a separate Ethernet. Therefore the total length of the IP network can exceed the maximum length of an Ethernet.
- Interconnecting dissimilar physical networks
IP routers can be used to link networks that have different and incompatible underlying network technologies. Figure 4-1 later in this chapter shows a central token ring subnet, 172.16.1.0, connecting two Ethernet subnets, 172.16.6.0 and 172.16.12.0.
- Filtering traffic between networks
Local traffic stays on the local subnet. Only traffic intended for other networks is forwarded through the gateway.
Subnetting is not the only way to solve topology problems. Networks are implemented in hardware and can be altered by changing or adding hardware, but subnetting is an effective way to overcome these problems at the TCP/IP level.
Of course, there are non-technical reasons for creating subnets. Subnets often serve organizational purposes such as:
- Simplifying network administration
Subnets can be used to delegate address management, troubleshooting, and other network administration responsibilities to smaller groups within the overall organization. This is an effective tool for managing a large network with a limited staff. It places the responsibility for managing the subnet on the people who benefit from its use.
- Recognizing organizational structure
The structure of an organization (or simply office politics) may require independent network management for some divisions. Creating independently managed subnets for these divisions is preferable to having them go directly to an ISP to get their own independent network numbers.
- Isolating traffic by organization
Certain organizations may prefer to have their local traffic isolated to a network that is primarily accessible only to members of that organization. This is particularly appropriate when security is involved. For example, the payroll department might not want its network packets on the engineering network where some clever person could figure out how to intercept them.
- Isolating potential problems
If a certain segment is less reliable than the remainder of the net, you may want to make that segment a subnet. For example, if the research group puts experimental systems on the network from time to time or experiments with the network itself, this part of the network will be unstable. You would make it a subnet to prevent experimental hardware or software from interfering with the rest of the network.
The network administrator decides if subnetting is required and defines the subnet mask for the network. The subnet mask has the same form as an IP address mask. As described in Chapter 2, it defines which bits form the “network part” of the address and which bits form the “host part.” Bits in the “network part” are turned on (i.e., 1) while bits in the “host part” are turned off (i.e., 0).
The subnet mask used on our imaginary network is 255.255.255.0. This mask sets aside 8 bits to identify subnets, which creates 256 subnets. The network administrator has decided that this mask provides enough subnets and that the individual subnets have enough hosts to effectively use the address space of 254 hosts per subnet. The upcoming Figure 4-1 shows an example of this type of subnetting. Applying this subnet mask to the addresses 172.16.1.0 and 172.16.12.0 causes them to be interpreted as the addresses of two different networks, not as two different hosts on the same network.
Once a mask is defined, it must be disseminated to all hosts on the network. There are two ways this is done: manually, through the configuration of network interfaces, and automatically, through configuration protocols like DHCP. Routing protocols can distribute subnet masks, but in most environments host systems do not run routing protocols. In this case, every device on the network must use the same subnet mask because every computer believes that the entire network is subnetted in exactly the same way as its local subnet.
Because routing protocols distribute address masks for each destination, it is possible to use variable-length subnet masks (VLSMs). Using variable-length subnet masks increases the flexibility and power of subnetting. Assume you wanted to divide 192.168.5.0/24 into three networks: one network of 110 hosts, one network of 50 hosts, and one network of 60 hosts. Using traditional subnet masks, a single subnet mask would have to be chosen and applied to the entire address space. At best, this would be a compromise. With variable-length subnet masks you could use a mask of 255.255.255.128 to create subnets of 126 hosts for the large subnet, and a mask of 255.255.255.192 to create subnets of 62 hosts for the smaller subnets. VLSMs, however, require that every router on the network knows how to store and use the masks and runs routing protocols that can transmit them. (See Chapter 7 for more information on routing.) Routing is an essential part of a TCP/IP network. Like other key components of your network, routing should be planned before you start configuration.
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:
- A network with no gateways to other TCP/IP networks
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.
- A network with a single gateway
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.
- A network with internal gateways to other subnets and a single gateway to the world
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.
- A network with multiple gateways to the world
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 network—for 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).[39] 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.
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 hostmaster@apnic.net.
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 hostmaster@arin.net.
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 hostmaster@ripe.net.
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://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.
To make your network user-friendly, you need to provide a service to convert hostnames into IP addresses. The Domain Name System (DNS) and the host table, explained in Chapter 3, perform this function. You should plan to use both.
To configure a computer, a network user needs to know the domain name, the system’s hostname, and the hostname and address of at least one name server. The network administrator provides this information.
The first item you need for name service is a domain name. Your ISP may be willing to get one for you or to assign you a name within its domain; however, it is likely that you will have to apply for a domain name yourself. You can buy an official domain name from a domain name registrar.
Your domain is not part of the official domain name space until it is registered. Only certain organizations are permitted to officially register a domain name. You need to locate an official registrar and obtain its services to register your domain. The place to start is either http://www.icann.org or http://www.internic.net. Both of these sites provide listings of official registrars.
ICANN is the Internet Corporation for Assigned Names and Numbers, a nonprofit organization created to take over management of some functions previously managed through U.S. government contractors. ICANN oversees the domain name registrars. The ICANN web site provides pointers to various international registrars.
http://www.internic.net is a U.S. government web site designed to point users to official gTLD registrars and to answer any questions Internet users might have about the domain registration process. The imaginary domain used in this book is registered in .com. For .org, .com, or .net domains, this is a good place to start. Figure 4-2 shows part of the alphabetical list of accredited registrars found at http://www.internic.net.
There is not much that differentiates registrars. Domain registration is very inexpensive, usually less than $50 a year, so cost is not much of a factor. Service is also difficult to determine because once a domain is registered, it doesn’t usually require any maintenance. Some administrators like to choose a registrar located close to home, but even this is not really significant in a wired world. Use your own judgment. I frankly can’t find anything to recommend any individual registrar. In the following examples, I used Network Solutions as the registrar, in part because they are located a stone’s throw away from my home. You, however, should choose your own registrar.
Once you select a registrar, go to its web site for instructions on registering a domain. At http://www.internic.net, simply clicking the symbol of the registrar should take you to its web site. Most registrars provide an online web form for registering your domain name.
For example, if you select Network Solutions from the list at http://www.internic.net, you go to http://www.netsol.com. There, you are asked to select a domain name. This first step searches the existing domain database system to make sure that the name you want is available. If it isn’t, you’re asked to choose another name. If the name is available, you must provide information about the servers that will be authoritative for the new domain. Some registrars, including Network Solutions, will provide DNS service for your new domain as an optional, extra-cost service. Because we plan to create our own server for the wrotethebook.com domain, we will provide our own server information.
First, you’re asked to provide the name of the person legally
responsible for this domain. This information is used by the registrar
for billing purposes and is included in the whois database that provides contact
information about the people responsible for domains. If you’re
already in the whois database,
you’re asked to provide your NIC handle, which is a unique identifier
linked to your whois database
record. For example, my NIC handle is cwh3.
If you are a new customer, you’re asked to provide the names and addresses of the people who will be the administrative, technical, and billing contacts. These can be three different people or the same person, depending on how your business is organized.
Next, the system prompts for the names and IP addresses of two servers that will be authoritative for this domain. Enter the names of the master and slave servers you have configured for your domain. The servers should already be operational when you fill in this form. If they aren’t, you can pay a little extra and have Network Solutions host your domain until your servers are ready. You shouldn’t enter the names of servers that aren’t yet ready to run because that will cause a lame delegation when the root servers use this information to put pointers into the top-level domain to servers that are not really authoritative. Either preconfigure your servers, even with only minimal information, or pay the somewhat higher fee to reserve your domain name until your servers are ready.
Check the information. Pay the bill. Now you’re ready to run your own domain.
Once you have a domain name, you are responsible for assigning hostnames within that domain. You must ensure that hostnames are unique within your domain or subdomain, in the same way that host addresses must be unique within a network or subnet. But there is more to choosing a hostname than just making sure the name is unique; it can be a surprisingly emotional issue. Many people feel very strongly about the name of their computer because they identify their computer with themselves or their work.
RFC 1178 provides excellent guidelines on how to choose a hostname. Some key suggestions from these guidelines are:
Use real words that are short, easy to spell, and easy to remember. The point of using hostnames instead of IP addresses is that they are easier to use. If hostnames are difficult to spell and remember, they defeat their own purpose.
Use theme names. For example, all hosts in a group could be named after human movements: fall, jump, hop, skip, walk, run, stagger, wiggle, stumble, trip, limp, lurch, hobble, etc. Theme names are often easier to choose than unrestricted names and increase the sense of community among network users.
Avoid using project names, personal names, acronyms, numeric names, and technical jargon. Projects and users change over time. If you name a computer after the person who is currently using it or the project it is currently assigned to, you will probably have to rename the computer in the future. Use nicknames to identify the server function of a system, e.g., www, ftp, ns, etc. Nicknames can easily move between systems if the server function moves. See the description of CNAME records in Chapter 8 for information on creating nicknames.
The only requirement for a hostname is that it be unique within its domain. But a well-chosen hostname can save future work and make the user happier.
Name service is the most basic network service, and it is one service that you will certainly run on your network. There are, however, other services that you should also include in your network planning process.
Three services that are used on many networks are file servers, print servers, and mail servers. The purpose of these services and the protocols they are built on was discussed in Chapter 3. In this section we investigate what information must be passed to the users so that the client systems can be successfully configured and how the network administrator determines that information.
At a minimum, the user needs to know the hostnames of the
network file servers. Using the names and the showmount command, the user can determine
what filesystems are being offered by the servers and who is permitted
to use those filesystems.[40] Without at least the hostname, the user would have to
guess which system offered file service.
A better approach is to give users information that includes
what filesystems are being offered and who should use those
filesystems. For example, if the Unix manpages are made available from
a central server, the users should be informed not to install the
man pages on their local disk
drives and should be told exactly how to access the centrally
supported files.
Whether printers are shared using lp, lpd,
or Samba, the basic information needed to configure the print server’s
clients is the same: the hostname and IP address of the print server
and the name of the printer. The printer make and model may be needed
for non-PostScript printers. Printer security may also require that
the user be given a username and password to access the
printer.
This is the only information needed to configure the client. However, you probably will want to provide your users with additional information about the features, location, and administration of shared printers.
TCP/IP provides the tools you need to create a reliable, flexible electronic mail system. Servers are one of the tools that improve reliability. It is possible to create a peer-to-peer email network in which every end system directly sends and receives its own mail. However, relying on every system to deliver and collect the mail requires that every system be properly administered and consistently up and running. This isn’t practical because many small systems are offline for large portions of the day. Most networks use servers so that only a few systems need to be properly configured and operational for the mail to go through.
The terminology that describes email servers is confusing because all the server functions usually occur in one computer, and all the terms are used interchangeably to refer to that system. This text differentiates between these functions, but it is expected that you will do all of these tasks on one Unix system running sendmail. The terms are used in the following manner:
- Mail server
The mail server collects incoming mail for other computers on the network. It supports interactive logins as well as POP and IMAP so that users can manage their mail as they see fit.
- Mail relay
A mail relay is a host that forwards mail between internal systems and from internal systems to remote hosts. Mail relays allow internal systems to have simple mail configurations because only the relay host needs to have software to handle special mail-addressing schemes and aliases.
- Mail gateway
A mail gateway is a system that forwards email between dissimilar systems. You don’t need a gateway to go from one Internet host to another because both systems use SMTP. You do need a gateway to go from SMTP to X.400 or to a proprietary mailer. In a pure TCP/IP network, this function is not needed.
The mail server is the most important component of a reliable system because it eliminates reliance on the user’s system. A centrally controlled, professionally operated server collects the mail regardless of whether or not the end system is operational.
The relay host also contributes to the reliability of the email system. If mail cannot be immediately delivered by the relay host, it is queued and processed later. An end system also queues mail, but if it is shut down no attempts can be made to deliver queued mail until the system is back online. The mail server and the mail relay are operated 24 hours a day.
The design of most TCP/IP email networks is based on the following guidelines:
Use a mail server to collect mail, and POP or IMAP to deliver the mail to the client.
Use a mail relay host to forward mail. Implement a simplified email address scheme on the relay host.
Standardize on TCP/IP and SMTP. Users who insist on using a proprietary email system should be responsible for obtaining and configuring an SMTP mail gateway for that system in order to connect to your TCP/IP email network.
Standardize on MIME for binary attachments. Avoid proprietary attachment schemes; they just cause confusion when the users of Brand X email cannot read attachments received from Brand Y.
For their client configurations, provide the users with the hostname and IP address of the mail server and the mail relay. The mail server will also require a username and password for each person.
All of the configuration information that you gather or develop through the planning process must be given to the end users to configure their systems. You can use several techniques to help your users configure their systems.
First, you want to relieve end users of as much of the burden of configuration as possible. In Chapter 3 we discussed NIS, NFS, and configuration servers. All of these play a role in simplifying the configuration process, with DHCP having the most important role. DHCP configuration servers provide every parameter needed to configure a TCP/IP client. Everything covered in this chapter—IP address, subnet mask, hostname, domain name, default gateways, and server addresses—can all be provided by DHCP without involving the end user in the process.
One important thing that DHCP does is point clients to the other network servers. The servers require that the client is configured to be a client. For NIS and NFS, the client must have a full basic configuration. Once the client is running, NIS and NFS can provide additional levels of configuration support. NIS provides several system administration databases that include many of the basic configuration values. With NIS, you maintain these databases centrally so that users do not have to maintain them on their Unix desktop systems. NFS can distribute preconfigured system files and documentation files to client systems.
However, even DHCP combined with other servers is not the complete solution. Even DHCP requires that the users know that DHCP is being used so that they do not enter any incorrect values during the initial system installation. Therefore, the network administrator must directly communicate configuration instructions to the administrator of the end system, usually through written documentation or the Web.
To communicate this information, the network administrator will often create a short list of information for the user. When DHCP is used, the information given to the user is often the same for all Unix clients and for all Windows clients. For example, Unix clients might be told to use DHCP to configure the interface, to run NIS, and to run NFS. They might be further directed to mount specific NFS filesystems. Windows clients might be told to run DHCP to configure the interface and to use specific workgroup and NetBIOS names.
Building a TCP/IP network requires careful planning on your part. Once you have made your plans, you must document them and communicate your decisions to the people who will be using your network.
Planning is the first step in configuring TCP/IP. We began this chapter by deciding whether our network will connect to the Internet and exploring how that decision impacts the rest of our planning. We also looked at the basic information needed to configure a physical network: an IP address, a subnet mask, and a hostname. We discussed how to plan routing, which is essential for communicating between TCP/IP networks. We outlined the basic network services, starting with DNS, and discussed file, print, and email servers. Finally, we looked at the different ways that this planning information is communicated from the network administrator to the system administrators and users.
In the chapters that follow, we put these plans into action, starting with the configuration of the network interface in Chapter 6. First, however, we will go inside the Unix kernel to see how TCP/IP is built into the operating system.
[34] The address used in this book (172.16.0.0) is treated as an official address, but it is a private network number set aside for use by non-connected enterprise networks. Feel free to use this address on your network if it will not be connected to the Internet.
[35] A martian is a datagram with an address that is known to be invalid.
[36] The range of addresses is called the address space.
[37] Even though 172.16.0.0 is an RFC 1918 private network number, this text treats 172.16.0.0 as if it were an officially assigned network number, for the sake of example.
[38] The faster the Ethernet, the smaller its network diameter. For this reason, high-speed Ethernet technologies use switches instead of a daisy chain cable to connect nodes.
[39] Refer to the section Section 2.3 for a discussion of autonomous systems.
Get TCP/IP Network Administration, 3rd Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
