From: Jason1 (jason1@xxxxxxxxxx)
Date: Sat Apr 07 2001 - 11:59:48 GMT-3
#6 This has nothing to do with saving or not saving config.. Did I mention
that it was ?????!!????
It has to do with stablility of certain protocols in certain situation,
could that have come out in the lab ? I don't know.. personally I won't set
such problems because it could be solved without the engineer knowing why,
but I won't put it beyond the lab either since this is common problems in
production. So... back to my question, did I said that it was related to
the saving of config ?????!!?? :-P
----- Original Message -----
From: "Scott Morris" <smorris@mentortech.com>
To: "'Jason1'" <jason1@v-labs.net>; "'Edward Moss'" <teklnk@home.com>;
<ccielab@groupstudy.com>
Cc: "'Chuck Church'" <cchurch@optonline.net>
Sent: Saturday, April 07, 2001 10:47 PM
Subject: RE: Couple of lab troubleshooting questions
> Re: #6 - Do you not think the proctor would SAVE the config before giving
> the pod back to you?!?!?!?! Especially if there is a password change. :)
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> Jason1
> Sent: Saturday, April 07, 2001 12:11 AM
> To: Edward Moss; ccielab@groupstudy.com
> Cc: Chuck Church
> Subject: Re: Couple of lab troubleshooting questions
>
>
> I've not done mine either BUT I understand that...
>
> 1. Fine if you are troubleshooting your own network....
> 2. you are NOT allowed to keep a copy of the running-config , else I don't
> even need to troubleshoot.. just upload it back in.. why compare ?? ;-)
> 3. Easier said then done due to Time factor.. nevertheless, you should do
> it...
> 4. Definitely
> 5. I would say, check Routes Table first..
> 6. Can I force a reboot of ALL routers first ? ;-)
>
>
> ----- Original Message -----
> From: "Edward Moss" <teklnk@home.com>
> To: <ccielab@groupstudy.com>
> Cc: "Chuck Church" <cchurch@optonline.net>
> Sent: Saturday, April 07, 2001 9:35 AM
> Subject: Re: Couple of lab troubleshooting questions
>
>
> > I haven't taken the lab yet, so I assume that I cant break the NDA....
:o)
> > My advise... Identify what is broken then work the physical layer up.
> > In the real world, for networks I support it can be "by the seat of my
> > pants"... but in customer's networks here is wht I do.
> > 1. Get the documentation (helps if interfaces and port numbers are
> > documented). I believe it is critical to know what the network was
> designed
> > to do.
> > 2. Get a copy of each config for a baseline (is the startup and running
> > config the same?). Even if it is bad... you can go back to it if
> necessary.
> > 3. On each device, check the interface status, ensure UP/UP - DCE vs.
> DTE,
> > clock rate, keepalives?
> > 4. Look at CDP if possible, check IP between devices. Verify the
configs
> > (IP/prefix) against the docs.
> > 5. Check the routing protocols... what is running on each device, what
> > should be advertised, is it in the appropriate route table.
> > 6 If necessary, remove route redistrubitions, access lists, etc... If
> > there are access lists... know what each one is doing.
> > Of course, each protocol and routing protocol have their own querks.
> >
> > Above all... document every change, why it was changed and note the
> results.
> > Did the change have the desired effect? If not, change it back (or have
a
> > good reason for keeping it in.)
> >
> > I think the Cisco Press book "Internetwork Troubleshooting Handbook" is
a
> > great on-the-job book. It details common problems as well as the
physical
> > layer up approach.
> >
> > Ed
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:29:42 GMT-3