Chapter 8 - Network Configuration

Article
02/20/2014

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Chapter 8 Network Configuration

As we've already seen, managing networking is an inextricable part of administering Windows NT systems. This chapter provides an overview of TCP/IP networking on Windows NT systems. Its goals are two-fold:

To enable you to perform everyday network management tasks, including adding new hosts to the network, configuring various network services, and monitoring network traffic.
To enable you to understand all of the most important TCP/IP networking options--including their inherent tradeoffs--so that you will be in a position to evaluate your current network configuration and practices and plan for and manage its future growth.

For book-length discussions of TCP/IP networking, consult Craig Hunt's two excellent books, Networking Personal Computers with TCP/IP and TCP/IP Network Administration (both published by O'Reilly & Associates).

A bit of history follows: Windows NT supports other standard networking protocols in addition to TCP/IP: IPX/SPX (NetWare), AppleTalk, and SNA (via a separate BackOffice product). In general, discussion of them is beyond the scope of this book.

One other "protocol" does require brief consideration: NetBIOS. On DOS systems, the Basic Input/Output System (BIOS) constituted the operating system's I/O interface. NetBIOS was developed to extend it to I/O operations over a local network. The NetBIOS interface needed a corresponding transport protocol. The first one developed was called the NetBIOS Frames Protocol (NBFP). Currently, in non-TCP/IP environments, NetBIOS traffic uses the NetBIOS Extended User Interface (NetBEUI) Frame Protocol (NBF); this is the transport protocol used in traditional Microsoft networks. NetBIOS may also be run over TCP/IP (NetBIOS over TCP/IP: NBT). Higher-level services for standard Microsoft networking functionality are provided by the Server Message Block (SMB) protocol.

Vanilla NetBIOS and NetBEUI don't scale well beyond fairly small networks for various technical reasons: they rely on a broadcast-based naming scheme, their packets cannot be routed, they lack networking compatibility with other kinds of computers, and other reasons. Accordingly, methods and standards for running NetBIOS on top of other protocols families, such as TCP/IP were developed. You can run either way on a Windows NT system. If the NetBEUI protocol is installed, local NetBIOS traffic will use its facilities, while standard TCP/IP facilities will use TCP/IP; otherwise, NetBIOS-based facilities will use the TCP/IP networking facilities for communication with other hosts.

