Re: Not a happy ending ... I came up short.

From: Iwan Hoogendoorn <iwan_at_ipexpert.com>
Date: Fri, 30 Oct 2009 09:23:13 +0100

Hi,

Great post man ... too bad you did not make it...
Next time another chance I guess...

-- 
Regards,
Iwan Hoogendoorn
CCIE #13084 (R&S / Security / SP)
Sr. Support Engineer  IPexpert, Inc.
URL: http://www.IPexpert.com
On Fri, Oct 30, 2009 at 5:13 AM, ALL From_NJ <all.from.nj_at_gmail.com> wrote:
> Hey team,
>
> I was hoping for a better post ... Yesterday I took the lab and failed.
> Some thoughts and comments, and hopefully you all will find these helpful.
> Sorry for the long post.
>
> *** OEQs - passed this part.
>
> - I found these to be fairly interesting.  3 were pretty easy and 1 was a
> bit hard IMO.  The hard one really belonged to another CCIE track, and not
> the R&S ... I gave it my best guess, but since I was not studying for this
> technology, I am not sure of the answer.  I suppose that one could argue
> that I should be aware of this hard question ..., and I was a little bit,
> but I certainly was not studying for it.
>
> - From my experience with the OEQs, I found these to fall in line with many
> of my lab testing and feature testing I had done in my preparation.  If you
> like to test a protocol and verify your work, then you will have no problems
> with the questions I had.  Simple memorization would have been hard to do.
> Example of what I mean (this was not on my lab and this is only an example
> of what I mean)
>
> Example: lets say that you are studying trunking and you want to practice
> configuring one side and not the other.  Looking at the config options with
> the trunk protocols and port modes, what would happen if you only configured
> one side?  What happens if you misconfigured one side?  What happens if you
> have misconfigured duplex and speeds?
>
> In my case, I have learned a lot by using debugs and misconfiguring things.
> You all know that when things do not go right, you will learn a lot.  It is
> easy to forget the labs you did when everything worked.
>
> So to continue following this example - if you were asked about a trunking
> config or about a trunk operation for a OEQ, you would probably get this
> question and think it was easy.
>
> For the 3 'easy' questions I had, I found that my normal study habits
> covered these nicely.
>
> I do wish Cisco would get rid of these OEQs all together however, they are
> not worth the time IMO, and do not really ensure 'only-experts' pass.  A lot
> of 'hit-or-miss' in these questions and my feelings are that some experts
> have failed the lab because of these, and I think these people should have
> passed.  Any who ...
>
> *** Troubleshooting section - I failed this section since I had not
> completed enough tickets in the time given.
>
> It was very disheartening that before lunch I knew my whole trip was a
> failure.  I simply had not completed enough tickets given the time.
>
> Most of these were similar to what I have labbed, however, a few of these
> were odd IMO and I did not even think of these for an R&S / enterprise type
> ...
>
> The wording of the problem is purposely vague, and the router access was
> clumsy.  I think the screen could be partitioned and presented in a much
> more clear way.  It is very easy to look at the diagram and get lost and or
> confused.  I got the feeling that Cisco is trying to do too much with one
> screen, and i would suggest that the screen be broken up some /
> partitioned.
>
> Overall, I liked the idea of having a troubleshooting section ...
>
> Putting the confusion and wording aside, you have to study very hard for
> this section.  I figured since I have done a fair amount of tshooting in the
> past and in my studies, that I would find this section an easy addition.  I
> also consider myself decent with the core technologies and some of the new
> 'non-core' lab items, so I was looking forward to this.
>
> My approach does not work.  One reason this does not work is because the
> questions are so vague.  An example that was previously shown by Cisco was
> "router X cannot communicate with router Y".  How to troubleshoot this
> quickly?  There are a few routers and or a frame relay network in the middle
> of the two end points ...
>
> Lets say you start with a ping and the ping fails, ok ... you verified that
> the trouble ticket are real trouble tickets.  Ping does not get you much in
> this environment ... so is the problem an IP address misconfigured on the
> end point routers or a router in the middle, an interface shutdown, a
> routing protocol configured wrong, etc ... how to start and find this
> quickly?
>
>  If you have 12 tickets in total, and you need to pass this section, then
> you need to solve about 9 or so ... Try to solve them all ... make sure you
> have some 'padding' in case one of your other solutions is not the right
> one.  My advice would be to solve as many as you can.
>
> You have about 11 to 13 minutes per question.  I found this section hard ...
> and did not pass this section.
>
> I wish the troubleshooting section could be included in the regular lab.
> This way you would solve the tickets as well as build your lab at the same
> time.  Any who ...
>
> *** Configure section - I failed this part as well.
>
> I agree with what others have said.  You have around 5.5 hours and an
> enormous amount of information to get through.  It seems like they have
> taken a normal lab and just reorganized it and now give you less time to
> solve it.
>
> Please forgive me for suggesting this, but ... in order to pass the config
> section, I almost feel as though you need to memorize commands and spit out
> the configs quickly.  No time for doc cd, and limited time for the '?'.  I
> think it is a terrible idea to blindly memorize materials ... but I cannot
> think of another way to answer a huge amount of material in just a little
> over 5 hours.
>
> Does this mean that being a CCIE requires you to have an amazing memory?  I
> hate to say it, but I think Cisco is missing it on this.  I do not think
> this format allows for a lot of individual creativity and style ... I think
> you will have to fit whatever mold is required.  Perhaps that is a good
> thing anyway, maybe ... I just think that the config section will force
> people to memorize technologies.  I would like to see differences in people
> and also still allow for different approaches and styles.
>
> Sorry team, I know I am not communicating this very well, and in fact I do
> not like the way this sounds.
>
> If I am to plan my next take, I will make sure that I can spit out the
> "non-core" commands quickly, as well as the 'extraneous' and obscure tweaks
> to each of these non-core topics ... I would need to do this super fast
> since time is so tight.  We used to have the doc cd for these obscure items
> ... maybe you can still rely on the doc cd, and you should know how to find
> everything super quick.
>
> What is core and non-core?  <-- ... IMO, this has not been communicated
> properly yet ...
>
> I think that my lab was really more of a network admin lab, and less like a
> 'set up an advanced and insane network'.  What does this mean in terms of
> lab topics?  Well ... look at the lab blueprint, and think about which items
> are 'on-going' and admin work.  Study the heck out of these ...
>
> My lab had some new topics on it, of course it was the new version; makes
> sense ... Lord knows I do not want to break the NDA here ... so I am trying
> to tip toe this topic carefully ...
>
> Let me just say, it is my opinion that you cannot pass without knowing the
> non-core topics.  Does this make sense?  Probably not ... what I think has
> happened is that the lab has shifted its core.   From what used to be
> advanced network set up, R&S, ... to more of a network admin role.  This is
> also what Cisco has told us.
>
> Folks - think back to what Maurilio has told us and the extensive research
> that Cisco did when re-designing the R&S CCIE.  Cisco found out that
> companies are not looking for network set up, but more of an ongoing
> maintenance, monitoring, troubleshooting, etc ...
>
> So this means less focus on what we used to think was core; folks, I cannot
> emphasize this enough.  I was very disappointed to find that what I had
> previously considered to be the traditional R&S core topics are not really
> core anymore ... in fact, my studies were off.  Cisco told us that the
> version 4 lab had changed its focus ... I guess I did not fully understand
> what this means in terms of prep work.
>
> Team - as mentioned above, look over the blueprint again and consider those
> items which represent this change in focus and study the heck out of them.
> (the non-core is now core topics).  Of course you have to know the "core R&S
> topics" ... but you will not pass without knowing the "new v4 core" (AKA
> non-core).
>
> Back to the earlier question ... what is core and non-core?  Another way of
> looking at this question is ... "can I pass without knowing the non-core
> topics?"  As others have mentioned in their v4 reviews, everything on the
> blueprint is fair game.  Ok ... we already knew this, and team, I hope this
> is becoming clearer.
>
> Do not make the same mistake as me and think that the R&S is a routing is
> switching lab ... the focus has changed some as Cisco told us.  I hope this
> message is getting out.
>
> 'nough said about that.
>
> A little about my prep work.  I have used the ASET labs, and these are
> great.  These helped me a lot in the CCIE v3 topics.  I was able to get
> through many of these in 6 hours or so ... and get 90%+  in scores.  I
> thought I was ready for the CCIE lab and everything seemed to be on target
> for my lab!  As mentioned above however, I did not fully understand the
> change in focus and how the non-core items have become core.  I also used
> CCBOOTCAMPs v3 materials, and I enjoyed these a lot.  I was completing these
> fairly well in my studies.
>
> I am sorry to be so confusing in my writing.  I hope what I have said makes
> sense.  Please also go back and re-read what Cisco has told us about the new
> v4 design and new topics.
>
> Also team, I hope to avoid a  word smith  exercise with any of you about
> what the word  core  means.  I am sure that this word has many meanings to
> many people.
>
> It is getting late and I am sure my ramblings have become long winded
> please permit a few more (then I promise to be done with this email)
>
> A suggestion to the vendors who are on this list.  I might suggest to take
> an 8 hour lab and fit it into a 5.5 hour time frame.  Please also consider
> the change in focus that Cisco told us about and ensure that there are
> plenty of additional items in the labs you create.  Remove some of the
> routing and switching portions and make sure you include extraneous and
> obscure non-core topics.  We have to be an expert in everything of course
>
> You all are very sharp, all of you, and so I am probably not telling you
> anything you do not already know.   Rock on vendors!
>
> For the Cisco partners, the change in focus is good for enterprise customers
> who need more of a network admin focus / role   and does this fit your
> business model?  What do Cisco partners want in a CCIE?   Is this
> represented in the new v4 format?  If not, I would suggest to voice your
> comments as it is important to both partners and enterprise customers.  Very
> important to voice your comments / praise / concerns.   Just a thought  .
>
> Team   pardon the delays in my next responses.  After having put many things
> on hold, I have an immediate honey-do list to take care of.  I have some
> work to do around the house before I can consider how I will take this on
> again   oh boy, it is fall in NJ and so I have mountains of leaves to attend
> to.  My aching back!
>
> Lol   have a great night team.
>
> --
> Andrew Lee Lissitz
> all.from.nj_at_gmail.com
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net
Received on Fri Oct 30 2009 - 09:23:13 ART

This archive was generated by hypermail 2.2.0 : Sun Nov 01 2009 - 07:51:01 ART