From: Howard C. Berkowitz (hcb@gettcomm.com)
Date: Sat Oct 01 2005 - 12:44:42 GMT-3
At 10:18 AM -0400 10/1/05, Tom Larus wrote:
>I felt the same way as I was preparing for the lab. When I was
>preparing for the Lab exam, Hutnik and Saterlee's Cisco CCIE Lab
>Practice Kit from McGraw-Hill was the only workbook product that I
>was aware of that provided task-by-task explanations of WHY
>something was configured the way it was. I worked through these
>labs (as well as other labs like the ones they provided me at a
>Cisco CCIE practice lab at NC State) BEFORE I tackled the labs in a
>workbook from a leading vendor.
Yes, they did do some of the first "why's". I was a pre-publication
technical reviewer for their first book.
The preparation review authors often have different ways of adding
value. For example, I was impressed with Hutnik and Satterlee's
first-book way of tying together protocol analyzer output with IOS
debug output. Remember this was at a time when the CCIE lab still had
troubleshooting, and it was fairly safe to assume that people going
into CCIE practice had hands-on protocol analyzer experience, but not
necessarily as much IOS experience.
In like manner, Bruce Caslow is the master at developing a strategy
for answering a question. At least for me, his analogies to graduate
seminars were especially vivid. They might not be for anyone who
hasn't been exposed to graduate-level education.
Personally, I like to bring in relevant parts of "true theory". Let
me digress for a moment. I've noticed, on Groupstudy, that many
posters treat "theory" as anything not associated with an IOS
command. For example, they consider the TCP windowing mechanism or
even basic principles of the Dijkstra algorithm to be "theory."
I don't. I consider those to be "principles of protocol operation."
Theory, to me, is something that mostly comes up in the IETF and
especially IRTF, and is used in making fundamental choices in
designing protocols and other mechanisms. TCP's original windowing
mechanisms are obsolescent with today's transmission speeds. More and
more modern transmission systems are "LFNs" or "elephants", and if
you don't know those concepts, see
http://www.isi.edu/in-notes/rfc1323.txt. You will find, in RFC 1323,
that they don't deal with selective acknowledgement, which is a more
recent subject, as well as analyses of transport enhancements such as
starting with a large window size.
Why is this relevant? Because if you don't have at least a moderate
understanding of _why_ TCP does things, you will have trouble really
understanding the role of Random Early Detect in QoS.
>After I passed the Lab exam and worked for a Cisco reseller for a
>while, I decided to a write a book in the same vein as the Hutnik
>and Saterlee CCIE Lab Practice Kit. I provide explanations of the
>vast majority of tasks (a few tasks are so simple as to not need
>explanations). I then wrote a Volume II with more of the same sort
>of scenarios, but this time two brilliant and experienced network
>engineers who had bought my first book agreed to be technical
>reviewers for my second book. They are both now CCIEs and are more
>experienced than I am, so they helped me make a better book than it
>would have otherwise been.
>These books focus heavily on the age-old lessons that CCIE
>candidates have struggled with for years. Many of these subjects
>would properly be considered "Foundation" or intermediate-level,
>but I also cover a few advanced or subtle matters. I have a complex
>redistribution scenario in the first book that some people like a
>lot.
For me, I like to introduce the theoretical idea that a routing
mechanism must have capabilities for loop avoidance or loop
prevention, and showing how this is done in various protocols, and
then needs to be done with redistribution. No, this doesn't mean
going into advanced theory such as the current topic of microloops.
A related issue, especially with BGP, is knowing under what
circumstances a routing mechanism may not converge -- and why you may
need to make compromises.
Unfortunately, many of these "theory" issues that affect real-world
protocols don't show up in CCIE-lab-scale systems of 8-10 routers or
so. I'm doing (sorry, NDA prevents further detail) a specialized
class that barely gets by with around 40 physical routers and L3
switches, plus tools that simulate dozens of autonomous systems and
possibly thousands (or more) hosts.
Watch for a new idea from Paul Borghese and others that might provide
some introductions in this area.
>
>Unfortunately, I did not incorporate IPv6, and I don't think I will
>have time to rewrite the books to incorporate IPv6, so they will, in
>a few months, become "obsolete" to some extent.
>
>I do not claim to be anywhere near as smart as the gurus who write
>the advanced books and teach the CCIE training classes, but I am
>pretty good at explaining things in a practical, plain English way
>that some people like a lot.
>
>I think there are lab guides available to provide explanations for
>the advanced workbooks, but in my opinion it is good to learn many
>of the hard lessons before you touch a major advanced workbook. I
>have not seen the lab guides that exist these days, but I would not
>expect them to spoonfeed you much when it comes to advanced
>scenarios. Better to learn the basic and intermediate lessons early
>on so that when you come to the advanced scenarios from the gurus
>you can fully absorb the advanced or subtle lessons the gurus are
>teaching.
>Best regards,
>Tom Larus, CCIE #10,014
>Author of the CCIE Warm-up e-books
>540-368-2601
>
>
>cciein2006@yahoo.com wrote:
>
>>I was considering purchasing one of the CCIE training workbooks,
>>but I'm not crazy about how solutions are presented.
>>
>>>From the workbooks my friends have shown me (I think one was
>>>IPEXPERT) they either provided no solution or the solutions were
>>>in the form of router configurations with no explanations of why
>>>certain commands were configured.
>>
>>I guess figuring out why the answers are configured that way is
>>part of the fun/challenge, but I find it more educating for the
>>solutions guide to explain exactly why certain commands are
>>configured.
>>
>>Are all the training workbooks like this? If not which ones provide
>>detailed explanations and also is the solution guide an extra
>>charge?
>>
>>Thanks!
This archive was generated by hypermail 2.1.4 : Sun Nov 06 2005 - 22:00:49 GMT-3