Some humor. http://www.youtube.com/watch?v=FL9-7AeFD5w
<http://www.youtube.com/watch?v=FL9-7AeFD5w>disclaimer: I would not even think to try something like this. On Tue, Sep 1, 2009 at 12:01 PM, Joe Astorino <[email protected]>wrote: > Hey Azhar, > > I recommend you reload your routers just before lunch. About 10 minutes > before lunch, the proctor will give you a warning that it is time to eat and > to save your configs. Save everything, reload and go enjoy a meal. > changing system MTU or anything involving an SDM profile requires a reload > to be effective. > > I would not recommend reloading your pod at the end of the day unless you > have adequate time left to troubleshoot if necessary. Many say proctors > reload your pod before grading you. That has not been proven to my > knowledge. Yes, you log out of your computer and restart your computer, but > I have not heard from any proctor directly or online that they in fact > reload your pod before grading. > > On Tue, Sep 1, 2009 at 11:30 AM, Azhar Mirza < > [email protected]> wrote: > >> Thanks. This is useful - >> >> >> At what stage do you recommend rebooting the devices (surly not before >> you r leaving?)? >> >> Can you predict when you will be required to reboot during the day? >> >> >> e.g. >> - if you see switches sys mtu has to be changed (dot1q tunnelling-asked >> later) that requires reboot? Change sys mtu early in the day & reboot? >> - you might have 0.0.0.0 FR routes? >> - any other possible situations where you have to reboot? >> >> Thanks. >> >> >> >> >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of >> Joe Astorino >> Sent: 01 September 2009 05:14 AM >> To: Andy Mueller >> Cc: rakesh m; Mark Matters; [email protected]; >> [email protected] >> Subject: Re: please share your lab strategy >> >> The approach that has been successful for me and some of the other guys >> is >> the following: >> >> 1) Read your lab front to back before you do anything. >> 2) While you are reading, make a checklist of tasks noting the point >> value >> for each task. Write notes in shorthand next to each task that gives >> you >> the basic idea of what you need to configure. Remember, you are only >> fresh >> ONCE in the morning when your mind is clear. By taking simple notes on >> the >> configuration you need to do, you are effectively making your own "cheat >> sheet" you can utilize later in the day. You also can quickly come up >> with >> a value of points you think you have at any point during the day. >> >> 3) If you run into something during your first read you don't know, >> simply >> mark it with a "?" and move on >> 4) Draw your diagram -- Everybody has their method and I have mine. I >> typically draw a single diagram that has all my interfaces, ip >> addresses, >> subnets, and IGPs all in one place. If I feel I am doing something >> insane >> at L2 like tunneling or Q-Q, I will make a second L2 diagram, otherwise >> no >> L2 diagram. If the BGP diagram I get is crappy or not detailed enough, >> I >> may do another one of those as well but this is not the norm. >> >> 5) Do a "sh run" on every device. Scan quickly and look for >> "suspicious" >> things... AKA "troubleshooting." If it doesn't look right, fix it. >> Some >> people do this all at the end of their lab and I don't understand that. >> Fix >> ANYTHING that is broken right at the beginning so you are not dealing >> with >> even more issues well into your lab that are not your own fault. Get >> everything running as it should be before you even do anything on your >> own. >> Make sure you can "ping" all locally attached ip addresses. This may >> save >> you from finding some L2 or minor L3 error down the line. >> >> 6) You should now be 30-45 minutes into your lab. Bust out notepad, >> bust >> out calc and have them ready. Start at the beginning...of course you >> have >> noted problem areas and other places in your lab where maybe you can >> kill 2 >> birds with one stone early, so you can go ahead and take care of those >> right >> off the shot. Take the lab apart one piece at a time building from the >> ground up. Go in layers...get L2 going before you tackle L3. Get L3 >> going >> before you go to L4 (BGP).... L4 before security, etc... You can't >> build a >> money house on a crappy foundation. Get the L2/L3 foundations done >> early >> and right. >> >> 7) IF you find yourself on a task that you just can't get, you HAVE to >> learn >> to pull away after 15 minutes. 15 minutes is the rule...no longer. If >> you >> are in a situation where a task you can't get is going to totally break >> reachability for your lab, configure it enough to get things working so >> you >> can get end to end reachability, and move on. For instance, maybe you >> have >> your PPPoFR working but couldn't figure out the authentication. Or >> maybe >> you couldn't get the PPPoFR at ALL ... well , better to just configure >> basic >> frame-relay and lose the points for PPPoFR then to totally fail the lab >> because you didn't have reachability at all over your frame cloud >> >> 8) I would suggest writing your config after every task as >> well...sometimes >> I do it more out of nerves/paranoia : ) >> >> I HTH! >> >> On Sat, Aug 29, 2009 at 12:06 PM, Andy Mueller >> <[email protected]>wrote: >> >> > Sorry I hit enter, new laptop! >> > >> > I am approaching the lab in the same way. Instead of freaking out >> about the >> > test, I am looking at it as a client I need to go service. They have a >> > network that need to be up in 8 hours time. I am covering as much >> material >> > as possible and with the help of the doc cd need to satisfy this >> client. >> > This makes me put on my "work" brain to take the test, rather than my >> oh >> > s$%! brain telling me I have a test to take. >> > >> > On Sat, Aug 29, 2009 at 11:02 AM, Andy Mueller >> <[email protected] >> > >wrote: >> > >> > > I am a network engineer for a consulting company. I never know what >> I >> > will >> > > run into at a client site. I rely on the cisco doc's a lot on a >> daily >> > basis. >> > >> > >> > Blogs and organic groups at http://www.ccie.net >> > >> > >> _______________________________________________________________________ >> > Subscription information may be found at: >> > http://www.groupstudy.com/list/CCIELab.html >> > >> > >> > >> > >> > >> > >> > >> > >> >> >> -- >> Regards, >> >> Joe Astorino - CCIE #24347 R&S >> Technical Instructor - IPexpert, Inc. >> Cell: +1.586.212.6107 >> Fax: +1.810.454.0130 >> Mailto: [email protected] >> >> >> Blogs and organic groups at http://www.ccie.net >> >> _______________________________________________________________________ >> Subscription information may be found at: >> http://www.groupstudy.com/list/CCIELab.html >> >> >> >> >> >> >> >> >> -------- >> NetServices plc, Company No. 4178393, >> Registered Office: NetServices House, 31 Modwen Road, >> Waters Edge Business Park, SALFORD, M5 3EZ >> -------- >> > > > > -- > Regards, > > Joe Astorino - CCIE #24347 R&S > Technical Instructor - IPexpert, Inc. > Cell: +1.586.212.6107 > Fax: +1.810.454.0130 > Mailto: [email protected] > > _______________________________________________ > For more information regarding industry leading CCIE Lab training, please > visit www.ipexpert.com > > -- - "The more I learn the less I know". This is incredibly frustrating to me.
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
