From: Scott Morris (swm@emanon.com)
Date: Fri Mar 16 2007 - 22:39:16 ART
I always go with a "test as you go" policy. That way as I check off tasks
on my checklist (to measure my point tally) I feel more confident than "I
think I did things ok".
While I do type fast, you're right, the faster you go the more errors can
creep in. Or worse, if something goes wrong when you finally DO test
things, you really aren't entirely sure where to start looking.
Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, JNCIE
#153, CISSP, et al.
CCSI/JNCI-M/JNCI-J
IPexpert VP - Curriculum Development
IPexpert Sr. Technical Instructor
smorris@ipexpert.com
http://www.ipexpert.com
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Sean.Zimmerman@clubcorp.com
Sent: Friday, March 16, 2007 11:15 AM
To: anthony.sequeira@thomson.com
Cc: ccielab@groupstudy.com; darbyweaver@yahoo.com
Subject: RE: Lab Strategy - Please Comment
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