Multiple IP Addresses

Windows NT computers can have multiple IP addresses—even if the computers only have a single network adapter
card. Multiple IP addresses are useful in several situations:
You want a single computer to appear to be several different computers. For example, if you're installing an
intranet server, you may also want the server to provide Web, FTP, and SMTP services. You can use a different IP
address for each service, and you can use different IP addresses for the intranet and the FTP services.
If your network is divided into multiple logical IP networks (subnets) and the computer needs access to these
subnets to route information or provide other internetworking services, you may want a single network adapter
card to have multiple IP addresses. For example, the address 192.55.10.8 could be used for workstations
accessing a server from the 192.55.10.0 subnet and the address 192.55.11.8 could be used for workstations
accessing a server from the 192.55.11.0 subnet.
Caution: When you use a single network adapter, IP addresses must be assigned to the same network segment or
segments that are part of a single logical network. If your network is divided into multiple physical networks, you
must use multiple network adapters, with each network adapter being assigned an IP address in a different
physical network segment.

Assigning Addresses and Gateways

Each network adapter installed on a computer can have up to five IP addresses (a sixth IP address is configurable
in some Windows NT installations). These addresses can also be associated with up to five default. Configure
multiple IP addresses using the Advanced IP Addressing dialog box. Each network adapter can have up to five IP
addresses and five gateways.
Note : You can specify up to three servers to use for DNS resolution. These servers are used in priority
order. If the first server can't resolve a particular host name, DNS attempts to use the next server on the list. If
this server fails to resolve the name, the next server is used, and so on. To change the position of a server in the
list box, click on it and then use the Up or Down button.
WINS is only supported on computers running Microsoft Windows 3.1, Microsoft Windows 95, Microsoft Windows
98, and Windows NT.

The DHCP Relay Agent service is available only on computers running Windows Server 2003, Microsoft® Windows® 2000, or
Windows NT 4.0. To use the DHCP Relay Agent routing protocol, the Routing and Remote Access service must be installed and enabled.
If you have multiple subnets in your network, and do not have a DHCP server on every subnet, determine whether
your current routers relay DHCP/BOOTP messages.
If your routers cannot be used for DHCP/BOOTP relay, set up a DHCP/BOOTP relay agent on at least one computer
running Windows Server 2003 on each subnet. The DHCP/BOOTP relay agent relays DHCP and BOOTP message
traffic between the DHCP-enabled clients on the local network and a remote DHCP server located on another
physical network by using the IP address of the remote DHCP server.
If your routers cannot be used for DHCP/BOOTP relay and you choose not to configure DHCP/BOOTP relay agents,
you must configure your network so that a DHCP server has a network adapter on each subnet it serves. You can
accomplish this by either placing a DHCP server on each subnet, or by multihoming DHCP servers. This distributed
configuration does not provide fault tolerance. If a DHCP server becomes unavailable, DHCP clients on the subnet
cannot receive IP addresses and options.
A single DHCP server can serve an almost unlimited number of clients. However, factors such as the size and
layout of your network, the IP address class selected for use, and the volume of traffic on your network often make
this impractical. You can deploy multiple DHCP servers to reduce the volume of DHCP-related traffic across your
network and create faster response times for DHCP messages. Deploying multiple DHCP servers also creates fault
tolerance on your network. If you choose to deploy more than one DHCP server, it is important to weigh the
benefits of increased response times against the costs required for additional hardware.
When deciding how many DHCP servers you need, consider:
• The location of DHCP-enabled clients on your network.
• The transmission speeds between the segments for which DHCP service is provided.
If you have slower WAN or dial-up links, place a DHCP server on both sides of these links to improve DHCP response times for local clients.
• The network traffic that DHCP produces, as well as your current network traffic.
If your current volume of network traffic is high, consider deploying multiple DHCP servers to reduce the volume of DHCP requests traveling
across the network. Make sure to account for periods when network traffic is heaviest, such as the beginning of the day, when many users turn
on their computers at the same time.
• Disk space requirements.
It is important to consider the database size when choosing your hardware. Each lease requires approximately 600 bytes per lease for the
database, plus 1200 bytes for backup (600 bytes for the backup and 600 bytes for the temporary directory). In addition, the audit logs require
approximately 500 bytes per lease transaction and are stored for seven days.
Tip
• In general, allow at least 50-70 MB for the audit logs, however the number of lease transactions depends on the number of leases as
well as the lease duration.
To figure out how much hard disk space is required, first multiply the number of leases by 600 bytes, then multiply the estimated number of
lease transactions by 500 bytes, and add these two results. The sum is the minimum amount of disk space required by the DHCP server.
For example, a DHCP server with 10,000 leases and lease duration of one week requires approximately 18 MB to store the leases and the
backup (6 MB for the database, 6 MB for the backup, and 6 MB for the temporary database). The audit logs would require an absolute
minimum of 10 MB: 5 MB (500 bytes x 10,000 leases) for startup, and 5 MB when the leases renew halfway through the week. If the number
of leases increases or if lease time is shortened, this requirement will increase. A company might allocate 100 MB for audit logs to allow for
flexibility in adding leases or reducing lease duration, as well as dealing with any peak-load events.

