Is Your Network Connected?: Finding Out Which Network Devices Are Responding

Articles and Tips:

Laura Chappell

01 Mar 1998

One of the first steps in troubleshooting your company's network is checking the connections among the servers, workstations, and other devices. In an intraNetWare or NetWare environment, you can use the IPX Diagnostic Responder or the IPX Ping utility to check whether a server or a workstation is communicating properly. You can also use the IPX Diagnostic Responder or the IPX Ping utility to test the response time of one network device or of all network devices. In addition, you can use these tools to test the speed of any network link.

This article explains how the IPX Diagnostic Responder and the IPX Ping utility work. This article also describes the packet formats used by the IPX Diagnostic Responder and the IPX Ping utility and discusses the information these tools provide about your company's network.

SHOULD YOU USE THE IPX DIAGNOSTIC RESPONDER OR THE IPX PING UTILITY?

If you have worked in the NetWare environment for a long time, you may be familiar with the NetWare Care utility, which was included with older versions of NetWare. The NetWare Care utility used the IPX Diagnostic Responder, a feature that generated a query packet which the NetWare Care utility then broadcast on the network. The NetWare Care utility used the responses it received to build a map of active network devices.

By default, the IPX Diagnostic Responder still runs on all intraNetWare and NetWare servers and on all Novell client software. However, the IPX Diagnostic Responder does not include a transmission utility. You must use a third-party utility to build, send, and receive the IPX Diagnostic Responder packets.

For example, my company, ImagiTech Inc., runs the IPX Diagnostic Responder with LANQuest's Net/WRx LANLoad, Novell's LANalyzer for Windows, Network General's Sniffer, and NCC's LAN Network Probe. To research this article, I used the Net/WRx LANLoad utility to transmit the IPX Diagnostic Responder query packets on the network. I then toggled to a LANalyzer for Windows screen to check the reply packets coming back.

In addition to providing the IPX Diagnostic Responder, Novell created the IPX Ping utility, which is similar to the Ping utility in the TCP/IP environment. Novell's IPX Ping utility is available with intraNetWare, NetWare 4.11, and NetWare MultiProtocol Router (MPR) 3.0 and above. Novell also included the IPX Ping utility in its 32-bit client software, such as intraNetWare Client for Windows 95 and intraNetWare Client for Windows NT.

Servers running NetWare 4.1 or below and workstations running Novell's Virtual Loadable Module (VLM) client software or Novell's NETX client software do not support the IPX Ping utility. If you use the IPX Ping utility to check a workstation running client software that does not support this utility, you do not receive any response. In other words, the workstation appears not to be responding on the network because the workstation doesn't respond to the IPX Ping utility. However, the workstation could actually be working fine.

If your company's servers and workstations support the IPX Ping utility, I recommend that you use this utility. Otherwise, you need to use the IPX Diagnostic Responder with a third-party utility. However, you should be aware that some routers, such as Cisco routers, do not support the IPX Diagnostic Responder. (See "Choosing Between the IPX Diagnostic Responder and the IPX Ping Utility.")

HOW DOES THE IPX DIAGNOSTIC RESPONDER WORK?

An IPX Diagnostic Responder query packet includes an IPX header with destination socket number 0x0456 and a 1-byte Exclusion Address Count field. (See Figure 1.) If you want specific devices to ignore the IPX Diagnostic Responder query packet, you can specify the number of devices that should not respond to this packet in the Exclusion Address Count field. You can then include these devices' hardware addresses or media access control (MAC) addresses in the Excluded Address fields. (These fields are described in more detail later in the article.)

Figure 1: An IPX Diagnostic Responder query packet is only 31 bytes in size, plus the MAC header.

To use the IPX Diagnostic Responder, you must know the network address and the MAC address of the destination device. If this device is on the other side of a router, you must also know the router's MAC address.

