NetWare 6 includes a browser-based administration tool called ConsoleOne. ConsoleOne is designed like a file manager utility with a left pane (where you browse containers) and a right pane (where you manage network resources and eDirectory objects). Check it out for yourself in Figure 15.1.

FIGURE 15.1 ConsoleOne browser tool.

As a browser-based GUI tool, ConsoleOne supports cross-platform compatibility from both the Novell Client workstation and NetWare 6 server. Both platforms require Java support. On the server, that support is provided by Java Virtual Machine (JVM), which is loaded by default when the server boots. On the workstation, the Java platform is installed as a Custom option during Novell Client setup.

When you upgrade NetWare or any of its components by installing a new Support Pack, you should also upgrade the NetWare management utilities—including ConsoleOne. By upgrading these tools, you can take advantage of improved performance, remote management capabilities, and additional features that will enhance your troubleshooting duties.

From a troubleshooting perspective, ConsoleOne for Windows enables you to generate pre-defined troubleshooting reports. Keep in mind that the other ConsoleOne platforms do not support reports functionality. To run reports, ConsoleOne must be installed on a Windows workstation with at least 128MB of RAM. In addition, the eDirectory tree must contain at least one NetWare volume for installation of report catalog files.

After you’ve extended the schema to support reporting, you must install the desired reports. The following pre-defined report categories are available:

Don’t forget, you must use the Windows version of ConsoleOne to enable troubleshooting reports. This functionality is not available on the other ConsoleOne platforms—NetWare, Linux, Solaris, and Tru64 Unix.

Remote Manager is the most robust of the five anytime, anywhere troubleshooting utilities offered by NetWare 6. You can use Remote Manager to monitor server health, to change the configuration of your server, and to perform diagnostic and debugging tasks.

To access Remote Manager from any Web browser, simply enter the following URL in the Address field:

The NetWare 6 Remote Manager window is shown in Figure 15.2. This screen is organized into five different management frames: Health Indicator, Header, Navigation, Main Content, and Online Help.

FIGURE 15.2 NetWare 6 Remote Manager.

Using Novell Remote Manager, you can monitor the health of your servers, their processes, and CPU usage. You can also perform common server management tasks such as mounting and dismounting volumes, managing server connections, configuring SET parameters, and shutting down, restarting, and resetting your server. Even though Remote Manager is designed for server-specific administration, it includes a link to iMonitor for eDirectory administration.

From a troubleshooting perspective, Remote Manager might surprise you with its versatility. Using the Console Screens feature, you can view and run all the console screens just as though you were using the keyboard at the server console. In addition, you can monitor a server’s health or access the DEBUG console. In addition, Remote Manager includes a variety of report and log files, including server personal log book, system error log files, abend log, and server health log.

Novell iMonitor enables you to monitor and diagnose servers in your eDirectory tree—regardless of platform. All you have to do is point your Web browser at the server’s 8009 port and NetWare 6 takes over from there. In addition, iMonitor is very secure. It uses the eDirectory ACL (access control list) to deliver frame tools based on the user’s administrative rights.

To use iMonitor, you must first ensure that the appropriate application is running on your eDirectory server. When using NetWare, NDSIMON.NLM is automatically placed in the AUTOEXEC.NCF; therefore, it is launched upon server startup. When the iMonitor application is running on your server, you can access it by entering the following URL in the Address field of your browser:

Check it out in Figure 15.3.

FIGURE 15.3 Novell iMonitor main page.

iMonitor enables you to explore the eDirectory environment in great depth. You can also use it to examine what processes are running on your server, when they are running, and what their results are. In fact, iMonitor was created by Novell developers to enable them to diagnose and troubleshoot their code as they were writing NetWare. Cool!

Now you can benefit from all of these hidden troubleshooting capabilities by accessing the following navigation frame tools:

iManage; therefore, I am.

