Techniques to Speed Up Your NT Network

In the October 1996 Lab Guys column, "Overloading Your Server with Multi-Homing," John Enck and I raised the issue of putting multiple IP addresses or multiple NICs in your Windows NT server: Does multi-homing work? We invited readers to submit ideas about how to make multi-homing work, because the Windows NT Magazine Lab ran into serious operational difficulties. Thanks to everyone who suggested ideas or echoed the Lab's concerns. We're happy to report that we have a solution--not the solution, mind you--but one possible solution. Let's look at some issues the Lab faced and how we resolved them.

The Problem
One problem is how to increase network bandwidth for application servers. We test servers of all sizes in an enterprise environment designed to mimic corporate networks. We need to know two things: 1) that we can build fat data pipes into our test servers for thousands of users on one network, and 2) that network I/O is not a bottleneck in our test environment.

You can take two approaches to network administration: Spend a lot of money and buy the biggest, fastest hardware; multiple Class-C IP licenses; and so forth, or make do with what you have and hope your users are patient. The Lab aimed somewhere in the middle: We limited IP addresses, servers, and network cards, but we used some expensive equipment.

Our setup is not unique. We need to run one NT domain, using TCP/IP, Dynamic Host Configuration Protocol (DHCP), and Windows Internet Name Service (WINS) for up to 50 workstations (simulating 500 to 2000 users) and 10 servers on 4 independent subnets, while maintaining trusts with other domains and access to our 10Mbps corporate network and the Internet. We need to operate on 100Base-TX so that our virtual users don't get bogged down by thin network pipes and we get a clear picture of server performance. Compared with a corporate organization that has 2000 client workstations, 100+ servers, and who knows how many separate networks, the Lab's setup is like a walk in the park.

The Solution
I won't describe all the things the Lab tried, but I will mention two things we learned not to do:

* Don't assign IP addresses to two cards in the same server on the same subnet (e.g., 205.200.45.50 and 205.200.45.51) without subnet masking. Such an arrangement hopelessly confuses NT, even if you run Multi-Protocol Routing (MPR), because the OS doesn't know which card to use for which packets.

* Don't cascade hubs. You can chain only a limited number of 10Base-T hubs, you cannot chain Class-1 100Base-TX repeaters at all, and you can cascade only two Class-2 hubs. If you cascade hubs, you end up with contention between ports; that is, systems (IP packets) earlier in the chain get priority over later ones. Instead, use switches, which boost network performance in other ways (e.g., add full-duplex capabilities and high-speed backbones).

What should you do? Your solution depends on your situation. Our limitations dictated our course of action. Figure 1 depicts our logical network layout, and "Windows NT Magazine Lab's Enterprise Testing Environment" details our resource and testing requirements. Working closely with engineers from Adaptec and Cisco Systems, who each supplied a piece to our puzzle, we set up our network solution as follows:

* We had only one Class-C license, so without setting up a proxy server (also an option), we divided our 256 available addresses among four IP subnets (one resource and three client virtual LANS--VLANS, same physical network, different collision domains).

* To accommodate four separate networks talking to the same resource server, we needed a router. We used a server running Microsoft's NT MPR software (built into NT 4.0; available for NT 3.51 from Microsoft's Web site at http://www.microsoft.com). Using an NCR Globalyst S40 with two 133MHz Pentiums, 128MB of RAM, three 2.1GB Fast and Wide SCSI-2 drives, and an Adaptec Quartet 4-port 100Base-TX full-duplex NIC, we installed MPR and DHCP services to route among our four networks and assign IP addresses to all clients and resource servers.

* Because our setup was a domain, we needed a Primary Domain Controller (PDC). We used a Digital Equipment Prioris HX 5133DP, with two 133MHz Pentiums, 64MB of RAM, two 2.1GB SCSI-2 drives, and a single Adaptec 100Base-TX NIC. This system also functioned as the WINS server for NetBIOS name resolution (our testing software referenced machines by name).

* We set up five 100Base-TX hubs for our network: one 8-port Netelligent from Compaq and four 12-port hubs from Adaptec. We also needed a fast Ethernet switch--we started with a 6-port Netelligent 100-TX switch from Compaq, but we outgrew it. So we acquired a Cisco Catalyst 5000--an expensive piece of networking hardware (with a base price of $11,000), but worth the price if you want the power. For our test environment, we needed expandability, flexibility, and performance. The Catalyst 5000 came with one supervisor card (with two 100Base-TX ports) and three line cards (12 ports each), giving us a total of 38 configurable full-duplex switch ports. We separated 32 of these ports into 4 VLANs, giving us 4 essentially independent 8-port switches. (We could have used 4 separate, smaller boxes, but the Cisco gave us more flexibility).