From: Amit Jain (netsteps@rediffmail.com)
Date: Fri Sep 02 2005 - 12:35:55 GMT-3
I have flagged this one. TOP POST.
Amit
----- Original Message -----
From: "ccie2be" <ccie2be@nyc.rr.com>
To: "'Gustavo Novais'" <gustavo.novais@novabase.pt>; "'Cisco certification'"
<ccielab@groupstudy.com>
Sent: Friday, September 02, 2005 7:53 PM
Subject: RE:Went yesterday to Brussels (How I overcame my weaknesses)
> 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
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sun Oct 02 2005 - 14:40:13 GMT-3