TCP/IP-Based Network Services

• Identify the purpose of the following network services: DHCP/BOOTP, DNS, NAT/ICS, WINS, and SNMP.

On its own, TCP/IP provides devices with a means to communicate, but combined with other services, such as the following, it can do even more:

• Dynamic Host Configuration Protocol (DHCP)

• BOOT Protocol (BOOTP)

• Domain Name System (DNS)

• Network Address Translation (NAT) and Internet Connection Sharing (ICS)

• Simple Network Management Protocol (SNMP)

• Windows Internet Name Service (WINS)

Services such as the ones discussed in the following sections provide functionality far beyond the basics of network communication. They provide a means to manage and administer a TCP/IP-based network. Today, it is quite likely that a network of any size will use one or all of the services discussed in the following sections. The first service we'll look at is one of the network administrator's best friends: DHCP.

Dynamic Host Configuration Protocol (DHCP)

Chapter 5 talks briefly about how IP addresses work. What it doesn't mention is that IP addresses can be assigned to devices statically or dynamically. Static IP addressing involves manually configuring the IP address of each system on the network; this is a potentially time-consuming process that provides plenty of opportunity for human error. For this reason, and because the reconfiguration of IP addressing is an equally arduous task, it's possible to have IP addresses assigned to systems automatically through a system called DHCP.

DHCP, which is defined in RFC 2131, allows ranges of IP addresses, known as scopes, to be defined on a system that is running a DHCP server application. When another system configured as a DHCP client is initialized, it asks the server for an address. If all things are as they should be, the server assigns an address to the client for a predetermined amount of time, which is known as the lease from the scope. Figure 6.2 shows a representation of DHCP.

At various points during the lease (normally the 50% and 85% points), the client attempts to renew the lease from the server. If the server is unable to perform a renewal, the lease expires at 100%, and the client stops using the address.

In addition to an IP address and the subnet mask, many other pieces of information can be supplied by the DHCP server, although exactly what can be added depends on the DHCP server implementation. In addition to the address information, the default gateway is often supplied, along with Domain Name Service (DNS) information.

As well as having DHCP supply a random address from the scope, it's also possible to configure it to supply a specific address to a client. Such an arrangement is known as a reservation. Reservations are a means by which you can still use DHCP for a system but at the same time guarantee that it will always have the same IP address.

The advantages of using DHCP are numerous. First, administrators do not have to manually configure each system. Second, human error such as the assignment of duplicate IP addresses is eliminated. Third, DHCP removes the need to reconfigure systems if they move from one subnet to another or if you decide to make a wholesale change of the IP addressing structure. The downsides are that DHCP is a broadcast system that generates network traffic, albeit a very small amount, and that the DHCP server software must be installed and configured. After the initial configuration, though, DHCP is about as maintenance free as a service can get, with only occasional monitoring normally required.

The DHCP Process

When a system that is configured to use DHCP comes onto the network, it broadcasts a special packet that looks for a DHCP server. This packet is known as the DHCPDISCOVER packet. The DHCP server, which is always on the lookout for DHCPDISCOVER broadcasts, picks up the packet and compares the request with the scopes that it has defined. If it finds that it has a scope for the network from which the packet originated, it chooses an address from the scope, reserves it, and sends the address, along with any other information, such as the lease duration, to the client. This is known as the DHCPOFFER packet. Because the client still does not have an IP address, this communication is also achieved via broadcast.

When the client receives the offer, it looks at the offer to determine whether it is suitable. If more than one offer is received, which can happen if there is more than one DHCP server configured, the offers are compared to see which is best. Best in this context can involve a variety of criteria, but is normally the length of the lease. When the selection process is complete, the client notifies the server that the offer has been accepted, through a packet called a DHCPREQUEST packet, at which point the server finalizes the offer and sends the client an acknowledgment. This last message, which is sent as a broadcast, is known as a DHCPACK packet. When the client system has received the DHCPACK, it initializes the TCP/IP suite and is able to communicate on the network. You can see a representation of the DHCP process between a server and a client in Figure 6.3.

Fault-Tolerant DHCP Configurations

It is prudent to have more than one DHCP server to provide fault tolerance; however, you need to consider a number of factors when you use this approach. If multiple servers are used, the scopes defined on each server must not overlap, or else it is highly likely that systems will be assigned duplicate addresses from the different scopes. If you don't have enough addresses to create multiple, nonoverlapping scopes, you should consider configuring the DHCP server functionality on an additional server but not actually enabling the service. That way, if one of the DHCP servers goes down, the other system can be enabled quickly. Thanks to the lease renewal system, having the server down for a short amount of time is unlikely to cause too many problems. This, combined with a robust monitoring system, should ensure that the DHCP service is always available.

Should You Use DHCP?

Given the simplicity of DHCP's setup, the fact that all common network operating systems include a DHCP server free of charge, and the fact that running a DHCP server consumes very little server resources, it's hard to think of an environment in which a DHCP server is not a good idea. Unless you have a very small number of systems (fewer than, say, 10), a DHCP server is a very good idea indeed.

BOOT Protocol (BOOTP)

BOOTP was originally created so diskless workstations could obtain information—such as the TCP/IP address, subnet mask, and default gateway—needed to connect to the network. Such a system was necessary because diskless workstations had no way of storing the information.

When a system that is configured to use BOOTP is powered up, it broadcasts for a BOOTP server on the network. If there is such a server, it compares the MAC address of the system issuing the BOOTP request with a database of entries. From this database, it is able to supply the system with the appropriate information. It can also notify the workstation of a file that it must run on BOOTP.

In the unlikely event that you find yourself using BOOTP, you should be aware that, like DHCP, it is a broadcast-based system. Therefore, routers must be configured to forward BOOTP broadcasts.

Domain Name System (DNS)

DNS performs a very important function on TCP/IP-based networks. It resolves hostnames, such as www.quepublishing.com, to IP addresses, such as 24.67.164.63. Such a resolution system makes it possible for people to remember the names of, and refer to frequently used hosts, using the easy-to-remember hostnames rather than the hard-to-remember IP addresses.

In the days before the Internet, the network that was to become the Internet used a text file called HOSTS to perform name resolutions. The file was regularly updated with changes and distributed to other servers. The following is a sample of some entries from a HOSTS file:

192.168.3.45    server1  s1          #The main
                                     file and
                                     print server
192.168.3.223   mail     mailserver  #The email server

As you can see, the IP address of the host is listed, along with the corresponding hostname. It is possible to add to a HOSTS file aliases of the server names, which in this example are s1 and mailserver. All the entries have to be added manually, and each system that is to perform resolutions has to have a copy of the file.

Even when the Internet was growing at a relatively slow pace, such a mechanism was both cumbersome and prone to error. It was obvious that as the network grew, a more automated and dynamic method of performing name resolution was needed. DNS became that method.

DNS solves the problem of name resolution by offering resolution through servers that are configured to act as name servers. The name servers run DNS server software, which allows them to receive, process, and reply to requests from systems that want to resolve hostnames to IP addresses. Systems that ask DNS servers for a hostname-to-IP address mapping are referred to as resolvers. Figure 6.4 shows an example of the DNS resolution process.

Because the DNS namespace, which is discussed in the following section, is very large, a single server is incapable of holding all the records for the entire namespace. As a result, there is a good chance that a given DNS server might not be able to resolve the request for a certain entry. In this case, the DNS server asks another DNS server if it has an entry for the host.

The DNS Namespace

DNS operates in what is referred to as the DNS namespace. This space has logical divisions organized in a hierarchical structure. At the top level are domains such as .com and .edu, as well as domains for countries, such as .uk (United Kingdom) and .de (Germany). Below the top level are subdomains that are associated with organizations or commercial companies, such as Red Hat and Microsoft. Within these domains, hosts or other subdomains can be assigned. For example, the server ftp.redhat.com would be in the redhat.com domain, or another domain called, say, development, could be created, and hosts could be placed in that (that is, ftp.development.redhat.com). Figure 6.5 shows a graphical representation of a DNS hierarchical namespace.

The lower domains are largely open to use in whatever way the domain name holder sees fit. However, the top-level domains are relatively closely controlled. You can see a selection of the most widely used top-level DNS domain names in Table 6.4. Recently, a number of top-level domains were added, mainly to accommodate the increasing need for hostnames.

^[*] In addition to country-specific domains, many countries have created subdomains that follow roughly the same principles as the original top-level domains (for example, co.uk, .gov.nz).

It should be noted that although the assignment of domain names is supposed to conform to the structure in Table 6.4, the assignment of names is not as closely controlled as you might think. It's not uncommon for some domain names to be used for other purposes. In particular, the .net and .org namespaces have been used for purposes other than what was intended.

Types of DNS Entries

Although the most common entry in a DNS database is an A (ADDRESS) record, which maps a hostname to an IP address, DNS can hold numerous other types of entries, as well. Some of particular note are the MX record, which is used to map entries that correspond to mail exchanger systems; and CNAME, or canonical record name, which can be used to create alias records for a system. A system can have an A record and then multiple CNAME entries for its aliases. A DNS table with all these types of entries might look like this:

fileserve.mycoltd.com  IN   A   192.168.33.2 
email.mycoltd.com      IN   A   192.168.33.7
fileprint.mycoltd.com  IN CNAME fileserver.mycoltd.com
mailer.mycoltd.com     IN  MX  10   email.mycoltd.com

As you can see, rather than map to an actual IP address, the CNAME and MX record entries map to another host, which DNS in turn can resolve to an IP address.

DNS in a Practical Implementation

In a real-world scenario, whether you use DNS is almost a nonissue. If you have Internet access, you will most certainly use DNS, but you are likely to use the DNS facilities of your Internet service provider (ISP) rather than have your own internal DNS server. However, if you operate a large, complex, multiplatform network, you might find that internal DNS servers are necessary. The major network operating system vendors are conscious of the fact that you might need DNS facilities in your organization, so they include DNS server applications with their offerings. It should also be noted that Microsoft Active Directory (see Chapter 9, “Network Operating Systems and Clients”) requires DNS to operate.

It is common practice for workstations to be configured with the IP addresses of two DNS servers for fault-tolerance. You can see an example of this in Figure 6.6.

The importance of DNS, particularly in environments where the Internet is heavily used, cannot be overstated. If DNS facilities are not accessible, the Internet effectively becomes unusable, unless you can remember the IP addresses of all your favorite sites.

Network Address Translation (NAT) and Internet Connection Sharing (ICS)

The need for almost every network, even small ones, to have Internet access has created the need for a mechanism to allow many computers to access the Internet through a single connection. Two mechanisms that make this possible are NAT and ICS.

NAT

The basic principle of NAT is that many computers can “hide” behind a single IP address. The main reason we need to do this (as you will see later in this chapter, in the section “IP Addressing”) is because there simply aren't enough IP addresses to go around. Using NAT means that only one registered IP address is needed on the external interface of the system that is acting as the gateway between the internal and external networks.

NAT allows you to use whatever addressing scheme you like on your internal networks, although it is common practice to use the private address ranges, which are discussed later in the chapter, in the section “Identifying the Differences Between Public and Private Networks.”

How NAT Works

When a system is performing NAT service, it funnels the requests that are given to it to the Internet. To the remote host, the request looks like it is originating from a single address. The system that is performing the NAT function keeps track of who asked for what and makes sure that when the data is returned, it is directed to the correct system. Servers that provide NAT functionality do so in different ways. For example, it is possible to statically map a specific internal IP address to a specific external one (known as the one-to-one NAT method), so that outgoing requests are always tagged with the same IP address. Alternatively, if you have a group of public IP addresses, you can have the NAT system assign addresses to devices on a first-come, first-served basis. Either way, the basic function of NAT is the same. Figure 6.7 shows a representation of NAT.

ICS

Although ICS is discussed separately from NAT, it is nothing more than an implementation of NAT on Windows platforms. More specifically, Windows Me, Windows XP, and Windows 2000 include the ICS feature, which makes it simple for users to create shared Internet connections.

Because ICS was intended as a simple mechanism for a small office network or a home network to share a single Internet connection, configuration is simple. However, simplicity is also the potential downfall of ICS. ICS provides no security, and the system providing the shared connection is not secure against outside attacks. For that reason, ICS should be used only when there are no other facilities available.

Simple Network Management Protocol (SNMP)

SNMP allows network devices to communicate information about their state to a central system. It also allows the central system to pass configuration parameters to the devices.

Components of SNMP

In an SNMP configuration, a central system known as a manager acts as the central communication point for all the SNMP-enabled devices on the network. On each device that is to be managed and monitored via SNMP, software called an SNMP agent is set up and configured with the IP address of the manager. Depending on the configuration, the SNMP manager is then able to communicate with and retrieve information from the devices running the SNMP agent software. In addition, the agent is able to communicate the occurrence of certain events to the SNMP manager as they happen. These messages are known as traps. Figure 6.8 shows how an SNMP system works.

SNMP Management Systems

An SNMP management system is a computer running a special piece of software called a Network Management System (NMS). These software applications can be free, or they can cost thousands of dollars. The difference between the free applications and those that cost a great deal of money normally boils down to functionality and support. All NMS systems, regardless of cost, offer the same basic functionality. Today, most NMS applications use graphical maps of the network to locate a device and then query it. The queries are built in to the application and are triggered by a point and click. You can actually issue SNMP requests from a command-line utility, but with so many tools available, it is simply not necessary.

Using SNMP and an NMS, it is possible to monitor all the devices on a network, including switches, hubs, routers, servers, and printers, as well as any device that supports SNMP, from a single location. Using SNMP, you can see the amount of free disk space on a server in Jakarta or reset the interface on a router in Helsinki—all from the comfort of your desk in San Jose. Such power, though, does bring with it some considerations. For example, because an NMS gives you the ability to reconfigure network devices, or at least get information from them, it is common practice to implement an NMS on a secure workstation platform such as Linux or Windows NT/2000 and to place the NMS PC in a secure location.

SNMP Agents

Although the SNMP manager resides on a PC, each device that is part of the SNMP structure also needs to have SNMP functionality enabled. This is performed through a software component called an agent.

An SNMP agent can be any device that is capable of running a small software component that facilitates communication with an SNMP manager. SNMP agent functionality is supported by almost any device that is designed to be connected to a network.

As well as providing a mechanism for managers to communicate with them, agents are also able to tell SNMP managers when something happens. When a certain condition is met on a device that is running an SNMP agent, a trap is sent to the NMS, and the NMS then performs an action, depending on the configuration. Basic NMS systems may sound an alarm or flash a message on the screen. Other, more advanced, products may send a pager message, dial a cell phone, or send an email message.

Management Information Bases (MIBs)

Although the SNMP trap system may be the most commonly used aspect of SNMP, the manager-to-agent communication is not just a one-way street. In addition to being able to read information from a device using the SNMP commands Get and Get Next, SNMP managers can also issue the Set command. Having just three commands might make SNMP seem like a very limited mechanism, but this is not the case. The secret of SNMP's power is in how it uses those three commands.

To demonstrate how SNMP commands work, imagine that you and a friend each have a list on which the following four words are written: four, book, sky, and table. If you, as the manager, ask your friend for the first value, she, acting as the agent, will reply “four.” This is analogous to an SNMP Get command. Now, if you ask for the next value, she would reply “book.” This is analogous to an SNMP Get Next command. If you then say “set green,” and your friend changes the word book to green, you will have performed the equivalent of an SNMP Set command. Sound simplistic? Well, if you can imagine expanding the list to include 100 values, you can see how you could navigate and set any parameter in the list, using just those three commands. The key, though, is to make sure that you and your friend have exactly the same list, which is where Management Information Bases (MIBs) come in.

SNMP uses databases of information called MIBs to define what parameters are accessible, which of the parameters are read-only, and which are capable of being set. MIBs are available for thousands of devices and services, covering every imaginable need.

To ensure that SNMP systems offer cross-platform compatibility, MIB creation is controlled by the International Organization for Standardization (ISO). An organization that wants to create a MIB can apply to the ISO. The ISO then assigns the organization an ID under which it can create MIBs as it sees fit. The assignment of numbers is structured within a conceptual model called the hierarchical name tree. Figure 6.9 shows an example of the MIB hierarchical name tree.

Table 6.5 extends the hierarchical tree further, to show the MIB entry on a Windows NT server, which corresponds to the number of DHCP offers that have been made by that server.

SNMP Communities

Another feature of SNMP that allows for manageability is communities. SNMP communities are logical groupings of systems. When a system is configured as part of a community, it communicates only with other devices that have the same community name. In addition, it accepts Get, Get Next, or Set commands only from an SNMP manager with a community name it recognizes. There are typically two communities defined by default: a public community that is intended for read-only use and a private community that is intended for read and write operations.

Whether you use SNMP depends on how many devices you have and how distributed your network infrastructure is. Even in environments that have just a few devices, SNMP can be very useful because it can act as your eyes and ears, notifying you in the event of a problem on the network.

Windows Internet Name Service (WINS)

On Windows networks, a system called WINS enables Network Basic Input/Output System (NetBIOS) names to be resolved to IP addresses.

NetBIOS name resolution is necessary on Windows networks so that systems can locate and access each other by using the NetBIOS computer name rather than the IP address. It's a lot easier for a person to remember that Mary's PC is called Mary than to remember its IP address, 192.168.2.34. However, even though the system can be accessed, from the user's perspective using the NetBIOS's computer name, this name still needs to be resolved to an IP address and subsequently to a MAC address (by ARP).

There are three ways a system can perform NetBIOS name resolution:

• Statically— A file called LMHOSTS can be manually updated with NetBIOS machine name-to-IP address mappings. It's also possible to make an entry in the file that points to a centrally located LMHOSTS file.

• Via broadcast— When a resolution is needed, the system can broadcast on the local network for the target host. The broadcast is picked up by all the devices on the local network, and each device looks at the target NetBIOS name to determine whether it is the target system. Only the intended target replies to the request.

• By using dynamic name resolution— When a WINS server is installed, WINS clients called resolvers are able to pass requests directly to the WINS server and have those requests answered from a database of records.

Of these three methods, the first requires that you manually configure at least one file with the entries. As you can imagine, this can be a time-consuming process, particularly if the systems on the network change frequently. You can forget using DHCP with static resolution. Unless you make reservations for each and every system on the network, the LMHOSTS file is likely to fall out of sync with the network fairly quickly.

The second method, broadcasts, works well in a small network environment, but if a large number of devices are on the network, the broadcast traffic can quickly become a problem. Add to that the fact that you can't browse across network segments (which is discussed shortly), and you'll see that the broadcast method is limited in its applications.

There are two basic reasons you might use a WINS server:

• To reduce broadcasts— In a network that does not have a WINS server, a system uses broadcasts to locate another system. On a large segment, these broadcasts can have a significant impact on network traffic.

• To communicate across routers— Because NetBIOS resolutions are broadcast based, they are not forwarded by routers. This makes it impossible for a NetBIOS name to be resolved from one segment to another. Although you can configure routers to forward these broadcasts, a more common practice is simply to use WINS. Because systems are configured with the address of the WINS server, it is possible for the client systems to query the server directly for name resolutions.

WINS in the Real World

WINS is a dynamic system. Each time a system is brought on to the network, it registers itself with a WINS server. When the system is taken off the network (that is, when it is powered down), it deregisters itself with the WINS server to make sure that the WINS database is kept up-to-date. For this and many other reasons, it is important that Windows systems are powered down in the correct manner.

It is possible to tune the NetBIOS name resolution by configuring the resolvers to use a specific order of resolution. For example, you can direct them to attempt a broadcast first and then contact a WINS server. Or you can direct them to only use a WINS server, and dispense with the broadcast resolution methods completely.

Although there are many environments in which you'll find WINS servers implemented, Microsoft is moving away from WINS as a resolution method and turning its focus to DNS. In particular, Windows 2000 offers DDNS, which basically eliminates the need for WINS.

REVIEW BREAK: TCP/IP Service Summary

Table 6.6 helps you quickly identify the purpose and function of each of the TCP/IP services covered in the previous sections.