tough to write the level of response the question has earned, but here goes:
""Howard C. Berkowitz"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > 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.) while not mutually exclusive, some of these goals may require a different mind set, if not skill set. I keep a clock at hand, next to my keyboard. Whether I am doing quick and dirty studies for the list, or practicing a lab scenario, I have gotten into the habit of noting my start time and my finish time. I try not to get distracted. I try to do the basic configuration down and working, and note the time it takes me to complete the setup, prior to doing the what if's of a study. If I am doing a lab, I try to time the entire lab. What I have come to conclude is that speed is not what many seem to think it is. Speed is not fast typing. Speed is rather a mentality. After a few months of clock watching, I have come to learn that my own speed problems have little to do with my typing ( which is a sophisticated hunt and peck ) but with my "contemplation" time - reading the requirement, staring at the screen, pondering the possibilities. It continues to be a hard fight for me, but I am learning, especially after intrioducing the clock to my pod, that if one thinks in terms of quickly banging out the basics, and then testing and refining quickly, then overall "speed" improves. I suspect that I have been completely wrong in my previous belief that the CCIE lab is about mastery, and that others have ben more correct in memorizing numerous scenarios, enogugh so that in the real lab they "see" the answers in one of the many memorized configurations. Kinda like a chess grandmaster, who does not think through every singel opening in every single game, but has a wealth of games, and responses internalized. Note that the first few moves of any chess game among grandmasters tends to be fairly standard and predictable. > 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. Let's call this the "NLI" approach. Massive labs with depth and complexity, forcing one to research, think, tst, and try again. there is certainly a place for this approach. Is it the only way to prepare? No. Is it the best way to prepare? Hard to say. Is the approach of value. Definitely yes IMHO. the real Lab can be an endurance test as much as anything else. You have to move out fast, getting your basic configs done quickly, but more importantly, you have to maintain a high energy level from start to finish. No drooping at 2:30. No naps. I'm to the point where I question the value of my periodic stand up and stretch routing, and my planned trips to the refridgerator and the restroom. ;-> > > 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. the folks on the list have done a very good job of this, from what I have read today. > > 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. ambiguity perhaps, but why pressure? and how do you define pressure? On my plate at work I have three large university campuses for which I am doing campus LAN design. I have a 3000 phone AVVID proposal I am working on. I have the most gawd awful 10 office LAN/WAN design and configuration I am trying to finish, and I have another 10 site WAN / LAN 250 phone AVVID design I am trying to complete. The CCIE lab is a vacation compared to this stuff. I no longer consider that the Lab is a place of pressure. Rather it is a place where good work habits place you in good stead. I sincerely believe that most of us on the certification trail do ot have good work habits. We are far too used to trial and error as our means of designing, configuring, and troubleshooting. I think many of us who have failed the lab have failed for similar reasons - there is no time to do things the way we are used to doing them. You have to "know" what you are doing. you have to be worth every penny of the 250 per hour you are going to charge as a CCIE. People who charge 250 per hour should not be guessing. they should not be trying. they should know. the question is, how do you make that point in training labs and practice scenarios? how do you the student internalize this very imnportant value? how doe you as a scenario writer or teacher impart this very important value? > > 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? different times and lengths to practice different skills, or to achieve different goals. > > 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. most definitely. students should also keep a clock at hand, and should be in the habit of noting how long it takes to complete various configurations. In the real Lab you are going to have to know how much you can reasonably expect to get done in how much time, so that you can estimate how much time you will have to spend on later area where you may have to put in some thought. > > 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)? hhhmmmm........ sure, if you are creating a "CCIE Lab Game". Any number of successful CCIE candidates have allowed me to collect their advice. At one time I made an effort to keep that advice current and post it on my own web site ( www.chuck.to, if anyone cares. it's pretty rudimentary ) One theme has been constant in the advice I have collected - that one must know several different ways to do things, and the implications of each. Knowing how wildcard masks work is the important skill, not how to block even or odd numbered subnets. knowing the options available for filtering route advertisements is the important skill, not just the obvious one. knowing in your heart of hearts the implications to any routing protocol over NMBA is the important skill, not how to configure frame or ATM. IMHO, the "ask a question" option might be fun, but you would have to convince me that it furthers the acquisition of the important skills. > > 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. absolutely. in the classroom, in the study lab, one should have solutions to the problems presented, which one can then reference. however - a caviat. It can become very easy to fool yourself into thinking you know something after reading the answer. > > 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? an important skill is that of reading through the entire scenario and making notes prior to any actual configuration. In line hints, hints on alternate pages, all would tend to interfere with the acquistion of this important skill. I want to add one last cynical comment here. I have become convinced that the successful CCIE canidate has to at some point decinde he or she is a big league player, and not just a schmuk. At some point you have to grow up, take responsibility for yourself, and decide you are going to do what it takes to get the cert. At that point you stop posting questions like "help me with this strange problem" and start research, discovering, learning, and then posting the results of your work. Cisco says they recommend that the Lab candidate have two years hands on experience before attempting the CCIE. One can easily obtain the equivalent and more what with the wealth of study materials now available. yet the overwhelming majority of us who take the lab fail, and fail more than once. why? I am convinced that there is a major difference between those who succeed and those who fail. I am convinced that those who succeed made the decision along the way that they were going to do what it takes to succeed. the rest of us have settled for doing what we think might get us by. there is a real big difference here. > > 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? IMHO students should have only one reference source available to them, and it is the one that is harped about, complained about, discounted, and ignored the most - the CCO technical documents page, or better yet, a documnetation CD. It remian VERY important that one be able to search for and find answers to questions using only this resource. Not only because it is the only one available to you in the real lab. But because it is an excellent way to practice and acquire the skill of correctly formulating questions and finding the answers to those questions. > > 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. absolutely, but remembering that you can lead a horse to water, but you cannot make it drink. reading the outputs is a necessary skill ( maybe not a CCIE Lab skill, necessarily ). > > --------- 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?" how to survive in a dog eat dog world while wearing milkbone underwear :-> > ***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 > thanks much for this post, Howard. It is a good one, for more reasons than even you might think. Chuck Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=42069&t=41955 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
