>"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]
