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.
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.
With this in mind, I think that Cisco is right on track.
Z
>From: "Howard C. Berkowitz" <[EMAIL PROTECTED]>
>Reply-To: "Howard C. Berkowitz" <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: CCIE Design...too much?
>Date: Thu, 1 Mar 2001 11:13:08 -0500
>
> >"Mark Holloway" <[EMAIL PROTECTED]> wrote,
>
>First, emphatic agreement with your concern. Design and
>implementation/support, at a serious level, tend to involve different
>skill sets and even mind sets.
>
>Second, the CCIE R&S lab introduces lots of artificial conditions due
>to the limited number of devices and the time constraints of
>configuring. For example, think of a relatively straightforward
>hierarchical, but high-reliability, enterprise design, using OSPF as
>the IGP but realistically using static routes at the edges. I'll
>assume the enterprise is in the process of acquiring two or more new
>companies, one of which uses OSPF and one uses RIP.
>
>You need at least two core routers, which indeed also could be ABRs.
>To avoid single points of failure, however, you presumably want two
>ABRs per area. Multiple ABRs per area also let you explore the
>quirks of nonzero area partitioning, and using virtual links to
>restore backbone partitioning.
>
>Each ABR needs to connect to at least two intra-area interfaces so
>you can see inter-area patterns. It's highly likely there should be
>one or more internal and/or ASBRs in the nonzero areas, and an
>assortment of edge routers that accept default from a distribution
>tier intra-area router, and to which the distribution router(s) have
>static routes redistributed into OSPF.
>
>The company being acquired doesn't yet have physical connectivity to
>your backbone, so they need to use a virtual link to reach it. To
>support a virtual link, the nonzero area it traverses can in no way
>be stubby. Areas into which static or RIP routes are redistributed
>must have an ASBR, so they must be either regular or NSSA. It's
>quite plausible, however, that you might have a data center or other
>corporate area that qualifies to be stubby or totally stubby.
>
>You want to explore load sharing to the Internet, so you need at
>least two ASBRs, in the backbone or elsewhere, that simulate your ISP
>connections.
>
>Now, you could force this to go onto a very small number of routers.
>But the configurations involved become nightmarishly complex, and I'm
>not sure that the ability to build and troubleshoot such
>configurations is really relevant to demonstrating understanding of
>design tradeoffs (e.g., I have to have an ASBR in this area, but
>should the area be stubby or NSSA? As a start, does the area have to
>support a virtual link?)
>
> >Looking at Cisco's requirements for all of their CCIE tracks, it looks
>like
> >the CCIE Design Lab requires "the candidate to configure all of the
>devices
> >included in the design."
> >
> >So not only do you design that proposed network, you must configure it
>too.
> >For those of use who work in the pre-sales engineering field where the
>CCDA
> >and CCDP made the most sense, I think this is going a little too steep
>for
> >CCIE Design. I'm not opposed to learning how to configure equipment, but
> >the list of equipment is literally impossible to build a home lab
>(Catalyst
> >6500, 3500, 2900, PIX, Local Director, 7500, 7200, 4700, 3600, 2600,
>2500,
> >7830 Call Manager, and more). This is double the R/S Exam. Is it really
> >realistic to expect someone who designs networks (as opposed to
> >administering/troubleshooting) to know all of this?
>
>No. Indeed, if one considers ISP design, you might not even need to
>know which vendors' routers are involved, but you had better
>understand routing policy specification REALLY WELL.
>
> >I'm assuming the
> >required knowledge of this technology needs to be top-notch, like with
>the
> >other CCIE exams.
> >
> >I always felt the design path was more geared toward pre-deployment and
>not
> >post. Of course, some knowledge of the hands on is good, but in my job
> >today I may sit with a client or a Data Engineer and go over some
>configs,
> >but I don't maintain the equipment.
>
>Again, strong agreement.
>
>Historically, there's been a tremendous lack of understanding, in
>Cisco's training and certification programs, of what good designers
>actually do. It's far easier to test "measurable" things like
>commands.
>
>_________________________________
>FAQ, list archives, and subscription info:
>http://www.groupstudy.com/list/cisco.html
>Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