iManager is an anytime, anywhere advanced administration utility that enables you to perform almost all the eDirectory management tasks typically handled by NetWare Administrator and/or ConsoleOne. iManager is platform independent and Web browser–based. Furthermore, iManager enables you to customize its capabilities based on pre-assigned or customized admin roles.

You can access iManager from any Web browser by entering the following URL in the Address field:

The iManager main page (shown in Figure 15.4) consists of the following three functional frames: Header, Navigation, and Main Content. iManager depends on administrative roles to customize its interface. Furthermore, this facility is controlled by an eDirectory feature called Role-Based Services (RBS). As the administrator, you can assign roles to other administrative users in your organization. If assigned a role, that user has the same rights assigned to the role enabling him to perform all tasks contained in that role.

FIGURE 15.4 Novell iManager main page.

Several new administrative and troubleshooting tools have been added to iManager Version 1.5, which ships with eDirectory 8.7 on the Web Applications CD-ROM. The following is a list of some of the more impressive new iManager categories:

Many of these new iManager capabilities contain some key troubleshooting actions. For example, iManager includes a link to iMonitor for performing certain repair tasks. iManager also includes a link to Remote Manager for server-specific maintenance. In addition to these two links, iManager includes some native troubleshooting features, including rights management, schema troubleshooting, server maintenance, and WAN traffic management.

The Novell Web site at www.Novell.com has links to several useful troubleshooting tips and tools. And, as a 21st Century silicon doctor, you must take advantage of all available resources.

The following is a brief description of Novell’s best troubleshooting tools available online:

This completes our first lesson in NetWare Medical School. So, what have you learned? First, you learned that you can use some of our favorite ol’ management utilities for troubleshooting the LAN, server, and eDirectory. Second, you learned that network troubleshooting encompasses more than just file servers. It extends to all other network components, including protocols and clients.

Now let’s extend our medical bag of tricks to include a variety of server and client protocol commands.

One of the first things you should do when troubleshooting your NetWare server or protocol is enter CONFIG at the server console. CONFIG returns the following information:

Domain Name Services (DNS) is a fancy network-based database that matches user-friendly computer names to device IP addresses. DNS naming operates similarly to fully distinguished naming in the eDirectory tree. In the IP world, an absolute DNS domain name is constructed by listing all domains on the path from the end device to the root. Just like eDirectory, a period (.) is used to resolve the labels in the domain name.

If your server is using TCP/IP to communicate with distributed clients, you can use NSLOOKUP to query DNS name servers. This tool enables you to identify your server’s DNS configuration, diagnose DNS setup problems, and identify DNS problems in a server application.

Using NSLOOKUP, you can perform two types of naming searches:

NSLOOKUP is a server console command. To activate this tool, you simply enter the command NSLOOKUP at the server console and press the Enter key. When you do so, the DNS server and its IP address appear. To view a list of NSLOOKUP commands, simply type ? and press the Enter key. When you’re finished using NSLOOKUP, exit the utility by typing EXIT.

All NetWare troubleshooting tools we’ll discuss in this lesson are server console commands except HOSTS. HOSTS, and its big brother HOSTNAME, are configuration files stored in the SYS:ETC directory. If you aren’t using DNS, these files store information about host devices on your IP network. Each entry in the HOSTS file provides alias information (up to 10) for a single HOST and cannot extend beyond one line. The alias is another, shorter name for the same system.

The HOSTS configuration file uses the following syntax:

