Chuck, Your post reminds me of those weird little ice cream stands that I sometimes see at the mall and various carnivals. It's called something like "Dipping Dots - The Ice Cream of the Future". The initial human instinct is much like the Cro-Magnon humanoids encountering the monolith at the beginning of 2001: A Space Odyssey (sp): jump up and down with excitement until you realize it's just freeze dried ice cream.
Rounding out that analogy, the CCIE of the future will probably be reduced to being the CCNP of today. Regardless, I have spent too much time and money to abandon the quest for CCIE now, but frankly, if I hadn't invested as much as I have, I would most likely abandon the quest in favor of broadening into other areas. I really don't see much market value for the CCIE anymore, especially with Cisco hellbent on making it a meatgrinding cash cow. Your java console and "one way only to configure" experience kind of bears this out. Sorry for the depressing post, just wanted to share. Charles ""The Long and Winding Road"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Been spending this weekend on what was once the Cisco Advanced SE Training > ( ASET ) set of labs. These are available for those whose Cisco account team > approves - there are a few conditions which can be found in the wee places > of certification training. > > The program is run by Lab Gear ( the only link I have is www.labgear.net, > but > this is a login page ) There are a number of labs of CCIE level, look, and > feel. > > Supposed to be real equipment, but the access is via java script windows, > not terminal emulation. This makes for some interesting situations. The > windows show or provide output only when they are active. So if you had two > router sessions open, and you made changes on one router that would generate > systems messages of one sort or another you would not see those messages on > the other. also, I have yet to find a way to generate output from debugging > commands. Things like term mon and logging of one kind or another have not > been successful. so no debug ip routing and debug ip ospf adj. > > As with the real lab, there are a series of tasks to be completed. Grading > is done via a script. This is the point of most interest. Actually, I > suspect a lot of the current CCIE Lab grading is done using scripting tools. > I believe the proctors still physically examine equipment configurations for > some things, but I could be wrong. > > It is of interest because to judge from the script outputs I am seeing, > there appears to be an assumption that there is one and only one way to do > things. I'm not sure this is always true. I am not sure that this results in > an entirely accurate grade. > > But more importantly, given my experience with the java consoles and the > manner in which these labs must be done, I am not sure I like where this is > headed. Something Brian Dennis and Brad Ellis and some other people started > talking about back when the CCIE Lab went from two days to one - something > about the longer term goal being to do the test remotely, and having people > show up at Sylvan or some other testing center and log in remotely. > > If the Lab Gear approach is any indication, this is not ready for real live > testing. I experienced far too many problems with terminal ( javascript ) > sessions disconnecting mysteriously. With 8 open windows, it sometimes got > to be very hard to find the session ( router ) I was looking for. Cut and > paste is a real pain. You have to open a "scratchpad" window, which is > associated with the javascript console window. cutting and pasting is done > to this wind. there are scratchpad windows associated with each java wind, > so if you had a scratchpad open for every router session, that makes for a > LOT of junk to fight your way through looking for what you want. then there > is the problem of actually moving what you want to copy and paste. highlight > and control c control v or alt e paste don't work. you have to click on > buttons on the java consoles to copy to and from routers. > > beyond that, there is the problems of whether or not the "script" answer is > the right answer. For example, in one lab, a particular instruction requires > that the rip routers on a particular segment have to use the neighbor > statement to see eachother ( and prevent other routers on that segment from > joining into the RIP domain ) well, the problem is, one of those routers is > connected to another RIP router via a different interface. need a neighbor > statement there too, but the script does not cover this, nor does the answer > configuration show this. > > anyway, I have seen the future, and the CCIE Lab future looks like it may be > heading to these kinds of remote lab settings. > > -- > TANSTAAFL > "there ain't no such thing as a free lunch" Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=62776&t=62776 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
