Networking

Reducing network traffic in a Windows 2000 environment

Use these tips on smart subnetting and Active Directory replication to free up more bandwidth on your network.


One of the big problems facing network administrators is that oftentimes bandwidth doesn’t grow along with the company. One particular company that I used to work for decided to open an office 20 miles down the road. This new office only had five PCs, but it was connected to the main office through a T-1 line. Needless to say, bandwidth was no problem at first. However, by the time I left the company, there were more than 400 employees working at the remote office. The once-adequate T-1 line was so congested with traffic that it became nearly impossible to use.

If you ever find yourself in a situation such as the one I just described, you’ll be happy to know that there are things that you can do to make your bandwidth usage more efficient. By doing so, you’ll be able to comfortably support more users with your existing connections. In this Daily Drill Down, I’ll explain several strategies that you can use to make network communications more efficient in a Windows 2000 environment.

Traffic reduction
When it comes to making more efficient use of your bandwidth, the most important thing to remember is that you have only a certain amount of bandwidth with which to work. There’s really no way to force more traffic across the network lines than the amount those lines are designed to handle. Therefore, if you’re at or near your bandwidth limit and you need to add more users, who will in turn require more bandwidth, then you’ll have to get rid of some of the existing network traffic to allow room on the line for the new traffic.

Many times when you hear someone talking about reducing network traffic, people’s minds immediately associate traffic reduction with a reduction in functionality. But let’s face it, in the business world, losing functionality is usually not an option. My goal in writing this Daily Drill Down is to provide you with some methods of reducing network traffic in a way that doesn’t reduce any of your existing capabilities. With that said, let’s look at some ways of reducing network traffic by eliminating unnecessary traffic.

Smart subnetting
If you’re running a TCP/IP-based network (and who isn’t these days?), you’re probably already familiar with the concept of subnetting. Just in case you’re not completely familiar with subnetting, it’s basically a technique that divides one large network into several small, interconnected networks. The benefit of subnetting is that packets stay within the network on which they originated unless they’re specifically destined for a PC on another segment of the network.

In theory, if you divided one large network into three subnets or segments and no traffic ever left the segment on which it originated, you would triple your bandwidth. The reason for this is you now have three networks instead of one. Of course, tripling the bandwidth by dividing a network into three subnets only happens in theory. In reality, there’s almost always traffic that flows between the subnets. For example, any time that someone needs to access data from a server that exists in a different subnet, packets must leave the subnet and travel across different subnets in the organization.

In spite of the fact that it’s almost impossible to limit people to consuming bandwidth only in their own subnet while still maintaining a functional work environment, there are some things that you can do to limit the amount of traffic flowing between subnets.

It isn’t always possible because of geography, but the best way to design your subnets is to think of each subnet as an independent network. Obviously, in any network situation, you want the network users to be able to access the resources they need. Likewise, you also want to prevent people who don’t belong on the network from browsing it. Keep these ideas in mind when designing your subnets.

One of the most effective ways of doing so is to create departmentalized subnets. Basically, this means each department has its own subnet. After all, why should the marketing department consume bandwidth from the finance department?

You can design these departmentalized subnets in a way that most of the resources needed by a department are located within the department’s subnet. For example, if the finance department has its own server, you should include it in the finance subnet. This will allow users in the finance department to access the server without sending packets across other subnets. Likewise, all of the department’s network printers should also be included in the department’s subnet.

Keep in mind that when I’m talking about departmentalized subnets, I’m not talking about building completely isolated networks. I’m enough of a realist to know that isolated networks seldom get the job done. After all, there will be times when the marketing department needs to access a file off the finance department’s server. Likewise, it’s usually financially impossible to give each subnet a dedicated Internet connection. When users access the Internet, many of them will have to send packets across other subnets to reach the company’s Internet portal. As you can see, even with departmentalized subnets, there are many times when it’s necessary for traffic to flow between subnets. Even so, by building departmental subnets, you’ll prevent the majority of the network traffic from escaping from the subnet where it originated, thereby increasing your available bandwidth.

Sites
Building departmental subnets prevents most of the user-related traffic from congesting the network, but what about server-related traffic? In a Windows 2000 environment, traffic caused by Active Directory replication can be considerable. Keep in mind that any time a change is made to Active Directory, the change is replicated to every domain controller in the entire network. The more changes that occur, the more bandwidth is consumed by server-related replication traffic. Fortunately, there’s a way of getting around this problem.

