I'd like to start a discussion on the design of two kinds of scenarios:
1. lab preparation. (problem recognition, speed building,
interaction among many protocols, time pressure, etc.)
2. In-depth understanding of protocols (seeing the effects of
alternative configurations, learning how to solve specific
problems with specific technologies). Pure tutorials on
technologies complement these hands-on experiences.
The two requirements, of course, are not mutually exclusive. #3 are
scenarios that either statically or dynamically switch between the
modes.
It is my hope that this will stimulate community discussion involving
both people who use scenarios and people who write them.
Now, a disclaimer: I work for Gettlabs and Gett Communications, the
former of which runs a virtual rack service. Gettlabs itself uses an
open-source model for its own scenarios, as does Fatkid and some
others. Gettlabs has partnerships with IPexpert and
CertificationZone, which sell scenarios and supplemental materials.
My comments here are intended to be neutral, and I will listen, learn
and share with competitors. I have discussed my intentions with Paul
Borghese, and one of our agreements is that this is eligible to stay
off the commercial list as long as I make free scenarios available.
1. Lab Preparation
-------------------
Above all, these have to prepare you for pressure and ambiguity.
A fairly basic question: should all lab preparation scenarios be of
8-plus hour length, or two four-hour segments (forcing the disruption
of a lunch break)? Alternatively, is it acceptable to have sets of
sub-scenarios that build on one another, so you can practice for an
amount of time you have available, then pick up later on?
I think it's a given that all you should be given is the addressing,
etc., in the one day lab, plus instructions on what you should do,
restrictions (e.g., no statics), and some criteria for judging
success. Estimated completion times/points also are important.
An interesting question, however, is whether the scenario should
include some of the sorts of things where it is fair (based on
non-NDA statements of Cisco policy and the variations in proctors) to
ask a proctor a question. Should such points include things where
variously the proctor will and will not answer, or even, in marginal
cases, flip a software coin to see if the proctor will answer)?
I believe it's realistic to be able to see a solved configuration,
but, when you see it, you either should have demonstrated successful
operation or accepted that you will accept losing points to be able
to go on.
I do not think that hints are appropriate in a lab preparation
scenario, with the caveat that this sort of thing is quite
appropriate to technology learning, and, as I suggested in #3 above,
scenarios could be developed (possibly with a specific execution
engine) that let you switch between preparation and learning modes,
and even back.
2. Technology Learning
-----------------------
My general approach to designing such things is again to start with
instructions, initialization, etc., but to break the exercise into
relatively small steps. Each step will have hints available, and
will be fairly small so you can look at the successive changes to the
configuration that move you closer to your goal.
One difference comes with the physical presentation of the scenario.
If it is a printed document, should the hints be in-line with the
text, or in a separate section so you will use them only if needed?
If the latter, should they be on separate pages or at least have
significant "spoiler space" between them so you don't inadvertently
get an unfair clue to what is coming next?
If the scenario is running interactively, should hints and hint
answers only be available with a specific user action (clicking a
link, opening a file, etc.)?
What backup materials should be available for technology learning
scenarios? Is a bibliography necessary, and is it adequate? Should
there be actual tutorials available?
Should learning scenarios routinely contain show command outputs as
well as solved configurations, or should they simply suggest which
show commands to use and what to look for in their output? There
will always be, of course, specific cases where the full display is
appropriate.
--------- semi-commercial but free content follows ----
First examples:
There are several beta-version downloadable scenarios, which
contain some interactive links, at the www.gettlabs.com site. I am
not completely happy with the display formats, and these will change.
The only conditions for their use are:
1. They are copyrighted, but carry an automatic license for personal
use by the person downloading.
2. They may not be used commercially without Gettlabs written
permission.
This includes both classroom and distance learning/virtual rack.
3. We ask that you do not send copies to others, but that each person
download their own copy. The simple reason for this is that the
scenarios are in frequent update and we want to be sure people get
the most recent version.
You are not required to run these on our racks, but, of course,
we'd like you to. Some scenarios may depend on traffic generators and
such which are not part of the scenario, but of the overall execution
environment.
Second examples:
I am actively putting together an FTP server that will have more
scenarios, but initially will not be in pretty format but in lots of
separate files. While we experiment with display formats, this
allows me to keep hints, solved configurations, etc., separate. This
server should start being available early next week.
This server will also have downloadable copies of lots of
presentations of mine from NANOG, the IETF and IRTF, ARIN, etc., as
well as other recommended reading. There will be some subdirectories
labeled "working" that contain documents actively being worked on by
teams/committees, and these may not make sense to anyone other than
the coauthors.
Some of these presentations may be a little old, and I'll be updating
them.
Warning, with half a smiley: my ISIS tutorial may carry a curse.
I tried to present it at NANOG twice. The first time, I came down
with a flu bug that had me down for a good six weeks. The second
time, I had to have a cardiac pacemaker installed the day it was to
have been presented. You Have Been Warned. There May Be Things That
Man Is Not Meant To Read. (or, as a bumper sticker some will
recognize says, "Vote for Cthulhu. Why settle for the lesser of two
evils?")
--
"What Problem are you trying to solve?"
***send Cisco questions to the list, so all can benefit -- not
directly to me***
********************************************************************************
Howard C. Berkowitz [EMAIL PROTECTED]
Chief Technology Officer, GettLab/Gett Communications http://www.gettlabs.com
Technical Director, CertificationZone.com http://www.certificationzone.com
"retired" Certified Cisco Systems Instructor (CID) #93005
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=41955&t=41955
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
