All,
As promised here are the questions and my answers, and also since several list
members asked about strategy I’ve added a couple sections on both study and
lab. Finally I have included a lessons learned section. All of the following
is based on my experiences preparing for, and sitting the exam and are in no
way representative of what someone else should necessarily do. If they help
you, great. If you have a better or alternative method, by all means please
help the other list membership by posting it. This is what finally allowed me
to pass the V3 lab and hopefully it will aid others in their efforts to do the
same.
Q&A I have rec’d and responded to:
1. q. How have the proctors adjusted to the V3 lab content? Are they familiar
with it or has anyone encountered confusion or bewilderment on behalf of the
proctor due to the new content in lab?
a. I asked a few questions of one proctor – none were terribly technical that I
can recall, but he was able to answer them immediately and clearly, which
implied to me that he was quite familiar with what I was asking about.
2. q. Do you work with Voice more than any other "area" of Cisco technology?
a. Yes I have worked voice - primarily Cisco voice products since 2000. In the
last two years it has been exclusively voice. Working with it in the field
helps develop troubleshooting techniques and a deeper understanding of the
product set system wide, but you also develop habits that don't necessarily
transport to the lab well.
3. q. Your history is much like mine, I've taken V1, V2 and now heading toward
V3. Can you tell me what you changed in studying that allowed a pass this time?
a. I will cover this below in the strategy section below
4. q. I do want to know how long you studied every day, my family is starting
to get annoyed by my lack of just being there (lights on but nobody home) when
I’m home labbing. How did you cope? Lots of coffee, monster drinks, redbull?
a. This is a tough subject and I had it easy by comparison to many on this
list. Since it spanned five years it went in spurts and starts – and yes my
family did get annoyed at times, but luckily my employer was supportive through
the entire gig and when I wasn’t billable I was able to study during the day.
Towards the end they also took me off of availability and allowed me to prepare
full time. Generally I would lab for about eight to ten hours starting at
6:00AM and then do another 2 to 3 hours of research and technology work after
that – or until my brain shut down. Let's face it - what you ask about is time
management - it's a big part of the lab preparations as well as the lab itself.
I don’t consider myself an expert on this at all – perhaps other folks can
contribute thoughts/strategies?
5. q. What is the equipment list of you home lab?
a. Please see below – I have no home lab.
Training Resources
I used IPExpert/Proctorlabs and this list as my sole providers of certification
materials and instruction other than materials on CCO. I signed up for their
end-to-end program last year and sat two of their instructor led boot-camps
(the second time free – per their guarantee). Both classes were very valuable
in my overall preparation – not only for the technical information gathered but
for the lab strategies and information/analysis of the CCIE Voice sections of
Cisco Live. I attribute a good deal of my success in passing this round (V3)
to the materials and instruction from IPExpert, as well as all of the V2
materials that are still applicable. I also would like to recognize Vik Malhi
for helping me adapt my field deployment habits to effective lab execution
routines.
Equipment
I utilized a mix of Proctorlabs racks and a shared company rack that had 2800s,
3800s, a 3745, UC500 and a 7845 with 8gig fully loaded disk and VMware ESX for
the five servers needed for V3. For some exercises the proctorlabs racks were
more appropriate. We are utilizing our old Unity 4 box from the V2 lab for
the AD/LDAP integration for V3. I had no home lab since my V1 attempts.
Preparation Strategy etc.
1. If you haven’t already, figure out your weak points. Mine are speed and
stress related mistakes. I never conquered my speed issues but the new lab has
some aspects that I will delve into that helped reduce the need for brute speed
on the console – for those of us lacking that talent. I took other measures to
mitigate my stress related problems, but they still plagued me.
2. When I came to the conclusion I was not going to get one last chance at V2
in late May I concluded that I would need to reset my study habits
significantly to account for the change. The first thing I did was to get OFF
the gear and read – the SRND, the CCM7 System guide, Features and Services
(F&S) guide, and the CME Administrator guide. Along with these add a number of
other documents like the SIP SRST administrator guide, gatekeeper technotes,
etc.etc.etc.. Although I had considerable experience designing and
implementing the Cisco UC solution in the field that does not necessarily give
you the opportunity to become a true “expert” on the gear – that kind of time
is just not generally available in a competitive bid world. In many cases you
build a best practices solution to fulfill the customers’ requirements without
going out of scope – which means you don’t explore off the beaten path most of
the time. Cisco has done an excellent job documenting the gear and software in
the lab – although you should not plan on utilizing the detailed documentation
to any great extent it behooves you greatly to be able to get to it immediately.
Out of this extensive reading exercise I was able to derive the following
benefits:
a. For the purpose of greatly reducing my errors while configuring various
features on CCM I became very familiar with finding the “configuration
checklist” at the beginning of every section in the F&S guide. I did NOT use
these sections to do the configuration – only to check my work so that I would
not overlook a small but critical step – they are generally 1-2 pages in length
and easy to locate for barge/cbarge/AC/IPMA/etc. These were especially useful
to me since some configuration details have changed for most features and
services between V2 and V3. Normally I would access the checklist only after
configuration – and only if basic testing failed.
b. I did the same with SIP documentation for SRST/CME/MWI/etc. Locate the
documents and related configuration examples so I would not leave out a
critical command. Again knowing where these are located for rapid retrieval
but only using them if a test failed.
c. The reading also helps to acquire knowledge for the OEQs – but you should
not expect the documents listed above to totally prepare you for them, and you
will have access to no documentation during the OEQ phase.
3. After reading and really familiarizing myself with the materials that would
be available to me in the lab I did run a number of timed labs (which I was
never able to complete) and quite a few technology practice sections – which
were based on particular devices that I did not have a clear understanding of
when trying to configure or troubleshoot issues during a lab. In prior
attempts I would stay very focused on the task at hand and not allow myself to
wander “off into the weeds” when I came across things that might cause me to
explore out of the bounds of the immediate subject at hand. This time I did
the opposite, and gained a much deeper understanding of the system as a whole.
4. Along that same line – you must learn the individual components by
themselves initially, but you also must understand very intimately how they
work with each other as a system or you won’t stand a chance. If you work on
learning BOTH aspects you will start to recognize many cause and effect
situations and their symptoms (no codec invoked, correct digits not passed,
etc.). There is NO shortcut here, at least none that I could find.
5. Study and practice all of the dial-plan components – both new and old. The
SRND gives good coverage to + dialing, and there are all the calling number
transformations, CSS’s etc. Read about them and then start “playing” with them
in different scenarios – put a transformation on at the inbound gateway –
change it again incoming to the phone or device and see how it impacts CDRs and
other logs. The new calling and called CSS and transformations are more or
less just extensions of the tools we had before, so if you have a good grasp of
PTs and CSS and transformations you should be able to conquer the new
constructs with some practice.
6. Leverage V2 materials and labs – although there were significant
enhancements in the jump from V2 to V3 much of the core functionality of all
the products is still basically the same, so the materials are still very
useful. You will very likely see some of the same scenarios since they cannot
re-write V3 completely from scratch.
7. Don't rush into the lab unless you feel really ready. One caveat - if you
want a $1400 lunch to see what it is like that is certainly understandable, but
don't do six times like me. I felt like I got hit by a bus, woke up, stood up,
got hit by a bus, woke up, stood up, hit by a bus.....you get the picture ; ^))
Lab Strategy
1. Of course the basics – read the lab from start to finish and note important
items – IP addresses and DNs you will be using repeatedly and other important
data. I also made note of whether I would have certain features to be aware of
during the entire lab (AAR, etc.) and things like QoS and even MWI breakers
(but don’t go overboard just make mental notes). IPExpert helped me a bunch in
this area.
2. The OEQs are your friend. If you know your VoIP and IPT trivia (not minutia
though) you will very likely be fine – they are very doable. Where else can
you pick up 21 points in less than 30 minutes? I believe that the time I
picked up here was the only reason I passed, because it gave me time I never
had in V2 to go back and find bugs (and fix stupid mistakes) and of course I
could move and think at a reasonable pace.
3. Pay attention to the small stuff - not that I was completely successful
with this, but it was an important part of my strategy and if I had effectively
engaged the strategy it would have been much less stressful (see “stupid
mistakes in lessons learned below).
4. Test – during or after – in most of my previous attempts I tried to test at
the end, but since I ran out of time my score reports were, well, depressing.
This time I decided to do fairly complete (not over the top) testing as I went.
It worked out well for me – when I did find a problem I had just gone through
the section in question and it was fresh in my mind. I did leave and come back
to a few (over and over) because I also would spend 10 minutes at most and then
force myself to move on. I ended up fixing almost all of them eventually – I
think I was working on them in the back of my mind the entire time
5. Take the easy points and make sure they are solid. Leave the things you
don’t feel comfortable with, or that will potentially “break” other things.
Come back to those when you are sure all of your gimmes are in the bank, and
only go after them if you are sure they won’t break your safe point sections –
or if they will make the difference between passing or not.
6. Try and keep a running count of what you need – what is left on the table?
This helps prioritize your tasks.
Lessons Learned
1. Know your tools – Don’t take for granted that you will have every tool that
you are used to using in practice. You may need to use something different to
see DNs being passed between devices, or to log on in a different way than you
normally do. Again I was not totally prepared here and ended up digging
through documentation to find things that I should have already mastered.
2. Don’t give up – About halfway through the lab things looked pretty bleak. I
had gotten hung up on a stupid mistake that cost me a good deal of time, and in
V2 would have sunk my ship. I decided to just keep hacking away section by
section on the ones I felt I could get the points (I did leave some on the
table).
3. This brings me to stupid mistakes you should avoid (and I didn’t). Don’t
take anything for granted no matter how many times you have performed them in
practice, no matter how small and insignificant – all it takes is a single
fat-fingered infrastructure address or omission and things just won’t work.
This stung me in prior attempts (again the stress) and they got me again on
this one, but luckily I had a bit more time to recover.
4. Check all of your interfaces in the final half hour to make sure NOTHING is
shutdown. As you go through the day you may shut a FR I/F for SRST or a PRI
for least cost routing or redundant routes – make sure they are all back up.
It is easy to leave them down after testing. I found one that I had left down
– by accident, in the last hour.
Hope this helps,
Art Sandborgh #25081
_________________________________________________________________
Get back to school stuff for them and cashback for you.
http://www.bing.com/cashback?form=MSHYCB&publ=WLHMTAG&crea=TEXT_MSHYCB_BackToSchool_Cashback_BTSCashback_1x1
_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit
www.ipexpert.com
