Getting More Speed from an NT Network

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.
By Ed Woodrick

On This Page

Reduce or eliminate subnets and routers to increase your network's speed
To Subnet or Not to Subnet: That's the Real Question
Routers: A Path Not Taken?
Putting Thoughts to Paper: The Network Design
Designing the Network Services
Configuring the Network
After It Is Built

Reduce or eliminate subnets and routers to increase your network's speed

This article appeared first in Windows NT Magazine in September 1997
Reprinted with permission from Windows NT Magazine.

In "Techniques to Speed Up Your NT Network" (April 1997), Joel Sloss describes how to create a network to connect clients to Windows NT servers. In this article, I'll show you another network design that can increase network speeds even more. I always try to design networks that install easily, work fast, reduce costs, and increase reliability. To create such networks, you need to avoid subnets and reduce the number of routers.

To Subnet or Not to Subnet: That's the Real Question

One major difference between Joel's design and mine is the use of IP subnets. Joel's design features four subnets. I prefer to configure a network without subnets because their use increases complexity and usually decreases performance.

Ethernet switching provides an easy way to segment a network without subnets. The difference between Ethernet switching and IP routing is how deep the device must look into the packet to determine where to send it. In IP routing, the device must look deep into the packet. In Ethernet switching, the device has to look at only the first few bytes, enabling much faster traversal of the network. Ethernet switches are protocol independent and require minimal, if any, configuration. In other words, they're almost Plug and Play.

You can also use IP switches (new devices that offer the speeds of switches and the ability to route packets simultaneously), but their cost is high. As the price of IP switches drops, they will become viable for networks. But at this time, you can justify them for only extremely high-speed TCP/IP networks.

In addition to speed and simplicity, switches offer versatility. With Ethernet switches, you can mix 10Base-T and 100Base-T adapters on the same network, decreasing costs. Many Ethernet adapters feature either 10 Megabits per second (Mbps) or 100Mbps operation. The only difference is the port they plug into. Because the network automatically detects the adapter's speed, you don't need any protocol or setup modifications.

With Ethernet adapters, you can connect 10Base-T hubs to 10/100 network cards in your workstations and servers. Then as the need develops, you simply plug the 10/100 network card into a 100Base-T hub, increasing throughput without touching the workstation.

Routers: A Path Not Taken?

Another difference between Joel's design and mine is how the network connects to other corporate networks or the Internet. Joel suggests that you create a router-to-router connection to link networks. Routers, however, have too many configuration parameters that you can inadvertently misconfigure. As a result, I suggest that you use a port on the existing corporate router to link to other corporate networks. To connect to the Internet, you probably need another router to link to your Internet Service Provider (ISP). You might also need a firewall to provide protection.

To minimize costs while keeping network throughput high, I use 10Base-T ports for standard workstations, 100Base-T ports for advanced workstations, and 100Base-T switched ports for servers. As Table 1 shows, ports for 10Base-T are inexpensive. But, if you have the money, you can connect everyone to 100Base-T, which will increase throughput for network intensive applications.

TABLE1: Cost Per Port

Port Type


10Base-T Hub


100Base-T Hub


10Base-T Switched


100Base-T Switched


10Base-T to 100Base-T Converter


Although I try to avoid using routers and subnets, they do have their place. I can't always design a network without subnets. Subnets work effectively for linking locations with low-speed connections, connecting large numbers of computers, and setting up networks that have many protocols.

Similarly, you might need to use routers. But router configuration isn't for the beginner. With a few hundred parameters to configure, you need to know what you are doing.

Putting Thoughts to Paper: The Network Design

With these considerations in mind, you can start putting the network design on paper. To begin, you must determine the configuration of the hubs, switches, and routers. An average small office needs to provide for about 50 low-speed hub connections, 12 high-speed connections, and 6 high-speed switched connections for the servers.

You can use low-speed connections for a majority of the devices on the network, such as standard workstations, printers, routers, and other instruments. You need to use high-speed connections for engineering workstations and other devices that need high-speed access but usually talk to only one or two other devices. You must use high-speed switched connections to servers or to any device that needs high-speed access and connects to many different devices on your network.

You can configure the network in many different ways. I like to use a 10/100 switch as the central point and connect the 10Base-T hubs, 100Base-T hubs, and servers to it. Figure 1 shows this configuration.

Figure 1: A Simple Configuration

Figure 1: A Simple Configuration

The amount of available bandwidth can help you determine whether to use a hub, switch, or router as the central point in your network. As Figure 2 shows, using a hub is like using one garden hose to connect all the devices. All information flows through the same line.


Figure 2: Difference Between a Hub and a Switch or Router

Using a switch or router is like using several garden hoses to connect each device on the switch or router. Because information flows through several lines, throughput increases significantly.

Routers and switches differ in their total speed capability. Routing imparts a significant penalty: Many smaller routers have problems keeping up with 10Base-T. Some smaller routers can't even handle a T-1 line at 1.544Mbps. Most switches provide full throughput between ports, providing a total of 400Mbps for an 8-port 100Base-T switch.

