Allied Telesis AT-8900 Series Troubleshooting
On-site debugging
Hide thumbs
Also See for AT-8900 Series:
- Hardware reference manual (47 pages) ,
- Quick install manual (13 pages) ,
- Release note (232 pages)
Advertisement
Quick Links
Best Practice |
Introduction
This How To Note describes techniques for on-site debugging. It is in no way intended to be
a comprehensive guide to debugging Allied Telesis equipment. Instead, it is aimed at passing
on some techniques that have been found to be useful. Particularly, this document describes
techniques which:
make it less likely that you will miss important pieces of information
make it simpler for someone else to analyse the debug information that you capture
enable you to be more accurate in after-the-event discussions of what you saw.
Which products does it apply to?
This document applies to the following Allied Telesis routers and managed layer 3 switches:
AR300, AR400, and AR700 series routers
AT-8600, AT-8700XL, AT-8800, Rapier, and Rapier i series switches
AT-9800 series switches
AT-8900, AT-9900, and AT-9900s series switches
x900 series switches
SwitchBlade series switches
Related How To Notes
You also may find the following How To Notes useful, because they specifically discuss how to
debug connections:
How To Troubleshoot ISDN Connections
How To Troubleshoot VPNs
Note that many other How To Notes include troubleshooting information as well as
configuration examples.
How To Notes are available from www.alliedtelesis.com/resources/literature/howto.aspx.
C613-16028-00 REV B
On-Site Debugging
www.alliedtelesis.com
Advertisement
Related Manuals for Allied Telesis AT-8900 Series
Summary of Contents for Allied Telesis AT-8900 Series
-
Page 1: Related How To Notes
This How To Note describes techniques for on-site debugging. It is in no way intended to be a comprehensive guide to debugging Allied Telesis equipment. Instead, it is aimed at passing on some techniques that have been found to be useful. Particularly, this document describes... -
Page 2: Starting Off
Starting off When going on-site to investigate a network problem, your guiding aim is to understand the root cause of the problem, which might be: a cable plugged into the wrong socket a misconfiguration of some piece of equipment an interoperability problem between two pieces of equipment a hardware fault in some piece of equipment a bug in the software of some piece of equipment. - Page 3 show ip count show pim route show pim count show pim neighbour and other commands relevant to the hardware forwarding of multicast in the particular models of switch you are working with. Once this initial survey is complete, you can start following up your theories about what is going on.
- Page 4 All the way through the capture, type (just at the CLI prompt) what you are thinking, and what you are doing. Just write it as stream-of-consciousness, things like: “Hmmm.. that counter value looks strange, lets look at this a bit more” “I have just pulled out blade 5, lets look the internal ports…”...
- Page 5 Providing a convincing case If you believe that you have successfully hit on the right theory, and have isolated what appears to be a good candidate for the root cause of what is going wrong, gather as much evidence as you can to support the theory. Concrete piece of advice #6: If you find a sequence of actions that make the problem happen, capture the full sequence (and the evidence that the problem has happened) multiple (more than 2) times if possible.