Back to 8/96 Enterprise Windows: Enterprise View
Up to Table of Contents
Ahead to 8/96 Enterprise Windows: Enterprise Administrator

8/96 Enterprise Windows: Enterprise Administrator

Do You Have the Right Tools?

A good tcp/ip troubleshooter is naked without the right toolkit.

By Tom Henderson

THE WORLD has gone Internet- and intranet-crazy, and TCP/IP is now a mandatory protocol on PC desktops. As TCP/IP proliferates, good troubleshooters become an increasingly hot commodity. That's where you come in. This month, I'll tell you what you should carry in your troubleshooter toolkit. I'll also present my top 10 list of TCP/IP failure points.

You can add TCP/IP to Windows by using either Winsock (see the July 1996 Enterprise Administrator) or a third-party connectivity package that includes its own Winsock or another TCP/IP protocol kit. The third-party packages vary widely both in components and ease of installation. And you'll find many of the same troubleshooting/utility programs inside Windows 95 and NT. You'll have to do some digging because they're either command-line oriented or terse and UNIX-like. You won't find any icons for them, either.

If you're troubleshooting an installation, though, these programs can be a weekend-saver and behave almost identically to their UNIX counterparts.

The most important tool for your troubleshooter toolkit is ping (envision a peashooter and a bell). Ping is the first utility that verifies connection between a user's PC and a TCP/IP host (which includes other Windows PCs that are correctly configured for TCP/IP). Ping uses a local (\windows\hosts) file, or a name service (such as the domain naming system-DNS), to associate IP addresses with host names. If the host's file or DNS is unavailable, substitute an IP address.

If you can't ping a host, you won't be able to use Internet browsers or any other TCP/IP applications with that host. Ping verifies that the local PC knows a route and perhaps a host name alias to an IP address, such as win- (usually supplied by a DNS server), and can get an answer back before the packet dies. Packets die according to a value called time-to-live (TTL), which you can set to transverse a long list of routers. I've never needed to set it for longer than its default unless I'm pinging hosts many routers away-in Tasmania, for example.

If nothing pings, you can use the ipconfig command to see if the local TCP/IP setup is correct. With ipconfig, you don't have to go into Network Neighborhood's Property sheets in Win95 or Control Panel/ Networks or Control Panel/Services sheet in Windows NT.

Ipconfig verifies that the local PC has a valid IP address, a subnet mask and the default gateway for the PC. You can also use it to force an IP address lease renewal for PCs that are using the dynamic host configuration protocol (DHCP) service. (DHCP leases IP addresses to PCs.) You'll probably never need to renew an address forcibly, but if you move a PC to a new network, it may need a new address. Ipconfig can also force a release of a DHCP address lease. Unlike its UNIX counterpart, ipconfig in Windows can't display individual network ports (network cards). Instead, it displays information about all network ports it identifies inside a PC.

No bells or whistles

The telnet application that comes with Win95 and NT is rudimentary compared with the commercial products' telnet applications. It can initiate a terminal session with a variety of host computer systems, but it lacks several features that set commercial products apart, such as programmable function keys, color, a choice of terminal emulations, 80x50 or 132x25 character displays and multiple concurrent sessions.

You can use the native telnet to achieve connections with many popular hosts. Once you're connected to the Internet, for instance, you can log onto CompuServe and other hosts with which you have an account. Special graphical user interfaces may be missing, but it's an easy way to use these services without a modem connection.

The next tool you should know about is tracert. Tracert displays the addresses of all the routers along the path from a correctly configured PC to a specific host destination. It increments the TTL value by one to determine the addresses of each router. Tracert is useful for watching the traced route to see how long it takes and which resources are transversed along the way. It also makes it easier to find misconfigured routing tables, especially in routers with partitioning capabilities.

When you couple tracert with netstat information, you get a complete traffic-flow picture. Netstat can show the TCP/IP protocol statistics, the current network connections from the PC and the PC's routing table. It can also display ICMP (Internet control message protocol) statistics, which come from various routers and gateways to indicate that there are downstream difficulties.

Top 10 TCP/IP failure points

With your toolkit in place, you can start hunting down the problem. Here are 10 hints:

1. A PC is incorrectly configured for an IP address, the subnet mask is missing or incorrect, or the default gateway either isn't present or has no address. Another possibility is that the TCP/IP address is just wrong.

2. TCP/IP configuration is missing altogether.

3. The transport isn't working because the card isn't present or is incorrectly configured. You must verify that the network card, modem or ISDN card is operating properly before you use TCP/IP.

4. The hosts or LMHOSTS file is missing. You use hosts in lieu of DNS to point a host name (such as toward its specific IP address.

5. DNS isn't working. Either you entered an incorrect IP address for the DNS server or no route exists to the DNS server. Symptoms include browsers that are unable to find URLs and pings that don't work with host names but do work for the host's IP addresses. Sometimes, however, DNS servers are just busy. Have users try several times to make DNS work.

6. DHCP servers are misconfigured. DHCP servers with address leases that are too short or time-blocked will ignore address requests. No address, no service. Unavailable DHCP servers are less common.

7. There are too many gateway or DNS listings. Often, overzealous administrators will list several gateways in an attempt to offer redundant routes. These gateways cause bizarre routings when a specific gateway is unavailable (unusually busy). With too many DNS listings, PCs can easily jump from one DNS server to another, causing abnormally long routes and possible response delays.

8. Router tables are damaged. Several UNIX hosts that serve as routers on LANs have dynamically built routing tables. High traffic that causes damaged packets can occasionally add bad entries into their router tables. A simple restart of the router can solve the problem.

9. Duplicate IP addresses exist. No two PCs can have the same IP address, although it's possible for two gateways to have the same IP address. Usually, the only way to find this problem is with a protocol analyzer.

10. A user has been fooling with it (UBFI). I know a user who took a look in Network Neighborhood/ Properties/Network_Card_TCP/IP Protocol/Properties and decided that was too big a number.

If you just can't find the answers, you may need a third-party TCP/IP package for compatibility or specific features. For a specific telnet emulation, for instance-or other specific features (built-in e-mail client software, Sun's Network File System) or added security (Pretty Good Privacy and Kerberos)-you'll have to look beyond the Win95 and WinNT boxes. You'll also need a third-party package if you're running X Windows or another traditional UNIX-based OS.

Contributing Editor Tom Henderson is vice president of engineering for Indianapolis-based Unitel. Contact Tom in the "Enterprise Administrator" topic of WINDOWS Magazine's areas on America Online and CompuServe. Click Here to find the e-mail IDs for our editors, who can put you in touch with this author.

Back to 8/96 Enterprise Windows: Enterprise View
Up to Table of Contents
Ahead to 8/96 Enterprise Windows: Enterprise Administrator