For example, suppose that you managed a simple internetwork with two LAN segments. (See Figure 2.) To use the Net/WRx LANLoad utility to query the BLDG2 server on network 0x00-00-22-22 from a device on the same network, you would send an IPX Diagnostic Responder query packet through the local router to the BLDG2 network: You would need to include the BLDG2 server's network address and MAC address in the IPX header. You would also need to include the local router's MAC address in the Ethernet header that is used to get the query packet to the local router.

Figure 2: To send an IPX Diagnostic Responder query packet across a router, you must know the local router's MAC address, as well as the destination device's network address and MAC address.

You can use the IPX Diagnostic Responder to test the following on your company's network:

The response time of one network device
The response time of all devices on the network
The speed of a network link

Testing the Response Time of One Network Device

If you want to test a device on the same network as the workstation on which your third-party utility is running, you include the device's MAC address in the MAC header (such as the Ethernet header), and you include the device's network address and MAC address in the IPX header.

In the IPX header (which includes a network address and a MAC address), you can also use destination network address 0x00-00-00-00 to indicate that you are checking only the local network. Figure 3 shows how you specify destination network addresses in the Net/WRx LANLoad utility.

Figure 3: To send an IPX Diagnostic Responder query packet to a device on the local network, you include the destination device's network address and MAC address in the IPX header, and you include this device's MAC address in the MAC header.

You must also specify your workstation's network address and node address so that you can trace the IPX Diagnostic Responder reply packets with a network analyzer. For example, if a device received the query packet shown in Figure 3, the device would send a reply packet to node 0x99-99-99-99-99-99 on the local network.

To make it easier to trace the IPX Diagnostic Responder reply packets, you could use a false node address instead of your workstation's node address. For example, if you sent a query packet from MAC address 0x99-99-99-99-99-99 (an unusual MAC address) to a device on the local network, the reply packet sent to that MAC address would be easy to spot.

When a device responds to an IPX Diagnostic Responder query packet, the reply packets contain a list of the device's primary network components. (See "Responding to an IPX Diagnostic Responder Query Packet".) Although the list does not provide detailed information, this list does identify the functionality of each network component. For example, component 2 is a LAN driver.

A server's IPX Diagnostic Responder reply packet is especially useful because this packet includes the addresses of each network to which the server is attached. A server's reply packet also includes the server's internal IPX address.

Testing the Response Time of All Devices on the Network

To test all of the devices connected to a network, you specify the broadcast MAC address in the IPX header. (See Figure 1.) All devices that support the IPX Diagnostic Responder send an IPX Diagnostic Responder reply packet, and the third-party utility you are using to receive reply packets should list the devices and their relative response times.

Testing the Speed of a Network Link

To test the speed of a network link, you must run two IPX Diagnostic Responder sessions, querying one side of the link in each session. Then you use the difference between the round-trip times of each session to determine the speed of the network link.

For example, Figure 4 shows a WAN link between an office in California and an office in New York City. Suppose that you wanted to test the speed of this WAN link. If you were running a third-party test utility from the California office, you would complete the following steps:

Figure 4: To test the speed of a network link, you must know the network address of each router.

Measure the round-trip time between the third-party test utility attached to the network at the California office and Router A.
Measure the round-trip time between the third-party test utility attached to the network at the California office and Router B.
Subtract the Router A time from the Router B time. This value is the round-trip time for the WAN link.
Divide the round-trip time for the WAN link in half. This value is the approximate one-way time.

To test the speed of a network link at the ImagiTech labs, I use the Net/WRx LANLoad utility to transmit the IPX Diagnostic Responder query packets and LANalyzer for Windows to receive and time stamp the reply packets. I also use LAN Network Probe, which simultaneously transmits and receives packets.

THE FORMATS OF AN IPX DIAGNOSTIC RESPONDER PACKET

The IPX Diagnostic Responder uses two packet formats:

The query packet
The reply packet

The IPX Diagnostic Responder Query Packet

As mentioned earlier, an IPX Diagnostic Responder query packet includes an IPX header with destination socket number 0x0456. This socket number indicates that the query packet contains IPX Diagnostic Responder information and should be handled by the IPX Diagnostic Responder. The Destination Network Address field and the Destination MAC Address field in the IPX header indicate which device or devices should respond to this query packet. (See Figure 3.)

