Previous Table of Contents Next


Protocol Problems

If you’re the one who installed your server, you’re probably already familiar with the INETCFG NLM, which I call the Swiss Army Knife of Novell networking. This NLM, similar to the Windows Network Control Panel, loads network drivers and binds and configures protocols to them. You can use it to quickly glance at the way things are configured.

Alternatively, you can simply type CONFIG at the console prompt (not LOAD CONFIG; that’s the configuration file generator). INETCFG tells you the way things should be, whereas CONFIG shows you the way things are (see Figure 13.9).


Figure 13.9  The CONFIG output of a server that has one network card and one network protocol (IPX/SPX).

If CONFIG doesn’t match up with INETCFG, you might have a problem. You can sometimes resolve this by telling the server to enact a networking “do over.” Simply type the following:

REINITIALIZE SYSTEM

Scary as this command seems, all it does is reload network card drivers, if necessary, and bind protocols to those cards. It’s really fast—so fast that I’ve run it on a test server, and my session didn’t get dumped. However, I sure wouldn’t try it on a live production server.

IPX/SPX

I’ve already talked a little bit about how automatic IPX/SPX configuration is. Older versions of NetWare did not have automatic server configuration; they left it up to the administrator. Newer versions will scan the network and attempt to set things up right. Let’s take a look at the way things should be on your server’s IPX/SPX configuration anyway, because if they’re not right, you’re in for trouble.

Each IPX/SPX segment needs a network number. This is not a big deal; you can select pretty much any hexadecimal number. The only caveat is that each IPX segment has be unique. The hard-and-fast rule is this: If the segments are connected via a switch, they should have the same network number because the segments are basically the same network. If, on the other hand, network segments are connected via router, they must have unique numbers. If the IPX network number for each network segment is not unique, you can run into problems, such as the inability for the servers and workstations on the segments to “see” each other.

NetWare is just full of unique prima donnas; there’s another number, particular to each server, called the server’s internal IPX network number. This number must also be unique, and it can be really useful in tracking down problems (as you saw in “No Need to Fear; Monitor Man Is Here!” when I tracked down the extra connections to the server itself). This number is hexadecimal; if it’s the same as another server’s number, then it, too, can cause big problems (particularly if a server is acting as a router). In that case, duplicate internal IPX numbers will cause routing to stop working.

If you don’t know what a particular server’s internal IPX network number is, or what the network number is on the attached networks, just type CONFIG (just like with the spaghetti sauce, it’s in there).

Server or Router

Each IntraNetWare or NetWare server with more than one network card in it automatically acts as a router. Without giving away too much from Hour 14, “Router and Switch Basics,” any router, by definition, needs more than one network card because it connects one network to another network.

The only IPX/SPX routing knowledge that you might need to know from a troubleshooting standpoint is that there are two kinds of IPX/SPX routing: NLSP (NetWare Link Services Protocol) and RIP (Routing Information Protocol). A NetWare server that’s configured for RIP can’t talk to an NLSP router unless the NLSP router is running in RIP-compatibility mode. (See Hour 14 for a quick comparison of RIP and NLSP.) I haven’t seen a lot of problems related to this, but it’s worth knowing that there are differences between RIP (older) and NLSP (newer).

TCP/IP

You’ll configure TCP/IP the way you do any protocol: from INETCFG.NLM. The basic configuration is just the way you’d configure a workstation. You do have, however, a couple more things to configure on a server, most notably the services that the server offers. To do this, use the UNICON utility. You can use UNICON to check the service configurations, as well as to start and stop the services if you suspect they’ve gone to la-la land. As you can see from Figure 13.10, UNICON will configure the following items:

  DNS
  NIS (you probably won’t need this unless you’re a hard-core UNIX shop)
  UNIX print services
  FTP


Figure 13.10  UNICON will configure UNIX-like services on your NetWare server.


See the UNI in UNICON? Think it might be referring to UNIX? You’re right! All these services, though ostensibly generic TCP/IP services, got their start in the UNIX world.


You can also check TCP/IP configuration files (or possibly restore the configurations from a backup tape) in the SYS:ETC directory.


In particular, the SYS:ETC/RESOLV.CFG is a really important configuration file—symbolic name lookup (DNS) won’t work unless this is configured properly.

The TCP Con Game

When you load TCPCON, you can check more TCP/IP-related statistics and functions than you’d ever want to. TCPCON can handle many functions, as shown in Table 13.1.

Table 13.1 TCP/IP Functions Available from TCPCON

Function TCPCON Navigation

Check TCP/IP statistics and error counts Statistics menu
Check the routing table IP routing table
Check current TCP or UDP socket table (just like netstat -a in UNIX or Windows) Protocol Information|TCP or UDP|Connections
Check the MAC-to-TCP/IP address table (just like arp -a in UNIX or Windows) Protocol Information|IP|IP Address Translations


Can’t load IPTRACE or PING? Believe it or not, these weren’t always included in the standard Novell TCP/IP distribution. Load the latest patches, and you’ll magically have these tools.

Other life-saving TCP/IP tools include these:

  LOAD PING Standard ping (but you can ping multiple stations at a time)
  LOAD IPTRACE Novell’s answer to traceroute


Previous Table of Contents Next