At 5:49 AM +0000 12/30/02, The Long and Winding Road wrote:
>""Howard C. Berkowitz"" wrote in message
>[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
>> At 3:00 AM +0000 12/29/02, Lan Wong wrote:
>> >Greetings,
>> >
>>snip some things>
>
>> I'll also throw out a general question. A post not long ago asked to
>> compare the labs of one vendor versus another, and I am affiliated
>> with one of the two. The question was "which is better," and, if I
>> responded, I would have said they really can't be compared directly,
>> because they are designed for different learning objectives.
>>
>> Would such a comment from the designer be acceptable? In other
>> words, no direct competitive analysis, but just a statement of the
>> design philosophy? While I think such information would be useful,
>> I'd rather not see it posted that trigering a series of "mine is
>> better than yours" posts.
>
>OK, Howard, I'll bite on this one, especially as seeing we had some
>conversation off line on this very topic.
Actually, I meant it for offline, but as long as it's here, I think
it's a worthy discussion. Let me talk about the way I personally
design labs that are not labeled "CCIE Lab Practice."
My approach is to focus on one technology at a time, and then the
interactions of that technology with others. This works especially
well in a situation where you have additional study material -- and,
before anyone jumps to conclusions about commercial products, this is
how I developed advanced classes that I did both independently and
with training partners.
In my classroom advanced routing course (mostly OSPF), I did the bulk
labs differently than most Cisco courses. Rather than splitting into
teams and doing a reasonably complete scenario, after each lecture
concept, I'd have them type a few configuration statements before and
after doing show commands, and possibly a debug once they were
configuring.
Hypothetical example:
show routes, show protocols
router OSPF with one network statement
show routes, show protocols, show ip ospf database and other
OSPF displays
start debug on the local router and a second router
on a second router, bring up OSPF on an interface that doesn't
connect to the first router, and do the various displays.
start OSPF on an interface that connected to the other router,
and watch what happens.
While this is going on, display either the live displays or
prerecorded ones with comments on the classroom screen. Discuss with
the class what they are seeing.
-----
During this exercise, people have been configuring within single
areas. I may then ask them, on their own, to establish full
connectivity within their areas, but not to bring up backbone
interfaces.
------
Now, again walk through the process of inter-area connectivity.
------
Do some form of summarization
------
Take a break or lunch, during which I break some of the
configurations and make it a troubleshooting exercise on their return
**********
Several writers of study guides (e.g., Satterlee and Hutnik) do
things along these lines. Other vendors of scenarios provide varying
amounts of study materials -- perhaps no more than links to the
documentation CD -- but do not immediately start with a CCIE-like
multiprotocol lab.
**********
There is ABSOLUTELY NOTHING WRONG with writing CCIE-like multiprotool
labs. Just know they serve a different learning objective than the
CCIE practice lab.
>
>I for one would love to see some interaction between the various purveyors
>of CCIE Lab prep materials regarding their products and the thought
>processess behind them. Not a sales pitch, but rather a discussion of the
>kinds of things that are included in their labs, why, and what skill set
>they believe is necssary for the attainment of the CCIE.
>
>As I said privately, I don't know how much ice anything I say might cut, as
>I have not succeeded as yet. But if I were asked today, I would say that
>there are just a couple of keys - mastery of the "core topics" which are
>pretty much discernable from any of the practice lab workbooks, or from
>Caslow, and then also a GOOD Lab methodology, or game plan. I can't say much
>about the core topics publicly because it could be construedas an NDA
>violation, but anything regarding game plan is fair game.
Caslow's methodology is brilliant, although, as he suggests, it's
much like the organization of a graduate school seminar (flash back
to CCIE vs. degree discussion). My approach uses some of those same
skills, but also uses a lot of the "what problem are you trying to
solve." I recognize that CCIE is not a design test, but I do think
the ability to abstract the process independently of the
configuration is very useful.
>
>BTW, I am not so sure I agree that lab writing is a CCIE skill set. I'd like
>you to elaborate more on why you believe that the ability to write a good
>lab is indicative of CCIE level skill. Maybe some other folks have some
>thoughts on this as well.
Well, maybe not commercial-grade lab writing, but if you can't write
a lab with functions that build on one another, how are you going to
"get inside" the minds of the lab developers?
>
>Hell, maybe Paul would let this particualr discussion cross post to the CCIE
>Lab list, where the vast majority of CCIE Lab candidates associate.
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=59961&t=59924
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