Using Split-Scope Configurations

You can increase fault tolerance by splitting DHCP scopes between multiple DHCP servers. With a split-scope
configuration, if one server becomes unavailable, the other server can take its place and continue to lease new IP
addresses or renew existing clients. Splitting DHCP scopes also helps to balance server loads.
When splitting the IP address pool of a scope between two servers, assign the same scope to both servers, and
exclude opposite portions of the address range. You also need to make identical reservations at both DHCP
servers, so that either server can assign the reserved IP address, ensuring that the intended device receives the
address that is reserved for its use
In Figure 2.4, DHCP Server 1 has 80 percent of the addresses in the scope and DHCP Server 2 has 20 percent of
the addresses in the scope. Splitting a scope between servers in this way, which is commonly referred to as the
"80/20 rule," often relies on the proximity of the DHCP servers to the clients it serves. For example, when a DHCP
client that is on the same subnet as DHCP Server 1 sends out a DHCP Discover packet, it takes longer for DHCP
messages from clients to reach the DHCP Server 2 than DHCP Server 1, because DHCP Server 2 is on the other
side of a router from the DHCP client. You can also configure a delay on the DHCP relay agent to ensure the local
DHCP server has adequate time to respond. Because DHCP clients always accept the lease from the DHCP server
that sends the first response, clients normally obtain leases from DHCP Server 1. If DHCP Server 1 goes offline for
any reason, clients accept leases from DHCP Server 2.

NetBIOS name resolution

As you know, these names must be resolved so that you can find someone or something on the network to interact with. For
NetBIOS names (such as those called from UNC commands) Microsoft uses a six-step resolution approach, as shown in

STEPS:
To resolve NetBIOS names
Step 1. Check the cache. The NetBIOS name cache, built by the computer browser, is checked for the NetBIOS name/IP
address mapping. If found, the resolution is complete.
Step 2. If the name isn’t resolved from Step 1, the first of three attempts is made to contact the WINS server (if one is
present). If the name is resolved, the IP address is returned to the source host. If the three attempts are unsuccessful,
the resolution process continues.
Step 3. If the name is not resolved by the WINS server, three b-node broadcasts are sent on the local network by the client. If
the proper NetBIOS name is found on the local network, the resolution to the IP address is complete.
Step 4. Next, the LMHOSTS file is consulted. Here again, if resolution is reached, the name resolution process terminates.
Step 5. The HOSTS file is consulted, assuming none of the previous steps have worked.
Step 6. Finally, as a final name resolution step, the source host sends a request to its respective domain name server, which
resolves the host name to an IP address if successful.

Host name resolution

A similar, six-step name resolution approach is used for host name resolution in Windows NT Server (see Figure 8-2):

To resolve host names

Step 1. The host name typed by the user is compared to the local host name. If the two names match, resolution occurs
without generating any network activity.
Step 2. Next, the HOSTS file is checked if the user-typed host name and the local name are not the same. Address resolution
occurs if the user-typed host name is found in the HOSTS file. The host name is mapped to an IP address.
Step 3. If the host name is still unresolved, the source hosts sends a request to the domain name server. If the host name is
resolved by a DNS, an IP address is mapped to it. If resolution doesn’t occur initially, more attempts are made on the
DNS at 5, 10, 20, and 40 second intervals.
Step 4. Assuming name resolution hasn’t occurred, the local NetBIOS name cache is checked next followed by three attempts
to contact and achieve resolution via configured WINS servers.
Step 5. The local host initiates three b-node broadcasts if name resolution still hasn’t occurred.
Step 6. Last, the local LMHOSTS file is checked.

If all six steps fail and you are unable to resolve a host name to an IP address, then darn it, you’re stuck with contacting the remote
host via IP address (not host name). And most likely, a round of troubleshooting will follow.