From: David Prall (dcp@dcptech.com)
Date: Fri Mar 16 2007 - 23:05:36 ART
If I've never broken it, how will I know how to fix it.
On one of my labs, I had everything configured and working before lunch. I
had everything tested and was thinking I was going to get to leave after I
finished lunch, afterall it was paid for. Then I noticed something. I
completed everything using the rack number from my previous attempt. Thank
god for notepad, was able to correct it just as the proctor called for
lunch. I spent the entire afternoon going over the configs in their
entirety, writing down very detailed notes about things I was concerned
about. I decided not to go back and make any changes at that point.
I'd recommend changing your addressing scheme a couple of times when you do
labs. So that you don't get caught doing something like this.
David
-- http://dcp.dcptech.com> -----Original Message----- > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On > Behalf Of Scott Morris > Sent: Friday, March 16, 2007 9:42 PM > To: Sean.Zimmerman@clubcorp.com; anthony.sequeira@thomson.com > Cc: ccielab@groupstudy.com; darbyweaver@yahoo.com > Subject: RE: Lab Strategy - Please Comment > > It may also simply be attributed to "experience" the more you > do something, > the more rapidly you'll be able to recall, adapt and execute > something. > Think about how you handle day-to-day tasks in your network > today compared > to when you started.... > > Same? (Doubtful) Faster? Yup... Yet, you're still > basically the same > person! > > While it not entirely impossible that some people are simply > geniuses, for > the rest of us it's better to simply attribute it to > experience! Break > something today. Fix it tomorrow. Know it forever, and > don't break it > again! :) > > > 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:47 AM > To: anthony.sequeira@thomson.com > Cc: ccielab@groupstudy.com; darbyweaver@yahoo.com > Subject: RE: Lab Strategy - Please Comment > > I've met one of those very fast people at an IPExpert > boot camp. > He was from Croatia and english was his 2nd language which would be a > disadvantage, but he'd fly through the practice labs at an > almost superhuman > pace. He'd be asking a question about BGP (at the end of the > lab) before I was done with IGP. I think I saw a message from > him that he > passed on his first attempt. Well deserved, but I'm thinking > he was an alien > or Einstein's genetic double at least from a brainpower and speed > perspective. > The best I can hope for is an hour at the end of the lab for > verification. I can type very fast, I copy and paste from notepad > extensively, and I just don't understand how anybody can get > through the > tasks so quickly. It's like seeing someone run 50mph. Truly amazing. > > Sean > > > > <anthony.sequeira@thomson.com> > 03/16/2007 10:35 AM > > To > <Sean.Zimmerman@clubcorp.com> > cc > <ccielab@groupstudy.com>, <darbyweaver@yahoo.com> Subject > RE: Lab Strategy - Please Comment > > > > > > > As slow as I am (in more ways than one) here was the overall > time breakout > for me on my passing version of the lab: > > 15 minutes until I started configuring > Config, Test, Troubleshoot > 45 minutes for error checking at end of day > > The 45 minutes of checking at the end may have indeed passed > me b because I > did catch some issues. > > I have heard stories of people passing and they finished just > after lunch b > including error checking. I have also heard that there might > be alien life > forms walking amongst us. If A is true, then I think B might > also be true. > > Anthony J. Sequeira > #15626 > > > From: Sean.Zimmerman@clubcorp.com [mailto:Sean.Zimmerman@clubcorp.com] > Sent: Friday, March 16, 2007 11:15 AM > To: Sequeira, Anthony (NETg) > 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. > > ______________________________________________________________ > _________ > Subscription information may be found at: > http://www.groupstudy.com/list/CCIELab.html > > ______________________________________________________________ > _________ > Subscription information may be found at: > http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sun Apr 01 2007 - 06:35:51 ART