Troubleshooting Internetwork Performance

Step 2 If the number of ZIP requests is greater than 10 and increasing, a ZIP storm is probably occurring.

Step 3 Use the show appletalk route EXEC command to see whether there is a network that is described as having "no zone set."

If you find such a network, a node in that network is probably not responding to ZIP requests, which results in a ZIP storm.

Step 4 Determine why the node is not responding to ZIP requests.

Either change the network number of the afflicted network or remove AppleTalk from the associated interface. In either case, the original network number associated with the interface should disappear from the internetwork within a few minutes. If it persists, you probably have found the duplicate network.

Step 2 If you changed the network number on the interface, no further action is required. If not, change it now (making sure it is unique). Remember to reenter the zone name and any other interface configurations for AppleTalk on that interface.

Step 2 If any bridges (including routers configured for bridging) are found, set all bridges to forward nonrouted protocols and filter routed protocols.

Step 3 Use the show appletalk route and show interfaces EXEC commands to monitor routes and neighbors.

Step 4 If networks continue to be associated with the wrong interfaces, consult your router technical support representative for more assistance.

If any output drops are found, bandwidth is probably insufficient. If the input and output rates indicate values close to the media maximum throughput for the line, the line is saturated.

Step 2 Use bridging filters to reduce traffic.

Step 3 If local-area transport (LAT) is being bridged and the problem persists, try LAT compression.

Step 4 Increase bandwidth or add parallel lines (combined with the bridge-group group circuit number interface configuration command) to increase available bandwidth.

If any output drops are found, bandwidth is probably insufficient. Collisions and unusually high 5-minute input and output rates also indicate that the media is saturated.

Step 2 Segment the network using internetworking devices (either routers or bridges, depending on your network and the situation).

Step 3 Implement bridging filters to prevent unnecessary traffic from flooding local segments.

Step 2 Check the physical connections of all suspect devices; check modems for proper attachment and functionality; check for noisy lines; check appliques and other router or bridge hardware.

Refer to the media and hardware troubleshooting discussions in the "Troubleshooting Router Startup Problems" and the "Troubleshooting Serial Line Problems" chapters.

Step 3 Remove and replace defective network interface cards or other devices.

Step 2 Use the show decnet traffic EXEC command to determine whether packets are being received and forwarded.

If the number of received packets is greater than the number of forwarded packets and if the queues are full, congestion is probably the problem.

Step 3 To reduce traffic overhead, increase hello timer or update timers to the same value on all routers in the network.

Step 4 Implement the priority queuing and buffer changes described in the section "Slow Host or Network Response over a WAN or Serial Link" later in this chapter.

Step 2 Compare data from all systems.

Step 3 Use a network analyzer (or perform a binary search) to isolate the problem nodes that are generating excessive data.

Step 4 Remove and replace defective network interface cards or devices.

Step 2 Check the configuration for multiple ISO-Interior Gateway Routing Protocol (IGRP) processes configured on a single interface.

Multiple ISO-IGRP processes on a single interface cause different Level 2 routing updates to be sent out on the interface. In a large network, the additional bandwidth of these unnecessary updates can degrade performance.

Step 3 In the router configuration, remove all but one IGRP routing process per interface.

Step 2 Use the show clns routes and show clns neighbors EXEC commands (for ISO-IGRP) or show isis database EXEC command (for Intermediate System-to-Intermediate System [IS-IS]) to display areas and routes.

Step 3 Verify that your network topology does not extend multihomed areas farther than necessary.

When an area extends farther than necessary, Level 1 traffic increases. The additional packet processing can degrade performance.

Step 4 Reconfigure the areas as required.

As an alternative, use the show interfaces EXEC command to get a rough estimate of the collision count.

Step 2 Examine the protocol analyzer output to determine bandwidth utilization. The protocol analyzer output will provide the most accurate reading of dynamic traffic information.

As an alternative, you can run the Novell load monitor command at a server console to get an approximate idea of bandwidth utilization.

If bandwidth utilization detected by the analyzer averages 15 to 20 percent or higher, you are likely to have a load-related performance problem.

Step 3 If you see that collisions are increasing steadily with a higher-than-expected bandwidth utilization, consider segmenting the network with additional bridges or routers.

Step 2 If performance is still inadequate, consider segmenting the network with additional bridges or routers.

When this kind of condition exists, Novell traffic is not getting adequate access to the CPU, and performance is affected.

Step 2 Use the show interfaces EXEC command to look for a high level of output drops.

Step 3 If you see output drops, and another protocol is dominating CPU time (indicated in the show processes Runtime (ms) field), use priority queuing to force the router to give priority to Novell traffic. More information about priority queuing is provided in the "Troubleshooting Serial Line Problems" chapter.

Step 4 If priority queuing does not improve performance, add bandwidth by implementing a higher-speed line or by adding additional lines of the same speed. If you add additional lines, use the ipx maximum-paths global configuration command to specify the number of paths.