Note: You must install the NetBIOS protocol if you want to support the standard Microsoft network (computer) browsing features (accessed, for example, by opening the desktop's Network Neighborhood icon). It is normally installed by default on Windows NT systems as part of their standard networking facility.

Understanding TCP/IP Networking

The term "TCP/IP" is shorthand for a large collection of protocols and services necessary for internetworking computer systems. In any given implementation, TCP/IP encompasses operating system components, user and administrative commands and utilities, configuration files, and device drivers, as well as the kernel and library support upon which they all depend. Many of the basic TCP/IP networking concepts are not operating-system specific, so we'll begin this chapter by considering TCP/IP networking in a general way.

Figure 8-1 depicts a typical TCP/IP network, including several kinds of network connections. Each computer system on the network is known as a host (also known as nodes in other networking lexicons). In our example, the systems named for countries are all connected in a local area network (LAN), as are those named for Shakespearean characters.[1]

[1] You may wonder whether this is one LAN with two subnets or two LANs. In fact, the term LAN is not precisely defined, and usage varies.

Figure 8-1: TCP/IP local area network

The country hosts are connected via an Ethernet. One of the fundamental characteristics of Ethernet is illustrated in the diagram. All hosts on an Ethernet are logically connected to every other host: to communicate with any other host, a system sends a message out on the Ethernet, where it arrives at the target host in one step (one hop). By contrast, for the other network, messages between duncan and puck must be handled by two other hosts first, thus taking three hops. If this second network ran at the same speed as Ethernet (10 Mbps), then this would be a disadvantage; however, since it is an FDDI network (running at 100 Mbps), more hops are not significant.

The system romeo serves as a gateway between the two subnets. It is part of both subnets and passes data from one to the other. There are special-purpose computers that are designed to be gateways and nothing else, but many sites only add an additional network interface to a less-used workstation, as in this example.

Names and Addresses

Every system on a network has a hostname. This name is unique within the network. Hostnames let users refer to any computer on the network by using a short, easily remembered name rather than the host's network address (described a moment).

Each system on a TCP/IP network also has a host address--known as an IPaddress--that is unique for all hosts on the network. When an actual network operation occurs, the hostnames of the systems involved are used to determine their numerical IP addresses, either by looking them up in a table or by requesting translation from a server designated for this task (we'll consider this topic in more detail later in this chapter).

If the system is connected to the Internet, its host address is taken from a range assigned by the Network Information Center to that site. Networks that are not connected to the Internet also generally use network addresses that obey the Internet numbering conventions.

An Internet network address is a sequence of four bytes.[2] Network addresses are usually written in the form a.b.c.d, where a, b, c, and d are all decimal integers (e.g. 192.0.10.23). Each component is 8 bits long and thus runs from 0 to 255. The address is split into two parts: the first part identifies the network, the second identifies the host within the network. The sizes of these parts vary. The first byte of the address (a) determines the address type (called its class), and hence the number of bytes allocated to each part. Table 8-1 gives more specific details about how this works.

[2] The Internet address format will change at some point in the near future to accommodate a greater number of hosts than are available under the present scheme. The IP6 standard will expand network addresses to sixteen bytes (128 bits), although it also contains provisions for continued support for present format addresses.

Table 8-1 Internet Address Types

Initial Bits	Range of a	Address Class	Network Part	Host Part	Max. # Nets	Max. # Hosts/Net
0	1-126	Class A	a	b.c.d	126	16,777,214
10	128-191	Class B	a.b	c.d	16,384	65,534
110	192-223	Class C	a.b.c	d	2,097,152	254
111	224-254	Reserved (includes multicast addresses)

Class A addresses are appropriate for networks with millions of hosts, while Class C addresses are appropriate for a networks with relatively few hosts (fewer than 255). There are few Class A networks; these network numbers are typically reserved for major national networks. Multicast addresses (also sometimes referred to as Class D) are part of the reserved range of addresses. They are used to address a group of hosts as a single entity and are designed for applications like video conferencing.

The IP addresses 10.0.0.0 through 10.255.255.255 are one of several ranges that have been reserved for use by private networks (not connected to the Internet).[3] If a site uses 10 for a, they might then use b and c to identify particular subnetworks within a larger network and use d to identify an individual host on some subnetwork. For Internet sites, the network is often determined by a and b, while c is used for subnetting, and d refers to the host. In any case, you must be consistent with whatever network addressing usage is already established at your site.[4]

[3] Other ranges are 172.16.0.0 through 172.31.255.255 and 192.168.0.0 through 192.168.255.255. See RFC 1597 for details.

[4] Traditionally, many sites that were not on the Internet used 192 or 193 for a. Note: Many people recommend obtaining an official Internet address for your network even if you never plan for it to be part of the Internet. See the O'Reilly's TCP/IP Network Administration for details on the procedures. In many cases, your Internet service provider will also be willing to assist with or perform this process for you.

By convention, the network address 127.0.0.1 is used as a loopback address: data sent to it is transmitted back to the same host. The loopback address is mostly used for testing. This address is usually given the hostname localhost. Similarly, some host numbers have conventional uses: host 0 refers to the network itself, and host 255 is used for broadcast addresses (specified for messages that are sent to all hosts on the local network).

So far, we've assumed that IP addresses are permanently assigned to each host within a network, but this need not be true. The Dynamic Host Configuration Protocol (DHCP) is a facility that allows IP addresses to be assigned to systems dynamically when they require network access. It is discussed later in this chapter.

A subnet mask specifies how the 32-bit IP address is divided between the network part and the host part, and all computers participating in a TCP/IP network have one assigned to them. The subnet mask is a 32-bit value constructed by placing 1 in each bit location for the network portion of the IP address and 0 in all of the bit locations for the host part of the address. Thus, a Class A IP address normally uses a subnet mask of 11111111000000000000000000000000, which is conventionally written as four period-separated decimal integers: 255.0.0.0. Similarly, a normal Class B address uses a subnet mask of 255.255.0.0, and a normal Class C address, a subnet mask of 255.255.255.0.

The subnet mask can also be used to further subdivide one network ID among several local networks. For example, if you use a subnet mask of 255.255.255.192 for a Class C address, you are making the highest two bits of the final address byte part of the network address (the final byte is 11000000), thereby subdividing that network into four subnets, each of which can have up to 62 hosts on it (since the host ID is coded into the remaining 6 bits).

Note: In general, all of the subnet masks within a subnet must be identical (and they are usually the same across an entire network). Be sure to comply with whatever conventions are currently in use at your site.

Media and Topologies

TCP/IP networks can run over a variety of physical media. Most current networks use some sort of coaxial cable (thick or thin), twisted-pair cable, or fiber-optic cable.

Network adapters provide the interface between a computer and the physical medium comprising the network connection; they usually consist of a single board. Network interfaces support one or more communications protocols, which specify how the computers use the physical medium to exchange data. Most protocols are not media-specific. For example, Ethernet communications--a protocol and not a type of media--can be carried over all four of the media types mentioned previously, and FDDI networks can run over either fiber optic or twisted pair cable. Such protocols specify networking characteristics, such as the structure of the base-level data unit, the way that data moves from host to host across the physical medium, how multiple simultaneous network accesses are handled and resolved, and the like.

All network adapters have a Media Access Control (MAC) address, which is a numerical identifier that is absolutely unique to that individual unit (board). For Ethernet devices, MAC addresses are 48-bit values expressed as twelve hexadecimal digits, usually divided into hyphen-separated pairs: for example, 00-00-F8-23-31-91. There are thus over 280 trillion distinct MAC addresses (which ought to be enough even for us). MAC addresses are also commonly referred to as Ethernet addresses and occasionally as hardware addresses. You can display the MAC address for the network adapters on a Windows NT system using the ipconfig /all command or the GetMAC command included in the Resource Kit.

Hosts within a local area network can be connected in a variety of arrangements known as topologies. For example, the 10.1.1 subnet in Figure 8-1 uses a bus topology in which each host taps into a backbone, which is standard for Ethernet networks. Many times the backbone is not a cable at all but merely a junction box where connections from the various hosts on the network converge, known as a hub. The 10.1.2 subnet uses a ring topology.

Networking protocols relating to the physical connection between computers may include a required topology as part of their specification. For example, FDDI networks are composed of two counter-rotating rings (two duplicate rings through which data flows in opposite directions), an arrangement designed to enable a network to easily bypass failed connections (FDDI networks can also include singly attached hosts, which tap into the basic double ring structure).

Nets and Subnets

Individual networks can be organized, subdivided, and joined in a variety of ways, as illustrated in Figure 8-2.

Figure 8-2: Connecting disparate LANs

Networks A, B, and C are geographically separated. In network C, the two hosts at the bottom of the ring are too far apart to be connected directly to one another (all physical media impose a maximum length for an individual cable), so a repeater is placed between them. This device simply passes all signals from one wire to the other, thereby connecting the two hosts. More sophisticated repeaters can transfer signals from one media type to another (for example, between twisted-pair and fiber-optic cable).

In network B, the two segments are joined by a bridge, a device somewhat more intelligent than a repeater in that it selectively passes only the data destined for the other segment between the two. More complex bridges can filter data in a variety of ways, and some are capable of connecting networks of different types--say, TCP/IP and SNA--by translating the data from one protocol family to the other as it passes it across.

The three networks are connected to one another via routers, a still more sophisticated network linking device. In addition to selectively handling data based on its destination, routers also have the ability to determine the current best path to that destination; finding a path to a destination is accordingly known as routing. The best routers are highly programmable and can also perform complex filtering on the data they receive, accepting or rejecting it based upon criteria specified by the network administrator. The routers connecting our three networks are arranged so that there are multiple paths to every destination; losing any one of them will cause no harm to communications between the two unaffected networks.

Layers and Protocols

Network communications are organized as a series of layers. With the exception of the one referring to the physical transmission medium, these layers are logical rather than literal or physical. Every network transaction moves down through the layers on its originating system, travels across the physical medium, and then moves up through the same stack of layers on the destination system.

No discussion of any network architecture is complete without at least a brief mention of the Open Systems Interconnection (OSI) Reference Model. Frankly, this description of networking is almost meaningless in terms of actually existing networks, but it is quite helpful in clearly identifying the distinct functions necessary for network communications to occur, even if things are not really divided up this way in real networks. Figure 8-3 shows the layers in the OSI Reference Model and those actually used by TCP/IP; the most important protocols defined for each layer are listed in parentheses.

Figure 8-3: OSI and TCP/IP network architectures

When a network operation is initiated by a user command or program, it (logically) travels down the protocol stack on the local host (via software), across the physical medium to the destination host, and then back up the protocol stack on the remote host to the proper recipient process. Each layer is equipped to handle data in particular predefined units. The names of these units for the two main transport protocols are listed in Table 8-2. However, the term packet is also used generically to refer to any network transmission.

Table 8-2 Data Unit Names

Layer	TCP Protocol	UDP Protocol
Application	stream	message
Transport	segment	packet
Internet	datagram	datagram
Network Access	frame	frame

On the originating end, each layer adds a header to the data it receives from the layer above it (breaking the data into multiple instances of its own units if necessary); similarly, on the receiving end, each layer strips off its own header before passing the data to the next higher layer (combining multiple units together if appropriate), so what is finally received is the same as what was originally sent.

Repeaters, bridges, and routers can be distinguished by how much of the TCP/IP protocol stack they handle. Repeaters operate only at the Network Access layer, bridges use both the Internet and Network Access layers, and routers operate within the three lowest TCP/IP layers. Note that a full network host, which supports all four TCP/IP layers, can accordingly perform the functions of any of these types of devices.

Network Services

Network operations are accomplished by a variety of network services, consisting of the software and other facilities needed to perform a specific type of network task. A service is defined by the combination of a transport protocol--TCP and UDP are the most important--and a port: a logical network connection identified by a number. The TCP and UDP port numbering schemes are part of the definition of these protocols.

Note: Port numbers are unique only within a given transport protocol; TCP and UDP use the same port numbers.

Various configuration files in the directory %SystemRoot%\System32\Drivers\Etc indicate the standard mappings between port numbers and TCP/IP services:

Protocol

Lists the protocol numbers assigned to the various protocols defined for the TCP/IP family.

Services

Lists the port numbers assigned to the various TCP and UDP services. Available TCP/IP services on Windows NT systems are listed in Table 8-3.

User and Administrative Commands

Windows NT provides a number of generic TCP/IP user commands, which may be used to access remote systems. The most important of these commands are:

telnet

Create a character-based (TTY-like) login session on a remote host

ftp

Copy files to or from a remote host

finger

Obtain information about a user account on a remote host, which must be running the Finger service in order to respond (not included with Windows NT, but there is a freely available version)

System administrators will find the following commands useful:

hostname

Display the name of the local system

ping

Perform a simple network connectivity test

arp

Display or modify the IP-to-MAC address tables

ipconfig

Display information about the system's TCP/IP configuration (useful for determining a system's current IP address when it is a DHCP client)

netstat

Display various network usage statistics

route

Display or modify the static routing tables

tracert

Determine the route to a specified target host

nslookup

Determine the IP address for a hostname via the Domain Name Service

nbtstat

Show current connections and statistics for NetBIOS over TCP/IP

A Sample TCP/IP Conversation

All these concepts come together when we look at a sample TCP/IP conversation. First, we consider what happens when the following generic TCP/IP command is successfully executed:

C:\> finger johnm@godot
[godot]
Login name: johnm               In real life: John Montgomery
Directory: /mf/johnm            Shell: /bin/tcsh
Last login Tue Jul 22 13:02 from johnm@verdi
No Plan.

This finger command (which requests information about a user account on a remote system) causes a network connection to be formed between the local host, which happens to be vala, and the remote system godot, a UNIX system elsewhere in the network.

The finger service uses the TCP transport protocol (number 6) and port 79. TCP connections are always created using a three-step handshaking process. Figure 8-4 displays a dump of the packet corresponding to the first step, initiated by the local system (created with the NetXRay utility from Cinco Networks). The highlighted entry in the top portion of the window displays summary information about the packet, and it indicates that it was transmitted from host vala to host godot.

Figure 8-4: First step in a TCP/IP handshake

The second section of this window shows the packet's contents, organized by network layer (remember that each one adds information to the packet as it travels down the protocol stack). The Ethernet area shows the Ethernet addresses of the two hosts (vala and godot in this case), and the IP area shows their IP addresses. The TCP area contains several important items:

The ports used by the two systems (line 1 of the TCP section): port 1355 on vala and the standard port for the Finger service on godot (which happens to be 79).
TCP flags set for this packet (line 6): the SYN flag is set in this case.
The sequence number for this packet (line 2). The TCP protocol requires that all packets be acknowledged by the receiving host (although not necessarily individually). The SYN (synchronize) flag alone indicates an attempt to create a new network connection, and, in this case, the sequence number is an initial sequence number for the conversation. It will be incremented by one for each byte of data transmitted (and by one at a minimum for each successive packet).

Figure 8-5 shows the next two packets in the sequence, which complete the handshake. In the packet on the left (sequence number 1672002085), sent from godot back to vala , both the SYN and ACK (acknowledge) flags are set. The SYN is the response to vala's SYN, and the ACK is the acknowledgment of the previous packet. The Acknowledgement Number field's contents match the sequence number of the previous packet incremented by 1 (indicating one byte of data received so far). The next packet (on the right) simply acknowledges godot 's SYN, and the connection is complete.

Figure 8-5: Completing the TCP handshake

Now we are ready to actually get some work done. The next packet in the sequence is illustrated in Figure 8-6. This packet sends the data "johnm" to the Finger service on godot (indicated in the Finger section of the display), and it also acknowledges the previous packet from godot. This data is passed up the various network layers, to be delivered ultimately to the proper local process on godot.

Figure 8-6: Transmitting a request to the remote finger service

godot acknowledges this packet and eventually sends a response. The resulting packet is displayed in Figure 8-7. The output from the local finger command on godot constitutes the data in this packet. The packet also acknowledges data received from vala (5 bytes since the previous packet).

Figure 8-7: Finger response from the remote system

All that remains is to close down the connection. Conceptually, it proceeds as follows (packets are vastly abbreviated):

IP: 193.0.13.4->193.0.9.42
Transmission Control Protocol
Code: ACK, FIN
 
IP: 193.0.9.42->193.0.13.4
Transmission Control Protocol
Code: ACK
 
IP: 193.0.9.42->193.0.13.4
Transmission Control Protocol
Code: ACK, FIN
 
IP: 193.0.13.4->193.0.9.42
Transmission Control Protocol
Code: ACK

The FIN flag indicates that a connection is to be terminated. vala indicates that it is finished first. godot acknowledges that packet and then sends its own FIN, which vala acknowledges.

When NetBIOS is being run on top of TCP/IP, a similar process occurs for a command like net view \\pele. Figure 8-8 shows the packet from pele containing the data from this command that is sent to vala (preceding packets from pele to vala are summarized in the upper part of the window). Notice how the NetBIOS and SMB protocols are subordinate to the TCP protocol.

Figure 8-8: NetBIOS running via TCP/IP

When the NetBEUI protocol is installed on a system, packets for such a command bypass TCP/IP, as illustrated in Figure 8-9.

Figure 8-9: A vanilla NetBIOS/SMB packet

Adding a Host to a Windows NT Domain

To add a new system to a Windows NT domain running TCP/IP, you must complete the following steps:

Install and configure the network adapter and identify it to the system, and physically connect the system to the network.
Install the TCP/IP networking facility on the system if you did not do so when you installed the Windows NT operating system. Network configuration on Windows NT systems is carried out primarily from the Network control panel applet (also accessible via the Network Neighborhood's Properties).
Assign a hostname and network address to the system (or find out what has been assigned by the network administrator).
Create a computer account for the system on the domain's primary domain controller.
Install and configure any additional network services that the system requires. This will include deciding on and implementing name service and routing strategies.
Test the network connection.

We'll look at each of these steps in some detail.

Configuring the Network Hardware

The first step is to install and configure the network adapter. I use a procedure like the following:

Configure any required jumpers on the adapter board to select an appropriate IRQ level and other settings, following the directions in the manufacturer's documentation.
Install the adapter board into the computer's CPU cabinet (the power should be off). Connect the system to the network.
Boot from a DOS diskette and run the diagnostic utility provided with the adapter to possibly configure and test the adapter board. Only when the board passes all tests at the DOS level do I try to configure it under Windows NT.
Reboot the system and tell Windows NT about the adapter via the Properties... button of the Adapters tab of Network control panel applet (illustrated in Figure 8-10). Be aware that you are merely informing the system about the device's settings in this dialog box, not specifying them. When the dialog box first opens, the most common settings for that adapter type are displayed; don't be confused by them and assume that they represent actual settings detected on the device.

You are now ready to install the TCP/IP software.

Figure 8-10: Configuring the network adapter

Installing TCP/IP

The Network control panel applet's Protocols tab (illustrated in Figure 8-11) lists the networking facilities installed on the system and allows you to add new ones. Pressing the Add... button brings up a list of available protocols; select TCP/IP Protocol to install the TCP/IP networking software. After an initial prompt about whether you want to use DHCP or not (which we will assume you answer with No for the moment), you will need to insert the Windows NT distribution CD.

Figure 8-11: The network control panel applet

Once the software is installed, closing the control panel applet automatically takes you to basic TCP/IP configuration (which is also always accessible via the Properties button on the Protocols tab when the TCP/IP protocol is selected). We will cover the various settings in the subsections that follow.

Note: As always, you should reapply the latest service pack that is installed when you add a network protocol or service.

Basic TCP/IP Configuration

The TCP/IP parameter that you need to specify is the system's IP address, which is accomplished via the IP Address tab of the TCP/IP Properties dialog box (illustrated in Figure 8-12). The two radio buttons in the dialog box are used to indicate whether the system has a permanent (static) IP address or uses the DHCP facility to obtain one on an as-needed basis. Select whichever setting is appropriate for this system (we'll discuss DHCP in a bit).

Figure 8-12: IP address configuration

After selecting the network adapter from the Adapter menu (if more than one is installed in the computer), specify the system's IP address and the subnet mask it will be using in the corresponding fields. Multiple IP addresses for this adapter may be specified with the Advanced... button.

The dialog box's final field, Default Gateway, is used to specify a gateway host for communications beyond the local network. We consider it later in this chapter.

The other tabs in the Microsoft TCP/IP Properties dialog box are used for various name resolution and routing options. We'll examine each of them in the course of this chapter.

Connecting to the Domain

Before users can log in to a Windows NT domain from the new system, it must be made known to the primary domain controller (PDC).[5] There are two ways of accomplishing this: from the PDC or from the new system.

[5] This step is not specific to the TCP/IP protocol.

On the PDC, you can use the Server Manager to create a computer account for the new system via its Computer->Add to Domain... menu path. The resulting dialog box is illustrated in Figure 8-13. After completing the dialog box, pressing the Add button adds the system to the domain in the specified capacity.

Figure 8-13: Adding a computer to the domain

Alternatively, on the new system, you can use the Change button on the Identification tab of the Network control panel applet to add it to a domain (or to change domains). This brings up the Identification Changes dialog box, illustrated in Figure 8-14. Use its lower section to create a new computer account in the desired domain, specifying a username and password for an account with administrative privileges.

Figure 8-14: Connecting to a domain for the first time

Additional Network Configuration

Depending on the uses for which the new system is intended, it may be necessary to install additional TCP/IP services. Table 8-3 describes the available networking services provided with the Windows NT operating system; the starred items are generally installed by default. Any of them may be installed via the Network control panel applet's Services tab.

Table 8-3 Available Networking Services

Service	Description
BOOTP Relay Agent	Allows the system to forward BOOTP broadcast packets across subnets (a pre-DHCP facility that supports remote booting of diskless workstations)
*Computer Browser	Provides support for Explorer-style browsing of networks
DHCP Relay Agent	Forwards DHCP broadcasts to a remote DHCP server in a different subnet (e.g., when the router connecting them will not do so)
Gateway (and Client) Services for NetWare	Provides access to NetWare networks
Microsoft DHCP Server	Assigns IP addresses to requesting computers
Microsoft DNS Server	Provides the IP addresses corresponding to hostnames (includes integration with WINS)
Microsoft Internet Information Server	Provides various web services (includes an FTP server formerly separate under Windows NT 3.5x)
Microsoft TCP/IP Printing	Supports printing to or from foreign TCP/IP hosts via the LPD facility
*NetBIOS Interface	Includes base-level support for NetBIOS (needed by some services)
Network Monitor Agent	Allows for network performance data collection
*Network MonitorTools and Agent	Allows for network performance data collection and includes data viewing tools
Remote Access Service	Enables dial-up networking (on top of PPP or SLIP)
Remoteboot Service	Provides booting services for diskless workstations
RIP for Internet Protocol	Enables TCP/IP routing between subnets
RIP for NWLink IPX/SPC Compatible Transport	Provides routing services for NetWare (IPX)
*RPC Configuration	Supports remote procedure call capabilities
RPC Support for Banyan	Provides support for RPC calls to computers on Banyan Vines networks
SAP Agent	Support for the NetWare Service Advertising Protocol
*Server	System functions as an NT server (uses the SMB protocol)
Services for Macintosh	Provides connectivity services for Macintosh clients
Simple TCP/IP Services	Adds connectivity-testing related TCP/IP services: Chargen, Daytime, Discard, Echo, and Quote (despite its name, this item is not needed by most systems)
SNMP Service	Implements the Simple Network Monitoring Protocol (used by many general network administration tools)
Windows Internet Name Service	Provides NetBIOS name registration and resolution services, translating NetBIOS computer names to IP addresses
*Workstation	Services required when system functions as a workstation (SMB client)

We consider many of these services throughout this chapter.

Other TCP/IP servers

As the preceding list makes clear, Windows NT does not provide the full compliment of TCP/IP services available on UNIX and other computer systems. However, it is possible to add almost all of the missing services via freely available or commercial software. The Resource Kit includes beta versions of an rsh daemon and a telnet server. Consult Appendix B for Internet sources of other TCP/IP servers for Windows NT systems.

Network Bindings

The Bindings tab of the Network control panel applet (Figure 8-15) can display and modify the network bindings: defined paths via the various networking layers, linking hardware, protocols, and services. The display in the figure shows the network hierarchy from the point of view of the installed network adapters (there is only one on this system). The same information may also be viewed from the point of view of networking protocols or networking services.

Figure 8-15: Network bindings display

You can use the control panel applet in a variety of ways. For example, if there are multiple adapters installed on the system, you can specify which protocol uses which adapter by disabling unwanted bindings via the protocols-oriented display format. You can also specify the order in which a given protocol or service will use the available network devices by reordering them with the Move Up and Move Down buttons.

Tools for Testing Network Connections

Testing the network connection is an important part of the configuration process. The first such step is to test the basic network setup and connection with ping, a simple command-line utility that tells you whether or not the network connection and its basic setup are working correctly.

Ping takes a remote hostname or an IP address as its argument. For example, the following command determines whether the host pele is accessible or not:

C:\> ping pele
Pinging pele [10.0.13.10] with 32 bytes of data:
Reply from 10.0.13.10: bytes=32 time<10ms TTL=128
Reply from 10.0.13.10: bytes=32 time<10ms TTL=128
Reply from 10.0.13.10: bytes=32 time<10ms TTL=128
Reply from 10.0.13.10: bytes=32 time<10ms TTL=128

From this output, it is clear that pele is receiving the data sent by the local system and that the local system is receiving the data pele sends back.

Once you have succeeded with ping, the next step is to run a command that uses higher levels of the TCP/IP protocol stack (ping operates at the IP layer using the ICMP protocol). For example, the ftp command can test connectivity to remote systems (which must be running an FTP server facility). The net time and net view commands are similarly useful for testing SMB protocol-based connectivity.

Name Resolution Facilities

For convenience, high-level user commands generally use hostnames to specify remote locations on the network. Accordingly, the networking software requires the network address of the system using that hostname for the requested operation to succeed. Thus, when a user enters a command like finger chavez@hamlet, one of the first things that must happen is that the hostname hamlet gets translated to its IP address (10.1.2.6). TCP/IP provides two methods for performing hostname-to-IP address translation (a process also called name resolution):

The IP address can be determined by looking up the hostname in the Hosts configuration file. On Windows NT systems, this file is generally stored in the directory %SystemRoot%\System32\Drivers\Etc.[6]

[6] The location of the TCP/IP configuration files is controlled by the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\TCPIP\Parameters\DataBasePath registry setting.
The system can request translation from a server running the Domain Name Service (DNS) in order to determine the IP address.

The same issues often arise when a user enters a command like net view tirzah or dir \\pele\homes\chavez. These commands rely on the SMB and NetBIOS protocols. NetBIOS operations can obtain IP addresses for specified hostnames via a configuration file, LMHosts (stored in the same directory as the TCP/IP Hosts file), or via the Windows Internet Name Service (WINS), which provides hostname registration and resolution services for NetBIOS names. On Windows NT systems, WINS can be run in conjunction with DNS, and the two systems are integrated.

The Hosts and LMHosts Files

On TCP/IP networks, the Hosts file traditionally contains a list of the hosts in the local network (including the local host itself). If you use this file for your hostname data, you must edit it whenever you add a new system to the network. When you add a new system to an existing network, you will have to edit the Hosts file on every system on the local network.

Here is a sample Hosts file for a small LAN:

# Loopback address for localhost
127.1            localhost
# Our hostname and address
10.1.1.2         spain spain.auroral.com
# Other hosts in the local network
10.1.1.1         brazil
10.1.1.3         usa
10.1.1.4         canada
10.1.1.5         england uk
10.1.1.6         greece olympus achaia
10.0.13.4        vala
192.168.34.77    dalton

Lines beginning with # are comments and are ignored. Aside from the comments, each line has three fields: the network address of a host in the network, the host's hostname, and any aliases (or synonyms) for the host. Every Hosts file must contain at least two entries: a loopback address for debugging purposes (by convention, 127.1), and the address by which the local system is known to the rest of the network. The other lines describe the other hosts in your local network. After the lines for the loopback address and the local system, the example Hosts file continues by listing the network addresses for all other systems in the local network. The file may also include entries for hosts that are not on your immediate local network (as its final entry illustrates).

Three hosts have been assigned aliases (or synonymous hostnames): the local host is called spain and may also be referred to by its full name spain.auroral.com. Similarly, uk is a synonym for england, and olympus and achaia are synonymous names for the host greece. A hostname may have as many aliases as desired; each alias is separated from the previous name by one or more spaces.

Here is a somewhat more complex Hosts file:

# Loopback address for localhost
127.1            localhost
# Our hostname and address
10.1.1.2         spain spain.auroral.com
# Other hosts in the local network
10.1.1.1         brazil
10.1.1.3         usa
10.1.1.4         canada
...
# gateway to LAN 4 subnet
10.1.1.87        dalton
 
# hosts in the LAN 4 subnet
192.168.34.77    dalton-gw
192.168.34.2     priestley
192.168.34.4     lavoisier
192.168.34.5     berthollet

10.1.1 is one local network, and 192.168.34 is another, separate network. The host dalton serves to bridge the two networks; it is connected to both networks, and it is listed as a member of each network in its own Hosts file. In this file, one entry has -gw appended to "dalton" so that all hostnames will be unique. The Hosts files on the other computers in the local LAN will contain only the 10.1.1.87 entry, and those on the other computers in LAN 4 will define dalton as 192.168.34.77. This way, every host on both networks will be able to call that computer dalton.

The LMHosts file serves the same purpose for mapping NetBIOS hostnames to IP addresses. It has a similar basic format to the Hosts file, and it is stored in the same directory location. Here is a simple example:

10.1.13.1      godot
10.1.13.2      leda
10.1.13.3      demeter
10.1.13.4      vala      #PRE #DOM:BOREALIS
10.1.13.5      janis     #PRE
192.168.34.77  dalton    #PRE
 
#INCLUDE \\vala\config\lmhosts
 
#BEGIN_ALTERNATE
#INCLUDE \\dalton\adminbin\lmhosts
#INCLUDE \\priestley\adminbin\lmhosts
#END_ALTERNATE

The first section of the file lists IP addresses and hostnames for several hosts. The #PRE comments following some of the entries are actually directives indicating that the corresponding entry should be pre-loaded into the NetBIOS name cache and retained there permanently. The #DOM directive identifies vala as the domain controller for the borealis domain. The second section of the file incorporates the contents of another file into the current LMHosts file.

The third section of the file allows for redundant sources for an additional external file to be incorporated within this LMHosts file. The #INCLUDE directives contained within the #BEGIN_ALTERNATE and #END_ALTERNATE directives list alternate sources for that include file (which are checked in order, as usual).

Both the Hosts and LMHosts files may be used in conjunction with their corresponding name resolution service (DNS and WINS, respectively).

The Domain Name Service

The Domain Name Service (DNS) facility relies upon server processes running on various network-accessible systems to provide hostname-to-IP address translations as required by the various systems on the network. DNS organizes groups of systems into units known as domains. DNS domains are organized into a single hierarchical structure on an Internet-wide basis, with the defined suffixes constituting the top-level of the tree (.com, .org, .edu, the various two-character country codes, and so on). A DNS domain generally corresponds to an organization. In our examples, we will use the fictional domain auroral.com.

Note: KEEP in mind that DNS domains are completely unrelated to Windows NT domains.

Within a DNS domain, individual systems are referred to by their fully qualified domain name (FQDN), consisting of the hostname prepended to the domain name. For example, the system vala in our domain would be referred to as vala.auroral.com. Domains can be divided into subdomains. Thus, the name viveca.multi.auroral.com would refer to the host viveca in the subdomain multi within auroral.com. Multiple levels of subdomains are possible, but they are seldom used in practice.

From the DNS server perspective, DNS domains are administered as one or more zones, where a zone is simply some pruned subtree of a DNS domain (and the entire domain is a potential subset of itself). The terms "domain" and "zone" are used somewhat interchangeably in many discussions of DNS. For clarity, we will use only the latter term when we are describing the translation data for a collection of systems. Zones may also be subdivided.

Warning: To further confuse matters, while the Microsoft DNS Administrator tool and its corresponding documentation refer to zones as "zones," they refer to subdivisions of zones as "domains," introducing yet another usage for an already overloaded term.

In this section, we consider the Microsoft DNS service available on Windows NT server systems.[7] DNS is a vast topic, so we won't be able to cover all of its intricacies. For more information about DNS, including planning a DNS implementation for your site, consult O'Reilly's TCP/IP Network Administration and DNS and BIND by Paul Albitz and Cricket Liu.

[7] Other freely available implementations of DNS are also available for Windows NT systems (including workstations). Consult Appendix B for sources.

Setting up a DNS client system

We'll begin by looking at setting up a system to use the DNS service for name resolution (if there is also a Hosts file on such a system, it will still be checked as well). A DNS Client is also called a resolver.

DNS name resolution is enabled via the DNS tab of the TCP/IP protocol's Properties dialog box (illustrated in Figure 8-16). Its configuration is straightforward.[8]

[8] This dialog box contains the same information as is traditionally stored in the resolv.conf configuration file on UNIX and other systems.

Figure 8-16: Setting up a DNS client

The Host Name field specifies the hostname by which this system will be known to the DNS system. It is generally the same as the system's Windows NT hostname (and making them different is only asking for trouble). The Domain field specifies the name of the local domain. The DNS Service Search Order contains a list of IP addresses for DNS servers that this system should use for name resolution. Servers are contacted in the order in which they appear in the list box.

By default, required hostnames are assumed to be in the local domain (put another way, the local domain name is applied as a suffix to unknown hostnames). The Domain Suffix Search Order may be used to specify additional domains in which to search for a hostname. This feature is not needed in most cases, unless your domain is more than two levels deep. If you do list additional domains here, then the local domain and the listed domains will be searched when attempting to resolve an unknown hostname (in the order in which they appear in the list box), and these will be the only domains checked. In contrast, when only the Domain field is specified in this dialog box, that domain and all of its parent domains are searched for unknown hostnames.

Setting up a DNS server

A Windows NT server system can also function as a provider of DNS services via the Microsoft DNS Server service of the TCP/IP protocol. There are three kinds of DNS servers:

Primary server

A system that permanently stores authoritative name information for a specific zone, which may range from a local subnet to a wide area of the Internet. It holds the master copy of the configuration files defining hostname-to-IP address translation for the zone.

Secondary server

A system that obtains a set of name information from a primary server when the DNS server process starts up. Thereafter, it can provide the same translations as the primary server. Secondary servers are useful for backup and to distribute the network load created by DNS clients.

Caching-only server

A system that relies on other hosts to determine all unknown hostname translations, but remembers names and addresses that it has learned. Such a host operates in an essentially client-oriented mode, but it minimizes its demands for network resources by not asking for the same name again as long as the name remains in its cache.

All DNS servers save the translation data that they learn in the course of doing their jobs. Such information is retained for a specified period of time and then removed from the cache. The cache is reinitialized every time the server is restarted.

A Windows NT server can function as any of these types of DNS servers, as we shall see.

The DNS Manager administrative tool (also accessible via the dnsadmin command) is used to configure a DNS server. This tool enables you to administer all of the Microsoft DNS servers throughout a network from a single system (but cannot affect other non-Microsoft DNS servers).

The steps for setting up a primary or secondary server are similar:

Install the Microsoft DNS Server network service if necessary (via the Add button in the Services tab of the Network control panel applet).
Select the DNS Manager's DNS->New Server... menu path, and enter the hostname or IP address for the system on which it will run. If the server is already present in the list, then simply select it.
Select the DNS->New Zone... menu path. This option is used to both create zones and to define the server as a primary or secondary server.
- For a primary server, select the Primary radio button and then click Next. Enter the zone name and zone database filename (which defaults to the zone name with the .dns extension added) into the subsequent dialog box. DNS database files are stored in the directory %SystemRoot%\ System32\DNS.
- For a secondary server, select the Secondary radio button (see Figure 8-17). Then enter the name of an existing zone and its primary server into the Zone and Server fields (respectively). Alternatively, you may use the hand icon in the lower section of the window to point to an existing zone (drag the hand icon from the dialog box into the tool's main server list window). Click Next when you are finished.
  
  In the next dialog box, enter the local name for the zone (usually just the zone name) and the path to the local data file (which defaults as for a primary server). Click Next when you are finished.
- Finally, list IP addresses of one or more master servers for the zone from which this secondary server should request its initial translation data (the server you specified in an earlier step is pre-filled into the list).
If desired, you may now subdivide the zone with the DNS->New Domain... menu path. Note that despite its name, this selection creates a subdomain in the currently selected zone, not a new DNS or Windows NT domain.
For a new zone, create its associated reverse-lookup zone, used to translate IP addresses back into host names. In most cases these zones are assigned names of the form b.a*.in-addr.arpa* where b and a are the second and first components of local IP addresses: for example, 1.10.in-addr.arpa would be the reverse-lookup zone for the 10.1 subnet.
Add an entry for each host within the zone to the database via the DNS->New Host... menu path. Checking the Create Associated PTR Record checkbox in the New Host dialog box causes a corresponding record to be automatically entered into the reverse-lookup zone at the same time.
Add any other DNS records needed for your site via the DNS->New Record... menu path, which allows you to enter arbitrary DNS records.

Figure 8-17: Configuring a secondary server

Figure 8-18 illustrates the DNS Manager's main window after a zone has been defined for the auroral.com domain. The database records for that zone appear in the right side of the window.

Figure 8-18: The DNS zone auroral.com

Importing existing DNS configuration files

You may also import DNS configuration from another system into the Microsoft DNS server via the following procedure:

Stop the DNS server service: net stop dns.
Copy the zone files and reverse-lookup files to the %SystemRoot%\ System32\DNS directory on the system where you want the server to use them. If you want to import the boot and cache files as well, you will have to disable registry-based DNS startup--see the next subsection.
Restart the DNS server service: net start dns.
Start the DNS Manager tool and select the appropriate system (creating a new server if necessary).
Create a new zone corresponding to the data you want to import, specifying the appropriate zone file in the Zone File field. You may then go on to create the corresponding reverse-lookup zone and import its data file.

If you add entries manually to the zone database files in %SystemRoot%\ System32\DNS, the new information is generally recognized. However, two caveats apply: first, you have to create the associated reverse-lookup record manually as well, and second, the forward and reverse translation records may not be linked properly, so subsequent changes to the host's record within the DNS Manager tool will not always update the associated PTR record properly.

Configuring a caching-only DNS server

By default, the DNS server facility is installed in caching-only mode. If your network is connected to the Internet, then no further configuration is required. If not, modify the DNS cache file as indicated in step 4 below. I prefer to run a caching-only server in manual mode. Here are the steps for setting one up:

Stop the DNS Server service if it is running (net stop dns).
Disable DNS startup from the Windows NT registry by setting the EnableRegistryBoot value of the HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\DNS\Parameters key to 0. Once you have done so, initialization information will be taken from the file named Boot in %SystemRoot%\ System32\DNS.
Create a boot file like this one:
```
directory %systemRoot%\System32\DNS
```

FakePre-2353e90863f84831af4446c78b47663e-18c3c027f72744c7a97d4589bc529029

The first line specifies the default location from which to apply relative pathnames (including empty ones) within the remainder of the file. The second line specifies the name of the DNS cache file. Note that the second entry in the line--a period--is required.

Set up a cache file (named Cache.dns) that points to one or more authoritative DNS servers for your domain. If you are connected to the Internet, then these will be the Internet's root name servers; these are provided in the default cache file provided with Windows NT and may also be obtained from ftp.rs.internic.net/domain/root.cache. If your network is not connected to the Internet, then the file should contain entries for the local root servers. For example, this file specifies the host with IP address 10.1.13.4 as the DNS server for the zone auroral.com:
```
; Cache file
```

FakePre-497560040ca843aa82695263d64c91c5-642608d0e0674275a7a98bc4e9fc3027FakePre-2dc8f49478e5443c8b29479bc896841c-f30ae538f8bd40628d3dbb149e602538FakePre-88dd137c16d4416a941c76b9511b3bb5-d996761a13fb40de9748604fb5012acc

Restart the DNS Server service (net start dns).

Additional DNS server configuration

There are many other DNS parameters that may be specified. In this subsection, we will briefly consider a few of the most important ones.

Parameters specific to a DNS zone may be set using the zone Properties, accessed by selecting the zone and choosing the DNS->Properties... menu path or by right-clicking on the zone. The SOA Record tab of the Zone Properties dialog box allows you to specify several timeout periods (see Figure 8-19) for the zone's servers.

Figure 8-19: Specifying parameters for a DNS zone

The Refresh Interval field indicates how often a secondary server should recheck the accuracy of its data with a primary server.
The Retry Interval field indicates how long a secondary server should wait after a refresh attempt has failed before trying to contact the unresponsive server again.
If a secondary server continues to be unable to refresh its data, the Expire Time field indicates when it will stop responding to DNS queries because its data is too old to be reliable.
The Minimum Default TTL field indicates how long a receiving name server is allowed to cache the data it learns as a result of any specific DNS query (known as the time-to-live interval).

The zone Properties dialog box's Notify tab lists secondary servers to notify automatically whenever the database for the primary server changes.

Systemwide properties for a specific server system are set via the server's Properties (accessed by selecting the server and then choosing the DNS->Properties... menu path or by right-clicking on the server name). These are the most important tabs in the resulting Server Properties dialog box:

The Interfaces tab lists additional IP addresses used by that host on which the name server will listen.
The Forwarders tab specifies a list of hosts which can be contacted for name resolution outside of the local domain (see Figure 8-20).

Figure 8-20: Accessing DNS servers beyond the local domain
If Use Forwarders is checked, then the listed systems will be contacted first to resolve names that cannot be translated locally. If Operate As Slave Service is also checked, then only the designated systems are used to forward name resolution requests beyond the local domain. This setting is designed to filter DNS requests beyond the local domain through a few designated systems. The final field in the dialog box specifies the timeout period before going on to the next forwarder in the list.

The Windows Internet Name Service

The Windows Internet Name Service (WINS) is a dynamic hostname-based addressing scheme used on Microsoft LANs supporting NetBIOS network operations. It is integrated with DNS via the Microsoft DNS Server, allowing WINS clients to resolve DNS names.[9] WINS translates NetBIOS names to IP addresses using a process like the following (which is simplified somewhat):

[9] The two facilities are rumored to be completely merged in Windows NT Version 5.0.

A client computer contacts the WINS server system, giving it its hostname and IP address and asking to be added to the database. Its request is accepted if the specified name and address aren't in active use by another system, and it's granted exclusive use of that name for a period of time known as a lease.
When the client system shuts down, it contacts the WINS server and releases the name it has registered.
When its lease period is 50% gone, the client system attempts to renew it with the WINS server. It keeps trying until it is successful or the lease period expires; in the latter case, it registers its name with an accessible WINS server.

Configuring a WINS client

A Windows NT system is configured to use the WINS facility for NetBIOS name resolution via the WINS Address tab of the TCP/IP protocol Properties (illustrated in Figure 8-21).

Figure 8-21: Configuring a WINS client

After specifying the network adapter to use for WINS queries, specify the IP addresses of the primary and secondary WINS servers this system should contact for name resolution services.

If Enable DNS for Windows Resolution is checked, the system will use DNS name resolution services (via the Microsoft DNS Server facility) to resolve a name if WINS is unable to do so. If Enable LMHOSTS Lookup is checked, the local LMHosts file is also searched for hostname translations. Pressing the Import LMHOSTS... button copies the information from a different file that you specify into the local LMHosts file, replacing its current contents (if any).

Configuring a WINS server

The following procedure prepares a system to operate as a WINS server:

Add the Windows Internet Name Service network service, if necessary, to that system (using the Add button in the Services tab of the Network control panel applet).
Start the WINS Manager administrative tool (also accessible via the winsadmn command). Select the appropriate WINS server from the list, adding it if necessary.
Use the Mappings->Static Mappings... menu path to define any static name mappings used within the network. These are hostname-IP address pairs, which are assigned to systems on a permanent basis.
Use the Server->Configuration... menu path to specify operating parameters for the WINS server (see Figure 8-22).

The most important fields of the WINS server configuration dialog box are:
- The Renewal Interval field specifies the lease period for a WINS client.
- The Extinction Interval field indicates how long a released database entry is held before it is marked as extinct (assuming that no other system requests that name).
- The Extinction Timeout field specifies how quickly extinct entries are removed from the WINS database during a scavenging operation (which is requested with the WINS Manager's Mappings->Initiate Scavenging menu option).
- The Initial Replication checkboxes in the Pull Parameters and Push Parameters areas indicate whether the server always sends information to or requests information from its replication partners at startup (discussed later).
- The Replicate on Address Change checkbox in the Push Parameters area specifies whether the server always informs its push replication partners when an entry in its database changes (including the creation of a new entry).
Use the Server->**Replication Partners...**menu path to specify other systems with which this server will periodically exchange name resolution data. A system to which this server sends its data is known as a push partner, and a system from which this server receives data is called a pull partner. A remote system can operate in one or both modes.

Figure 8-23 illustrates the Replication Partners dialog box for a single partner, along with those used to configure push partners and pull partners (accessed via the corresponding Configure... button in the Replication Options area).

You may add and delete replication partner systems with the Add... and Delete buttons. You may force an immediate replication operation for a selected system with the Replicate Now button. The buttons in the Send Replication Trigger Now area can be used to request a push or pull operation individually. If Push with Propagation is checked, a push partner will be directed to send any new information it receives as a result of the operation to all of its own pull partners.

The Push Partner Properties dialog box allows you to specify how many changes must be made to the WINS database before the server notifies this push partner about them (the Update Count field). The Pull Partner Properties dialog box indicates the first time a request for data is sent to this pull partner and how often updates are requested thereafter.

Figure 8-22: Configuring the WINS server

Other useful features of the WINS Manager administrative tools are the following:

The Mappings->Show Database... menu path displays the current database entries for the selected server.
The Backup Database... and Restore Local Database... items on the Mappings menu to save the current contents of the WINS database and restore a previously saved file into the active database (respectively).

Figure 8-23: Configuring replication partners for a WINS server

The Resource Kit contains several command-line utilities for administering the WINS facility, including winscl and winschk; the latter can be used to verify the consistency of the WINS database.

WINS integration with DNS

WINS server integration with DNS is enabled with the DNS Manager using the Zone Properties dialog box's WINS Lookup tab (illustrated in Figure 8-24). When the Use WINS Resolution checkbox is selected, the Microsoft DNS Server submits hostnames to the specified WINS servers when it cannot resolve them itself.

Figure 8-24: DNS server integration with the WINS facility

Dynamic IP Address Assignment with DHCP

While its purpose is somewhat different than the two name resolution facilities we have examined so far in this section, the Dynamic Host Configuration Protocol (DHCP) facility performs a related function. It is used to assign IP addresses to network hosts dynamically. This facility is designed to decrease the individual workstation configuration necessary for a system to be successfully connected to the network. It is especially suited to computer systems that change network locations frequently (e.g., laptops).

As we've seen previously, you designate a system as a DHCP client via the Identification tab of its TCP/IP protocol Properties. On such systems, you can use the ipconfig command to display its current IP address:

C:\> ipconfig
Windows NT IP Configuration
 
Ethernet adapter elpc3r1:
 
    IP Address. . . . . . . . . : 10.1.13.100
    Subnet Mask . . . . . . . . : 255.255.255.0

The output from the ipconfig command indicates that this system is currently using the IP address 10.1.13.100.

Warning: NEVER use dynamic addressing for any system that functions as a resource server of any kind: this includes not only domain controllers but also file servers of all sorts (including via Windows NT shares), providers of network services (DNS, DHCP, WINS, RAS, etc.), print servers, and so on.

The DHCP facility assigns an IP address to a requesting host for a specified period of time known as a lease, using the following process:

The requesting (client) system broadcasts a DHCP Discover packet (UDP port 67).
DHCP servers reply with a DHCP Offer packet (UDP port 68), containing an IP address, subnet mask, server IP address, and lease duration. The server reserves the offered address until it is accepted or rejected, or a timeout period expires.
The client selects an IP address and broadcasts a DHCP Request DHCP packet. All servers other than the successful one release the pending reservation.
The selected server sends a DHCP Acknowledge packet to the client.
When the lease is 50% expired, the client attempts to renew it. If it cannot do so at that time, it will try again when it reaches 87.5% of lease period; if the second renewal attempt also fails, the client will look for a new server.

As this description indicates, the DHCP facility depends heavily on broadcast messages and so can generate a significant amount of network traffic.

The Microsoft DHCP Server facility is integrated with DNS and WINS on Windows NT server systems.

Configuring a DHCP server

The following steps configure a Windows NT server to function as a DHCP server:

Add the Microsoft DHCP Server network service to that system, if necessary (via the Add button in the Services tab of the Network control panel applet).
Start the DHCP Manager administrative tool (also accessible via the dhcpadmn command). Select the appropriate server from the list, adding it if necessary.
Create a new scope : a named block of IP addresses that this server is allowed to assign. This can be done via the Scope->Create... menu path. The resulting dialog box is illustrated in Figure 8-25.

The various fields in the dialog box have the following meanings:
- The Start Address and End Address fields specify the range of IP addresses that constitute this scope (inclusive).
- The Subnet Mask specifies the subnet mask in use on the network.
- The fields in the Exclusion Range area are used to specify subsets of the previously specified IP address range that are not part of the scope. Use both fields to specify a range of IP addresses or just the Start Address field here to specify a single IP address. Excluded addresses appear in the list in the upper right portion of the dialog box.
  
  IP addresses should be excluded if they are assigned (statically) to a specific host or if they are already being administered by another DHCP server. Doing the latter is a way to provide DHCP server redundancy. For example, if you have two DHCP servers, you would divide the available addresses between the two of them.
  
  You may also want to exclude a few addresses for future use (although you can often do so by manipulating the beginning and end of the scope range).
- Specify the lease length in the Lease Duration area. Unlimited lease lengths are generally a bad idea (and counter to the purpose of DHCP). A lease duration of days is reasonable in environments with frequent system turnover or a scarcity of available IP addresses, and a lease length of months might be appropriate in a far more stable environment without resource constraints.
- The Name and Comment fields specify a name and description for the scope.
A DHCP server can administer multiple scopes if desired.
The next step in setting up the DHCP server is to reserve IP addresses for systems that use static IP addresses. When an IP address is reserved, it is both excluded from general use within the scope and always assigned to a designated system when it requests an IP address. You need to specify reservations for the systems using static IP addresses that receive their IP address from the DHCP facility (for example, a system that might be moved or replaced frequently).

The Scope->Add Reservations... menu path defines a new reservation. The resulting dialog box is illustrated in Figure 8-26. Its unique identifier field holds its MAC address.
Set any desired DHCP options. Options can be set either on a global or scope-specific basis, via the DHCP Manager's DHCP Options menu. The resulting dialog box is illustrated in Figure 8-27. Select the option you want from either of the lists, and press the Value button to set its value.

Figure 8-25: Creating a DHCP scope

Figure 8-26: Creating a DHCP reservation

Figure 8-27: Setting DHCP options

Figure 8-28 displays the main DHCP Manager window after the server has been configured with a single scope. DHCP options appear in the right half of the window.

Figure 8-28: DHCP Manager server display

Some functions of the DHCP Manager may also be performed via a command-line interface with the dhcpcmd command included in the Resource Kit.

DHCP with subnets

If you want systems on a local subnet to receive IP addresses from a server on a separate subnet, then one of the following conditions must be met:

If a router connects the two subnets, it must include support for DHCP/BOOTP Relay (broadcast packets normally dropped by routers and not forwarded).
The DHCP Relay Agent must be installed on a system within the subnet not containing the DHCP server. This network service provides a software solution to the same problem.

Once installed, the DHCP Relay Agent is configured via the DHCP Relay tab of the TCP/IP protocol Properties (illustrated in Figure 8-29). The DHCP servers to which the system will forward DHCP requests are listed in the DHCP Servers list box and are specified via the buttons below it.

Figure 8-29: Configuring the DHCP relay facility

Servers are contacted in the order in which they're listed in the display. The Seconds threshold field specifies the number of seconds to wait for a response from a server before going to the next one in the list. The Maximum hops field indicates the maximum number of hops that may be taken to reach a DHCP server.

Routing Options

Routing is the process by which a packet finds its way from its source system to its final destination. As with hostname resolution, there are a number of options for configuring routing within a local network:

If the LAN consists of a single, isolated Ethernet network, no explicit routing is usually needed, since all of the hosts are immediately visible to one another. Gateways to adjacent Ethernet LANs may be listed in each system's TCP/IP protocol Properties. The default gateway is specified in the Default Gateway field of the IP Address tab, and this dialog box's Advanced button may be used to specify additional gateway hosts.
More complex static routing may be set up by issuing explicit route commands.
Distinct LANs can be linked by routers (or gateway hosts that can function as routers) that can dynamically determine the best route to a given destination.

The Windows NT version of the route command has the following syntax:

route [options] cmd dest [mask netmask] gateway [metric]

where cmd is one of add, delete, change, or print. Dest specifies the destination corresponding to this route (usually a network), netmask specifies the subnet mask to use, gateway specifies the gateway host (or router) that provides a connection to the specified destination, and metric specifies the number of hops to the destination.

The route command has two options: /F clears all gateway entries from the routing tables, and /P defines (or refers to) a persistent route (which survives system reboots).

For example, the following command indicates that the route to the 10.1.9 subnet is through the gateway with the IP address 10.1.13.5:

C:\> route /P add 10.1.9.0 mask 255.255.255.0 10.1.13.5

This route persists across system boots and specifies a subnet mask of 255.255.255.0.

The command route print may be used to display the routing tables:

C:\> route print
Active Routes:
 
  Network Address          Netmask  Gateway Addr    Interface  Metric
          0.0.0.0          0.0.0.0     10.1.13.5    10.1.13.4       1
        127.0.0.0        255.0.0.0     127.0.0.1    127.0.0.1       1
         10.1.9.0    255.255.255.0     10.1.13.5    10.1.13.4       1
        10.1.13.0    255.255.255.0     10.1.13.4    10.1.13.4       1
        10.1.13.4  255.255.255.255     127.0.0.1    127.0.0.1       1
      10.1.13.255  255.255.255.255     10.1.13.4    10.1.13.4       1
        224.0.0.0        224.0.0.0     10.1.13.4    10.1.13.4       1
  255.255.255.255  255.255.255.255     10.1.13.4    10.1.13.4       1

The columns of the display indicate the destination address, its subnet mask, the IP address of the gateway for that destination, the IP address of the network adapter within the local system to use for communication with that destination, and the number of hops to that destination. This display shows the routes for a simple network. It contains a route to a single other network, the 10.1.9 subnet. All the other entries are standard ones used for any LAN and ones corresponding to the system's own LAN.

Consult O'Reilly's TCP/IP Network Administration for further information about setting up static routing.

Note: As of this writing, Microsoft has just made available a new facility (code-named "Steelhead") that combines routing and dial-up networking (RAS) services within a single facility. It also incorporates the DHCP Relay facility examined earlier in this chapter.

Enabling IP Forwarding

Normally, systems will not forward IP packets received that are not addressed to the local system (it simply discards them). If you want a Windows NT system to function as a gateway between two subnets, you will need to enable IP forwarding. This can be done using the Routing tab of the TCP/IP protocol Properties (Figure 8-30).

Figure 8-30: Enabling IP forwarding

Configuring the Remote Access Service

The Windows NT operating system provides the Remote Access Service (RAS) for dial-up networking access for remote computer systems.[10] This facility allows a remote user to dial into a Windows NT server and connect to its local network as a full-fledged network host; the various network protocols are implemented over the serial line connecting the remote system to the server. RAS is a complicated facility worthy of a book-length treatment on its own. This section provides an overview of installing and configuring a RAS server on a Windows NT server system.

[10] RAS runs on top of either PPP or SLIP, standard networking protocols for serial lines.

The following steps are required to enable the RAS network service on a Windows NT server system:

Install one or more modems onto the system. This is accomplished with the Modems control panel applet. In most cases, allowing the system to detect the modems automatically works fine. In those rare cases where the system cannot determine your modem type, select the corresponding entry from the list of manufacturers and modem models.

Once the modem is added to the system, you can specify standard settings, such as its maximum speed, parity, and flow control scheme using the Properties button.
Install the Remote Access Service network service, using the Add button in the Services tab of the Network control panel applet. After the required software is copied to the system disk, the installation process will guide you through the remaining basic RAS configuration steps.
Select a device in the Add RAS Device dialog box (Figure 8-31). If necessary, you can install a modem or an X25 device at this time using the corresponding buttons.

Figure 8-31: Designating a modem as an RAS device
The next dialog box forms the heart of the RAS setup process (Figure 8-32). You may add additional ports to the RAS configuration using its Add... button, and configure a port with the Configure... button. The Clone button may be used to copy a port, including its configuration information. Finally, the Network button allows you to configure RAS networking parameters.

Figure 8-32: The RAS setup control dial-up box
Port configuration is accomplished using the Configure Port Usage dialog box (Figure 8-33). You use this dialog box to specify whether a port accepts incoming calls, allows outgoing calls, or both.

Figure 8-33: Configuring an RAS port
The Network Configuration dialog box (Figure 8-34) may be used to specify the allowed networking protocols for outgoing and incoming RAS connections from this server and port. The lower section of the dialog box allows you to specify whether user authentication communications are encrypted or not. I don't recommend allowing clear text authentication across a dial-up line.[11]

[11] Be aware that the encryption scheme used by the RAS facility is proprietary, however, and doesn't work with most non-Microsoft PPP servers.

Figure 8-34: Specifying allowed RAS networking protocols

The Enable Multilink checkbox at the bottom of the dialog box is used to enable multilink dialing on the selected port. This facility allows multiple phone lines to be combined into a single logical session with increased effective network bandwidth. This feature must be enabled for all of the ports that participate in the multilink bundle.
The Configure... buttons on the Network Configuration dialog box allow you to specify the range of access for incoming RAS connections. Such users can be given access to the entire network (subject to its usual permissions and security constraints), or they may be limited to the local system only. Figure 8-35 shows the resulting dialog box for the TCP/IP protocol.

Figure 8-35: Configuring RAS network access for the TCP/IP protocol
The lower portion of the RAS Server TCP/IP Configuration dialog box allows you to select between using the DHCP facility to assign IP addresses to incoming network connections and having the RAS facility assign an IP address itself, taken from the range of IP addresses designated in this dialog box. Using addresses from a static range is recommended if the network adapter on the local system supports more than one IP address. However, if you choose to use DHCP in such a case, subnets normally accessible from the local network adapter via one of its IP addresses, other than the one used for DHCP, will not be available to RAS clients.
The final step is to grant RAS access to the appropriate users. This is accomplished using the user properties facility of the User Manager tool (specifically, its Dialin button) or via the RAS Administrator administrative tool's Users->Permissions... menu path (the latter utility is also accessible using the rasadmin command). A similar dialog results from both routes (Figure 8-36).

Figure 8-36: Setting RAS access for a user account
The Grant dialin permission to user checkbox determines whether the user may dial into the domain using the RAS facility. The Call Back area allows you to enable mandatory call-back for this user, either to a specified telephone number in all cases (Preset To) or to a telephone number that the user specifies at connection time (Set By Caller). Preset call-back numbers are more secure, but the latter setting is needed when the user can't know the appropriate telephone number in advance (for example, when traveling).

The RAS Administrator tool may also be used to start and stop the RAS service on the local system or a remote system and to view and manipulate current RAS connections.

Note: As of this writing, Microsoft has just made available a new facility (code-named "Steelhead") that combines routing and RAS services within a single facility.

The Dial-Up Networking utility in the standard Accessories folder (one path is %SystemRoot%\Profiles\Default User\Start Menu\Programs\Accessories) provides user-level access to the RAS facility.

Network Monitoring Tools

The netstat command is used to monitor a system's TCP/IP network activity. It can provide some basic data about how much and what kinds of network activity is going on. It has the following basic syntax:

netstat [options] [interval]

The netstat command's most useful options are /S (produce detailed statistics), /Pproto (limit the output to the specified protocol), and /R (display the local routing tables). If an interval is specified, the command runs continuously until it is aborted and produces a new display every interval seconds.

Without arguments, netstat lists all active network connections with the local host:

C:\> netstat
Active Connections
 
  Proto  Local Address          Foreign Address        State ...
  TCP    vala:1025              demeter:nbsession      ESTABLISHED
  TCP    vala:1091              dalton:ftp             ESTABLISHED
  TCP    vala:1100              hamlet:finger          CLOSE_WAIT
  TCP    vala:nbsession         demeter:1026           ESTABLISHED
  TCP    vala:nbsession         lilith:1037            ESTABLISHED
  TCP    vala:nbsession         pele:1037              ESTABLISHED

At the current time, the local system (vala) has active NetBIOS connections to demeter (two separate connections), lilith and pele (all of which correspond to shared filesystem resources). Someone is also running a finger command to host hamlet (which is almost finished), and an FTP session to dalton.

Netstat's /S option produces a more detailed set of network-related statistics:

C:\> netstat /S
IP Statistics      Overall TCP/IP traffic statistics
  Packets Received                   = 1552
  Received Header Errors             = 0
  Received Address Errors            = 0
  Datagrams Forwarded                = 0
  Unknown Protocols Received         = 0
  Received Packets Discarded         = 0
  Received Packets Delivered         = 1552
  Output Requests                    = 1172
  Routing Discards                   = 0
  Discarded Output Packets           = 0
  Output Packet No Route             = 0
  Reassembly Required                = 0
  Reassembly Successful              = 0
  Reassembly Failures                = 0
  Datagrams Successfully Fragmented  = 0
  Datagrams Failing Fragmentation    = 0
  Fragments Created                  = 0
 
ICMP Statistics       Used by ping and for routing
                            Received    Sent
  Messages                  42          25
  Errors                    0           0
  Destination Unreachable   18          1
  Time Exceeded             0           0
  Parameter Problems        0           0
  Source Quenchs            0           0
  Redirects                 0           0
  Echos                     8           16
  Echo Replies              16          8
  Timestamps                0           0
  Timestamp Replies         0           0
  Address Masks             0           0
  Address Mask Replies      0           0
 
TCP Statistics          Connection-oriented data
  Active Opens                        = 42
  Passive Opens                       = 24
  Failed Connection Attempts          = 17
  Reset Connections                   = 3
  Current Connections                 = 7
  Segments Received                   = 827
  Segments Sent                       = 806
  Segments Retransmitted              = 51
 
UDP Statistics         UDP data
  Datagrams Received    = 545
  No Ports              = 170
  Receive Errors        = 0
  Datagrams Sent        = 288

One use for this display is to check the various error counts. Clearly, this network is working extremely well, since all of them are 0. Small numbers of errors over time are normal and nothing to be concerned about. How small is small? Error levels above a very few percent of the total network traffic need further investigation and may indicate flaky or failing network hardware.

The Network Monitor administrative tool (also accessible via the netmon command, which is located in the Netmon subdirectory of %SystemRoot%\Sys-tem32) provides a graphical display of the same data (see Figure 8-37). You initiate the network statistics display with the Capture->Start menu path or the F10 key. Its display is subdivided into four windows; moving counterclockwise from the upper-left corner, the windows currently display three bar graphs indicating the overall network usage and traffic levels, a list of active connections of remote systems with the local host (systems are identified by MAC address), detailed total I/O statistics for each active connection, and overall network statistics data (in numerical format) since the capture operation began.

Figure 8-37: The Network Monitor administrative tool

Data collected with the Network Monitor may be saved to a file and viewed again at a later time. See the documentation for more information about its data capturing facilities.

These facilities can provide you with a snapshot of a system's current network activity and load. We will consider network monitoring for performance purposes in Chapter 11.

Managing Domain Controllers

We conclude this chapter on network configuration by considering how to manage the domain controllers within a domain. A server system can be designated as a primary or backup domain controller when the Windows NT operating system is installed.

The Server Manager administrative tool (also accessible with the srvmgr command) may be used for a variety of high-level system management tasks:

Sending a message to all of the users on any system in a domain
Starting and stopping Windows NT services on any system in a domain
Managing shares on any system in a domain
Displaying the current usage for shared resources for any system in a domain
Managing the directory replication facility
Adding and removing systems from a domain

Most relevant to our current consideration are its features for configuring and synchronizing domain controllers.

Synchronizing the Data on Backup Domain Controllers

The data on backup domain controllers (BDC) is automatically synchronized with that on the Primary Domain Controller (PDC) on a periodic basis. When a new backup domain controller is added to a domain, a full synchronization of the complete contents of the domain databases is performed. Thereafter, partial synchronization operations are performed whenever possible. You can force a partial synchronization using the Server Manager's Computer->Synchronize with Primary Domain Controller menu path.

The PDC maintains a list of changes to its data in a buffer known as the change log. When a BDC requests data synchronization, it sends it all of the changes from the change log that have been added since the previous synchronization. The change log is a circular buffer, overwriting the oldest entries when it is full. If an entry that has not been sent to a BDC is overwritten, the PDC performs a full synchronization with that system the next time it requests data. Such synchronizations are time consuming and best avoided if at all possible. If they are occurring consistently, the change log may need to be increased in size (its default size is 64 KB, which corresponds to about 2,000 changes).

You can change the size of the change log by editing the ChangeLogSize value of the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Para-meters registry key (you may need to add the key, which is type REG_DWORD). This value specifies the size of the change log buffer in bytes. Reboot the system to put the new setting into effect.

Modifying Domain Controllers

It is easy to move a workstation or stand-alone server to another domain: simply delete its computer account from its current domain and use the Change button on the Identification tab of the network Properties to specify its new domain.

Performing this and related actions for domain controllers is generally more complicated. We'll consider several of them.

Adding a new backup domain controller is most straightforward if you decide to do so when you install the Windows NT operating system. At that time, designate the system as a BDC. You can then add a computer account for the new system via the Server Manager's Computer->Add to Domain... menu path. The resulting dialog is illustrated in Figure 8-38.

Figure 8-38: Adding a backup domain controller

Converting an existing server system within a domain to a BDC is more tedious:

Delete its computer account from the domain.
Reinstall Windows NT on the target system, designating it as a BDC.
Add the computer back into the domain.

As you can see, it is much, much easier to designate a system as a BDC right from the start.

An existing BDC can be promoted to the domain's primary domain controller using the Server Manager's Computer->Promote to Primary Domain Controller menu path. If the current PDC is accessible at the time, it will automatically be demoted to a BDC. If the PDC is unavailable at that time, you will have to demote it manually when it comes back online (Computer->Demote to Backup Domain Controller, a menu path available only when a lame duck PDC is selected).

Replacing the system serving as the PDC uses a similar strategy:

Perform a full backup of the PDC.
Install the Windows NT operating system on the new computer, designating it as a backup domain controller. Install any required software for the system in the normal manner.
Restore files from the PDC backup to the new system as appropriate. You may have to restore some registry hives to transfer all of the customization of the old system to the new one (although recreating them by hand may be easier).
Add the new system to the domain as a BDC.
Wait a few hours to ensure that all data has been transferred, and then promote the BDC to the PDC. The old PDC will be demoted automatically.
Remove the system that previously served as the PDC from the domain (if desired).

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. All prices for products mentioned in this document are subject to change without notice.

Click to Order