To provide the fastest connections to the application servers, I give the servers a dedicated 100Mbps port on the switch. If the switch and the network adapter support full duplex, you can run both devices at 200Mbps with no collisions. This configuration provides an extremely fast connection from the clients to the server. Collisions are isolated to the user segments, and each server can obtain full 200Mbps throughput.

Designing the Network Services

After designing the network, you need to create the network services design. Because you don't have multiple subnets to worry about, you might be tempted to put all the network services—such as Primary Domain Controller (PDC), Domain Name System (DNS), Windows Internet Name Service (WINS), and Dynamic Host Configuration Protocol (DHCP)—on one server. But you don't want to build in a single point of failure.

Instead, you can use two servers, each capable of performing all the necessary services. Neither server needs to be very large or fast, just reliable. Two 486 or small Pentium systems, for example, can easily fill the needs of up to 100 users.

When designing the services, you first need to determine the domain controller architecture. An NT domain controller provides security for a network. It lets you centralize user administration to provide a fairly secure network. The NT domain system consists of a PDC and any number of Backup Domain Controllers (BDCs).

Although BDCs are optional, I strongly suggest having at least one. If your PDC fails and you don't have a BDC, you will lose all security information and the ability to access most of the network. Thus, you need to configure both a PDC and BDC. (For more information about how to configure PDCs and BDCs, see Ed Tittel and Mary Madden, "PDCs, BDCs, and Availability," August 1996.)

Although not mandatory, I recommend including DHCP in your network because it can save you a lot of time. DHCP lets you set up workstations and servers without worrying about TCP/IP addresses, gateways, or subnets. You simply set up the package once and then forget about it. DHCP also makes using laptop computers on different networks easy. You just plug the laptop into a new network and reboot the computer. NT will issue the laptop a new IP address so that it can operate on the new network. (For more information about DHCP, see Mark Minasi, "DHCP and Assigning IP Addresses," August 1996.)

Another network service that you can add is WINS, which is a lot like DNS for NetBIOS. On a basic NetBEUI network, computers periodically broadcast who and where they are so that they know about each other's presence. These broadcasts add a lot of traffic to a network and do not work across routers. WINS provides a centralized database of computer names and associated IP addresses to reduce network traffic and enable connectivity across routers.

When a computer running NetBIOS over TCP/IP starts, the computer looks in its configuration (which it probably got from DHCP) and determines whether it knows where the WINS server is. If not, the computer reverts to broadcasts. Otherwise, the computer registers with the WINS server. The registration process includes not only the computer's name and IP address, but also a list of services available on that computer.

Workstations use the registration process to know where the domain controllers reside. Domain controllers register as such with WINS. When other computers need the services of a domain controller, they query WINS for the addresses of all domain controllers. WINS responds by providing those addresses. The clients then communicate with the domain controllers. (For more information about WINS, see Mark Minasi, "NetBIOS Names and WINS," January 1997.)

One service that you might not need is DNS. Basic Microsoft TCP/IP does not require DNS because WINS satisfies all the requirements for name resolution. But if your network needs to communicate with UNIX servers or the Internet, you will probably want to install a DNS server. If you are running Exchange Server, you will want to install a DNS server to decrease client load times. (For information about DNS, see Spyros Sakellariadis, "Configuring and Administering DNS," August 1996, and "Integrating and Administering DNS," September 1996.)

NT 4.0 DNS has a feature not present in many other implementations: It can query WINS for name resolution. Thus, NT 4.0 and WINS can effectively meet all your name resolution needs.

Of the PDC, BDC, WINS, DNS, and DHCP services, DHCP generates the least amount of traffic and requires the least amount of processor time. The DHCP server operates only when a workstation boots and every 36 hours (the default) after that. Thus, on most networks, DHCP works only once when employees turn on their workstations. Because networks use WINS, PDCs, and BDCs whenever the network accesses a resource on a remote system, the usage of these servers occurs at about the same frequency.

For my network services configuration, I typically put PDC on one system and DHCP, DNS, and WINS on the other. This configuration is a good split of resources, especially when running on slower systems. Although most systems can easily handle all the services, I use two systems for redundancy.

I put secondary versions of WINS, DNS, and installed-but-not-operational DHCP on the PDC. Why isn't this DHCP operational? One quirk with DHCP is that it doesn't recognize secondary or backup servers. This quirk isn't a problem, however, because with default settings, a DHCP server can be unavailable for up to three days and the network will continue to operate. But for those of us with redundancy on the brain, this safety net isn't enough. One alternative is to set aside a range of unused IP addresses on the primary DHCP server. If the primary server fails, you can turn on the backup server and configure it with the IP addresses, enabling the network to continue its operations.

Figure 3 shows a complete network and network services design. Server A and Server B are application or file servers needing fast connections to clients, so they have 100Base-T ports. The PDC and BDC do not require fast connections, so they have 10Base-T ports. To provide redundancy, the PDC and BDC are on separate hubs. Besides user workstations, other devices on the 10Base-T hubs are printers and the router connection.


