From: Thomwin Chen (thomwin_chen@yahoo.com)
Date: Fri Sep 02 2005 - 13:04:07 GMT-3
Excellent tips TIM !!
thanks
ccie2be <ccie2be@nyc.rr.com> wrote:
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
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Gustavo Novais
Sent: Friday, September 02, 2005 5:59 AM
To: Cisco certification
Subject: Went yesterday to Brussels
Hi,
I went yesterday to brussels, and did the RS exam. All went well, I did
all the exam with the exception of a 2 point question, everything was
fine, I thought I got all the tricks, I was all excited on the plane
back home, nevertheless I've failed. :(
I kept thinking about the exame and I think I would do everything the
same way, I kept annoying the proctor with questions on which I had
doubts interpreting, just to not let anything pass unseen.
I am at the stage where I think that studying one more month would not
do any difference on that exam, the difference is on how the decisions
are made, and whether or not it will cost you points.
So, I'd like to share with you some errors that I did that I think that
costed me points.
- Do not do anything that they didn't specifically told you to ---
example: a preempt on a HSRP group active router. You may think of it as
a best practice (if we want it to be active as much time as possible,
but if not said in the lab...)
- Be as specific as possible when allowing/changing policies on your
network --- example: Even if no other BGP peer, do not just set weight
to the peer indiscriminately if not specifically told so. Even in QoS,
beware match any.
- ISDN can be ambiguous in wording - try to get as much information from
the proctor as possible.
- KISS - Keep It Simple and Stupid - DO NOT GET FANCY
I'd like to ask for your opinions on that, and complete the list, just
to see if we can once and for all dominate the Cisco way of doing things
Thank you
Gustavo
This archive was generated by hypermail 2.1.4 : Sun Oct 02 2005 - 14:40:13 GMT-3