For example, to query the BLDG2 server on the network shown in Figure 2, you would address an IPX Diagnostic Responder query packet to network 0x00-00-22-22 and node 0x00-20-C5-00-5F-C1. To query all of the devices on this network, you would address the query packet to network 0x00-00-22-22 and node 0xFF-FF-FF-FF-FF-FF (the broadcast node address).

The data portion of an IPX Diagnostic Responder query packet typically contains only one field: the Exclusion Address Count field. (See Figure 5.) This field indicates the number of devices that should not respond to the query packet. If you did not want to exclude any device from responding to this query packet, you would pad the Exclusion Address Count field with 0x00. This field requires 1 byte.

Figure 5: The data portion of an IPX Diagnostic Responder query packet typically contains only one field: the Exclusion Address Count field.

If you wanted to prevent particular devices from responding to an IPX Diagnostic Responder query packet, the Exclusion Address Count field would contain a number to indicate how many devices are excluded from responding. (See Figure 6.) You would then use one or more of the Excluded Address fields to specify the MAC addresses of these devices. In this case, you must specify values in multiples of 6 bytes. However, ignoring reply packets from some devices that are of no interest is easier than locating the MAC addresses of relevant devices and entering these addresses in the query packet.

Figure 6: This IPX Diagnostic Responder query packet indicates that the device with MAC address 0x00-20-C5-00-5F-C1 should not respond to the packet.

The IPX Diagnostic Responder Reply Packet

When a device receives an IPX Diagnostic Responder query packet, the device sends a reply packet. Like the query packet, the reply packet contains source socket number 0x0456 in its IPX header, indicating that this packet contains IPX Diagnostic Responder information. (See Figure 7.)

Figure 7: An IPX Diagnostic Responder reply packet contains a variety of information about the responding device, including this device's primary network components.

In addition, the IPX Diagnostic Responder reply packet contains information about the device sending this packet. For example, the reply packet indicates how many network components the device has and what these components are. If the device is a server or a router, the reply packet contains additional information such as the number of networks to which this device is attached and the type of network (internal or external). (See "The Contents of an IPX Diagnostic Responder Reply Packet" and Figure 7.)

HOW DOES THE IPX PING UTILITY WORK?

Instead of using the IPX Diagnostic Responder, you can use the IPX Ping utility to determine whether one or more devices are responding on the network. The IPX Ping utility actually sends an IPX Ping query packet that contains the wordPingto the destination device's network address and MAC address. (See Figure 8.) The reply packet echoes the data portion (the wordPing) of the query packet. (See Figure 9.) Unlike the IPX Diagnostic Responder, the IPX Ping utility does not require devices to exchange information about their network components.

Figure 8: An IPX Ping packet contains the word Ping in ASCII characters.

Figure 9: When a device responds to an IPX Ping query packet, the device echoes the data portion of the query packet.

You run the IPX Ping utility on an intraNetWare or NetWare 4.11 server. To launch the IPX Ping utility, you enter the following command at the server console:

LOAD IPXPING

When the New Target menu appears, you enter the network address of the destination device--the device you want to test. If you enter 0xFF-FF-FF-FF (the broadcast network address), the IPX Ping utility does not transmit anything, ensuring that you do not flood the internetwork with IPX Ping broadcast packets.

You must also enter the destination device's node address. The default node address is 0x00-00-00-00-00-01. To ping all of the devices on a network, you enter the broadcast node address, which is 0xFF-FF-FF-FF-FF-FF.

In addition, you specify the number of seconds the IPX Ping utility should wait between each ping. The lower you set this value, the more traffic you generate on the network.

To test one server or one workstation, you address the IPX Ping query packet directly to that server's or that workstation's network address and MAC address. To test multiple servers or workstations, you enter the exact network address and the broadcast node address.

