From: Darby Weaver (darbyweaver@yahoo.com)
Date: Fri Mar 16 2007 - 13:07:29 ART
And notepad is my bestest friend...
I use it extensively. However, I am by no means a
fast typist...
I'm not sure where the idea of rushing anything came
in.
I used to type configs into routers and even notepad
just to ensure it could all be done in the time
required and done accurately. But that is a different
story and time actually.
:)
--- Darby Weaver <darbyweaver@yahoo.com> wrote:
> Do I write that badly?
>
> I think I actually configure and then test as I go
> for
> each item.
>
> Maybe I wrote it wrong...
>
> But that is how I work.
>
> Now I do tend to look first before I leap these
> days.
> I like to ask myself little questions as I go and I
> try to reason through my options.
>
> Now maybe when I write these things down it does not
> quite come out so crytal clear. But all in all, I
> do
> work towards a plan with a goal in mind.
>
> I setup trunks, etherchannel, assign vlans (link
> layer
> is tested per link) and frame relay (again per link)
> I build link layer connectivity.
> I build per-IGP connectivity
> I configure redistribution.
> I ping scan with script.
> <NAT, DHCP, HSRP, etc. may be required if so I
> account
> for it>
> I build IPv6 as required - again connectivity per
> link
> and per protocol and with redistribution if asked
> for.
> I build my bgp connectivity.
> I build my multicast only after all of the above are
> working.
>
> Then I tend to worry about adding features such as
> MD5, filters, QoS, other security aspects etc.
>
> I guess I need to read my own words again...
>
> But this is how I work and I thought I was making
> pretty decent time with time to spare (a couple of
> hours or so).
>
>
>
>
>
> --- Sean.Zimmerman@clubcorp.com wrote:
>
> > It seems to me that you could either fly through
> the
> > exam as fast as
> > possible, then go back and correct, or take
> > Anthony's approach of slow
> > deliberate config and back check tasks such as
> ACL's
> > that could affect
> > previous tasks. I type very fast, but I noticed
> that
> > my mistake rate goes
> > up significantly when I rush.
> >
> >
> >
> > <anthony.sequeira@thomson.com>
> > 03/14/2007 07:20 PM
> >
> > To
> > <darbyweaver@yahoo.com>,
> > <Sean.Zimmerman@clubcorp.com>,
> > <ccielab@groupstudy.com>
> > cc
> >
> > Subject
> > RE: Lab Strategy - Please Comment
> >
> >
> >
> >
> >
> >
> > 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