|
Home > Archive > CCNP > June 2001 > troubleshooting handbook
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
troubleshooting handbook
|
|
|
| Hi all,
Im putting together a troubleshooting handbook, and wanted to see if people cared to add insight or suggestions.
The concept is to issue relevant show commands on routers and switches to isolate what kind of problem may be occuring. However the users that will be using this handbook will not have privelaged access, so all commands must be available without enabling privilaged access.
For instance: show run will not work.
Now im thinking the best way to approach is opening section with general commands:
show ip int brief
show int
show cdp neighors
ping
show ver
The second section technology specific:
Switches
Routers
Firewalls
OSPF, EIGRP, BGP, ATM, HSSI, FRAME, ISDN, and Sonet
ANy and all suggestions as well as resources or command references would be gratefully appreciated.
And again the purpose of this document is to not help the users resolve issues, but rather be able to identify problem and escalate to proper people with as much info attached as possiblle.
thanks | |
| bugmn99 2001-06-26, 7:50 pm |
| Forgive me for saying but, should somebody without priviledged access really be troubleshooting a production network? I consider anybody without "access" a "user" and "users", for the most part, will do more harm than good whenever they decide to "wax technical" so to speak. | |
| strikeattack 2001-06-27, 8:41 am |
| I suppose that question is specific to each organization. For example, lets say you have Distribution Centers in a remote state with only one circuit available. Lets also say that you had no IT support staff there because there is not enough work for one. If that circuit goes down, obviously you will not be able to telnet to the device. You could have a few power users that can initiate a telnet session and run diagnostics in user exec mode. User exec mode is non-intrusive, and will only show you information, and will not allow you to change the config. This way, you may be able to find the solution faster.
Just a possibility. It really depends on the organization. However, generally speaking, I would prefer that users not have telnet access to the routers. | |
|
| the concept here is that NOC people can weave out first line of trouble issues.
The document im putting together would be the information they used to move through troubleshooting procedures.
Thats why there is no need for privelaged access, because they wont be configuring anything just gathering information, so they can open tickets with Telco or contact network enginner with info.
think helpdesk | |
| peterd 2001-06-28, 2:02 am |
| Hi Strikeattack,
you have a good point but in that situation I'd have (and actually do have on all of my sites) some kind of dial-up access to the remote site where I can get in by the 'back-door'.
Mostly it's ISDN for data fall-back but on a couple of sites the PC Support guys have modems on the NT server running RAS so i use those if I need to.
As for users getting into routers...sorry but that seems to me like you're asking for trouble. I keep the riff-raff out of my cabinets at all times...
I don't want them knowing how easy my job is!
Regards
Peter | |
|
| Guys,,,
NOC people are usually a little bit trained. (smile)
How about something relevant to my post???
This is not designed for (USERS), its designed for tech support people (NOC), to help determine 1st line issues. Being able to issue show commands from a router wont hurt much,,, you cant do much else..
Especially with TACACS+ or RADIUS ( Cisco ACS server)
Any helpful suggestions would be great, but im not sure i can keep explaining the idea behind this post. Big companies with world wide networks need things like this in place to help off-load network engineer'r work loads. |
|
|
|
|