The HOSTNAME file uses the same syntax; however, it doesn’t include any alias information. In both configuration files, the HOST_NAME entry defines a link between the device IP address and DNS naming information. This name cannot contain a space, tab, number sign (#), or end-of-line character, and each HOST_NAME must be unique.

TCPCON is a server console utility that monitors TCP/IP operations and provides detailed information on the status of network segments, protocols, routing tables and the SNMP trap log. TCPCON enables you to view the configuration and statistics for an SNMP target only, and is an excellent troubleshooting utility for viewing errors that occur within your server’s TCP/IP stack.

To use the TCPCON utility, type TCPCON at the server console and press the Enter key. The initial TCPCON screen displays an IP Forwarded field. If any value is entered into this field (including 0), the server is configured to act as an IP router. Check out Table 15.1 for a brief overview of the areas and statistics available in TCPCON.

TABLE 15.1 TCPCON Statistics

PING is network yodeling. PING continuously transmits echo requests to specific devices and waits for a response. When your system is configured correctly, you can PING a device from the server using the device’s HOSTSNAME or IP address. You can also PING the loopback address (127.0.0.1) to validate the TCP/IP stack within your local server.

When you initially PING another host, the ICMP echo request (type 8) and ICMP echo reply (type 0) are used to verify communications between the server and target device. If you don’t hear a response, the target device is not communicating.

As you can see in Figure 15.5, the NetWare PING utility provides the high and low roundtrip times, as well as the last roundtrip time between your server and target device. It can also tell you the average roundtrip time and trend of roundtrip times to measure distance and network performance. The default packet size for PING is 64 bytes.

FIGURE 15.5 PING troubleshooting tool.

The NetWare server supports many DEBUG screens that help you identify and resolve TCP/IP communication problems. Be careful though: Many of these DEBUG screens are IO intensive and can affect server performance. See Table 15.2 for a list of some of the most useful DEBUG settings.

TABLE 15.2 DEBUG Troubleshooting Settings

That completes our detailed lesson in NetWare troubleshooting tools available for IP/IPX communications. Remember, the central server is the cornerstone of your network. As such, you should begin there when troubleshooting communication problems. Of course, the answer doesn’t always present itself at the server. Sometimes you must travel to the distributed clients to zero in on a potential solution. Now, let’s explore seven LAN troubleshooting tools available at the Windows Client.

IPCONFIG is a Windows 2000/2003/NT/XP console command that displays the client IP address, subnet mask, and default gateway for each network adapter bound to TCP/IP (see Figure 15.6). In addition, IPCONFIG /ALL adds WINS and DNS configuration information.

FIGURE 15.6 IPCONFIG troubleshooting tool.

As a Windows console command, IPCONFIG requires that you enter DOS command mode by choosing CMD from the Windows Start menu. In addition to the /ALL parameter, you can also use /RELEASE to release the IP address for a specific adapter or /RENEW to renew the IP address for a specific adapter. This is helpful for resolving DHCP address assignments.

Similar to the PING tool available on the NetWare server, you can use this command from the Windows console as well. PING is one of the first places you should start when troubleshooting client connectivity. Begin by entering PING 127.0.0.1 at the DOS command line. This will cause the client to PING its own internal IP stack, thus validating that communications are active on the network. If a workstation cannot PING its own internal stack, verify that IP address information within the Control Panel is automatically assigned using a DHCP server. If not, there should be a dedicated IP address for the client.

See Table 15.3 for a detailed list of the parameters supported by the client PING command.

TABLE 15.3 Client PING Troubleshooting Tool

Routing is the process of moving packets from point A to point Z on an internetwork. The next two client troubleshooting tools enable you to display and configure information about client-server routing: ROUTE and TRACERT.

See Figure 15.7 for a sample routing scenario. Suppose that the internetwork consists of five subnets (A through E). In this example, workstation 100 sends a message to workstation 300. First, the packet travels directly to router AB, which recognizes that it is for segment C. This is accomplished using an internal routing information table (RIT). Router AB changes the logical address and sends the packet to router BC. Router BC then forwards the packet to the correct segment. In this example, subnets D and E are untouched, and the packet travels a minimum path instead of being broadcasted throughout the network.

FIGURE 15.7 Internetwork routing.

Routing uses the following two-step process to enable intermediate network devices to make intelligent decisions about how a package should travel from point A to point Z:

The ROUTE Windows command tells you how a packet is traveling from your client to the central server. When the client needs to route a packet to a remote destination, it looks at its own internal RIT first. This RIT is dynamically learned from the network; however, entries can be placed in the table manually. Examine Table 15.4 for descriptions of all available ROUTE parameters.

TABLE 15.4 ROUTE Parameters

Trace Route (TRACERT) is the second of our two client routing troubleshooting tools. If ROUTE tells you how a packet travels from point A to point Z, TRACERT tells you where along the route the packet bogs down. This troubleshooting tool helps define the time needed to reach the routers along the path and identify sluggish bottlenecks. Figure 15.8 shows one possible path to http://www.Novell.com.

FIGURE 15.8 TRACERT troubleshooting tool.

TRACERT uses the Time To Live (TTL) value of each packet to obtain the routers along the path. The following is a list of the four parameters you can use with the Windows TRACERT console command:

TRACERT responses are not always accurate. If a network supports load balancing (as the Internet does), separate TRACERT tests can yield different paths. In addition, some companies disable ICMP responses to TRACERT to deter hackers from exploring their network and exposing the path to specific devices. In these cases, TRACERT will time out before it reaches the destination device.

Just like at the server, NSLOOKUP at the client provides configuration information for DNS name servers. NSLOOKUP is a Windows console command, and therefore requires access to the DOS command line. This is available using the CMD option within the Start menu.

Remember NSLOOKUP works only if the client is communicating with the network using the TCP/IP protocol.

ARP is the Address Resolution Protocol. ARP combines the client’s logical address with its physical address to create a complete Internet address. In addition, ARP assigns logical names to make addressing more user friendly.

The ARP command enables you to view the workstation’s ARP cache. In addition, you can force an ARP broadcast in an attempt to resolve an IP-to-Ethernet address. This troubleshooting tool will help you determine how ARP entries are being acquired and provide a solution for deleting incorrect entries from the client’s table.

See Table 15.5 for a description of the ARP parameters.

TABLE 15.5 ARP Parameters

The NETSTAT console command displays details for the protocol operations of the client’s TCP/IP connection. NETSTAT shows statistics for the following Internet protocols: TCP, UDP, ICMP, and IP.

NETSTAT can be used with the -r parameter to show routing tables in dynamic form. For example, if you want to watch the NETSTAT information in real-time, enter an interval (in seconds) following the parameters. Here’s a list of the other parameters supported by NETSTAT:

When you use NETSTAT at the client command line, it will provide the local address, foreign address, and connection state for each of the protocols specified. Look over Table 15.6 for a description of the different connection states supported by NETSTAT.

TABLE 15.6 NETSTAT Connection State

Congratulations! So far, you’ve acquired three separate compartments and 18 troubleshooting tools for your NetWare medical bag. In these lessons, we’ve discovered some hidden troubleshooting capabilities within NetWare’s five central management utilities—ConsoleOne, Remote Manager, iMonitor, iManager, and Novell.com. Then we explored six built-in NetWare commands and seven Windows-based client troubleshooting tools. That’s enough to keep any NetWare troubleshooter way ahead of the game.

However, you’re no ordinary NetWare troubleshooter. You’re a CNE. Because of that, I’ll arm you with three more valuable network troubleshooting tools: protocol analyzers, TCP/IP Toolkit, and IP address calculators. Sometimes you need an extra-power tool to get the job done.

Protocol analyzers enable you to monitor network performance, troubleshoot network errors, optimize the network, and plan for growth. One of the most popular protocol analyzer is LANalyzer. This combination of software and hardware gathers, sorts, and reports data about how your network is running.

During a typical protocol analysis session, you must perform the following five tasks:

1.   Access the network—Protocol analysis begins by plugging the device into the same hub as the central server.

2.   Capture the traffic—Next, you must capture trend data for a minimum of one month. This information isolates bandwidth, kilobytes, packets, and errors. A baseline is established as a simple measurement of your network’s typical performance.

3.   View the captured traffic—The baseline information is gathered over time and plotted on trend graphs to create the foundation of your fitness program. To complete your baseline, you should track the most active users, servers, and routers on your network. This will indicate basic network load balancing for future planning.

4.   Filter out and view just the needed traffic—In addition, you can use the analyzer’s display filter to view just the packets you’re interested in. Filtered packets enable you to focus on anomalies in your network.

5.   Document your findings—After you’ve established a baseline and built a display filter, you can document your findings. A seasoned CNE will be able to quickly identify communication problems within the network and implement appropriate solutions.

Every network can benefit from a quick review of network performance. You can use a protocol analyzer to analyze your network’s performance regardless of the protocol media access type. For example, you can use an analyzer to identify excess ICMP redirection messages and reconfigure devices to use a more appropriate default gateway. Similarly, you can identify and remove devices causing excessive broadcasts on the network.

Protocol analyzers also enable you to tune up your router configurations to reduce the routing protocol overhead caused by these excessive periodic broadcasts. Finally, you can use protocol analyzers to remove unsuccessful discovery processes that are running on the network.

When you test an application or plan for growth, you can use a protocol analyzer to determine how much bandwidth a single user requires to run a particular application on the network. Then you can multiply this number by the number of users who will ultimately use the application to determine whether you have enough bandwidth on the segment to support the application. This is just another example of how protocol analyzers help you troubleshoot and optimize your network.

So far, we’ve discovered several built-in network troubleshooting tools at the NetWare server and Windows workstation. In addition, there is a whole world of third-party TCP/IP toolkits available out there. Two of the most popular are iNetTools and NetScanTools.

A company called WildPackets provides iNetTools. In addition to standard features, such as PING and TRACERT, iNetTools provides the following:

NetScanTools Pro 2004 was developed by Northwest Performance Software as a comprehensive protocol analyzer. The following is a list of the network troubleshooting features included in NetScanTools Pro 2004:

IP addressing is one of the most challenging aspects of network troubleshooting. Logical IP addressing uses a combination of physical addressing and logical network addressing. This address consists of a 32-bit, dotted-decimal value that contains both network and host address components.

It’s fairly common to express IP addresses in binary (base 2) format. This is especially helpful when implementing or decoding addresses on the network. In this notation, each bit represents a value ranging from 128 (leftmost position) to 1 (rightmost position). Using this scheme, IP can identify any network using one of the following five classes: Class A (small number of networks and large number of hosts), Class B (equal support for networks and hosts), and Class C (large number of networks and small number of hosts). In addition, Classes D and E are reserved for special addressing.

Fortunately for you, WildPackets offers a free IP subnet calculator to help you configure your network design and/or check existing IP addressing. Subnetting enables you to extend IP addresses by breaking up the internal network address into “sub” nets. With this scheme, external Internet devices cannot access internal devices directly, but they are aware that a network has been subnetted.

The IP subnet calculator computes subnet information based on the IP address and class and the number of subnet bits being used. As you can see in Figure 15.9, the WildPacket calculator includes the following four tabs:

FIGURE 15.9 IP addressing calculator.

And that completes our NetWare medical bag! Yeah!

Let’s review: It all started with five ol’ friends in the NetWare management arena: ConsoleOne, Remote Manager, iMonitor, iManager, and Novell.com. I bet you didn’t realize how much life these old tools still have in them.

Next, we explored five console commands and one configuration file at the NetWare server. These server-based IP/IPX troubleshooting tools armed us with some excellent diagnostic and troubleshooting capabilities from the server’s point of view. Then, we bounced over to the client and discovered seven IP troubleshooting tools built into Windows. Finally, our NetWare medical bag was complete with protocol analyzers, TCP/IP toolkits, and IP addressing calculators.

Well, there you have it: your NetWare medical bag in a nutshell. See what you have to look forward to? So, are you prepared for the rigors of medical school? If you think this first chapter was fun, wait until you see what’s in store in Chapter 16, “Novell Server Troubleshooting,” and in Chapter 17, “Novell eDirectory Troubleshooting.”

Scalpel not included.