To use the IPX Ping utility to test the speed of a network link, you define multiple IPX Ping query packets to run simultaneously. For example, to test the speed of a WAN link, you would send a query packet to the router on each side of the link and find the difference between the routers' response times. Figure 10 shows a ping test using multiple query packets.

Figure 10: You can send IPX Ping query packets to multiple devices on the network.

The IPX Ping utility lists the response times for each ping test and provides some trend information. (See Figure 10.) The IPX Ping utility's report includes the following information:

Target. The Target field contains the network address and the node address of each destination device.
Sent. The Sent field contains the number of query packets sent since the IPX Ping utility was launched.
Received. The Received field contains the number of reply packets received since the IPX Ping utility was launched and the percentage of responses. Broadcast pings can exceed 100 percent because each device equals 100 percent. For example, if five devices responded to a single query packet, the percentage would be 500. (The maximum percentage from one device is 100.) The percentage can fall below 100 percent if responses cannot arrive because the network is busy.
High. The High field contains the slowest round-trip time since the IPX Ping utility was launched.
Low. The Low field contains the fastest round-trip time since the IPX Ping utility was launched.
Last. The Last field contains the last round-trip time since the IPX Ping utility was launched.
Trend. The Trend field contains the average round-trip time since the IPX Ping utility was launched.

The Format of an IPX Ping Packet

Unlike the IPX Diagnostic Responder, the IPX Ping utility uses the same format for both query packets and reply packets. (See Figure 11.) These packets include seven fields, which contain the following information:

Figure 11: The format of an IPX Ping packet

Ping Data (4 bytes). The Ping Data field contains the wordPingin ASCII characters. (The hexadecimal value is 0x50-69-6E-67.)
Version (1 byte). The Version field contains the version number of the IPX Ping utility. (The current version number is 1.)
Type (1 byte). The Type field indicates whether the packet is a query packet or a reply packet. The value 0x00 indicates a query packet; the value 0x01 indicates a reply packet.
Ping ID (2 bytes). The Ping ID field contains a unique identifier that is inserted into a query packet by the requesting device and is echoed in the reply packet. This information is used to match query packets with reply packets.
Result (1 byte). As with the Type field, the Result field contains the value 0x00 in a query packet. This field contains the value 0x01 in a reply packet.
Reserved (1 byte). The Reserved field contains the value 0x00 and is ignored upon receipt.
Data (variable). The Data field contains a variable set of data that is inserted into a query packet by the requesting device and is echoed by the responding device.

When using the IPX Ping utility, you must send all query requests to destination socket number 0x9086.

HOW CAN YOU FIND OUT MORE?

