From: Howard C. Berkowitz (hcb@xxxxxxxxxxxx)
Date: Sat Apr 27 2002 - 12:22:50 GMT-3
At 12:58 PM -0400 4/26/02, Thomas Trygar offered some excellent
observations (IMNSHO):
>Group,
>
>Watch your addressing you use when practicing. The IP addressing I used for my
>last lab was very similar to the lab and caused problems. I had to re-addr
>interfaces with the correct network more then a few times. And since I didn't
>create the IP addressing scheme, I had to keep flipping from one
>page to another
>for diagrams and addressing placement. The lab addressing seemed logical, but
>since I didn't create and configure individual interfaces, I lost
>more time with
>transposing then if I just did it the addressing myself.
Flashbacks to my very first Cisco class, where I held up the entire
class until I found that I had transposed a 128 into a 182.
There are pros and cons for the scenario writer in having the user
define addresses. Having predefined and sometimes bad addressing is
probably better lab practice. Designing your own addressing certainly
improves understanding of the technologies.
>
>Per Purchasing Lab Scenarios:
>
>I'd like the material to have is all:
>1) straight labs tasks and diagrams
>2) hint(s) to guide you to the specific problem
>3) hints to specific solution
>4) explanation on who/what/where/when/why on problem and why that particular
>solution is
> used/best
>
>Obvious, with this much detail and documentation needed, the price
>would in the
>high range for Lab material. This layout would satisfy everyone's need. Or you
>could have a lower fee for Options 1 & 2 and then a little higher
>the Options 1
>thru 4. Since the 1-Day format is relatively new, Cisco will not it, so the
>documentation would not have to change noticeably in the next few years. They
>might add a little section for troubleshooting or just depend on the tasks
>uniqueness for the gotchas and candidates own fat fingers and DUH factors.
>
>Included in Lab Docs should be basic and advanced technology
>specific labs on a
>handful of gear.
>These should be designed for no more then 6 routers. The sweet spot
>would be 3-4
>routers.
Very valid points about the number of routers. David Newman, who
runs one of the major testing labs, made the observation on an IETF
list that four routers were the minimum needed to get a real sense of
a routing protocol. You need a minimum of 3 to avoid direct
connections, but you need the 4th to be able to see failover and load
balancing.
In designing virtual labs for CCIE practice, things get more complex.
First, of course, 6 routers and a couple of switches are closest to
the lab. 6 or more routers, however, is around the minimum needed to
have a wide range of interfaces (e.g., ATM, ISDN, voice, FR, etc.)
and still keep down the cost of the basic routers (e.g., 2500/2600
and 4000/3600 rather than going to 6000/7000 series).
Additional routers are a challenge. It's impractical, for example, to
both generate reasonably complex BGP updates in a 6-router
configuration that also must make, say, multihoming decisions based
on these updates. Not enough routers for the number of AS needed.
Commercial labs, whether in-person or virtual, have an advantage here
because the load-generating routers can be shared over multiple
racks/pods, giving economies of scale.
>
>I'd recommend that any labs not be designed on equipment most people cannot
>reasonable afford.
See above both for this point and the next.
>Designing 12-15 routers labs seems excessive unless all you
>will be doing is labs designed for 1-Day lab exam only for testing speed, time
>management, knowledge, etc. This could be a solution for a commercial remote
>rack plan, but care should be taken to compile a 1-Day format lab for less
>equipment requirements.
>
>Recommended times for Options 1-2 & 1-4 should be included for
>comparison. This
>would give the candidate a loose measurement on his speed, and their level of
>knowledge to over come any time management obstacles. The time limits would
>provide a gauge on proficiency and a stopping point to look at hints, or
>explanations. This would help everyone who will working on a problem for hours
>with arriving at a fix. Given time, everyone will try every command and all
>fixes, while spending time on CCO and Doc CD for hours and hours when all they
>need is a clock reference that says, "Times up, here's a hint." If after that
>hint you reach another time reference, you should get another, "Here's another
>hint" or "The solution is X, you need you practice/technology background."
>
>Tom
>
>"Howard C. Berkowitz" wrote:
>
>> At 4:47 PM -0500 4/19/02, DAN DORTON wrote:
>> >When I say your own I mean...
>> >
>> >Give them a major net 135.50.0.0/16, or something like that.
>> >
>> >Then say R2 tokenring needs to be a /28.
>> >
>> >R3 to R5 P2P connection needs to have no more than two host addresses.
>> >
>> >So on & so forth.
>> >
>> >Make them work a bit to figure it out.
>> >
>> >This was vital to my understanding of subnettting/VLSM/CIDR.
>> >
>> >I thought I really knew all this stuff well until I hit the rack.
>> >
>> >Then I realized after 8 months that now I can crank it out without
>> >even thinking about it & how little I really did know.
>> >
>> >Also as far as time is concerned.
>> >
>> >I can address & get layer 2 operational on a 10 router lab in less
>> >than an hour. frame/atm/switching/ the works.
>> >
>> >Helps pound all the meaningless stuff that you might overlook into
>> >your head so far that you can never forget it.
>> >
>> >Of course this is just my opinion.
>>
>> And a good one, because you are opening up a whole area of discussion
>> on addressing models for study. My practice is generally to use lots
>> of /24 and smaller, except when doing BGP models that call for
>> multilevel aggregation. My rationale for using /24, and often
>> smaller, is to force people out of classful thinking.
>>
>> I do have a couple of variants, one of which is like yours -- a
>> single /16, and another that has two or three /16 to force some
>> discontiguous networks.
>>
>> What I hear you saying is that having one large network number allows
>> you to focus on learning the hierarchical aspects of VLSM/CIDR. The
>> only problem I have with doing that generally is that you won't have
>> problems with auto-summary and discontiguous networks.
>>
>> Thanks. Good stuff.
>>
> > Howard
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:58:20 GMT-3