From: Scott Morris (smorris@ipexpert.com)
Date: Sat Apr 14 2007 - 13:10:24 ART
Keen for finding the details, but don't over-solve problems!
I would disagree with things being "standardized" as far as solutions go.
The lab should be pretty specific if there are really things it wants.
While detail-oriented is important, it's also important to keep things
simple! Your example of point to point and frame relay. Unless there are
some VERY specific things that only work with PPPoFR, I wouldn't dream of
using that as the solution. A point-to-point subinterface will solve the
basic task just fine.
Our goal here is not to come up with a deliberately convoluted solution just
to see if we can. That's what practice labs are for! On the real lab, it's
to follow instructions, no more, no less. You won't impress the proctors.
But you run the risk of being "too far" out of the norm for a graded
solution!
Just my two cents of course, but I would suggest keeping things as simple as
possible while watching for the details of what may sneak up on you! I
can't agree more though about verifying things! Too many times I see people
"assume" something works because they've done it before and by the time they
discover an error, everything has gone downhill badly.
Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, JNCIE
#153, CISSP, et al.
CCSI/JNCI-M/JNCI-J
IPexpert VP - Curriculum Development
IPexpert Sr. Technical Instructor
smorris@ipexpert.com
http://www.ipexpert.com
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Darby Weaver
Sent: Saturday, April 14, 2007 11:07 AM
To: smorris@ipexpert.com; 'Ryan'
Cc: ccielab@groupstudy.com
Subject: RE: Getting medieval this weekend - almost time to confirm 3rd
attempt.
Perhaps and while everything is subject to some degree of interpretation, I
think the gist is there is a common interpretation that is more or less the
"generally accepted solution" for a task given its pitfalls and its given
restrictions; else how would so many eventually come to the relative same
conclusions in order to actually pass the lab in the first place.
Now I say this for a few reasons:
1. The lab, despite rumors to the contrary, is quite standardized these day.
2. The proctors have stated that all labs around the country are the same
aka standardized.
3. They use a script for preliminary grading (something must be expected,
else a script would simply not do). Now that is does not mean one could not
use a class map to solve security problems, however, this is probably not
what they mean or are asking for. So the proctors may make the difference
here via double-checking or even re-grading.
4. Overall the lab while tricky is probably pretty fair.
I can tell you from personal experience of having sat the lab twice and
living to tell the tale, I am now much more keen about things I took for
granted last year or assumed - even when I thought I did not "assume too
much" at all.
Hmmm...
Basically the more hours we put into our studies, the more reading, the more
classes, the more practice, etc. the better prepared we are obviously going
to be.
No secret there right.
The problem is we are all human and if we read something say 3x then say we
retain 80% short term and 40-50% long term.
Hmmm...
And then to make matters worse, our pride allows us to believe we "mastered"
that topic and can now move on to the next... until we figure out that
there are still things we do not know.
It gets worse we may even tend to favor one topic over another and again
this is based on familiarity with a topic.
Most people tend to fear BGP, IPv6, Multicast, and QoS as a given and
intially Redistristribution, even Frame Relay and Switching...
So whatever the topic we fear, we may choose to attack it directly or we may
choose to go around that topic.
How many of us have trouble with HSRP and the bia and
say... Port Security? and for how long?
Then we figure out there are like at least 2 ways to handle the scenario.
If we favor one then in the lab we may choose it every time thoughlessly.
There lies the crux of the problem - thoughtlessly.
Perhaps this is a question that needs more light from a proctor, as there
may be a preference or there may well not be.
Hmmm...
A simple problem, but one that can cause issue and perhaps lose one points.
Same for items like etherchannel - which method? One or another?
And let us not forget how many times we add to the problem that is the lab,
by creating scenarios that do not need to be there in the first place.
BGP - update-source lo0 anyone? Why if it is not called for? Perhaps it
alters something that is desired or worse not...
Hmmm...
More tales from the crypt.
What if one is asked about Frame and PPP? Would you use a virtual template?
a subinterface with p2p specified? or even just the PPP protocol?
Now why would one assume one over the other on any given day?
When dealing with OSPF over any given frame cloud?
Why use a certain interface type?
These are the kinds of things that may be subject to interpretation.
We can usually figure out easily to use MD5 or plain text, pap vs chap or
ssh vs telnet.
Or at least I think "we" can.
When I think of NTP, I'll never forget a lab scenario that I was presented
with that called for using an upstream NTP time source outside of my pod - I
just had not even considered something outside of my pod as a conceivable
part of a given scenario.
I even recall a certain lab that called for configuring frame relay switch
route statements in order to make it work properly. Truthfully I spent far
too much time, I would have done better to lose the points associated with
it and configure something else.
But again a proctor question: Would I lose other points that are dependent
on something if I configure it this way versus the way asked for?
Considerations can be many, no doubt, iterpretation is always in the eye of
the beholder.
The trick is to make our eyes as keen as possible.
--- Scott Morris <smorris@ipexpert.com> wrote:
> Is there a point in noting to the public that a reply was private?
>
> As for the working configurations and such, you need to keep in mind
> that many things are not just "one rule" or "one method"
> to solve. By that, your
> solution may be perfectly functional, but if it doesn't do what, or
> ALL of what they ask (or breaks something else previously done), then
> it's not really correct, is it?
>
> THAT is one of the hardest things that candidates have with the exams
> and testing things. Many people have discussed that over the years,
> and everyone can debate working vs. non-working solutions all day
> long, but without violating NDA there's no way to REALLY be sure that
> what one candidate did (while working) was accurate per all of the
> rules in their workbook.
>
> The hard parts of life.
>
>
> Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service
> Provider) #4713, JNCIE
> #153, CISSP, et al.
> CCSI/JNCI-M/JNCI-J
> IPexpert VP - Curriculum Development
> IPexpert Sr. Technical Instructor
> smorris@ipexpert.com
> http://www.ipexpert.com
>
>
>
> -----Original Message-----
> From: nobody@groupstudy.com
> [mailto:nobody@groupstudy.com] On Behalf Of Darby Weaver
> Sent: Saturday, April 14, 2007 12:45 AM
> To: Ryan
> Cc: ccielab@groupstudy.com
> Subject: Re: Getting medieval this weekend - almost time to confirm
> 3rd attempt.
>
> Replied privately.
>
>
> --- Ryan <ryan95842@gmail.com> wrote:
>
> > Your comment about quota's got me thinking...a
> little on the
> > conspiracy side, maybe...
> >
> > Let's assume their is a quota system for a moment,
> and they need to
> > fail some people. So how do you fail some one with
> a working
> > configuration?
> >
> > Let's take NTP as an example (since I was reading
> the Doc CD on it
> > today) and the always questioned, "over
> configuration".
> >
> > The question of over configuration has been
> brought up numerous times
> > and the general consensus is that it won't hurt
> you.
> > UNLESS their is a quota
> > system!!!!
> >
> > So for an example, let's say you were asked to
> configure NTP peers.
> > Simple enough. But let's say you "over config" and
> configure the 'ntp
> > peer x.x.x.x'
> > command for each peer. Sure it will work, but it
> is also not fully
> > correct since you only need to configure the
> peering on one router. So
> > a Proctor grading could then say, "hmmm...this
> 'extra'
> > configuration demonstrates they
> > do not clearly understand this technology. Minus 2
> points".
> >
> > Oh look! You just failed for over configuration
> even though you had a
> > working config...
> >
> > Thoughts?
> >
> >
> > -Ryan
> >
> >
> >
> >
> >
> >
> >
> > On 4/13/07, Darby Weaver <darbyweaver@yahoo.com>
> > wrote:
> > >
> > > Basically a sleepless weekend. With a lot of
> > review
> > > and soul-searching - not to mention UNIVERCD
> searching.
> > >
> > > But the goal is not only to assess but to ensure
> optimal
> > > performancce under adverse conditions as
> > well.
> > >
> > >
> > > --- Scott Morris <swm@emanon.com> wrote:
> > >
> > > > Or there will be holes/singes in the exam when
> > he's
> > > > done. :)
> > > >
> > > > -----Original Message-----
> > > > From: nobody@groupstudy.com
> > > > [mailto:nobody@groupstudy.com] On Behalf Of
> jslauer@hotmail.com
> > > > Sent: Friday, April 13, 2007 9:02 PM
> > > > To: Darby Weaver; ccielab@groupstudy.com
> > > > Subject: Re: Getting medieval this weekend -
> > almost
> > > > time to confirm 3rd
> > > > attempt.
> > > >
> > > > if your getting medieval does that mean you're
> > going
> > > > to flog yourself? :)
> > > >
> > > >
> > > > J
> > > >
> > > > ----- Original Message -----
> > > > From: "Darby Weaver" <darbyweaver@yahoo.com>
> > > > To: <ccielab@groupstudy.com>
> > > > Sent: Friday, April 13, 2007 8:29 PM
> > > > Subject: Getting medieval this weekend -
> almost
> > time
> > > > to confirm 3rd attempt.
> > > >
> > > > > So...
> > > > >
> > > > > Training dollars are down and tide is
> high...
> > > > >
> > > > > 3 IE Mock Labs in the about 40 hours span of
> > > > time...
> > > > > (I'll be tired and worn out - been this way
> on
> > > > each of my previous lab
> > > > > attempts - got to simulate exhaustion too).
> > > > >
> > > > > 2 more already scheduled for next weekend.
> > > > >
> > > > > And one more to go.
> > > > >
> > > > > 2 CCIE Accessors are in the approval
> process.
> > > > >
> > > > > And I have a few other labs I am reviewing
> as
> > > > well.
> > > > >
> > > > > Basically, I should have a decent idea of
> > where
> > > > most weaknesses are
> > > > > and if I have or have not covered them
> > properly.
> > > > >
> > > > > So here I go again...
> > > > >
> > > > >
> > > >
> > >
> >
>
This archive was generated by hypermail 2.1.4 : Tue May 01 2007 - 08:28:35 ART