From: Guyler, Rik (rguyler@shp-dayton.org)
Date: Mon Sep 05 2005 - 12:55:59 GMT-3
John, I'm in Tim's corner on this one. The lab Blueprint I printed out
6/28/2005 has Mobile IP listed under section V "IP and IOS Features".
However, looking at the current Blueprint on CCO today, Mobile IP is now
nowhere to be found.
Rik
-----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
This archive was generated by hypermail 2.1.4 : Sun Oct 02 2005 - 14:40:14 GMT-3