Multiple Ip Addresses

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.