Analyzing LAN/WAN Internets: 
Testing IPX Routes 
Using Novell's LANalyzer 3.0

Tim Hayes
Systems Engineering Manager
Novell Network Analysis Products Group
LANalyzer Products Division


Abstract:
This AppNote describes techniques used to make analysis and problem 
resolution simple for large LAN and WAN systems. It presents a method for 
analyzing internets that was applied to a real problem at Novell. 

Disclaimer

Novell, Inc. makes no representations or warranties with respect to the 
contents or use of these Application Notes (AppNotes) or of any of the 
third#party products discussed in the AppNotes. Novell reserves the right to 
revise these AppNotes and to make changes in their content at any time, 
without obligation to notify any person or entity of such revisions or 
changes. These AppNotes do not constitute an endorsement of the third#party 
product or products that were tested. Configuration(s) tested or described 
may or may not be the only available solution. Any test is not a 
determination of product quality or correctness, nor does it ensure 
compliance with any federal, state or local requirements. Novell does not 
warranty products except as stated in applicable Novell product warranties or 
license agreements.

Copyright { 1991 by Novell, Inc., Provo, Utah. All rights reserved.

As a means of promoting NetWare AppNotes, Novell grants you without charge 
the right to reproduce, distribute and use copies of the AppNotes, provided 
you do not receive any payment, commercial benefit or other consideration for 
the reproduction or distribution, or change any copyright notices appearing 
on or in the document.

Contents

Introduction		29

The San Jose - Provo Internet		29

LAN/WAN Analysis Method		30

Determining the Route		30

Determining the Delay for the First Hop		32

Determining the Delay for the Final Hop		33

Introduction

Resolving performance problems on large internets can be challenging because 
of the number of components and LAN or WAN segments that need to be analyzed. 
There are techniques, however, that can make the analysis and problem 
resolution easier. This AppNote presents a method for using the LANalyzer to 
diagnose internet bottlenecks. It explains how this method was applied to a 
real problem at Novell.

The San Jose - Provo InternetA number of PC users at Novell in San Jose, 
California, use LAN Access Servers in Provo, Utah, to access data on a server 
in Provo.  To access the remote database, users' connections must traverse 
three IPX routed segments. One of those segments is a 1/3 T1 WAN link 
operating at approximately 52K bits per second.  shows a map of the internet 
between San Jose and Provo. 

: Map of the Internet Between San Jose and Provo
 

The users in San Jose complain that this remote data access is intolerably 
slow. They often wait several seconds for data to appear on their screens. 

LAN/WAN Analysis Method

To isolate the performance bottleneck, you can measure the delays between the 
user's segment and each of the intermediate segments and the end segment. 
Novell's LANalyzer version 3.0 has an application called BRIGVIEW which was 
developed specifically for this purpose.  BRIGVIEW  allows the user to send 
IPX diagnostic packets through bridges and routers. To help in measuring the 
transmit delay, the LANalyzer has high resolution time stamping on both the 
transmitted packet and the response packet. 

Although the method here uses IPX diagnostic packets, the technique itself is 
general. The LANalyzer can perform this same experiment for any protocol. 
There are LANalyzer applications similar to BRIGVIEW for TCP/IP, AppleTalk, 
DECnet, and XNS.

Basically, we're going to put a LANalyzer on network C9 99 00 02 and measure 
round trip delay times to  components on segment 00 00 00 BD and also to 
components on segment 01 08 00 05.  BRIGVIEW can transmit an IPX diagnostic 
packet from C9 99 00 02 to any specified segment. We will repeat this 
experiment ten times to calculate an average round trip delay time. After 
doing this for each segment, we will compare the Access Server 110  round 
trip delay to the delay for other devices on that segment.

Determining the Route

The first step is to determine the route used to go from San Jose to Provo. 
We used the LANalyzer BROADCST application to capture IPX RIP (Routing 
Information Protocol) packets and look for the route to 01 08 00 05. Figure 2 
shows the RIP packet which advertises the three#hop route from San Jose to 
Provo. The routing is done by a NetWare server called OSD#ROUTER. 

: IPX RIP Packet 

Next, we modified the BRIGVIEW application to transmit packets to OSD#ROUTER 
(using the Ethernet station address contained in the RIP packet). We also 
entered the source address of C9 99 00 02 and the destination address of 00 
00 00 BD and 01 08 00 05. Since the LANalyzer has six transmit channels, we 
could test all connections in one pass. Figure 3 shows an IPX packet that 
traveled from network C9 99 00 02 to 01 08 00 05.

: IPX Diagnostic Packet 

Determining the Delay for the First Hop

To determine the average delay from the first to second hop of the three#hop 
path, we transmit ten packets  from C9 99 00 02 to 00 00 00 BD. Then we take 
the average of the round trip delay times through OSD#ROUTER to the attached 
segment. Figure 4 shows the LANalyzer trace summary screen. 

: Round Trip Delay to Segment 00 00 00  BD 

Note that the round trip delays average about 18 milliseconds. This indicates 
the delay going through the first part of the three#hop route is about 18 ms, 
which is a reasonable delay. Thus, this is not a bottleneck.

Determining the Delay for the Final Hop

Next we transmit a single packet to 01 08 00 05 (using the default broadcast 
node ID convention) to get responses from all devices on the Provo segment. 
This allows us to identify other nodes that we can use as a control group in 
our round trip delay measurements. If all the devices respond in about the 
same amount of time, then the problem is not with any particular device. If, 
however, some device accessed by our complaining users responds more slowly 
than the other devices, we will have identified the problem. Figure 5 shows a 
response from a server on that segment.

: Response from Segment 01 00 08 05 

For our control experiment, we transmit ten packets directly to the server 
identified in Figure 5. That will tell us about how long the delay is going 
from San Jose to that segment in Provo without going through the access 
server. 

Figure 6 shows the LANalyzer trace summary from our control experiment. From 
the interpacket arrival times, we can see that it takes 30 to 80 milliseconds 
to go from San Jose to Provo and back. Subtracting the 18 ms delay from our 
first hop tests yields a 12 to 62 ms delay across the WAN link. This is also 
a reasonable delay, ruling out the entire route from San Jose to Provo as the 
bottleneck. 

: San Jose to Provo Control Experiment Results
 

If the delay time through Access Server 110 is significantly slower than the 
30 to 80 ms average from our control experiment, then we have found our 
bottleneck. 

To check this, we transmit ten packets to Access Server 110 (whose Ethernet 
address we know from USERLIST /A). Figure 7 shows the LANalyzer trace summary 
of the packets going from San Jose to Access Server 110 in Provo and back. 

: Access Server 110 Round Trip Delay We can see that the round trip delay is 
300 to 800 milliseconds. That is ten times longer than the delay in our 
control experiment. We can conclude (happily) that our LAN and WAN routing 
links are not the bottleneck. Rather, Access Server 110 is either slow or it 
is overutilized.

We can repeat this experiment during off hours and see if Access Server 110 
responds better when no one is using it. If so, it's an indication that the 
Access Server is being overutilized. If it doesn't  respond faster during off 
hours, then we have a basic performance problem with this machine. 

Editor's Note: The author accepts written feedback at FAX (801) 429#5511.

