Binding

So the client is responsible for letting your various programs access file and print network resources. Fair enough. Now, how does the client talk to the network? Well, as we discussed in Hour 1, a client needs to know how to speak the right language, how to use the protocol, and how to ask the network card to initiate a call.

Windows has so many potential protocols, clients, and network cards that Microsoft introduced a concept called binding. This helps straighten out what can appear to be an unholy jumble of protocols, services, clients, and network cards. Taking it from the top, each client can be bound to one or more protocols. Each protocol, in turn, is also bound to one or more network cards (also called network adapters).

---

Don’t bind more protocols than you’re actually using to a network card. Each protocol you bind to an adapter translates into more processing that the CPU must do each time it refers to that adapter. Consider, for example, your dial-up adapter. You probably use it to talk to the Internet via TCP/IP. It would be wasteful to also bind IPX/SPX to this adapter, because the Internet doesn’t speak IPX/SPX. In extreme cases, an overly bound network card attached to a very slow CPU can even cause network problems.

---

---

One of the network newsletters I subscribe to points out that one should not use autodetection to detect frame types in an IPX/SPX environment, because this generates unnecessary network traffic and can really slow down the network in large installations.

Frame types are something I haven’t talked about so far. In a nutshell, a frame type is the way a packet gets built by a network card. You can think of a frame type as a dialect of the protocol—it’s hard for one dialect to talk to another dialect, even though they’re the same language. When someone from the Southeast U.S. says, “I’m fixing to wait on you all night,” someone who’s not from that region might get the wrong idea!

You can find out the frame type in use on your NetWare network simply by typing config at your NetWare server’s console. You can then enter it manually on your Windows workstations. Because autodetection doesn’t always work, this is probably a good idea anyway. I’ve fixed workstations that were acting odd by getting rid of autodetection.

What if you have lots of workstations? Isn’t this a lot of work? Nope. See Hour 16 for tips on how to standardize workstations.

---

Of course, binding is a two-way street; each network card is also bound to one or more protocols. Figure 11.4 shows the Windows 9x screen where you can specify which protocols are bound to a given network card (whether that network card is dial-up or not). To see this for your network card, follow these steps:

1.  Open the Network Control Panel.

2.  Select your network adapter.

3.  Click Properties.

4.  Click the Bindings tab.

Figure 11.4  Showing the bindings on a particular network card.

The Properties dialog box allows you to enable or disable the protocol for a given client or service. (Figure 11.5 shows the Properties dialog box for TCP/IP.) This is the only part of binding that I’m not crazy about; I would rather do it all from one place. In this case, you select the TCP/IP protocol from the Network Control Panel, click Properties, and then click the Bindings tab.

Figure 11.5  Showing the bindings for a particular protocol.

Fortunately, under Windows NT, binding is much more straightforward (see Figure 11.6). Each network card is shown with associated protocols, clients, and services, and everything can be turned on or off from this one place. You reach this dialog box from NT’s Control Panel by performing the following steps:

1.  Double-click Network.

2.  Click the Bindings tab.

3.  Select All Adapters on the Show Bindings For list.

4.  Show subcomponents by clicking components that have a plus sign next to them. (If you see a component with a minus sign next to it, all subcomponents are shown.)

5.  Turn off a bound component by clicking the Disable button; turn it on by clicking on the Enable button.

Figure 11.6  Showing bindings for all components on Windows NT.

Command and Conquer

This is the fun part: You actually get to do something. The following sections cover the TCP/IP commands that can give you the information you need to make intelligent diagnostic calls.

winipcfg

Any time you’re troubleshooting TCP/IP, you want to know how the workstation is configured. You can go to the Control Panel, but that only tells you a limited amount of information, particularly if the workstation is using DHCP. Instead, get to a DOS prompt in Windows 9x and type this:

winipcfg

You’ll need to click the More Info button or type winipcfg /all to get the full output shown in Figure 11.7; otherwise, you’ll see a less complete screen. The full screen is a pretty complete and concise summary of just about every TCP/IP option configured on that workstation. Notice that even though my network card is not DHCP assigned, I can still look at its configuration this way.

Figure 11.7  WinIPCfg output for a client that doesn’t use DHCP or WINS and only uses TCP/IP as a means to access the Internet.

Windows NT users can type

ipconfig /a

at a command prompt to get similar text-based output.

---

A quick comparison of the IP configuration information of two workstations can lead to rapid problem resolution. Of course, any time you compare workstations, make sure you’re comparing apples to apples; they should be on the same subnet. Here’s what to compare:

•  IP addresses—The IP addresses of the workstations should be the same, except for the node numbers (192.168.10.5 and 192.168.10.6 are the same ; 192.168.9.5 and 192.168.11.6 are not).

•  DNS server(s)

•  WINS server(s)

Chances are, if these settings are different, you’ve got a configuration problem rather than a hardware or network problem.

---