>One skill required of designers, that can be measured in a lab
>environment, is the ability to specify appropriate equipment for the
>proposed technologies to be implemented. The designer needs to be
>able to specify a product that supports the proposed design.
>
>Remember that the CCIE Design measures the candidates ability to
>design *CISCO* networks - recommending technologies appropriate to
>the scenario limitations and then recommending Cisco hardware
>appropriate to the technologies.
When I taught CID, I had a running argument with Cisco that it was
far more important to put a current catalog and price list into the
student kit than, say, a command reference. I was always told this
was too expensive.
But, to refer back to your point about *CISCO* networks, pricing
(and, for that matter, relevant discounts and support costs) is more
important, IMNSHO, than the ability to configure a representative
system in the lab (if you can -- see below).
In designing real networks (not solutions -- also see below), the
cost-effective way to do things isn't necessarily the most elegant.
For example, the conventional wisdom is to "pick the best box" to
meet some set of requirements. But a single best box isn't
necessarily the most cost-effective.
This is going back a bit, but I remember several cases I had where
there was a need to do assorted SNA stuff. It needed more token ring
interfaces than were available on a small platform, so the school
solution was to use a 7000.
But the 7000 didn't have that fast a CPU, only a 68040. In contrast,
a 2500 series has only a 68030, with a speed of 0.5 relative to the
68040 in the 7000.
But by stacking four 2500's, I could get 4 or 8 TR interfaces, with
twice the CPU power of the 7000.
In a different scenario, I had lots of RSRB circuits to be
terminated. They were TCP encapsulated, so that took lots of CPU.
There was a need to use an IBM channel interface, which only plugged
into a 7x00 router. To get the necessary CPU power, the school
solution was to use a 7500. But a better approach, for the specific
customer, was to use a 7010 with a CIP card and a Fast Ethernet card,
using the FE card to link to a 4700 that handled the TCP sessions.
>
>Can technology X be implemented on Cisco platform Y? If so, how? Are
>there caveats, tradeoffs, or flaming hoops to jump through in order
>to get product Z to effectively run feature A, B, and C at the same
>time?
>
>I think that this is the approach that Cisco is taking with the CCIE
>Design track. Certainly designers are not expected to be responsible
>for implementing and maintaining hardware, but they need to be
>certain that their designs CAN be implemented on the hardware
>available (in this case, Cisco's), and one good way to determine if
>a person knows this is to have them do it, at least once, in the lab.
But in a practical amount of time in the lab, how many devices can
you configure? Even a relatively small network might have dozens of
access routers, several distribution points with distribution routers
plus switches for regional servers, and a core. At what point is a
lab setup using a lesser number of devices going to validate both
functionality AND WORKLOAD/PERFORMANCE?
If I were going to require anything along a lab, as opposed to, say,
a presentation before qualified designers, I'd much rather the
demonstration use a block-level simulator such as BONES. Netsys is
at too fine a level, because it depends on configurations.
>
>With this in mind, I think that Cisco is right on track.
>
>Z
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
