From: Bruce Sharapov (BruceS@phtss.com)
Date: Tue Mar 20 2007 - 08:02:47 ART
I managed to dig that archive and send it for the convenience - Darby Weaver and everyone.
Tim, this is a really nice post that you did.
-------------------Tim's------------------------------
This is a repost of an earlier with a different subject line.
Gustavo,
Having failed the lab many times, I can sincerely say I feel your
pain (Actually, until Tuesday I could honestly say I've been feeling
your pain for the past 2 years).
So, what I'm about to say is for those people like yourself, who have
enough knowledge and skill to pass the lab but still fail anyway.
Personally, I believe there are 4 primary reasons people who should
pass the lab don't.
1. Task mis-interpretation
2. Insufficient organization during the lab
3. Not seeing the implied requirement
4. Insufficient checking and verification
Here are the some of the things I did to overcome the first problem.
I think there are 3 reasons people mis-interpret the task requirements:
1. Cisco, by design and with malice of intent, often writes the
tasks in a vague or misleading way.
For example, if you've been following GS posts over the past couple
of weeks, you may have noticed questions regarding Mobile IP.
However, Mobile IP is not on the lab. This was a response to a
question re: forwarding Mobile IP registration broadcasts.
"Ip forward protocol with IP helper is what I would use...you can
forward mobile-ip registrations which are udp...I'm not sure about
your configuration but that's what it appears to me what you are
trying to do.."
Reading between the lines, it seems to me that a task could be
written with the words Mobile IP in it where the solution has nothing
to do with configuring Mobile IP. Now, I can't speak for anyone but
myself but I know that if I read a task with the words Mobile IP in
it, I would AUTOMATICALLY think about having to configure Home Agents
or Foreign Agents or something related to that. Not in a million
years would it occur to me that the solution was really calling for
the ip forward udp command.
Could it possibly be that the proctors who write these labs would be
so wicked? I think the answer is definitely YES.
On the other hand, there are ways to combat this wickedness. First of
all, DON'T ALLOW YOURSELF TO BE SUCKED INTO THE BLACK HOLE OF WASTED
TIME.
Losing the points of one or two non-layer connectivity tasks won't
automatically cause you to fail the lab. I had at least 2 tasks on
my lab which I didn't even attempt to answer and I still passed.
2. Reading the task too quickly (or not carefully enough)
To combat the scourge of task mis-interpretation, slow down. Yes, I
said it. Slow down. Read the complete set of bulleted sub-tasks
slowly and multiple times. Here's what often happens when you don't
slow down. You read the task too quickly and realize you know how to
do that and you configure the task using the most common method or
the way you're most familiar with - and you're wrong. You make the
assumption that just because you know A way to fulfill the task
requirements, you are fulfilling the task in THE correct way. Of
course, it doesn't appear that you're wrong because you verify
reachability and you have reachability but you didn't fulfill all the
conditions of the task. Bingo !!! At least another 2 or 3 points
lost.
(You might also lose points for subsequent tasks because of
dependencies.)
Here's another example. "Allow pings to bring up the isdn link"
which is not exactly equal to "Allow icmp traffic to bring up the isdn
link".
Consider this. Does "Allow pings..." mean "Allow ONLY pings..."?
If your acl is like this: access-list 100 icmp permit any any
This acl does in fact "Allow pings..." to bring up the link but it
also allows other traffic as well. What should you do? Will the acl
above cause points to be lost? I don't know for sure but I suspect
that it's better to be as specific as the task allows.
This brings me to next KEY reason people mis-interpret the task:
3. Not knowing every way to accomplish a given task.
Of course, the best to deal with this problem is easily said but not
that easily done.
KNOW EVERY WAY TO ACCOMPLISH A GIVEN TASK.
The lab is FAMOUS for restricting your choices for how something is done.
For example, there are 3 ways to advertise a loopback in OSPF without
a
32
bit mask. There are 3 ways to advertise the ip address assigned to
an interface in IS-IS. There are multiple ways (at least 3 that I
know of) to assign an ip or ipv6 address to an interface. There are
a gzillion ways to configure isdn to back up lost connectivity
somewhere else in the network.
There are multiple ways to overcome reachability problems.
Here's my list:
1. Redistribution
2. NAT
3. Default network
4. Static route
5. Tunnel
6. Policy based Routing
7. Summary Addressing
8. Virtual-links
When you don't know every way to accomplish a given task, it's easy
to be faced with the dilemma of thinking, "They must mean ...". So,
then you configure something that seems to be pretty close to what
they were asking for but not 100% exactly what they were asking for.
Bingo !!! Another 2 or
3
points down the drain.
Now, I'll talk about the 2nd reason I think people fail the lab.
Insufficient organization during the lab
This could also be referred to as STUPID MISTAKES.
We all make them and I suspect I do much more than most people. For
example, let's say early in the lab (in the section on bridging and
switching), you have to configure f/r end-to-end keepalives. So,
that's what you do. You check it. It works. You go on your merry
way. Later on, you're working on the QoS sections and you have to
configure FRTS. So, that's what you do. You check it. It works. You
go on your merry way.
But,
if you're anything like me, you didn't notice that the interface you
applied the FRTS to were the same ones already configured for FREEK.
Whoops !!!
Another 2 or 3 down the drain.
You can probably think of hundreds of examples like this where you do
something early in the lab only to do something later in the lab that
breaks your earlier configurations.
To address this problem which probably caused me to fail multiple
times, I started getting in the habit of making lists during the lab.
If I have to create an acl or map-class, I write it down on the
scratch paper they hand out at the beginning of the lab. Then, if at
any later point in the lab, I need to create another acl or
map-class, I first check to see if I've already had to create one
before and on which interface. I also used to create a list of every
loopback interface and make a note of which IGP it's in. When I'm
done with the IGP section I check to see if I've advertised every
loopback. I don't do that anymore. Now, I use a tcl script to check
that. But, the list method worked fairly well before I was
comfortable with using TCL scripts.
Reason # 3 people fail: MISSING THE IMPLIED TASKS
Let's assume for a moment you take the lab and only do what they
explicitly tell you. If they didn't EXPLICITLY tell you to do
something, you didn't do it. How many points would you lose? My
guess is at least 6 to 9 points.
Of
course, they did tell you full reachability was required at all times
perhaps in the general directions but not in any of the numbered
sections of the lab. Hmmm. How do you combat this challenge?
The way I tried to address this challenge was by making lists. For
example, I have a short list of things to check for ospf and bgp.
Before leaving the IGP section, I looked at my IGP diagram and looked
for any potential virtual-link or gre tunnel requirement. Not only do
I look for the obvious v-link requirement but also a potential
requirement if the frame relay cloud went down. It's amazing how
often a v-link or gre tunnel becomes required when the f/r link goes
down. For another example, with BGP, I always used to forget
configuring the neighbor ... next-hop-self command. Before moving
from BGP, I always check, do I need to configure next-hop-self.
As my last example, if there's any task that has anything to do with
time, I automatically think "SET CLOCK". This includes acl's with
time-ranges,
logging, ntp, etc. Now, I know there's been extensive discussion her on
GS
about whether or not it necessary to set the clock if the routers are
rebooted anyway at the end of the lab and those routers without
hardware clocks will reset the clock to the default after a reboot.
But, if I see any task that relates to time in any way, I make a
beeline to the proctor.
And, of course, look for tunnel and NAT requirements. Refer to the
reachability list shown earlier. So, make your list of potential
implied requirements and look for them. Let this list be your mental
trigger.
TOP REASON # 4 people fail the lab: Insufficient checking and
verification
I used to assume that if I knew how to do something and then did it,
I did it correctly. Experience has painfully and expensively taught
me that's the wrong assumption. I now assume when it comes to
configuring routers and switches that anything I've configured IS in
some way large or small, WRONG.
In other words, I nominate myself as the world's number one ccie most
likely to make configuration mistakes. Maybe I'm a bit dyslexic.
Maybe it's because I hate configuring routers and switches. Maybe
it's because my mental wiring just isn't configured properly for
configuring routers and switches.
Whatever the reason, I suck at configuring routers and switches and
make loads of mistakes while doing so. But, yet on Wednesday I became a
ccie.
Having a deep awareness of my weakness in this area and yet being
determined and convinced of my ability to join the club, I had to
figure out a way to overcome this handicap. It wasn't easy. But,
here's what I did.
I practiced finding mistakes by using various show and debug commands.
For
example, I would misconfigured a dlci or ip address in a frame relay
map and then study how that would affect the output of the show fram
map command.
I
did the same for every technology covered by the lab. Slowly,
painfully, tortuously, I got reasonably competent at finding my
mistakes reasonably quickly. I still don't consider myself very good
at troubleshooting but, what the hell, I'm still a ccie.
So, my final words of advice to anyone wanting to be a ccie is this.
Ask yourself, "What is your level of determination to become a ccie?"
If your answer is, "I am 100% committed to this.", then figure out
what your weaknesses are and how you're going to overcome them.
If I can do this, so can you.
Tim
--------------End----------------------------------------
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Tim
Sent: Saturday, March 10, 2007 7:24 PM
To: 'Darby Weaver'; 'joshua lauer'; 'Abderrahim sadki';
ccielab@groupstudy.com
Subject: RE: Discipline and Honesty
Darby,
Shortly after I passed the lab back in August of 2005, I wrote a paper on
why people who should pass, fail the lab. I posted this paper on GS in
early September 2005.
Have a look in the archives. It may make the difference for you and others.
HTH, Tim
This archive was generated by hypermail 2.1.4 : Sun Apr 01 2007 - 06:35:52 ART