From: John Matus (jmatus@pacbell.net)
Date: Sat Sep 03 2005 - 01:34:46 GMT-3
oh, wow..........actual documentation from cisco. it would be nice if they
would have posted this on their site. IE actaully included ip mobile in
their volume 2 manual..........oh well :) that's good enuf for me
Regards,
John D. Matus
MCSE, CCNP
Office: 818-782-2061
Cell: 818-430-8372
jmatus@pacbell.net
----- Original Message -----
From: "Farrukh Haroon" <farrukhharoon@gmail.com>
To: "Scott Morris" <swm@emanon.com>
Cc: <ccielab@groupstudy.com>
Sent: Friday, September 02, 2005 8:47 PM
Subject: Re: Top Reasons Me & people with enough skill fail the lab
> here is the link from the archive
> http://www.groupstudy.com/archives/ccielab/200508/msg00730.html
>
> mobile ip is no more a topic for the lab.
>
> On 9/3/05, Scott Morris <swm@emanon.com> wrote:
>> It quietly disappeared from the BluePrint. So one has to wonder whether
>> it
>> was a typo (and IS still on) or a quiet way of saying "Just Kidding" (and
>> it
>> shouldn't have ever been on).
>>
>> *shrug* Can't hurt to be vaguely familiar with it and know where to look
>> it
>> up JUST IN CASE!
>>
>> :)
>>
>> -----Original Message-----
>> From: John Matus [mailto:jmatus@pacbell.net]
>> Sent: Friday, September 02, 2005 11:22 PM
>> To: swm@emanon.com; 'ccie2be'; 'John Matus'; ccielab@groupstudy.com
>> Subject: Re: Top Reasons Me & people with enough skill fail the lab
>>
>> hehe......sorry scott, merely a continuation of our NDA and isdn
>> switch-type
>> discussion :) what was the original question btw?? i'm was responding to
>> tim's suggestion that ip mobile was "not" on the exam. i don't believe
>> that
>> cisco has stated anywhere that it is "not" fair game for the exam, much
>> the
>> same way is i can say that voip is not on the R&S exam.
>>
>>
>> Regards,
>>
>> John D. Matus
>> MCSE, CCNP
>> Office: 818-782-2061
>> Cell: 818-430-8372
>> jmatus@pacbell.net
>> ----- Original Message -----
>> From: "Scott Morris" <swm@emanon.com>
>> To: "'John Matus'" <jmatus@pacbell.net>; "'ccie2be'"
>> <ccie2be@nyc.rr.com>;
>> "'John Matus'" <john_matus@hotmail.com>; <ccielab@groupstudy.com>
>> Sent: Friday, September 02, 2005 7:50 PM
>> Subject: RE: Top Reasons Me & people with enough skill fail the lab
>>
>>
>> > Why am I being sucked into this? Am I somehow the NDA Nazi? (No
>> > offense to Nazis, of course)
>> >
>> > I won't feel bad letting everyone know that I had X.25 and Decnet on
>> > my exam. While likely an NDA violation, it falls into that concept of
>> "BFD"
>> > kinda like "IP" being on your exam. However, the original question
>> > was specific. In fact a bit TOO specific which is (I believe) how we
>> > got where we are now.
>> >
>> > *shrug* I'm going back to kicking someone's ass at Internet Reversi.
>> > ;)
>> >
>> > Scott
>> >
>> > -----Original Message-----
>> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
>> > Of John Matus
>> > Sent: Friday, September 02, 2005 10:43 PM
>> > To: ccie2be; 'John Matus'; ccielab@groupstudy.com
>> > Subject: Re: Top Reasons Me & people with enough skill fail the lab
>> >
>> > is it an NDA to discuss "topics areas" that appear on the exam? for
>> > instance, can i say that "IP" may appear on the exam?....what about
>> > being so bold as to say "yes, i had IP on my exam". probably the
>> > later is a
>> > violation but not the former. scott? whaddaya think?
>> > if one says that IP "may" appear on the lab, can another candidate
>> > logically infer that IP does and will appear on the test? that is
>> > probably inductive rather than deductive and probably hence no a
>> > violation, unless cisco's NDA covers inductive references or other
>> > matter of relative truth.
>> >
>> >
>> >
>> > "when asked if ip mobile would be on the exam, the buddhist master
>> > knocked twice on the table"
>> >
>> > "if ip mobile might appear on the exam...don't knock twice on the
>> > table!"
>> >
>> >
>> >
>> > Regards,
>> >
>> > John D. Matus
>> > MCSE, CCNP
>> > Office: 818-782-2061
>> > Cell: 818-430-8372
>> > jmatus@pacbell.net
>> > ----- Original Message -----
>> > From: "ccie2be" <ccie2be@nyc.rr.com>
>> > To: "'John Matus'" <john_matus@hotmail.com>; <ccielab@groupstudy.com>
>> > Sent: Friday, September 02, 2005 4:46 PM
>> > Subject: RE: Top Reasons Me & people with enough skill fail the lab
>> >
>> >
>> >> John,
>> >>
>> >> This was posted on Group Study not that long ago and I also saw it
>> >> somewhere on Cisco's web site but can't find it now.
>> >>
>> >> Did you do a search for mobile ip in the GS archives?
>> >>
>> >> Tim
>> >>
>> >> -----Original Message-----
>> >> From: John Matus [mailto:john_matus@hotmail.com]
>> >> Sent: Friday, September 02, 2005 6:00 PM
>> >> To: ccie2be@nyc.rr.com; ccielab@groupstudy.com
>> >> Subject: RE: Top Reasons Me & people with enough skill fail the lab
>> >>
>> >> tim,
>> >> what leads you to believe that mobile IP is NOT on the lab. (i'm not
>> >> sure that it would be a violation of the NDA to say what might lead
>> >> me to believe
>> >>
>> >> that is IS on the lab)
>> >>
>> >> john
>> >>
>> >>
>> >>>From: "ccie2be" <ccie2be@nyc.rr.com>
>> >>>Reply-To: "ccie2be" <ccie2be@nyc.rr.com>
>> >>>To: "Group Study" <ccielab@groupstudy.com>
>> >>>Subject: Top Reasons Me & people with enough skill fail the lab
>> >>>Date: Fri, 2 Sep 2005 12:12:18 -0400
>> >>>
>> >>>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
>> >>>
>> >>>_____________________________________________________________________
>> >>>__ Subscription information may be found at:
>> >>>http://www.groupstudy.com/list/CCIELab.html
>> >>
>> >> _________________________________________________________________
>> >> Is your PC infected? Get a FREE online computer virus scan from
>> >> McAfeeR Security.
>> >> http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
>> >>
>> >> _____________________________________________________________________
>> >> __ 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
>>
>> _______________________________________________________________________
>> 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