From: Darby Weaver (darbyweaver@yahoo.com)
Date: Wed Mar 14 2007 - 22:18:06 ART
Actually I did this on my last attempt and I had
plenty of time to spare.
I'm more of a measure twice, cut once type of person.
And I use notepad to a good advantage as well.
Things I do across the board, I use notepad for. It
also helps me minimize my mistakes.
I do this day to day while configuring things.
I guess I'm kind of used to it.
I spent a time learning aliases, but now, I've just
taught myself to use abbreviated commands.
My way my sound like it takes a while and I allot for
it, but I've been working on my config speed and my
verification speed.
I don't think time is my issue, and I know I am not a
fast typist.
I took labs early on and just typed them into the rack
to get myself used to typing full configs and
measuring how long it took me to input a whole lab
successfully and accurately.
Once I attained confidence there that it was doable I
had to learn some things and make a lot of mistakes.
My earlier graded labs show that for what it is and I
review my scores and what I did wrong from time to
time, just to be humble and remember what it was that
tripped me up.
I spend a while searching the archives of GS, and
looking for items I may not understand and look them
up read them, and try them as well.
One by one, piece by piece, I pick up speed and the
ability to spot issues. I can spot a lot of issues
just be looking at configs these days.
Reading a given requirement, asking myself which
options are available to meet those requirement and
ruling out that are not applicable.
Some people on GS ask questions, I sometimes pick
questions out and either ask them questions or find
links or even try to break it down a bit to help out.
So, I assure you I am a certain degree faster and more
able that I was only last October and much more than
the June before that and not even a resemblence of
where I stood last January.
Still need a bit of work, but now I know explicitly
where I need adjustments.
I'll tell you being able to write a list and think of
issues that can come up within a few short minutes has
helped me considerably. Knowing which topics are on
the outline and being able to recite them helps a lot.
It all goes a long way towards knowing one's options
and one's own limitations.
I know where I am lacking. Some things are acceptable
to me, and others are not.
--- anthony.sequeira@thomson.com wrote:
> This looks like a pretty solid Checklist. And it is
> unique to many I
> have seen which makes sense because everyone seems
> to have their own
> strategy approach.
>
> I just want to point out that because I am so slow
> and deliberate at
> configurations - and my typing is terrible - I would
> never have been
> able to pass if I did everything PRIOR to
> configurations that you
> describe here.
>
> Here is what I learned to do prior to starting and
> it worked perfectly
> for me:
>
> 1. Read very closely the overall Lab Requirements.
>
> 2. Skim all of the Lab Tasks.
> a. I am looking for major issues that later tasks
> can cause for earlier
> tasks.
> b. I am getting a feel for what I am going to need
> to do in each
> section.
> c. I am getting a nice picture of the overall
> network design and
> functionality - or lack thereof!
>
> 3. Start configuring and re-diagramming (if
> necessary) Layer 2.
>
> Notice that I am configuring after about 10 minutes.
> If there are issues
> with equipment of any kind - I am running to the
> proctor about it - and
> that will still be early in the day because I will
> touch all devices
> early enough in my configurations of core lab tasks.
>
>
> I am smiling thinking about one of my dual-CCIE
> mentors who passed both
> the R/S and the Security on first tries! He
> re-diagrams the entire lab
> as he carefully studies each task. After this time
> intensive task - he
> then begins configuring off of his new diagram. As
> you might guess - he
> is one of the fastest and most accurate at
> configurations I have ever
> seen.
>
> To each his own sometimes I guess.
>
> Anthony J. Sequeira
> #15626
>
>
>
>
> -----Original Message-----
> From: Darby Weaver [mailto:darbyweaver@yahoo.com]
> Sent: Wednesday, March 14, 2007 7:50 PM
> To: Sequeira, Anthony (NETg);
> Sean.Zimmerman@clubcorp.com;
> ccielab@groupstudy.com
> Subject: Lab Strategy - Please Comment
>
> Here's some of the techniques I've picked up so far,
> mostly from Bruce Caslow, Bob Sinclair, Scott
> Morris,
> and from Brian Dennis, however I might have a few
> other tricks sprinkled in that I just like a bit.
>
>
> 1. Read the Lab - Yes the Whole Lab. - Now just
> reading it is great, since we are excited and all
> but
> what are we looking for?
>
> - Diagrams
> - IP Addressing
> - Physical Loops
> - Logical Loops
> - Issues with Split-Horizon
>
> 2. Read the Lab again - Yes I know the clock is
> ticking. But I can promise you'll find something
> you
> didn't see before and besides the more familair you
> are with the layout the better your performance will
> be later when you have that headache, yours eyes are
> sore, and you are wondering what you came for...
>
> - Again look closely
> - Draw your diagrams
> - Switch Layout VLANS/TRUNKS
> - Spanning-Tree Topology
> - Physical Diagram (Link-to-Link and IP's)
> - Watch those IP Addresses - Anything wrong?
> - Frame Relay Map - P2P, P2M, Phy.
> - IGP Diagram per-IGP (note where they meet i.e
> Redistribution (Y/N))
> - BGP Fiagram
> - Mcast Diagram
> - Make a Diagram for your points/section
>
> Task Points Y N ?
> ===========================
> 1.1
> 1.2
> 1.3
> 1.4
> 2.1
> 2.2
> 2.3
> 3.1
> 3.2
> 3.3
>
>
> OK, So you spent about 20 minutes on item number 1
> and
> another 25-30 minutes on the items in number 2. You
> still have not touched your pod.
>
> 3. Setup your icons. Now I'm kinda weird here, I
> work
> off of Notepads and I label each one per Device, ie.
> R1, R2, R3, S1, S2, S3, etc. I also prefer to work
> on
> one session and only use other sessions when I need
> them for testing. However you may like 1 session or
> tab per device. You decide.
>
> As you are setting up your icons, you should log
> into
> each device. For a few reasons:
>
> - To be sure you can.
> - To do a sh ver - Check the ver AND
> config-registers
> or if on a switch - look for env_vars and in any
> case
> look for other configs that may be there - you don't
> need them and they could hurt you.
> - To do a sh cdp neigh
> - To do a sh ip int brief
> - To setup housekeeping commands and/or aliases
> - TO VERIFY WHAT IS ON YOUR WORKBOOK IS WHAT IS ON
> YOUR RACK - If I yelled it any louder the glass
> would
> break.
> - Oh yes, and a quick sh run might be valuable to
> determine if any extra configuration is present or
> not.
> - Sometimes, I may also check anything that is
> pre-configured for me. If there are vlans, I might
> do
> a sh vlan, or if there are trunks, I might do a sh
> int
> trunk. If there were pre-configured etherchannels,
> I'd perform a cursory sh channel-group command, etc.
>
> What I am really doing is carefully inpsecting
> anything that they gave me... Not that I do not
> trust
> the proctors, but hey...
>
> - config cdp on eveything - even frame, especially
> frame - I like visibility.
> - turn on multicast and IPv6 where required -
> afterthought but it helps and besides - you did
> script
> it right?
>
> 4. Work on your layer 2 configuration and as you do
> so
> - verify link layer connectivity on a per-Link
> basis.
> Here I do things like config my VTP, Trunks,
> EtherChannel, assign ports to trunks, config my
> frame
> relay, bridging, fallback bridging,
> virtual-templates
> etc.
>
> Here are the tips for this section.
>
> - Shut down interfaces before configuring things
> like:
> trunks, frame interfaces followed by no fram inv,
> interfaces used for etherchannels, etc.
>
> - Create vlans before assigning ports.
>
> - Verify L2 etherchannel, before moving to L3
> Etherchannel which we verify as well.
>
> - Verify connectivity to the Backbone. - We may have
> to filter here one way or the other. But we need
> connectivity first. Hah!
>
>
> debug is our friend here for anything that even
> think
> it looks out of place.
>
> 5. Start configuring my IGP AS's one at a time, and
> verify connectivity per AS. router-id's (yes, I use
> them for eigrp and ospf).
>
> 6. Now configure Redistribution if and where
> required.
>
> 7. OK - Time for a TCL Script.
>
> sh ip alias, notepad, and copy/paste are the tools
> of
> the trade.
>
> Verify connectivity - should not have problems. And
> if you do you would fix them here and now.
>
> Run the Switch Macro too...
>
> 8. Repeat steps for IPv6 if required.
>
> - Intermission - Might as well reboot - Ensure
> things
> are going great. Ping script.
>
> Note: Some people say before lunch - I say after
> IGPs.
> Just me - I like to make sure things are the way I
> want them and I tend to watch the order of the boot
> as
> well and watch for things that are not like I might
> like and then I fix them.
>
> 9. Quickly complete BGP Connectivity (bgp router-id,
> no auto, no sync or not)
>
> 10. Quickly enable PIM interfaces.
>
> 11. Quickly perform any authentication on a per-link
> bassis, adhere to order of operations and then
> verify
> on a per-link and per-AS basis.
>
> 13. Ping scripts are working? Right? Try again.
> Fix
> any discrepancies.
>
> 14. Pick off easy tasks, SPAN/RSPAN, AUTOINSTALL,
> NTP,
> SYSLOG, RMON, FTP, SSH, CRASHDUMP, NAT/PAT, DHCP,
> VRRP, IRDP, GLBP, HSRP, MENU, BANNERS, etc. The fun
> and misc stuff.
>
> 15. Get Multicast working and testing.
>
> 16. Get BGP Advanced Tasks working
>
> 17. Get QoS Tasks working - would anything even
> remotely filter or break anything - Check anyway.
> The
> Scripts were working before they work now. Only
> takes
> a few minutes.
>
> 18. Security - Let's get these guys in place.
>
> 19. I know you may have questions. You have
> everything you know how to work working. So take a
> step back and breathe. Look at your work. Run the
> Scripts - BTW some labs may not require full
> reachability.
>
> Tunnels, DHCP, NAT, or FHRP may be done earlier if
> you
> think you need them to work.
>
> Ask the proctor any mind-numbing questions.
> Go back and work any sections you found difficult or
> you skipped or that were ambiguius.
>
>
> Anyway - I had a few random minutes so I thought I
> would jot this down for RouterGirl2003 and anyone
> else
> who might find it handy...
>
>
> I may have missed something, but not too much I
> hope.
>
>
This archive was generated by hypermail 2.1.4 : Sun Apr 01 2007 - 06:35:51 ART