To understand how it’s possible to reduce the traffic caused by Active Directory replication, it’s necessary to consider the nature of Active Directory. Active Directory contains security and biographical information for each user, computer, printer, etc. on the network. But not every user needs constant access to all of this information. After all, if you’ve built the departmentalized subnets that I described earlier, then why should a user in marketing care if the finance department gets a new printer?

To put it simply, you must replicate Active Directory changes among the domain controllers on your network so that your Active Directory will remain consistent. While some Active Directory updates need to be replicated faster than others, you can greatly reduce the amount of directory replication traffic on your network by delaying unimportant replications until a time when the network is less busy, such as late at night.

The trick to dividing up replication traffic is to divide your network into sites. A site is nothing more than an Active Directory structure that’s designed to group together the servers that service a similar group of people or a similar geographic area. For example, you might create a marketing site and a finance site. If you did so, replication would occur quickly within the site. After all, if you made an Active Directory change within the marketing site, then the people in the marketing department would be the ones affected by the change. Therefore, it’s necessary to replicate the change to the marketing site quickly.

Since the people in the finance department would be unaffected by the change and would likely never even know about the change, it’s usually okay to put off replicating the change to the servers in finance until a less busy time. When you configure the site connector (an Active Directory object that establishes a logical link between sites), you’ll have an opportunity to set the replication schedule in a way that meets your needs.

I mentioned that a site is usually a group of servers that share a similar purpose or geographic location. So far I’ve discussed sites in terms of a local area network. In essence, my examples have all assumed that the individual departments are in close proximity to one another. Dividing a network into sites works really well if your network is divided by a WAN link. By creating a site on each side of the WAN link, you can minimize the amount of replication traffic that flows across the link during business hours, thus freeing up the bandwidth for more important things.

More on intersite directory replication
When you divide up your network into sites, there are other things that you can do to minimize the impact of server-related traffic and other delays. One such technique involves designating a preferred bridgehead server in each site. The bridgehead server is the server responsible for replicating Active Directory changes with other sites.

When choosing a bridgehead server, it’s usually a good idea to select a server with plenty of free memory and hard disk space. It’s also a good idea to select a server that has plenty of processing power but that isn’t carrying a heavy workload. The reason for the selection criteria is that the replication process can consume a lot of power, and you don’t want to bog down a server with replication tasks to the point that its other functions suffer.

Another consideration is the amount of bandwidth available to the bridgehead server. Needless to say, the more bandwidth that’s available, the less impact that replication traffic will have on client-related traffic. One way of ensuring that the bridgehead servers have adequate bandwidth is to connect the bridgehead servers to each other via a dedicated connection. Such a dedicated connection between servers is sometimes referred to as a backbone.

In such an arrangement, each bridgehead server would have two network cards. One network card would be connected to the local area network. This is the card that would be used for client/server communications. The second network card would be connected to a dedicated line that services only bridgehead servers.

Setting up the bridgehead servers with a dedicated replication path accomplishes two purposes. First, it guarantees that under normal circumstances no intersite directory replication traffic will flow on the normal network lines, thus freeing up that bandwidth for client use. Second, it provides a degree of redundancy.

When you set up a site connector, you must configure Windows 2000 with knowledge of which network cards it can use to connect to a remote site. If it’s possible to reach the remote site through either card, you can associate a cost with each network card. Windows will always use the lower cost connection unless it’s unavailable.

Therefore, if you set the cost of the dedicated connection to 1 and set the cost of the normal connection to 2, then Windows 2000 would always send intersite directory replication traffic through the dedicated port, unless a failure made that port unavailable. If a failure did cause the dedicated path to be unavailable, Windows would route the replication traffic through the next lowest cost port—in this case, the primary network.

Unfortunately, setting up a dedicated replication network works only on LANs. In environments in which traffic must pass through a WAN link, there’s usually no way to provide a dedicated backbone between the servers, and you’ll end up having to use the WAN link for client/server traffic and replication traffic. In that situation, your best bet is to simply limit the amount of replication traffic flowing across the WAN link by adjusting the replication schedule.

Conclusion
In this Daily Drill Down, I explained that many times companies don’t add more bandwidth as the user count increases. I then discussed several techniques you can use in a Windows 2000 environment to make the bandwidth usage more efficient.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.

Editor's Picks

Free Newsletters, In your Inbox