Segmenting Your Network
Tweak your physical infrastructure to improve performance
by Douglas Toombs, MCSE, Windows NT Magazine - March, 1999
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.
(If your browser does not support inline frames, click here to view in a separate page.)
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.