Step 2 Perform serial debugging or other media debugging. For media and hardware diagnostic information, refer to the "Troubleshooting Router Startup Problems" chapter. For more specific information about serial debugging, refer to the "Troubleshooting Serial Line Problems" chapter.

Step 3 Replace hardware or add bandwidth as necessary.

Step 2 Apply priority queuing if feasible.

Step 3 If you cannot implement priority queuing or if priority queuing does not help, add bandwidth or additional routers.

Step 2 If ping or trace packets are stopped along the way, check the specific router for access lists.

Step 3 If an access list is found, disable the list and monitor traffic through the router, using the ping and trace EXEC commands.

Step 4 If ping and trace packets get through after removing the access list, you might need to add explicit permit statements to the access list to allow the blocked traffic type.

If extended access lists are specified, ping and trace packets might get through, even though intended traffic is not getting through.

Step 5 If ping packets get through, attach a network analyzer along the path where problems occur to see where the dropped packet type was last seen. The next node is the most likely suspect.

Step 6 Remove any access list, use the protocol being blocked, and monitor traffic through the router.

Step 2 Perform serial debugging or other media debugging.

Step 3 Replace hardware or add bandwidth as necessary.

Step 2 At the point of congestion, relieve traffic problems by adding a router in parallel or by increasing the bandwidth of the link.

Step 3 If you cannot add a router or bandwidth, try adjusting the hop count on the congested router. This is done using the offset-list router configuration command to add a hop to a route received from a particular router.

Step 4 Use the distance router configuration command to set the administrative distance for a particularly slow route.

Step 2 If input errors appear and are increasing, diagnose the serial line as described in the "Troubleshooting Serial Line Problems" chapter.

Step 2 If input errors do not appear, the problem is related to congestion.

Step 3 Turn off fast switching on the affected interface.

Step 4 Check the applications that are being run, especially for very large file transfers scheduled at particular times of day.

Step 5 If large transfers occur, set up priority queuing. (Priority queuing requires that the protocol allow flow control.)

Step 6 Rearrange the timing of file transfers so that links are not overused during normal business hours.

Step 7 Add bandwidth and consider using dial backup over the new link for applications that are taking excessive bandwidth on existing links.

Step 8 Adjust buffer size. For details, see the section "Adjusting Buffers to Ease Overutilized Serial Links," in the "Troubleshooting Serial Line Problems" chapter.

Step 2 Replace hardware as necessary.

Step 2 Ensure that the carrier provides a dedicated circuit if automatic switching is causing performance problems.

Step 2 If input errors appear and are increasing, diagnose the serial line as described in the "Troubleshooting Serial Line Problems" chapter.

Step 2 Turn off fast switching on the affected interface.

Step 3 Check the applications being run, especially for very large file transfers scheduled at particular times of day.

Step 4 If you find large, scheduled file transfers, set up priority queuing. (Priority queuing requires that the protocol allow flow control.)

Step 5 When bridging LAT, consider using the bridge-group group lat-compression interface configuration command to reduce bandwidth by implementing LAT compression.

Step 6 Rearrange the timing of file transfers so that links are not overused during normal business hours.

Step 7 Add bandwidth and consider using dial backup over the new link for applications that are taking excessive bandwidth on existing links.

Step 8 Adjust buffer size. For details, see "Adjusting Buffers to Ease Overutilized Serial Links," in the "Troubleshooting Serial Line Problems" chapter.

Step 2 Replace hardware as necessary.

If, after these actions, load is still about 80 percent, the line is inadequate for traffic requirements.

Step 2 Add another serial line.

As an alternative, use the show interfaces EXEC command to get a rough estimate of the collision count.

Step 2 Examine the output of the protocol analyzer to determine bandwidth utilization. Output from a protocol analyzer will provide a more accurate reading of dynamic traffic information.

If the protocol analyzer detects bandwidth utilization of 15 to 20 percent (on average) or higher, you are likely to have a load-related performance problem.

Step 3 If you see a higher-than-expected bandwidth utilization and if collisions are increasing steadily, consider segmenting the network with additional bridges or routers.

Step 2 If performance is still inadequate, consider segmenting the network with additional bridges or routers.

When this kind of condition exists, XNS traffic is not getting adequate access to the CPU, and performance is affected.

Step 2 Use the show interfaces EXEC command to look for a high level of output drops.

Step 3 If you see output drops and another protocol is dominating CPU time (indicated in the show process Runtime [ms] field), use priority queuing to force the system to handle XNS traffic over other protocols. More information about priority queuing is provided in the "Troubleshooting Serial Line Problems" chapter.

Step 4 If priority queuing does not improve performance, add bandwidth by implementing a higher-speed line or by adding additional lines of same speed. If you add additional lines, use the xns maximum-paths global configuration command to specify the number of paths