From: Jeffrey Fry (Jeff@FryGuy.Net)
Date: Wed Mar 14 2007 - 21:42:22 ART
Another added idea.... don't forget to save your lab after each section.
You never know when you may run across unexpected environmental issues.
Also - this may sound a bit weird - leave and get some water before you
start the lab. This will allow you a few moments before the lab to calm
down, relax, and ignore all the other people who may be madly typing
away at the test when they first get there.
I did this on my last attempt and felt that it helped. I was much more
calm in my approach at the lab.
Jeff
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Craig Tompkins
Sent: Wednesday, March 14, 2007 8:16 PM
To: Darby Weaver
Cc: ccielab@groupstudy.com
Subject: Re: Lab Strategy - Please Comment
With number 1 - make sure your lab and your topology diagram, match the
initial equipment setup. Basically make sure you were given the right
lab.
Yes it does happen that some people get the wrong labs. Happened to me,
probably doesn't happen often, but I would assume it might be a bit
unnerving to some people, to spend 50 minutes on diagramming and reading
only to find out that they have the wrong lab.
On 3/14/07, Darby Weaver <darbyweaver@yahoo.com> wrote:
>
> 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