Figure 3: Configuration Details

Configuring the Network

The next task is to configure the network. Steps 1 through 5 summarize the configuration process.

Step 1: PDC and BDC configuration. In an NT domain, you need to configure the PDC server first. You will install WINS and DHCP on the PDC server, so you need to assign the server a static IP address. Before starting the installation, you must determine the server name, domain name, and Administrator password. The server name can consist of up to eight characters with no punctuation. The domain name can be the same length and contain a dash. (These restrictions for the server and domain names are tighter than Microsoft's current requirements. I added more restrictions to accommodate NT 5.0's enhancements to the domain system.) The Administrator password, which must be hard for another person to guess, can be a combination of characters and numbers.

NT Setup will prompt you to set up the PDC during the installation. When NT Setup comes to the server function, select Primary Domain Controller. You will then get the options to set the Administrator password and domain name. After you configure the PDC, you can set up the BDC, selecting Backup Domain Controller as the system function. You will need to enter the domain name and password during the setup so that the BDC can authenticate the PDC and replicate the user database.

Step 2: DHCP configuration. Because the DHCP doesn't recognize backup servers, you need to configure only the PDC. One DHCP server can provide services to a subnet or an entire network. If the network has multiple subnets, you need to configure the routers so that they route the DHCP packets to the DHCP server. (Because the network design discussed here has only one subnet, I will not explain how to do this task.)

To install DHCP, you need to go to the Network applet in Control Panel and add the DHCP Server service. In DHCP, each subnet is known as a scope. A scope contains the information necessary for configuring a specific subnet.

DHCP has global and scope settings. A global setting is the default for all scopes on the server. An example of a global setting is the domain name. The domain name is usually the same for all workstations in a company. Defining the information once simplifies the administration of servers that have many scopes. If you have one scope, you can define settings as either global or scope settings, but good procedure dictates that you put settings in their correct place. With correct scope settings, you can avoid many problems if you have to expand the network in the future.

One of the biggest problems on a TCP/IP network is the assignment of IP addresses and subnets. Two sources assign IP addresses. If you are connecting to the Internet, you will receive the IP addresses from your ISP. If you are connecting to private networks, use one (or a portion) of the address spaces set aside by Request for Comments (RFC) 1918: to, to, and to

Step 3: WINS configuration. WINS is one of the easiest network services to install and configure. (As a result, it's the one that many people tinker with and mess up.) To install WINS, you need to go to the Network applet in Control Panel and add the Windows Internet Naming Service. You don't have to set any properties during installation. The system will request that you reboot when you finish.

Because WINS lets you set up secondary servers, you can replicate databases to other servers. The hardest part of installing WINS is configuring the replication. To change the WINS configuration, select the WINS Manager in the Administrative Tools Program Group. You don't need to change any of the operating parameters except to enable replication. Then select the server on the Server Replication Partners window and enable the Push Partner and Pull Partner selections at the bottom of the window. You must complete this task for each server.

Step 4: DNS configuration. With Microsoft networking, you do not need DNS. However, you will need DNS if you are running UNIX systems, other non-Microsoft network platforms, or Exchange clients. For an internal network, the parameters are fairly simple. (Internet or intranet DNS goes beyond the scope of this article.) Like WINS, just select the Domain Name System service from the Network applet in Control Panel. Choose defaults whenever possible.

Step 5: Connection to the corporate network. I designed the network topology in Figure 3 to make the integration with the rest of the corporate network as simple as possible. As long as the corporate network administrator assigns the IP network address, the connection will be fairly easy. Just get the network administrator to configure a port that will connect you to the rest of the network. To make the network run, all you need is a 10Base-T connection from one of the hubs to the corporate router.

Many methods are available to connect the network to the Internet. The easiest method to use is Microsoft's Proxy Server and a dial-up modem connection. This method is not the most elegant or flexible solution, but it is inexpensive and easy to configure.

After It Is Built

After you have configured the network, you're basically finished. The only maintenance you need to schedule is a periodic compaction of the WINS database if you are not running NT 4.0. Many networks use the AT service to perform this maintenance as a weekly process. The only other task you might need to do is add users and workstations to the network. As you can see, ease of operation is the best feature of this network design.

About The Author

Ed Woodrick is a consultant with ED-COM, a networking and messaging organization. He is an MCSE and MVP currently specializing in Exchange and Directory Services. You can reach him at

About Windows NT Magazine

Windows NT Magazine is the leading publication for corporate IS teams deploying Windows NT and related applications and technologies. Each month you'll find timely, how-to articles, tips and techniques to help you get the most out of your NT system. Keep up with the rapid pace of Windows NT technology changes and better equip yourself to make those all-important technology decisions for your company. Subscribe today!

Over 100,000 paid subscribers receive Windows NT Magazine every month in over 110 countries. Don't delay, for subscription information/to order, point your browser to:

Call 970-203-2782 or 800-793-5712, or email

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.