Optimize your binding settings in Windows 2000, part 1

Brush up on bindings, an often overlooked but crucial aspect of networking. One of our experts offers IT pros these tips on how to optimize bindings and their networks.

One of the most important but lightly taught aspects of networking is bindings and the order in which they can be processed. In two articles I provide a few simple steps to help improve network performance and reduce network traffic.

In this installment, I will introduce bindings and the transport driver interface and offered tips on how to adjust protocols to improve networks. In part two, I will cover network driver interface specification, how to best reduce the number of network protocols and how to optimize network bindings.

Bindings can be confusing at first, so let's take a look at what they do before optimizing their settings.

Figure 1 shows an example of how bindings are typically set up, starting with the I/O Manager in Windows 2000, which resides in the executive portion of the Windows 2000 operating system. Click here to view Figure 1.

While at first glance this may look confusing, it's actually fairly simple. The entire model resides under the I/O Manager. The I/O Manager is a true manager: it doesn't do anything itself; it simply passes requests off to someone else.

Let's say the I/O Manager receives a request from a network client for a file located in a share on a server. The I/O Manager passes the request to the local file system, which retrieves the file and passes it back to the I/O Manager. Because the server service originally requested the file and handled the incoming request, the server service receives the file and sends it to the proper protocol through the transport driver interface.

The transport driver interface (TDI)
The TDI is an interface between the transport layer and upper-level applications and interfaces, such as NetBIOS or Winsock applications; services such as the server service and any redirectors, including clients for Microsoft Networks service and workstation service; and any third-party redirectors, such as client services for Netware or Gateway and client services for Netware, if a server.

Third-party software manufacturers usually provide their own redirectors. For example, Novell provides a redirector of its own, and Microsoft's redirectors are built in. Microsoft also has a redirector for Novell, so you have a choice. Redirectors reside on the presentation layer of the OSI Model. The TDI makes it easier to write transport layer protocols, because any protocol conforming to the TDI model can communicate with higher-level applications using the common TDI interface.

On the reverse side, the TDI makes it easier for IT programmers to develop upper-level client applications and services because the software only has to be written for the TDI standard. This means programmers don't have to write separate clients for Microsoft Networks for TCP/IP and NetBEUI. The TDI lets the Microsoft Networks client work with any installed protocol that recognizes it. If you install the TCP/IP, IPX/SPX and AppleTalk protocols, for example, the Microsoft Networks client will automatically bind to TPC/IP and IPX/SPX, but not AppleTalk. On the other hand, if you install Gateway and client services for Netware, the Microsoft Networks client only binds to IPX/SPX, because that is all it's programmed to use.

You can see in Figure 1 that transport protocols are directly below the TDI. These protocols can have a huge impact on network performance.

The first rule of installing protocols is minimalism. If you don't have to install a protocol, then don't. Remember, the network will broadcast on all installed protocols because it doesn't know which protocols you're watching. The network wants to ensure all protocols get messages.

Also, if the network can't contact you on the first protocol in the binding order, it will try the rest until it either finds you or runs out of protocols. If you have one protocol and add another, you basically double the network broadcast traffic. The more protocols you add, the more traffic on the network.

A fellow administrator once complained to me that his network was slow and asked me to take a look. He had every available protocol installed "in case someone wants to call me on one of them," he said. Most likely you're not running the phone company, so there should be no unexpected calls. And your Active Directory design process should outline what protocols will be used for before installation.

If later you need another protocol, install it. But until then, only install protocols the network requires. On the other hand, take every opportunity to remove unnecessary protocols. For example, if you don't use NetBEUI anymore, get rid of it. If you upgraded Novell servers, remove IPX/SPX. Every protocol removed should decrease network traffic and improve network performance.

These simple steps will help you to improve network performance and lower bandwidth usage. I simplified the explanations for brevity. If you want to learn more, I recommend the comprehensive and well-written Windows 2000 TCP/IP Black Book by Ian McLean, published by Coriolis, Networking Essentials by Microsoft Press, and TechNet's Knowledge Base.

About the author: Douglas Paddock, MCSE, MCT, MCSA, is a CIW security analyst and CIW certified instructor. He is also A+ and N+ certified. He teaches at Louisville Technical Institute in Louisville, Ky.


>> Vulnerable ports on Windows 2000 Web servers

>> Security checklist for system administrators

This Content Component encountered an error



Enjoy the benefits of Pro+ membership, learn more and join.



Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: