From: M_A_Jones@Dell.com
Date: Fri Nov 02 2007 - 16:22:01 ART
Great Points!!!
Michael Jones
Network Engineer
Global Network Operations
Dell Inc.
512.723.3268
-----Original Message-----
From: nrf [mailto:noglikirf@hotmail.com]
Sent: Friday, November 02, 2007 7:08 AM
To: Jones, Michael A - Authorized Dell Representative;
smorris@ipexpert.com; istong@stong.org
Cc: ccielab@groupstudy.com; security@groupstudy.com;
comserv@groupstudy.com
Subject: Re: CCIE Lab Price Increase
----- Original Message -----
From: <M_A_Jones@Dell.com>
To: <noglikirf@hotmail.com>; <smorris@ipexpert.com>; <istong@stong.org>
Cc: <ccielab@groupstudy.com>; <security@groupstudy.com>;
<comserv@groupstudy.com>
Sent: Friday, October 26, 2007 10:57 AM
Subject: RE: CCIE Lab Price Increase
>Now the question is , where would one find an actual emulator that
>mirrors Cisco CLI.
Uh, actually, the real question is, would it really be that hard for
Cisco to build such an emulator? Heck, I very strongly suspect that
Cisco probably already has emulators inhouse, being used by their
internal IOS development/testing team. After all, the truth is, many
(probably most) software projects for embedded devices (and
routers/switches are basically just big embedded devices) are developed
on emulators.
I'll give you some examples. A bunch of my friends work as developers
for handheld devices (i.e. Palms Symbian-controlled smartphones, MS
Windows Mobile handhelds, etc.). But they don't directly program a
handheld itself.
Rather, their development environment is an EMULATED handheld.
Basically, they're using SDK's that are provided by the vendors that
speak to an emulated handheld that mimics, down to the hardware level,
the complete functionality of that particular handheld. Hence, they're
developing from standard Windows/Linux/Unix workstations that are
speaking to a 'virtual
device'. When development and testing is done, they then port their
code
to the actual device. Similarly, I know guys who programmed
microprocessors that go into cars (i.e. the processors that control
engine fuel injection systems or the processors that control car
electronic user interfaces).
Again, they don't write directly to the processor itself. They write to
an emulated processor.
Now, keep in mind that these are DEVELOPMENT emulators. These emulators
are obviously extremely elaborate because you have to provide a complete
programming environment to the developers. I am not talking about that
for the CCIE lab. I am simply talking about a CONFIGURATION emulator.
That's a
far far simpler request. After all, I think we can all agree that, no
matter how hard you think it is to configuring a router, it clearly is
nowhere near as hard as actually developing the software for the router.
{Think of it this way. You think BGP is hard to configure? Just
imagine trying to write the actual BGP code that is in IOS. Now THAT is
hard.}.
The point is, Cisco could do it, and in fact probably already has (in
some form). If not, then the open-source community could do it. {After
all, if the open-source community can create entire OS's like Linux,
entire RDBMS's like MySql, entire language compiler sets like gcc,
entire GUI's like GNOME, and the most popular web-server in the world
(Apache), then I really don't think it would be that hard that for the
community to create a Cisco router/switch configuration emulator.} But
the point is, it can be done.
It's not THAT hard to do, relative to all of the other
far-more-difficult software projects out there that were nonetheless
successfully completed.
Some of you guys seem to be talking as if this is an impossible
undertaking - the "Mt. Everest" of software projects, when I see it as
anything but.
And to re-address the question of why Cisco should want to do this, the
answer to me seems to be simple: you can get rid of all of those labs
around the world (or convert that space to other purposes). After all,
does Cisco really need to maintain a lab in Brazil? Really? People can
just take the lab remotely at some authorized testing centers. They can
obtain their proctor access through decent videoconferencing, a
technology that Cisco also offers. After all, Cisco is SUPPOSED to be
enabling remote work, remote productivity, and remote learning. After
all, isn't that the whole
point of even having a network in the first place? Doesn't anybody
else
find it ironic that Cisco - a NETWORKING vendor - forces people to
PHYSICALLY travel to sites to test their knowledge about how to
configure that very networking gear that is supposed to enable remote
access?
This archive was generated by hypermail 2.1.4 : Sat Dec 01 2007 - 06:37:27 ART