This is what I did only on my third attempt and finally passed. Each ticket, take 2 minutes to find the FAULT (note: not solve). If you don't find the FAULT within 2 minutes, move to the next ticket. Keep cycling through tickets until you find faults. Then take 3-4 minutes to solve. Again, after 3 minutes- move on. Keep cycling through, rinse, repeat. I also skipped tickets that were larger point values on my first cycle through.
Sent from my iPhone > On Dec 21, 2013, at 5:05 PM, Bob McCouch <[email protected]> wrote: > > I always just went through a checked all the interface IPs and masks (seem > to be a common place to inject a fault) and also look for some other things > that would typically be a mistake in the lab like "no ip cef" or "no ip > routing". > > On my second (successful) attempt, I only found one of two after about 15 > minutes so I had to move on. I did find what I'm very confident was the > injected fault a little later on when a feature wasn't working. > > I guess my strategy was to do a really fast first pass to check the most > likely things, and then after 15 mins just trust that I'd find the other > one as I went. Those were my least-favorite tasks, since it was basically > impossible to *know* that you completed the task correctly. > > >> On Tue, Dec 17, 2013 at 9:24 PM, Donald Robb <[email protected]> wrote: >> >> My take is that generally the first thing I do when starting a lab is read >> through the exam then verify basic connectivity between Routers on a >> segment >> while I'm at it I check the IP address and mask against the diagram. Also >> I >> verify the vlan assignments, vtp status/password, and check trunk links. >> >> It'll probably take you 15-20 min but you'll probably find most if not all >> the errors and also have a good feel for the network as well as have >> confidence that there is not any hardware faults etc. >> >> Cheers, >> Donald Robb >> Productive Networks / Network Consultant >> >> CCIE Written, CCIP, CCSP, CCDP, CCNP: R&S/Security, CCNA: Voice, JNCIP, >> SCP, >> MCSA 2012, VCA-DCV, CCA: XenApp 6, Security+, CCSE.R65, PACE >> >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Mills, Derek >> (NAZ-V) >> Sent: Tuesday, December 17, 2013 8:18 AM >> To: '[email protected]' >> Subject: [OSL | CCIE_RS] Finding pre-configured faults... >> >> I'm curious to hear what the group's strategy is on finding pre-configured >> faults. I find that I can waste a lot of time if I go searching for them. >> On >> the other hand, by virtue of configuring the tasks in the lab I seem to >> inevitably find the faults when troubleshooting a task configuration later. >> Usually, they are the first or second thing you check when you don't have >> reachability or when a EIGRP neighbor won't come up, for example. They >> really don't end up costing me time because I find them fast when >> troubleshooting a technology. >> >> What is your take on it? >> >> >> >> ---------------------------------------------------------------------------- >> >> ---------------------------------------------------------------------------- >> >> ---------------------------------------------------------------------------- >> ---------------------------------------------------- >> Anheuser-Busch InBev Email Disclaimer www.ab-inbev.com >> _______________________________________________ >> Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: >> >> iPexpert on YouTube: www.youtube.com/ipexpertinc >> _______________________________________________ >> Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: >> >> iPexpert on YouTube: www.youtube.com/ipexpertinc > _______________________________________________ > Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: > > iPexpert on YouTube: www.youtube.com/ipexpertinc _______________________________________________ Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc
