by Don Benage
This chapter describes TCP/IP (Transmission Control Protocol/Internet Protocol), a network protocol and related applications that have gained wide acceptance and use over the last decade. TCP/IP is the network protocol used on the Internet, which by itself makes the topic worthy of study. It is also very useful in private networks, especially as they grow in size.
The chapter begins with a brief tutorial on TCP/IP. Those familiar with the subject from a background in UNIX networking can skip this section, or at least just skim it. No claims are made of academic rigorñit is intended to be a practical and accessible overview for those interested in a little background material. Nothing presented in the tutorial is essential for installing and using TCP/IP, although it may help you to understand some of the terminology used by TCP/IP aficionados and why things are done the way they are.
TCP/IP is a suite of network protocols that describe precisely how information can be transmitted from one computer to one or more additional computers. It is designed to operate in environments where the conditions are not particularly suitable for this task, and therefore has a strong error detection and correction capability. Most often when the term TCP/IP is used, it is meant to denote not only the protocol suite itself, but also a group of compatible applications and utilities that have been created and used to implement and test the protocols.
TCP/IP has been developed cooperatively by members of the Internet community using a proposal and peer-review process involving documents called Request for Comments (RFCs). A person or group will propose a design and publish an RFC describing that design. It will be reviewed by other members of the community, some of whom may refine the proposal with additions of their own, again put forth in an RFC. Some of these designs are implemented, tested, and refined even further. Eventually an RFC that describes a set of standards will be developed, and manufacturers will design products that conform to one or more of these RFCs.
This process turns out to be quite effective, over time, at discovering and eliminating problems. The RFC process is ongoing, and existing RFCs are available for public review. You can find them and download them without charge from various locations on the Internet, although average computer users have little use for them. They are primarily intended for individuals and organizations who are designing products and services to be used on the Internet. Some of them include useful information for Internet users, and do not describe standards at all. RFC 1118, The Hitchhikers Guide to the Internet, is an example of this type of RFC.
TIP: You can find RFCs on the Internet by using any of the large search engines on the World Wide Web. For example, use your Web browser to connect to http://www.yahoo.com, and search for RFC.
Some of the terminology used in association with TCP/IP may be confusing at first. The term host is used to describe a component on a network, such as a computer or router. In some circles, the term host has the connotation of a large computer system, such as an IBM mainframe computer. In the context of TCP/IP discussions, a host can be a desktop personal computer or laptop, or a multiprocessor supercomputer.
The term gateway is used to describe a piece of equipment commonly referred to as a router, which is used to create wide area network (WAN) connections to remote locations. It should not be confused with its other connotation, that of a connection to a computer system using a different operating system or communications protocol. For the purposes of TCP/IP, your default gateway is nothing more than the router that connects your local area network (LAN) to the rest of your WAN.
Finally, the term Internet itself can be confusing. Internet, with a capital I, is generally used to describe the worldwide collection of public and private networks that link educational institutions, research facilities, commercial organizations, government agencies, and military sites. The term internet, with a lowercase i, refers to any collection of TCP/IP networks linked together with routers. Private internets, or internetworks, are increasingly referred to with the term intranet. For more extensive coverage of the Internet, see Chapter 19, "I-Net Tools and Techniques."
There are many reasons why the use of TCP/IP is growing. During the last decade, many organizations implemented LANs in offices and sites throughout their facilities. Eventually, they desired to connect these LANs together into WANs. In addition, a growing number of organizations have started to view the WAN as a strategic resource, critical to the success of their efforts. To implement these views, they need a protocol capable of managing large numbers of systems in a routed, WAN environment. This is precisely what TCP/IP was designed to deliver.
TCP/IP is also the protocol used on the Internet and is therefore useful for those individuals and organizations who want to attach directly to the Internet, or access it through a service provider. Furthermore, it allows a high degree of interoperability between dissimilar systems, such as computers running Windows NT and UNIX operating systems. It also provides an environment that supports the development of powerful applications using feature-rich programmatic interfaces. For all these reasons, TCP/IP is a technology whose time has come.
The central capability provided by TCP/IP, as already mentioned, is a transmission facilityñmoving information from point A to point B. The transmission of information must be done in a manner that takes into account the involvement of both computers and humans. The computers must be able to send and receive information accurately and quickly, and their human operators must easily be able to specify what actions they desire and understand the results.
The fact that computers and humans require different naming schemes for the elements of a network is the source of much of the difficulty surrounding its operation. Computers need to have a unique address for each component on the network to accurately send information to just those components for which it was intended. Humans also need to be able to specify the computer they want to communicate with, and to name their own computer system so that they can describe it to other humans, especially if they are sharing information on the network. But the kind of name appropriate for computer use is much different from that suitable for humans.
This leads to one of the central problems that TCP/IP must solveñname and address resolution. Three types of names are designed for humans, and two addresses are designed primarily for computers and their operating systems and applications. Matching a name with its corresponding address is more difficult than it might at first appear. The types of names involved in a Windows NT network using TCP/IP are the following:
NOTE: You can contact InterNIC via e-mail at [email protected] or by phone. In the US, call 1-800-444-4345. In Canada or elsewhere, call 1-619-455-4600. From overseas, you may need to use a country code to access the US when dialing. Or, visit their Web server at http://rs-internic.com.
NOTE: You can use the same name for your host name and NetBIOS name, which can eliminate confusion when entering commands. Each name still retains its own role, however, and the applications that use these names are each designed for a particular type of name (either NetBIOS or host name, but rarely both).
See "Name Resolution in the TCP/IP Environment," [Ch 10]
During the execution of a network command, the application or operating system must eventually discover the machine address of the devices involved. Because the machine address is almost never entered into an application by users, some means of resolving the host name, NetBIOS name, or IP address to machine address must be used. A variety of mechanisms for this purpose have been developed, and they are discussed in this section.
Separate mechanisms exist for each type of name and sometimes more than one process may occur. For example, an application that knows the host name may first resolve this to an IP address and then to a machine address. The mechanisms for resolving each type are presented in the following list and discussed in more detail in the next section. Some of these mechanisms are based upon standards as defined in RFCs or other standards documents, and others are Microsoft-specific methods. IP addresses are resolved to machine addresses using the following methods:
NOTE: There are other approaches for IP address to machine address resolution, but they are not implemented by Windows NT. The use of ARP is the most common method of IP address resolution.
Host names are resolved to IP addresses using the methods in the following list. If the computer is configured to use all methods, they will be tried in the following order:
1. HOSTS file
2. Domain Name Server (DNS)
3. Windows Internet Name Service (WINS)
4. A local broadcast
5. LMHOSTS file
NetBIOS names are resolved to IP addresses using the methods presented in the following list. If the computer is configured to use all methods, they will be tried in the following order:
1. A NetBIOS name cache in the computer's memory
2. Windows Internet Name Service (WINS)
3. A local broadcast
4. LMHOSTS file
5. HOSTS file
6. Domain Name Server (DNS)
Name resolution mechanisms for host names and NetBIOS names are similar, but they are carried out in a different order. The mechanisms used can vary depending on how the computer is configured.
This section provides an overview of how the various name and address resolution mechanisms function. Some of these mechanisms include many options and implementation details. This overview presents only the most salient points to assist in a general understanding of the processes involved. Additional information is provided in volume 2 of the Windows NT Resource Kit, Windows NT Networking Guide.
See "Name Resolution in the TCP/IP Environment," [Ch 10]
ARP
The Address Resolution Protocol is part of the TCP/IP protocol suite. It is only necessary to use ARP on a TCP/IP address that is known to reside on the local physical network. To resolve an IP address for a host on the same local network, the following steps are taken:
See "Routing in Windows NT 4.0," (Ch 9)
1. The computer checks its own ARP cache, a list of IP addresses, and corresponding hardware addresses that it dynamically manages in memory as it operates.2. If the address is not found in the ARP cache, an ARP request is broadcast on the local network (broadcasts are not generally forwarded through routers). This request includes its own hardware address and IP address, and the IP address that needs to be resolved. The ARP request is an IP broadcast message. On an Ethernet network, this will map to an Ethernet broadcast.
3. Each computer or host on the local network receives the ARP request. If the IP address does not match its own address, the request is discarded and ignored. If it does match, the host responds with an ARP reply directly (not broadcast) to the original host with its own hardware address. It also updates its own ARP cache with the hardware address of the original host.
4. The original host receives the reply and updates its own ARP cache for future use. A communications link can now be established.
If a destination machine is not on the same physical network as the sending machine, there is no need to resolve the machine address of the destination machine. The packet will be routed at the IP level trough an intermediate router. The IP portion of TCP/IP will need to resolve the MAC address of the router so that the packet can be forwarded to the router.
Local Broadcasts
The Microsoft implementation of TCP/IP uses an enhanced version of the b-node (broadcast method) of NetBIOS name resolution described in RFC 1001/1002. Broadcasts are used only after first checking the NetBIOS name cache and attempting to contact a WINS server if configured for WINS. (See "Windows Internet Name Service (WINS)" later in the chapter.) Broadcasts use an address that all computers on the local network segment will accept and evaluate. Three broadcasts are sent before the next mechanism is attempted.
TIP: The contents of the NetBIOS cache on a computer can be listed by typing the command nbtstat -c. Other uses for the nbtstat command are available by typing nbtstat -?.
LMHOSTS File
The LMHOSTS file is a text file that lists IP addresses and the corresponding NetBIOS name for remote hosts only (because active local hosts will be discovered by WINS or broadcast first). It is closely related to the HOSTS file described in the following section. The LMHOSTS file is located by default in the \systemroot\SYSTEM32\DRIVERS\ETC directory. It is specifically designed to resolve NetBIOS names and is consulted by traditional TCP/IP utilities (if they accept NetBIOS names) only after trying the NetBIOS name cache, WINS, and b-node broadcasts.
The file is searched sequentially from top to bottom so that frequently used names (such as servers) should generally be listed near the top. By using the #INCLUDE directive in the file, you can load entries from a centralized copy of the LMHOSTS file from a server. A sample LMHOSTS file included with Windows NT Server provides examples of this, and other, directives and describes their usage. Additional information is provided in volume 2 of the Windows NT Resource Kit, Windows NT Networking Guide.
TIP: You can create entries with the #PRE directive in the LMHOSTS file and use the following command to manually preload these entries into your NetBIOS name cache, thereby avoiding the need to perform broadcasts (even without WINS):nbtstat -R
Be sure that you have enabled LMHOSTS lookup in the TCP/IP configuration dialog box if you want to use this technique. See "Installing and Configuring TCP/IP for Windows NT Server" later in this chapter for more information.
HOSTS File
The HOSTS file (see also "LMHOSTS File" in the preceding section) is a text file that lists IP addresses and the corresponding host name. This file is located by default in the \systemroot\SYSTEM32\DRIVERS\ETC directory. It is designed to resolve TCP/IP host names and FQDNs and is the first mechanism consulted by traditional TCP/IP utilities. It is consulted by NetBIOS-based utilities only after trying the NetBIOS name cache, WINS, b-node broadcasts, and the LMHOSTS file. The HOSTS file is search sequentially from top to bottom so that frequently used names (such as servers) should generally be listed near the top. The HOSTS file must be located on the local computer.
Domain Name Service (DNS)
Domain Name Service is an IP address resolution method frequently used on UNIX systems. One or more DNS servers are implemented and can then be consulted to resolve names not listed in the local HOSTS (or LMHOSTS) file. Windows NT can be configured to use DNS. Microsoft has included a DNS in release 4.0 of Windows NT Server. Configuring Windows NT to use DNS for name resolution is described in the section "Installing and Configuring TCP/IP for Windows NT Server" later in this chapter.
See "Domain Name System Name Resolution," [Ch 10]
Dynamic Host Configuration Protocol (DHCP)
DHCP is a protocol that enables IP addresses to be automatically assigned from a pool of available IP addresses centrally stored and managed on one or more servers. In addition, other TCP/IP related information, such as the subnet mask and default gateway, can also be retrieved. DHCP servers do not share information with other DHCP servers or with DNS servers. The IP address pool managed by a DHCP server must be entirely owned by that server. No other server or individual should be able to assign an address from that pool.
DHCP is defined in RFCs 1533, 1534, 1541, and 1542. It is an extension to, and builds upon, the BOOTP protocol defined in RFC 951, which automatically assigns IP addresses to diskless workstations. Microsoft has designed a server-based service, an administration utility, and client software that implement the DHCP protocol. The installation and configuration of DHCP on Windows NT Server is covered in detail later in this chapter in the section "Implementing Dynamic Host Configuration Protocol (DHCP)."
Windows Internet Name Service (WINS)
WINS is a NetBIOS Name Server (NBNS) implemented as a Windows NT service. Also included with Windows NT Server are an administration utility and client software. It can be used with or without DHCP to register NetBIOS names and resolve them to IP addresses without using b-node broadcasts, which can be problematic in large networks. Name resolution requests are resolved using directed datagrams (network packets) that are routable.
WINS is a dynamic name service that tracks network names as users start and stop client workstations. Multiple WINS servers can be configured to provide redundancy and to improve name resolution performance. Changes to the names database on one WINS server are replicated to other WINS servers set up as Push or Pull partners. The installation and configuration of WINS on Windows NT Server is covered in detail in Chapter 10, "Name Resolution with Windows NT 4.0."
See "Implementing Windows Internet Name Service (WINS)," [Ch 10]
Now that you have had a brief overview of TCP/IP and some of its elements, you are ready to learn how to install TCP/IP on Windows NT Server.
This section teaches you how to install TCP/IP on a Windows NT Server computer. You learn how to install the protocol suite and all the options offered by Microsoft. A variety of client-based utilities for the TCP/IP suite are included in Microsoft's implementation, including connectivity such utilities as Finger, lpr, rcp, rexec, rsh, Telnet, and tftp.
Both client and server support is provided for FTP (file transfer protocol). These utilities enable a Windows NT server or Windows NT workstation to interact with UNIX workstations and other platforms supporting TCP/IP. Notably missing from the connectivity utilities is support for NFS, the network file system, but this is available from at least three third-party software companies for the Windows NT platform. Microsoft has suggested it may include NFS in a future release of Windows NT Server. A number of diagnostic utilities are also offered including arp, hostname, ipconfig, lpq, nbtstat, netstat, ping, route, and tracert. An SNMP agent, implemented as a Windows NT service, enables a remote network management console, such as Sun Net Manager or HP Open View.
TCP/IP can be installed during the original setup of Windows NT Server, or it can be added at a later time using the Network icon in the Control Panel. In this section, you learn how to add TCP/IP to an existing Windows NT Server installation. Adding it during the initial setup is an almost identical process, so the following steps should still be helpful. You simply follow these instructions when you get to the network portion of SETUP.
To install TCP/IP and related services, follow these steps:
In addition to the base protocol, you may want to install some of the TCP/IP specific services. These services include TCP/IP printing, the simple TCP/IP, and the SNMP services (SNMP is the Simple Network Management Protocol that allows the configuration and monitoring of network devices). The TCP/IP printing services allow the user to print to TCP/IP printers.This is most useful when printing to existing UNIX host printers.The simple TCP/IP services installs a FTP server and a telnet server. The SNMP services allows this computer to become the source of SNMP events or the destination of SNMP messages.
See "Host Name Resolution with TCP/IP " [Ch 9]
Now that you have learned some of the background information about TCP/IP and how to install and configure it on your computer, you are ready to learn about two additional services that can facilitate the management of IP addresses (DHCP) and NetBIOS name resolution (WINS).
In this section, you learn how to configure a DHCP Server. You learn the process of defining a scope, configuring client reservations, configuring DHCP clients, testing clients, viewing and managing DHCP client leases, and maintaining your DHCP database. A DHCP scope is a pool of available IP addresses and (optionally) additional addressing information for various shared devices or services. As a DHCP client computer connects to the network, a unique IP address will be assigned and, with the addresses of other shared resources (for example, servers), can be transmitted to the client computer.
The IP address is said to be leased to the client computer because it can be returned to the pool of available addresses and used by another client at a later time. You can define global options that will apply to all scopes defined on a DHCP server. You can also define options that apply to only one scope.
You need several pieces of information before you can complete the configuration of DHCP. They are listed here for your convenience. If you are unsure of the answers to some of the questions, read this entire section for additional background on the operation of DHCP and how it is configured. If you are still not clear, remember that you can update the DHCP scope at a later time and force clients to renew their leases, which automatically updates them with new information. You must answer the following questions before configuring DHCP:
See "The Windows NT 4.0 Multi-Protocol Router," (Ch 9)
DHCP offers several advantages over the manual configuration of TCP/IP addresses, as follows:
An overview of the DHCP lease address process may help you to administer the process more effectively. The first step is to configure a DHCP server, as described in the next section. After the server is operational, the basic steps involved in a DHCP client lease are as follows:
1. A client computer starts and initializes an unconfigured version of TCP/IP. Then it broadcasts a request for an IP address. The request contains the computer's hardware address and computer name so that DHCP servers know who sent the request.
2. All DHCP servers that have an available lease that is valid for the client send a response using a broadcast message (because the client does not have an IP address yet). The message includes the client's hardware address, the IP address being offered, the subnet mask, the duration of the lease, and the IP address of the server making the offer. The server must reserve the address in case the offer is accepted.
- The client accepts the first offer it receives. It broadcasts its acceptance to all DHCP servers with a message including the IP address of the server whose offer was accepted. Other servers release the temporary reservation on their offered addresses.
3. The server with the selected address sends an acknowledgment message with the IP address, subnet mask, and possibly other information defined in the scope as described in the next section. The client receives the acknowledgment and initializes a full version of TCP/IP, and can communicate with other hosts on the LAN or WAN.
A DHCP server is configured using the DHCP Manager utility. Open the DHCP Manager
utility by selecting Programs, Administrative Tools, DHCP Manager
from the Start menu. The DHCP service is started, stopped, paused,
and continued like all servicesñusing the Services icon in the Control Panel or using
the Windows NT Server Manager. Make sure that the service, formally named the Microsoft
DHCP Server, is started.
The rest of this section describes the procedures you use to define a DHCP scope, set various options, and configure and test DHCP client workstations. You also learn how to reserve certain addresses that are manually assigned (for example, for servers and routers) so that they will be excluded from the pool of available addresses managed by the DHCP service.
See "A Flexible Set of Services," [Ch 2]
Creating a DHCP Scope
To create a DHCP scope, follow these steps:
Another scope is shown in Figure 9.6. This scope would compliment the scope shown in Figure 9.5 on a network with two subnets. A DHCP server would be implemented on each subnet. Each DHCP server can back up the other with a range of addresses from the other scope.
This figure depicts another scope that would compliment the scope shown in Figure 9.5 for a small network involving two subnets.
Configuring Global Options
To set options that will be provided to all clients from all scopes as they receive an IP address lease, follow these steps:
Configuring Scope Options
To set options that will be provided to clients from a particular scope as they receive an IP address lease, follow these steps:
Configuring Client Reservations
There are occasions when a client computer must always have the same IP address. This can occur based on the needs of a particular application. In addition, if you are using a client workstation as a peer server, and sharing resources with many other clients, it may be useful to reserve its address so that it will not change, much as server addresses are best not to change. To reserve an IP address for a particular client, follow these steps:
TIP: The hardware address for a Windows NT computer can be found by running WINMSD.EXE and clicking the Network button. It can also be discovered on most Windows clients (including Windows NT) by typing NET CONFIG WKSTA at a command prompt.
Configuring DHCP Clients
You configure clients to use DHCP by clicking the Enable Automatic
DHCP Configuration check box in the TCP/IP Configuration dialog box. This is accessed
by using the Network icon on the Control Panel. Run Network Setup on Windows for
Workgroups clients. All other settings can be received from the DHCP server if they
are defined in the scope used by this client. Any entries made for other parameters,
the default gateway for example, will take precedence over values received from the
DHCP server.
Testing DHCP Clients
In this section, you learn how to use the IPCONFIG diagnostic utility to report the status of your current network configuration. You will be able to view the IP address you have leased from a DHCP server and other information passed to your computer from the defined scope. To verify the operation of DHCP, you will view your current address, release it, and then renew a lease. This operation is only for testing or other diagnostic and troubleshooting use. These commands are not required by typical users in the normal course of computer operations.
To test the operation of a DHCP client, follow these steps:
IPCONFIG /all
PING 182.111.200.3
IPCONFIG /release
IPCONFIG /all
IPCONFIG /renew
Viewing DHCP Client Leases and Reservations
To view the current status of the leases and reservations supplied by a DHCP server, follow these steps:
Maintaining the DHCP Database
At periodic intervals, the DHCP database may need to be compacted using a utility provided for that purpose named JETPACK.EXE. This utility reclaims wasted space in the database left by the process of entries being added and deleted. For large networks, this should be performed approximately once a week. For smaller networks, once a month is appropriate. See "Restoring the DHCP Database," in the Windows NT Server TCP/IP manual for information on restoring a corrupted DHCP database.
To use JETPACK to compact the DHCP database, follow these steps:
net stop dhcpserver
copy dhcp.mdb dhcp.bak
jetpack dhcp.mdb temp.mdb
del dhcp.mdb
ren temp.mdb dhcp.mdb
net start dhcpserver
Due to the explosive growth of the Internet, it is now possible to connect to the Internet from most locations in United States with a local telephone call. Access to the Internet is also widely available outside the US although the rate structures and availability vary widely in different parts of the world. Nevertheless, the wide availability of connection to the Internet offers a tantalizing prospectñwhy not use the public Internet as a means of accessing your organization's private network from other geographic locations? This idea is sometimes referred to as a Virtual Private Network (VPN).
Although the idea sounds promising, the first two concerns that arise are security and reliability. In order to be useful, information sent over the Internet between the remote client computer and a corporate server would need to be encrypted to prevent unauthorized access or eavesdropping. And using the Internet as part of your organization's WAN means that your remote connectivity is only a reliable and available as the Internet itself. Although the reliability track record of the Internet has been pretty good, problems and outages have occurred, and serious concerns have been raised by Bob Metcalfe (inventor of Ethernet) and other industry pioneers.
CAUTION: Encryption for the broadcast of information over the Internet is a quickly changing technology. What was safe one day will be easily compromised on another. Caution should always be taken when sending sensitive data over the Internet.
A group of corporations (Microsoft, 3Com/Primary Access, Ascend Communications, U.S. Robotics, and ECI-Telematics) has formed the PPTP Forum. This forum is working to create a protocol that would enable network traffic to be transmitted between two points on the Internet in a secure manner. The PPTP specification was entered as an Internet draft in June of 1996 and will be proposed as an Internet standard protocol when the forum has completed its work. There are other competing technologies being developed that also offer the opportunity to create VPNs, such as the Secure Wide Area Network initiative (S/WAN).
The PPTP specification enables any type of network traffic (e.g. IPX and AppleTalk) to be encapsulated and transmitted over a TCP/IP network. A complete discussion of the specification is beyond the scope of this book, however a copy of the specification can be found at the InterNIC's Web site. The current URL for the Internet Drafts index is http://www.ietf.cnri.reston.va.us/1id-abstracts.html.
Internet reliability is a complex issue depending on the cooperation of many organizations. Discussions are underway on how the infrastructure of the Internet could be improved, especially the routers and hubs that connect various physical network segments. The nature of the Internet will make ongoing reliability a somewhat elusive commodity. The Internet is not owned by any single organization, and is not (in its entirety) under the direct control of any single entity. As its use continues to grow there will undoubtedly be points in time when reliability and throughput begin to suffer, then periods of improvement as upgraded equipment and software are implemented. You must make a judgment as to whether the level of throughput and reliability provided are suitable for the application or type of usage you are implementing.
The Remote Access Service (RAS) that is included with Windows NT Server does address the security concerns, and through the use of encryption technology provides a way to deliver network traffic over the Internet that will be highly secure. Although there is no absolute guarantee that a given encryption method is secure, the method being used in the Microsoft implementation of RAS (RSA RC4 with a 40-bit session key) is considered lightly secure. For most organizations this level of security is adequate for ordinary business communications. Other products offering the capability to use a larger key would be required for sensitive information that must be kept secure for periods of a month or more.
NOTE: There is a great deal of information on encryption available on the Web. Use any search engine (e.g., www.yahoo.com) to find additional information on this topic, and be sure to check the RSA Data Security, Inc. site for information on their products and technologies.
CAUTION: The level of encryption that is appropriate for your networking needs really depends upon the type of information that being sent on the network. The more valuable the information is, the more important it is that you spend time and effort securing the data.
PPTP is implemented in a variety of ways. In some cases, special PPTP compliant hardware is required. A few scenarios that use PPTP are outlined below.
One of the principle uses of PPTP, as already discussed, is to enable remote client computers to use the Internet as a means of gaining access to a private network. There are two different methods for achieving this connection, depending on how the client accesses the Internet. If the client is directly attached to the Internet (e.g. with an Ethernet cable provided by some organization with direct Internet access) the configuration would look something like Figure 9.12.
FIG. 9.12
A remote client directly attached to the Internet can access your private
network in a relatively secure manner using PPTP.
See "Remote Access Services," (Ch 11)
The second method for connecting is for the client to dial into an Internet Server Provider (ISP). This would look just like Figure 9.12.
PPTP offers the possibility of outsourcing your communications infrastructure. Many organizations are using Windows NT Server and RAS to provide mobile- or home-based employees access to their corporate network services. This often turns out to be a system that is harder to manage than it first seems. There are many reasons for this, including the following:
Using the PPTP technology, it is possible to use a local ISP. The ISP is maintaining a large communications infrastructure already. Using PPTP, your users dial in to the ISP and access your network. In addition to outsourcing this tricky communications option, utilizing PPTP has these additional advantages:
A sample scenario is illustrated in Figure 9.13.
FIG. 9.13
Communication hardware can be outsourced when using the PPTP protocol.
The TCP/IP protocol was specifically designed to be routed from one local LAN to another. This allows corporations to form large networks by connecting together many small networks, and forms the basis for the Internet.
This section covers the basics of TCP/IP routing in the Windows NT 4.0 operating system. IP routing is referred to as static routing because the routing is based upon a static locally configure routing table. We will also address the more advance concepts in routing, such as how these are addressed in the Multiprotocol Router (MPR) for the Windows NT 4.0 operating system. You will then learn how to properly set up the static and MPR routers.
All TCP/IP stacks provide the ability to route packets to different addresses. This is one of the primary purposes of the TCP/IP stack. When a packet is leaving the computer, the TCP/IP stack will analyze the packet and decide the appropriate destination to send the packet.
The Internet Protocol (IP) portion of the stack is assigned the responsibility of determining the destination of an outgoing packet. The IP uses the Address Resolution Protocol (ARP) to determine the MAC or physical network address of the destination computer.
Each packet that is sent from a computer goes throught the IP portion of the TCP/IP stack. The IP portion will identify the IP destination of the packet. If the IP address identifies a computer that is on the same subnetwork, the packet is sent directly to the destination computer. Otherwise, the packet needs to be routed through intermediate computers, often called routers, to its final destination.
Routing allows for one IP address to become a sink destination for groups of IP addresses. The IP portion of the TCP/IP stack maintains a table of potential destinations for each outgoing packet. Looking at the structure of the routing table will help to understand how the routing performs in Windows NT (see Table 9.1).
| Network Address | Netmask | Gateway Address | Interface | Metric |
| 0.0.0.0 | 0.0.0.0 | 199.217.177.253 | 199.217.177.3 | 1 |
| 127.0.0.0 | 255.0.0.0 | 127.0.0.1 | 127.0.0.1 | 1 |
| 199.217.177.0 | 255.255.255.0 | 199.117.177.3 | 199.217.177.3 | 1 |
| 199.217.177.3 | 255.255.255.255 | 127.0.0.1 | 127.0.0.1 | 1 |
| 199.217.177.255 | 255.255.255.255 | 199.217.177.254 | 199.217.177.3 | 1 |
| 224.0.0.0 | 224.0.0.0 | 199.214.177.3 | 199.217.177.3 | 1 |
| 255.255.255.255 255.255.255.255 | 255.255.255.255 199.217.177.3 | 255.255.255.255 199.217.177.3 | 255.255.255.255 1 | 255.255.255.255 |
Table 9.1 can be acquired for any Windows NT 4.0 system that has the TCP/IP stack installed by typing route print. The route command is used to add, delete, and analyze the TCP/IP routing tables.
In Table 9.1, there are the following five columns, with each row in the table a different route:
The routing table on most Windows NT computers is computed and filled automatically when the sytem is booted up. There are two potential sources for filling in the routing table. The first are the settings for the TCP/IP stack. The second are settings acquired from DHCP.
When a packet is presented to the IP part of the TCP/IP stack, IP will compare the destination address of the packet with each of the network addresses and the netmask parameter. Each bit in the netmask is either a one or zero. If the bit in the netmask is a one, then the destination IP address and network address must match exactly for this route to be chosen for this packet. The IP address that does not have any incorrect bits and has the most ones in the netmask is selected as the best route. If several IP addresses tie in this regard, the route with the lowest metric is selected. If packet does not reach the destination, IP will try an alternative route.
NOTE: Before a packet is sent, the TCP portion of the TCP/IP packet will resolve the hostname to the actual IP address of the destination machine.
A short example will explain the determination of how a packet is routed. The first packet is sent to an IP address that is on this sub network 199.217.177.5. Since you are on a class C network and on the computer 199.217.177.3, you do not need to route this packet through a intermediate router. Line 3 of the routing table has a netmask of 255.255.255.0. This means that the first three octets of the destination IP address must match the first three octets of the Network Address in the routing table. This is exactly the case for this packet. This packet is routed to the NIC card itself. At this point, IP will check to see if it has an MAC address associated with the destination IP address. If there is a MAC address for this destination, the packet is sent to the destination computer. If not, IP will resolve MAC address for the IP address by using the Address Resolution Protocol (ARP).
A second packet is sent out of this computer; this time, the destination IP address is not on the same physical network. The destination IP address is 207.68.156.73. Each of the lines of the routing table will be analyzed to match this address. It is actually line one that serves as a catch-all IP address. Since the netmask is 0.0.0.0, none of the destination IP address bits must match the network address. So this packet will be sent to the 199.217.177.253 address for routing to its final destination. The 199.217.177.253 address happens to be the IP address that is set up in the TCP/IP configuration screen for the default router address.
Now that we understand how routes are chosen, let's address each of the seven routes shown in this routing table example. The first route is the default gateway route. If no other routes match the destination IP address, this route will be taken. The second route is the loopback address. In TCP/IP packets that are sent to 127.XXX.XXX.XXX, addresses should be echoed back by this same machine. The third line corresponds to the local subnet route. This will result in ARP resolution of the MAC address of the destination machine. The fourth line is the host route for our local machine. Notice that this is pointed to the loopback TCP/IP address and will end in the packet being sent right back to ourselves. The fifth line is a local subnet broadcast address. The packet will be sent to all machines on this subnet. On an Ethernet LAN, this will result in a Ethernet broadcast message. The sixth line is an IP multicast address. IP multicast allows the packet to multicast across special multicast gateways.
Additional static routes may be added to the Windows NT 4.0 TCP/IP routing table so that the NT computer will act like a router. This configuration would occur when you have two subnets and you are using a Windows NT system with two network cards to route packets between the two subnets. For any demanding routing needs, you would want to use the Multi-Protocol Router that is discussed in the following section.
In addition to the static IP routing, many network environments need more full-featured routing capabilities. Windows NT 4.0 has added the Multi-Protocol Router to address these full routing needs. The Multi-Protocol Router adds the following three primary functions to the static IP routing:
Understanding the Multi-Protocol Router
The IP routing that is offered by the Multi-Protocol Router (MPR) improves on the standard static routing by enabling dynamic updates of the routing tables. Dynamic updates of the routing table allows the MPR to learn about how packets can be routed on the network. The Routing Information Protocol (RIP) provides the method for routers to convey their routing information.
In addition to improving upon static IP routing, the MPR adds the routing of IPX packets. IPX is the basis of the SPX/IPX network architecture that the majority of Novell NetWare routers use. The IPX routing in the MPR is also supported by the Routing Information Protocol for IPX. This allows the IPX routing to dynamically update its routing tables.
The ability to relay BOOTP messages is important in an NT environment. When client computers are set up to obtain an IP address from a DHCP server, the client computer does this by using the BOOTP protocol. BOOTP uses an IP broadcast to find a BOOTP server. This IP broadcast is typically limited to the local subnet. In an Ethernet networking environment, the IP broadcast is implemented as a Ethernet broadcast. These broadcast messages are typically not propagated across routers. This means that any client that wants to obtain its TCP/IP settings from a Windows NT DHCP-enabled server will need to be on the same physical network. The MPR allows these protocols to be extended across router boundaries.
See "Implementing Dynamic Host Configuration Protocol (DHCP)," (Ch 9)
The Routing Information Protocol (RIP) is the most popular method for dynamic router configuration. Dynamic router configuration becomes very important when the number of routers involved in a network increases. The basis of RIP is that a router is set to broadcast the contents of its router table every 30 seconds. The router uses this IP broadcast to advertise its routing table to the rest of the network. When each router on a network receives a broadcast of a router table, they increase the hop count for all of the networks in the table update for their own routing table and send the packet on. This continues until the hop count goes over the maximum hops allowed, which is typically 16. As time passes, the routing tables will propagate across the network.
The RIP packets ride on top of TCP/IP or UDP/IP for IP RIP. For IPX-based RIP, the RIP packets ride on top of SPX/IPX. The RIP protocol is the same for both the IP protocol and the IPX protocol.
The MPR system allows routing between any two LAN segments. The current architecture of the Windows NT RAS server and client do not allow you to use the MPR or any other routing system over the RAS links. RAS will provide a remote client a great tool to connect to network resources. It does not provide the ability to setup dial-up routing between two LAN segments. Microsoft is planning to release the capability to establish routing over RAS in a service patch to be released later. RAS can be configured to route packets from the local network to the Internet.
Implementing the Multi-Protocol Router
To install the components of the MPR, you click the Add button of the Services tab in the Network Settings dialog box. The available services that can be added are the DHCP Relay Agent, RIP for Internet Protocol, or RIP for NWLink for IPX/SPX. Before installing the DHCP Relay Agent or RIP for Internet Protocol, you need to make sure the TCP/IP protocol has been installed. Before installing the RIP for NWLink for IPX/SPX, again you need to make sure that the IPX/SPX protocol has been installed.
To configure the BOOTP/DHCP relay agent, you can go to the DHCP Relay Agent tab in the TCP/IP Properties dialog box. The parameters that you can configure in the DHCP Relay Agent tab include the following:
After RIP of IP has been installed, you can enable RIP in the Routing tab of the TCP/IP Setting dialog box. The RIP for IP is configured by using the Registry Editor. The RIP parameters are found under the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IpRIP\Parameters. Under this registry key, you will find the following RIP parameters:
The RIP routing table is the same routing table as the static IP routing tables. Earlier in this chapter, you read that the routing table is managed by the route command line utility.
RIP for IPX/SPX is configured by selecting the Enable RIP routing check box in the Routing tab of the NWLink IPX/SPX Configuration dialog box. The RIP for IPX/SPX has one important configuration setting. In the Routing tab, there is an option to enable routing of NetBIOS broadcast messages, which are Type-20 messages. These messages are used to manage browsing in the Windows NT Sever. Enabling this will allow these packets to cross router boundaries.
CAUTION: NetBIOS broadcast messages can cause a lot of traffic on a network. Routing these packets can cause excessive traffic. If you are not sure, it is best to leave IPX routing turned off.
Routing tables for IPX/SPX are managed using the ipxroute command line utility. This utility has many of the same features as the route command for the TCP/IP protocol.
In this chapter, you received a tutorial overview of TCP/IP and related technologies that included the reasons they are important and how they operate. You learned how to install, configure, and use TCP/IP and related services. You also learned how to use DHCP and WINS to dynamically assign IP addresses and manage NetBIOS names. For more information on these and related topics, see the following chapters.
© Copyright, Macmillan Computer Publishing. All rights reserved.