Segmenting Your Network

Tweak your physical infrastructure to improve performance

When I think about performance tuning, I always see images of car-racing pit crews using precision instruments to make subtle adjustments to their cars' engine, tires, and chassis. To get the maximum performance from their cars, pit crews tweak their cars' parts to suit environmental factors such as track condition and air temperature. Similarly, Windows NT administrators continually apply patches and tweak settings on their networks in an ongoing effort to squeeze as much performance as possible out of their systems. This issue of Windows NT Magazine provides many suggestions to help you improve the responsiveness of the systems you administer. As you make performance improvements to your individual machines, don't forget to maintain a sound physical network infrastructure. A poorly designed physical network can completely negate any performance improvements you make on a server, just as flat tires would restrain a finely tuned Indy-car engine. Use the following tips and techniques to properly segment your network and maximize the benefits of performance tuning your systems.

What Is Network Segmenting?
Segmenting at its most basic level is the process of separating certain portions of network traffic, either for performance, security, or reliability reasons. You can use a bridge, a switch, or a router to separate your network's devices into segments.

Performance tuning is at once a science and an art. Knowing your options for grouping various devices to form a network is the science of network segmenting. However, successful networking requires you to choose your segmentation points wisely, considering all the devices on your network—this requirement is the art of network segmenting. To master this art, you must understand the types of traffic on your network and the path each type of traffic takes. Then, you must minimize the number of devices between the source and destination points of each packet.

NT Servers Between Segments
Many administrators use NT servers as routers between their network's segments because of budget constraints or because adding NICs to an existing server is easier than restructuring a network. Figure 1 depicts a network with two servers—each of which has two NICs—and two user segments. This network might seem simplistic, but many companies employ this type of network configuration—sometimes with hundreds of user workstations. This segmenting scheme places a performance burden on the two servers. The servers not only provide standard user services, but they are also responsible for routing packets between network segments. In addition, both servers in this network design must be available for users on one segment to be able to access the other segment. If one server goes down, users on that server's segment are unable to access the failed server and are also unable to access resources on the other segment.

To maximize performance, this network's administrators need to place a bridge between the two segments, as Figure 2 depicts. In Figure 2, each server is on the segment on which it gets the most use. Bridges don't retransmit packets that don't need to pass through them, so this configuration reduces network traffic without introducing routing overhead onto the servers. In addition, Figure 2's users won't lose access to the other network segment if one server crashes; the bridge will route traffic, so users on both sides of the network will still have access to the functional server. Bridges occasionally crash, and a bridge failure would prevent users on each segment from accessing the other segment. But most bridges crash far less often than servers crash, and in the event of a bridge crash, users on each side of the network can access the server on their segment.

Switched Environments
Suppose your network has grown to the point that you don't want to keep all your devices on one physical segment anymore. Switches provide the easiest and most common way to segment traffic. Switches and bridges behave similarly; both devices accept traffic on any of their ports, examine each packet for destination information, and transmit the packet only to the port on which the target device resides. The primary difference between a switch and a bridge is that switches work on a larger scale. Switches usually have at least a dozen ports, but bridges usually have only two ports.

Unlike switches and bridges, a hub transmits packets to all of its active ports. Many people refer to hubs as shared media because every device that connects to the hub has to share its bandwidth with all the other devices that connect to the hub. If you connect too many hubs, you end up with a shared network too large to let users work effectively.

To design a switching layout for your network, start with a switch on the central backbone of your enterprise network. This switch must extend to hubs or more switches. Users on some networks connect to the network through those secondary switches; this configuration is commonly referred to as a switched-to-the-desktop setup. This setup is becoming more common as low-cost switches are becoming more prevalent. This configuration provides more security and better performance for each user than any other network segmenting configuration, but it costs more per port than any other segmenting method.

Most companies still connect their user workstations to hubs. If your central switch connects to hubs or groups of hubs for user workstations, you can take several steps to improve your network's performance. Keeping in mind how traffic flows on your network, use the following guidelines to improve your network performance in a switched-and-shared environment.

Group frequently talking partners together. Consider keeping some servers on the same network segment as the servers' most frequent users. This concept runs contrary to the typical centralized-IS mentality, which encourages you to keep all major servers in a common area, but it might increase your network's performance. For example, if 90 percent of a server's traffic relates to your graphic arts department's production work, you might want to place that server on the graphic arts department's physical network segment. This server placement would reduce traffic on the central switch and shorten the path that the production work's packets take to get to their destination.

Give many-to-one devices their own port. When you install a switch, you know that some devices—such as servers and hubs—need their own ports on the central switch. But what about other devices that many users will attempt to access, such as an Internet connection? In general, if more than a few users routinely access a device, it needs a separate port on the switch.

Load-balance bytes on each switch port. Experts debate how many devices can and should be on each network segment. Most experts think that running between 24 and 48 devices on the same physical 10Mbps Ethernet network segment is acceptable. However, the number of devices a segment can hold depends on how much traffic each device generates. When you determine how many users to place on each logical segment of your network, consider the amount and type of traffic each user generates rather than simply balancing the number of users on each switch port. Some users (e.g., a graphic arts department) might use much more bandwidth than other users. Therefore, if you use one switch port to connect to a 24-port hub for most of your users, consider purchasing two 12-port hubs for your high-bandwidth users and connecting each hub to a separate port on the switch. This configuration will increase the high-bandwidth users' performance.

