From: Howard C. Berkowitz (hcb@gettcomm.com)
Date: Thu Feb 26 2004 - 22:44:34 GMT-3
At 11:41 AM -0500 2/26/04, Thomas Larus wrote:
>I think CCIE training camps, even the ones that do not offer one-on-one
>instruction, can be very helpful. Still, you really should know "the
>basics, the basics, the basics" before you go, so you can absorb the subtle
>lessons a good training camp should teach. (I do not teach CCIE classes, so
>I am not saying this out of fear for my job).
>
>And then, as you say, work on getting the basics right some more. It is
>amazing how easy it is to make mistakes involving the basics. Forgetting to
>put a loopback interface or LAN interface into a routing protocol, or making
>a simple mistake with a mask or wildcard mask, or making a mistake involving
>static frame relay mapping. One must maintain vigilance.
Tom, I thoroughly agree with the emphasis on the basics. Now that
Washington DC is going through yet another football coach, the
ritualistic "we have to train on the fundamentals" is back.
Modern military training emphasizes as realistic training as
possible, and that includes a great deal of repetition of some very
fundamental things. An infantryman MUST be able to clear rifle
stoppage, reload, etc., blindfolded and under stress. Tank gun
loaders practice, again and again, getting the movement absolutely
coordinated of taking a shell from storage and loading it, with great
speed and also getting all parts of his anatomy out of the path of
parts of the gun -- especially when it fires and recoils.
Before the CCIE candidate goes off into the nuances of multiple
mutual redistribution, he or she should systematically practice every
way of establishing basic connectivity amopng six or so routers
-- RIPv2, EIGRP, ISIS, and OSPF. Not even hierarchical to start.
-- running over every sort of medium, including NBMA, demand, etc.,
and also knowing what kinds of media are not supported by the
routing protocol.
-- developing fast ways to check the ocnfiguration (e.g., other than
for one special case, I _always_ write a separate OSPF network
statement, with an 0.0.0.0 wildcard mask, for every interface that
will run OSPF. If the number of network statements doesn't match
the number of interfaces, I know I've done something wrong. Especially
on multi-area area border routers, I avoid other than exact
interface address matches for fear I get the network statements
out of order and wild-card an interface into the wrong area.
I'm developing a set of multi-step scenarios that I call "speed
builders". They are compare-and-contrast drills on these
fundamentals, much like a piano teacher gives "finger exercises", a
master chef has you slice and chop again and again until you turn out
perfect dice or whatever shape is needed, etc. These should be
available within a month.
It may be even more useful for learners to develop their own speed
builders, taking a technology and systematically working out tables
of all the permutations.
This archive was generated by hypermail 2.1.4 : Fri Mar 05 2004 - 07:13:58 GMT-3