home *** CD-ROM | disk | FTP | other *** search
/ Netware Super Library / Netware Super Library.iso / app_note / an106b / an106-2
Encoding:
Text File  |  1991-05-30  |  8.1 KB  |  179 lines
  1. Analyzing LAN/WAN Internets: 
  2. Testing IPX Routes 
  3. Using Novell's LANalyzer 3.0
  4.  
  5. Tim Hayes
  6. Systems Engineering Manager
  7. Novell Network Analysis Products Group
  8. LANalyzer Products Division
  9.  
  10.  
  11. Abstract:
  12. This AppNote describes techniques used to make analysis and problem 
  13. resolution simple for large LAN and WAN systems. It presents a method for 
  14. analyzing internets that was applied to a real problem at Novell. 
  15.  
  16. Disclaimer
  17.  
  18. Novell, Inc. makes no representations or warranties with respect to the 
  19. contents or use of these Application Notes (AppNotes) or of any of the 
  20. third#party products discussed in the AppNotes. Novell reserves the right to 
  21. revise these AppNotes and to make changes in their content at any time, 
  22. without obligation to notify any person or entity of such revisions or 
  23. changes. These AppNotes do not constitute an endorsement of the third#party 
  24. product or products that were tested. Configuration(s) tested or described 
  25. may or may not be the only available solution. Any test is not a 
  26. determination of product quality or correctness, nor does it ensure 
  27. compliance with any federal, state or local requirements. Novell does not 
  28. warranty products except as stated in applicable Novell product warranties or 
  29. license agreements.
  30.  
  31. Copyright { 1991 by Novell, Inc., Provo, Utah. All rights reserved.
  32.  
  33. As a means of promoting NetWare AppNotes, Novell grants you without charge 
  34. the right to reproduce, distribute and use copies of the AppNotes, provided 
  35. you do not receive any payment, commercial benefit or other consideration for 
  36. the reproduction or distribution, or change any copyright notices appearing 
  37. on or in the document.
  38.  
  39. Contents
  40.  
  41. Introduction        29
  42.  
  43. The San Jose - Provo Internet        29
  44.  
  45. LAN/WAN Analysis Method        30
  46.  
  47. Determining the Route        30
  48.  
  49. Determining the Delay for the First Hop        32
  50.  
  51. Determining the Delay for the Final Hop        33
  52.  
  53. Introduction
  54.  
  55. Resolving performance problems on large internets can be challenging because 
  56. of the number of components and LAN or WAN segments that need to be analyzed. 
  57. There are techniques, however, that can make the analysis and problem 
  58. resolution easier. This AppNote presents a method for using the LANalyzer to 
  59. diagnose internet bottlenecks. It explains how this method was applied to a 
  60. real problem at Novell.
  61.  
  62. The San Jose - Provo InternetA number of PC users at Novell in San Jose, 
  63. California, use LAN Access Servers in Provo, Utah, to access data on a server 
  64. in Provo.  To access the remote database, users' connections must traverse 
  65. three IPX routed segments. One of those segments is a 1/3 T1 WAN link 
  66. operating at approximately 52K bits per second.  shows a map of the internet 
  67. between San Jose and Provo. 
  68.  
  69. : Map of the Internet Between San Jose and Provo
  70.  
  71.  
  72. The users in San Jose complain that this remote data access is intolerably 
  73. slow. They often wait several seconds for data to appear on their screens. 
  74.  
  75. LAN/WAN Analysis Method
  76.  
  77. To isolate the performance bottleneck, you can measure the delays between the 
  78. user's segment and each of the intermediate segments and the end segment. 
  79. Novell's LANalyzer version 3.0 has an application called BRIGVIEW which was 
  80. developed specifically for this purpose.  BRIGVIEW  allows the user to send 
  81. IPX diagnostic packets through bridges and routers. To help in measuring the 
  82. transmit delay, the LANalyzer has high resolution time stamping on both the 
  83. transmitted packet and the response packet. 
  84.  
  85. Although the method here uses IPX diagnostic packets, the technique itself is 
  86. general. The LANalyzer can perform this same experiment for any protocol. 
  87. There are LANalyzer applications similar to BRIGVIEW for TCP/IP, AppleTalk, 
  88. DECnet, and XNS.
  89.  
  90. Basically, we're going to put a LANalyzer on network C9 99 00 02 and measure 
  91. round trip delay times to  components on segment 00 00 00 BD and also to 
  92. components on segment 01 08 00 05.  BRIGVIEW can transmit an IPX diagnostic 
  93. packet from C9 99 00 02 to any specified segment. We will repeat this 
  94. experiment ten times to calculate an average round trip delay time. After 
  95. doing this for each segment, we will compare the Access Server 110  round 
  96. trip delay to the delay for other devices on that segment.
  97.  
  98. Determining the Route
  99.  
  100. The first step is to determine the route used to go from San Jose to Provo. 
  101. We used the LANalyzer BROADCST application to capture IPX RIP (Routing 
  102. Information Protocol) packets and look for the route to 01 08 00 05. Figure 2 
  103. shows the RIP packet which advertises the three#hop route from San Jose to 
  104. Provo. The routing is done by a NetWare server called OSD#ROUTER. 
  105.  
  106. : IPX RIP Packet 
  107.  
  108. Next, we modified the BRIGVIEW application to transmit packets to OSD#ROUTER 
  109. (using the Ethernet station address contained in the RIP packet). We also 
  110. entered the source address of C9 99 00 02 and the destination address of 00 
  111. 00 00 BD and 01 08 00 05. Since the LANalyzer has six transmit channels, we 
  112. could test all connections in one pass. Figure 3 shows an IPX packet that 
  113. traveled from network C9 99 00 02 to 01 08 00 05.
  114.  
  115. : IPX Diagnostic Packet 
  116.  
  117. Determining the Delay for the First Hop
  118.  
  119. To determine the average delay from the first to second hop of the three#hop 
  120. path, we transmit ten packets  from C9 99 00 02 to 00 00 00 BD. Then we take 
  121. the average of the round trip delay times through OSD#ROUTER to the attached 
  122. segment. Figure 4 shows the LANalyzer trace summary screen. 
  123.  
  124. : Round Trip Delay to Segment 00 00 00  BD 
  125.  
  126. Note that the round trip delays average about 18 milliseconds. This indicates 
  127. the delay going through the first part of the three#hop route is about 18 ms, 
  128. which is a reasonable delay. Thus, this is not a bottleneck.
  129.  
  130. Determining the Delay for the Final Hop
  131.  
  132. Next we transmit a single packet to 01 08 00 05 (using the default broadcast 
  133. node ID convention) to get responses from all devices on the Provo segment. 
  134. This allows us to identify other nodes that we can use as a control group in 
  135. our round trip delay measurements. If all the devices respond in about the 
  136. same amount of time, then the problem is not with any particular device. If, 
  137. however, some device accessed by our complaining users responds more slowly 
  138. than the other devices, we will have identified the problem. Figure 5 shows a 
  139. response from a server on that segment.
  140.  
  141. : Response from Segment 01 00 08 05 
  142.  
  143. For our control experiment, we transmit ten packets directly to the server 
  144. identified in Figure 5. That will tell us about how long the delay is going 
  145. from San Jose to that segment in Provo without going through the access 
  146. server. 
  147.  
  148. Figure 6 shows the LANalyzer trace summary from our control experiment. From 
  149. the interpacket arrival times, we can see that it takes 30 to 80 milliseconds 
  150. to go from San Jose to Provo and back. Subtracting the 18 ms delay from our 
  151. first hop tests yields a 12 to 62 ms delay across the WAN link. This is also 
  152. a reasonable delay, ruling out the entire route from San Jose to Provo as the 
  153. bottleneck. 
  154.  
  155. : San Jose to Provo Control Experiment Results
  156.  
  157.  
  158. If the delay time through Access Server 110 is significantly slower than the 
  159. 30 to 80 ms average from our control experiment, then we have found our 
  160. bottleneck. 
  161.  
  162. To check this, we transmit ten packets to Access Server 110 (whose Ethernet 
  163. address we know from USERLIST /A). Figure 7 shows the LANalyzer trace summary 
  164. of the packets going from San Jose to Access Server 110 in Provo and back. 
  165.  
  166. : Access Server 110 Round Trip Delay We can see that the round trip delay is 
  167. 300 to 800 milliseconds. That is ten times longer than the delay in our 
  168. control experiment. We can conclude (happily) that our LAN and WAN routing 
  169. links are not the bottleneck. Rather, Access Server 110 is either slow or it 
  170. is overutilized.
  171.  
  172. We can repeat this experiment during off hours and see if Access Server 110 
  173. responds better when no one is using it. If so, it's an indication that the 
  174. Access Server is being overutilized. If it doesn't  respond faster during off 
  175. hours, then we have a basic performance problem with this machine. 
  176.  
  177. Editor's Note: The author accepts written feedback at FAX (801) 429#5511.
  178.  
  179.