Avoid overloading your devices. One of the primary reasons for implementing switching on a network is to reduce performance bottlenecks. However, if you don't design your network properly, your network segmenting might introduce new bottlenecks. Consider the network diagram in Figure 3. This network switch has 12 ports, 8 of which link to 10Mbps hubs and 4 of which connect directly to servers. Suppose that during peak periods, users on each of Figure 3's 8 hubs create 2Mbps to 3Mbps of bandwidth for the servers. This situation would result in a total of 16Mbps to 24Mbps heading to the network's servers. If the servers have only 10Mbps connections to the switch, one server might become overloaded if it received half the network's traffic. Make sure your network can handle user loads during periods of peak traffic.

Segmenting via Routers
Although routers commonly connect geographically dispersed networks, you can use them to segment local networks. However, because administrators usually use routers to route traffic across WAN links, bandwidth between routers is usually limited and expensive. Minimizing router traffic is a key goal of performance tuning a network that uses routers.

To reduce the bandwidth they use, most routers don't retransmit broadcast packets by default. However, you might want your router to retransmit broadcasts to improve the success rate of one of NT networks' primary housekeeping chores—name resolution. By understanding how Windows Internet Naming Service (WINS) clients resolve names on your network, you might be able to reduce traffic across your WAN links.

WINS clients have four methods for resolving a network device's name. First, they can send a broadcast packet looking for the name of the machine. If a machine with a matching name doesn't respond to the broadcast, WINS assumes that no such device exists on the network. Second, a WINS client can send a directed packet to a WINS server requesting a name resolution. If the WINS server knows the IP address of the target machine, it passes that information to the client. The other two ways that WINS clients resolve NetBIOS names are combinations of the first two methods: broadcast first, then send a directed packet if the broadcast is unsuccessful (known as mixed node), and send a directed packet first, then broadcast if the directed packet is unsuccessful (known as hybrid node). For more information about NetBIOS name resolutions, see Mark Minasi, "Inside a NetBIOS Name Resolution," March 1997.

Because broadcast packets don't typically cross routers, broadcast name resolution doesn't work if the device the client is trying to access is on another network segment. Therefore, directed packets are the primary mechanism for resolving NetBIOS names on routed networks. However, broadcasts might be useful in the network Figure 4, page 69, depicts. As you can see, the network has two primary offices (Office B and Office C), which connect via a high-speed T1 circuit, and two satellite offices (Office A and Office D), which connect to the network via slower, 56Kbps connections. Office B and Office C include WINS servers that are replication partners. If users in Office A typically access only other devices in their office, their workstations shouldn't have to send directed requests to a WINS server across a WAN link to find local devices. If users primarily use local devices and don't have a local WINS server, you'll probably want to let them broadcast first to resolve addresses and send directed packets only when the broadcast fails. Setting client machines to mixed node might improve performance by reducing communications across the WAN link and allowing local clients to resolve the names of local devices quickly.

You might have considered another alternative that I've carefully avoided mentioning: putting a WINS server in each satellite office so that WINS servers in every office can resolve names locally without broadcasts. I don't usually recommend such a configuration; adding WINS servers to your network usually increases the number of replication partners each system has, and therefore increases the amount of replication traffic on your network. Depending on your WINS servers' replication configurations, the additional WINS servers might increase your replication traffic exponentially. You might actually reduce your network's speed by adding WINS servers. Let me put into perspective the potential for delays on a network with too many WINS servers: Microsoft had only about a dozen WINS servers on its corporate network last time I checked.

Multi-NIC, Multiprotocol Environments
Suppose budget constraints have forced you to expand your network by adding NICs to your server, and you now have a large server that contains five NICs—four NICs for user segments and one NIC for a dedicated Internet connection, as Figure 5 shows. Also suppose that you have to leave IPX and NetBEUI running on the server to support some old DOS or Windows clients. If you accepted the NT defaults when you added all those protocols to your server, you bound each protocol (TCP/IP, NetBEUI, and IPX) to each of your five adapters. Binding each protocol to every NIC lets you plug in devices that use any of the three protocols anywhere on your network, so this approach might seem like a good time-saver for overworked administrators.

However, because of how Microsoft browsing works, binding each protocol to each NIC adds a lot of unnecessary broadcast overhead to your network. Microsoft clients and servers find out about other devices on the network through browsing. In case some of the devices on your network have only one protocol installed (e.g., an old IPX client), the server responsible for maintaining the browse list must broadcast its information to each network segment in every protocol that segment uses.

Therefore, in a multi-NIC, multiprotocol environment, you can get better network performance if you group machines by protocol, then unbind the unnecessary protocols from each server's NICs to prevent the server from sending out unnecessary broadcasts. You don't need your server to send IPX and NetBEUI browser announcements through the adapter for your Internet connection. Examine where your clients are and what protocols they're running. If you can run all your machines under one protocol, do so. But if you need multiple protocols on your network, try to group clients that use the same protocol on a network segment, then bind only the protocols necessary for each segment to that segment's NIC.

Get the Tools
Just like an Indy-car pit crew, you need the right tools to understand the traffic that travels across your network. By making subtle changes to your network's traffic patterns and reducing unnecessary traffic, you can tweak your network for maximum performance. I highly recommend getting familiar with a network-monitoring tool such as Network Monitor, a limited version of which comes with NT, or a more robust program such as Network Associates' Sniffer Basic (formerly NetXRay—for information, see Michael P. Deignan, "NetXRay 3.0," January 1998), HP OpenView NetMetrix, or Concord's Network Health. (For more information about network monitoring, see Toby J. Velte, "Application Testing with Network Monitor," September 1998, and "Simulating Your NT Network," January 1999.) With the right tools in hand, you'll be well on your way to squeezing every last drop of performance out of your network.