Information Technology Reference
In-Depth Information
Table9-6
AppleTalk: Network Services Intermittently Unavailable (continued)
Possible Problems
Solution
Route flapping
(unstable route)
(continued)
The following example is output from the show interfaces
command:
Ethernet0 is up, line protocol is up
Hardware is Lance, address is 0000.0c32.49b1 (bia
0000.0c32.49b1)
Internet address is 192.168.52.26/24
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
rely 255/255, load 1/255
[...]
The load field displayed in the show interfaces command is the
load on the interface as a fraction of 255 (255/255 is completely
saturated), calculated as an exponential average over five
minutes.
2. If the load is less than 50%, reconfiguring timer values
might solve the problem by allowing RTMP updates more
time to propagate through the network.
If the load is more than 50%, you might need to segment the
network to reduce the number of routers (and therefore the
amount of traffic) on each network segment.
Use the debug apple events privileged exec command to
determine whether routes are being aged incorrectly. The
output should resemble the following:
3.
Router# debug apple events
AppleTalk Events debugging is on
Router#
%AT-6-PATHNOTIFY: Ethernet0: AppleTalk RTMP path to
250-250 down; reported bad by 200.41
The debug apple events command is useful for solving
AppleTalk network problems because it provides an overall
picture of the stability of the network. In a stable network, the
debug apple events command does not return any information.
If, however, the command generates numerous messages, the
messages can indicate where the problems might lie.
Turning on debug apple events will not cause apple
event-logging to be maintained in nonvolatile memory. Only
turning on apple event-logging explicitly will store it in
nonvolatile memory. Furthermore, if apple event-logging is
already enabled, turning on or off debug apple events will not
affect apple event-logging .
Search WWH ::




Custom Search