I know- eyes hurt from all that monitor time though...

----- Original Message -----
From: "EA Louie" <[EMAIL PROTECTED]>
To: "Circusnuts" <[EMAIL PROTECTED]>; "Control Program"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, April 09, 2001 6:30 AM
Subject: Re: Cisco IOS Documentation: How useful is it, really?


> Phil - The print version is the same information as on the CD-ROM.  I'm
also
> sold on the usefulness of the printed set - I have a set of 11.2 manuals,
21
> volumes, that fill the entire bottom shelf of my bookshelf  :-)
>
> -e-
>
> ----- Original Message -----
> From: "Circusnuts" <[EMAIL PROTECTED]>
> To: "EA Louie" <[EMAIL PROTECTED]>; "Control Program"
> <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Sunday, April 08, 2001 11:42 AM
> Subject: Re: Cisco IOS Documentation: How useful is it, really?
>
>
> > http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=1228062723
> >
> > This is the best IOS & command reference I know of.  I've purchased the
> > 11.0(22) release a few years ago & now one of these 12.1's.  I can think
> of
> > no better way to master Cisco IOS.
> >
> > Phil
> >
> > ----- Original Message -----
> > From: "EA Louie" <[EMAIL PROTECTED]>
> > To: "Control Program" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> > Sent: Sunday, April 08, 2001 7:33 PM
> > Subject: Re: Cisco IOS Documentation: How useful is it, really?
> >
> >
> > > ----- Original Message -----
> > > From: Control Program <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>
> > > Sent: Sunday, April 08, 2001 8:36 AM
> > > Subject: Cisco IOS Documentation: How useful is it, really?
> > >
> > >
> > > > I'm interested in thoughts and opinions on the practical utility of
> the
> > > > official Cisco IOS Configuration Guides and Command References
> available
> > > in
> > > > print, on CCO, and on the documentation CD-ROMs that ship with Cisco
> > > > products.  There have been a number of allusions on and off this
list
> to
> > > the
> > > > importance (or even necessity) of studying the official docs if
> "you're
> > > > serious about CCIE preparation."  I even recall seeing some advice
> given
> > > by
> > > > someone that one should read the entire set of configuration guides
> and
> > > > command references before attempting the lab exam.
> > > >
> > > First off, the "practical utility" for the IOS Config guides is in the
> > > configuration of the devices (duh), and not for light reading unless
you
> > > have a photographic memory (which actually might be a detriment ;-)
> > >
> > > If you've ever put together a configuration for multiple routers (for
> > > example, even a small 5 site WAN), you discover that the parameters
set
> on
> > > one device are dependent on its neighbors, and that if you don't get
the
> > > commands right, the results that you want will not be realized.
> Sometimes
> > > it can be easy (point-to-point T1's and RIP all using fixed subnet
> masks),
> > > but the complexity rises as the routing protocol is implemented and
> > features
> > > required are added, and WAN technologies used.
> > >
> > > > How useful do you all find the IOS documentation, both with respect
to
> > > CCIE
> > > > study, and in general?
> > > >
> > > VERY.  You go to http://www.cisco.com and click on Training and
> > > Certifications.  From there, there are links that take you to the CCIE
> > > Blueprint, which lists a plethora (ad nauseum) of the material that
you
> > need
> > > to be familiar with, and it is NOT all Cisco documentation.  But there
> are
> > > lots of links to Cisco IOS Documentation there, and some good white
> > papers,
> > > too.
> > >
> > > > Have you succeeded in using it to learn to configure services you
were
> > > > previously unfamiliar with, or is it just useful as a reference once
> you
> > > > already mainly know what you're doing?  Is it even useful as a
> > reference?
> > > >
> > > Yes - ergo ATM (LANE) and LECS/LES/BUS configuration at a router and
ATM
> > > switch level (two different devices, two different IOSes).  Also, the
> > > interface buffers (queuing commands), and it has really helped me in
my
> > BGP
> > > configurations and in route redistribution.  Again, if you haven't had
> > > experience on the console, its almost impossible to study the
> > configuration
> > > guides except to get familiar with how these device commands are
> entered.
> > >
> > > Many times, the configuration examples at the bottom of the Config
> Guides
> > > are good starting points, but don't provide sufficient detail to solve
> my
> > > particular problem.  Knowing the context of a router (one big ARP
table)
> > > helps alot, and knowing the capabilities and limitations of the router
> in
> > > terms of filtering and traffic movement also help.  Interface-specific
> > > commands versus global commands also proves to be valuable, because it
> > gives
> > > me a reference point to search the documentation.
> > >
> > > >
> > > > My own thoughts:
> > > >
> > > > I ask because I find the IOS documentation hard to digest at best,
and
> > > > actively confusing at worst.  I use it frequently, but almost
> > exclusively
> > > as
> > > > a reference to look up command options and syntax details.  Even
then,
> > > half
> > > > the time I find that there either isn't enough detail in the manual
to
> > > > answer the question I have, or there's so much detail that the
> > information
> > > > I'm looking for is buried in an avalanche of optional parameters and
> > > > unrelated features.  The idea of resorting to the IOS documentation
> to,
> > > say,
> > > > learn how to set up async and ISDN interfaces using a combination of
> > > static
> > > > and dynamic addressing to support user dialin and backup/DDR
functions
> > on
> > > an
> > > > access server makes my blood run cold.  It could be done -
> eventually -
> > > but
> > > > it would require piecing the information together from eight
different
> > > > chapters, one of which would provide 200 pages of information just
on
> > PPP,
> > > > another of which would provide 150 pages of information on ISDN
> > signaling,
> > > > and so on.
> > > >
> > > If you're just reading the configuration guides without live equipment
> to
> > > see what the config command does, then it *is* confusing at best,
> > > frustrating at worst.  I've studied the configuration guides without
> > > equipment around, but I also have the benefit of setting up lots of
> > > equipment, so when the config guide refers to a command, I know the
> basic
> > > context of why it needs to be done.  Much of the configuration can be
> > trial
> > > and error, much like any other programmable device, as they don't put
> > every
> > > possible combination of every command into the config guides, but
that's
> > why
> > > the TAC has resorted to providing sample configurations which are now
> very
> > > well documented:
> > > http://www.cisco.com/public/technotes/serv_tips.shtml
> > >
> > > As far as detail is concerned, I agree with you that there often is a
> big
> > > (sometimes HUGE) disconnect between the config guide and command
> > reference,
> > > and I've complained about it (and the poor quaility documentation on
the
> > > output of the show and debug commands).  You end up having to dig
deeper
> > > than the documentation in the TAC area on CCO.  And I'll allude to my
> > > disgust with the undocumented commands, but not expound on it here.
> > >
> > > Basically, what you're asking for is analogous to asking Intel to
> provide
> > a
> > > complete guide of applications for the Pentium processors, and giving
> all
> > > the various commands in a particular flow in the order that you need
> them.
> > > I doubt that would ever happen, which is why experienced CCxx's are in
> > such
> > > high demand.
> > >
> > > > I just can't imagine the official documentation as the preferred
means
> > to
> > > > learn to do something new.  Should you be familiar with the
structure
> > and
> > > > contents?  Of course.  It's still the last word when it comes to
> > resolving
> > > > ambiguities or finding information on that one option you knew was
> there
> > > but
> > > > couldn't remember the keyword for.  Is it time well-spent to sit
there
> > and
> > > > study these manuals as an attempt to increase your knowledge and
> > > > proficiency?  Not in my experience.  That's not to say you won't
learn
> > > > anything by doing it - just that there are better ways to use your
> time.
> > > >
> > > It isn't the preferred means to learn something new, but again, unless
> you
> > > have some experience in configuration of multiple devices (for
example,
> > ATM
> > > LANE between a LS1010, LANE Module in a 5500, and 7x00 and 3600
> routers),
> > > new is probably not the context that you'd be using.  I'm unfamiliar
> with
> > > your level of expertise, but to try and read the manuals to learn to
> > > configure Cisco routers, you'd be very wise to have a router there
with
> > the
> > > capabilities that you need to use.
> > >
> > > When I've had to configure something new (for example, ISDN DDR for
> serial
> > > circuit restoral, or PPP over X.25), I just had to use the
documentation
> > > (ver 11.0) and fiddle with it until I got the configuration right.
The
> > > Config Guide gave me a good starting point, but then I had to
customize
> > the
> > > configuration for my own use.  I had to learn how to generate a
floating
> > > static route, which is not covered in the DDR part of the Config Guide
> > >
> > > > Comments encouraged!  Maybe some of you have actually devised a way
to
> > > > triage the documentation and learn a lot from it despite the way
it's
> > > > organized.  If so, I'd love to hear your strategies.
> > > >
> > > I actually feel that Cisco's attempt to change the documentation has
> been
> > > very positive, but I still use the basic 10.3 and 11.0 configuration
> > guides
> > > because it is what I "grew up" with, and if there is something that I

> > really
> > > don't know how to do with the new commands, then I'll open up the 12.0
> and
> > > 12.1 documentation.
> > >
> > > >
> > > > --
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Reply via email to