RE: Lab Strategy - Please Comment

From: emad fahmi (emad_fahmi123@yahoo.com)
Date: Sun Mar 18 2007 - 07:55:03 ART


i have had my CCIE last january and i finished 6.5 hours and had 1.5 hour ro revise
  Well the cluse here is to give everything its time and not to begin typing before you correct all the errors at the beginning
  Well i did about 28 remote labs and my speed was ok but i did not find anyone finishing before lunch
  i almost took my time in Switching and iGP (i finished them before lunch )then the rest went so fast cause the base was ok
  i trained myself many times in real tests and i almost finished at the same time so do not fear the reality of the test cause it is like the same remote labs u always do
   
  Emad Yousry Fahmy
  CCIE #17388

David Prall <dcp@dcptech.com> wrote:
  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 > > > > > 03/16/2007 10:35 AM > > To > > cc > , 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. > > > > 03/14/2007 07:20 PM > > > To > , , > > 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