If you want to learn about other tools you can use to troubleshoot communications problems on your company's network, you can readNovell's Guide to LAN/WAN Analysis: IPX/SPX, which will be published in April by Novell Press. This book explains the basics of network analysis and provides in-depth information about configuration options and troubleshooting techniques for IPX, SPX, and other protocols. (To orderNovell's Guide to LAN/WAN Analysis: IPX/SPX, look for theNetWare ConnectionBookstore order form in the next issue ofNetWare Connection.)

CONCLUSION

The next time users complain that they cannot connect to a server, you have two good tools to begin the troubleshooting process: If you want to test servers running NetWare 4.1 or below or workstations running Novell's NETX or VLM client software, you can use the IPX Diagnostic Responder with a third-party utility. If you need to test servers running intraNetWare or NetWare 4.11 or workstations running Novell's 32-bit client software, you can use the IPX Ping utility.

The IPX Diagnostic Responder and the IPX Ping utility help you determine whether servers, workstations, and other devices are responding on the network. These tools also help you determine how fast network traffic is flowing, even across routers.

Laura Chappell researches, writes, and lectures on NetWare protocol performance, troubleshooting, and optimization. Laura also speaks at NetWare Users International (NUI) conferences and presents customized training courses on network analysis. You can reach Laura via e-mail atchappell@imagitech.com.

Choosing Between the IPX Diagnostic Responder and the IPX Ping Utility

Before you decide whether to use the IPX Diagnostic Responder or the IPX Ping utility, you should refer to the list below. For example, suppose that you used the IPX Ping utility to determine if a workstation running Microsoft's Client for NetWare Networks were communicating properly with the network. Because Microsoft's Client for NetWare Networks does not support the IPX Ping utility, you would receive no response from this client software when you ran this utility. You might then mistakenly assume that this lack of response was caused by a communications problem.

Product	Responds to IPX Diagnostic Responder Queries	Responds to IPX Ping Queries
NetWare 2.x server	Yes	No
NetWare 3.x server	Yes	No
NetWare 4.0x server	Yes	No
NetWare 4.1x server	Yes	Yes
intraNetWare server	Yes	Yes
NetWare MPR 3.0 and above	Yes	Yes
Novell's NETX client software	Yes	No
Novell's VLM client software (through version 1.22)	Yes	No
Novell's 32-bit client software	Yes	Yes
Microsoft's Client for NetWare Networks	Yes	No

Responding to an IPX Diagnostic Responder Query Packet

The following list indicates the primary network components of devices that respond to an IPX Diagnostic Responder query packet:

Responding Device	Primary Network Components
Workstation running Novell's VLM client software	Component ID: 0 (IPX/SPX stack) Component ID: 2 (LAN driver) Component ID: 4 (Shell) Component ID: 9 (DOS application)
Workstation running Novell's 32-bit client software	Component ID: 0 (IPX/SPX stack) Component ID: 2 (LAN driver) Component ID: 4 (Shell) Component ID: 9 (DOS application)
Workstation running Microsoft's Client for NetWare Networks	Component ID: 0 (IPX/SPX stack) Component ID: 2 (LAN driver) Component ID: 4 (Shell)
intraNetWare or NetWare server	Component ID: 0 (IPX/SPX stack) Component ID: 1 (Router driver) Component ID: 6 (Server or router) Number of Local Networks = 2
NetWare MPR 3.0 or above, or an intraNetWare or NetWare server attached to multiple networks	Component ID: 0 (IPX/SPX stack) Component ID: 1 (Router driver) Component ID: 6 (Server or router) Number of Local Networks = 3

The Contents of an IPX Diagnostic Responder Reply Packet

An IPX Diagnostic Responder reply packet contains the following fields:

Minor Version (1 byte)	This field contains the first digit of the IPX Diagnostic Responder version that is responding.
Major Version (1 byte)	This field contains the second digit of the IPX Diagnostic Responder version that is responding. Servers use version 1.0; clients use version 1.1.
SPX Diagnostic Socket (2 bytes)	This field contains the socket number to use for SPX diagnostic queries.
Number of Components (1 byte)	This field contains the total number of network components listed in the next field.
Component IDs (1 byte each)	This field contains the component IDs of the responding device's primary network components. (If the field includes component ID 6, this device is a server or a router.) Component ID: 0 IPX/SPX stack Component ID: 1 Router driver (also used to get to internal IPX network address) Component ID: 2 LAN driver Component ID: 3 Shell Component ID: 4 Value-added process Component ID: 6 Server or router Component ID: 9 DOS application
Number of Local Networks (1 byte)	This field contains the addresses of all networks to which the responding device is attached, including the MAC address used to access a particular network.
Local Network Type (1 byte)	This field contains information about whether the responding device's local network is an internal or external IPX network. (In Figure 2, the internal IPX address of RTR4X is 0xAA-AA-AA-01, which the network analyzer defines as a virtual, or internal, network interface board. The two networks attached to the server are 0x00-00-11-11 and 0x-00-00-22-22.)
Network Address 1 (4 bytes)	This field contains the 4-byte address of the internal or external IPX network.
Node Address 1 (6 bytes)	This field contains the MAC address of the network interface board that is attached to the network with the address defined above. (Node address 0x00-00-00-00-00-01 always belongs to the internal IPX network.)

* Originally published in Novell Connection Magazine

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.