One of the most important but lightly taught aspects of networking is bindings and the order in which they can be processed. In this two-part series, I provide a few simple steps to help improve network performance and reduce network traffic.
In part one I introduced bindings and the transport driver interface and offered tips for adjusting protocols to improve networks. In this installment, I will cover network driver interface specification, how to best reduce the number of network protocols and how to optimize network bindings.
Network driver interface specification (NDIS) 5.0
NDIS links multiple protocols to a single adapter. The NDIS wrapper shown in Figure 1 is a collection of network interface card (NIC) device drivers that allow NICs to bind to any or all of the supported protocols. Click here to view Figure 1.
This prevents developers from having to write a NIC driver for each protocol and keeps administrators from having to either install more than one driver for the same NIC or installing a different NIC for each protocol.
Remember NIC drivers reside on the media access control (MAC) sub-layer of the data link layer in the OSI model. The NDIS wrapper is an interface between NIC drivers on the MAC layer and the transport layer protocols. (I didn't forget the network layer. I just lumped it with the transport layer in this model for simplicity.) Shown last in Figure 1 are the physical NICs themselves, which interface with the MAC sub-layer of the data link layer.
Under Start, Settings, Network and Dial-up Connections, there's a Network and Dial-up Connections folder. Click on Advanced, then Advanced Settings, and you'll see a panel similar to the illustration in Figure 2. When I installed the server in this case, I installed TCP/IP as my only protocol. Later, I acquired a few older Novell clients and a Novell 3.12 server, so I installed file and print services for Netware and Gateway and client services for Netware and NWLink IPX/SPX protocol.
Because IPX/SPX was installed last, it comes out first in the bindings order. This is a problem because I have 2,000 Microsoft clients and 12 Novell clients. But because IPX/SPX is listed first, my network will always try to contact all clients using IPX/SPX first then try again using TCP/IP. Because the network has only a 12-in-2,000 chance of being correct in trying to contact clients with IPX/SPX first, my network performance is significantly hampered.
|Corrected bindings list|
How do you fix this?
Just highlight NWLINK once, then click on the down arrow on the panel's right side. This moves the IPX protocol down (see Figure 3). Now TCP/IP will be used first when contacting clients. You have to do this for both file and printer sharing and client for Microsoft Network Bindings.
Installing Gateway and Client Services for Netware put Netware at the top of both the Network Providers and Print Providers lists. Again, highlight one of the entries and move Microsoft Windows Network to the top of the list. Move Netware to the bottom of the Print Providers list to optimize performance.
You can further optimize bindings by disabling unused ones. By default, all protocols are bound to all services that can use them. However, if you're running file and print services for Netware to support older Netware clients, you can improve network performance by unbinding IPX/SPX from your client for Microsoft Networks, because only the server service will be using IPX/SPX to support Novell clients.
|Original provider list|
Just clear the check box for IPX/SPX under Client for Microsoft Networks. Note: make sure the service you're unbinding is not needed by that client, or you might receive some calls from irate users. All my IPX/SPX clients reside on the subnet serviced by NIC 1, so I don't need to install IPX/SPX on NIC 2, improving performance on that subnet.
These simple steps will help you 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.
FOR MORE INFORMATION
>> Share your bloopers with us. You could win a prize! E-mail Editor@searchWindowsManageability.com
>> Here is a full listing of all our true IT bloopers.