I am not familiar with Marko's approach for "on-screen" window placement.
I actually don't have a specific strategy in this area. I do create a notepad file for the following: basic.txt : basic infrastructure notes and notes on phone/user configs sw.txt : switch configs hq.txt : HQ gateway/router configs sb.txt : Site B gateway/router configs sc.txt : Site C gateway/router configs rp.txt : Route plan configs (when I get to that point) I have the above .txt files open all of the time. I only keep basic.txt "up" on the screen. I keep the others minimized. I restore them "as needed". During the course of the exam I will create other notepad files temporarily. Most notably: 1. When I create partitions. I have a naming convention that is basically uniform across sites. So, I lay out the HQ versions in notepad. Paste in CUCM. Then do a search/replace for "HQ"/"SB". Repeat for Site C. Kill the notepad 2. When I provision phones. I use a series of SQL commands from the CLI to provision phones. I type them out in notepad and paste from there. Then I kill the notepad. 3. Troubleshooting questions. Because I don't want to deal with VNC's sluggish nature, I'll do my TS work in notepad on the candidate PC and then copy/paste to the VNC desktop. I think that's it. As far as window orientation. I keep basic.txt in the top right corner of the screen. If I need hq.txt/sb.txt/etc. then I restore to bottom right. I'll keep (or try to keep) console sessions in the middle and IE sessions near the left. But I haven't really thought about it that much. -Bill -- William Bell blog: http://ucguerrilla.com twitter: @ucguerrilla On Apr 3, 2013, at 12:32 PM, Ramcharan Arya wrote: > Hi Bill, > > Thank you very much for nice writeup on strategy. > > This is really helpful for CCIE vocie lab aspirants. Do you have any > strategy how many notepad sessions to keep open simultaneously. > > How to arrange SecureCRT sessions screen, online lab webpage, and notepad on > 32" screen. > > I am still practice same method which I learn during R&S bootcamp with > Marko.If you have any better approach please share. > > > Regards, > Ramcharan Arya > CCIE # 28926 (R&S) > > > > On Wed, Apr 3, 2013 at 10:57 AM, William Bell <b...@ucguerrilla.com> wrote: > I have had this as a draft for a few days. Just too busy to finish it until > now. So, some of my thoughts are redundant to what others have said. > Hopefully that isn't a bad thing. > > Timing is definitely a critical aspect of the exam. I know I have areas where > I am slower than I should be. I suspect most people do. Most of my comments > herein are based on my self-study practice labs. I have taken the lab a > couple of times but most of the tinkering I have done with my method is > during self-study. When I sit for the real lab, I don't tinker. I go with > whatever method I have been practicing. So, that is suggestion #1: Don't > tinker on lab day, stick to your guns and don't 2nd guess your method. > > Going back to the OP, I believe you should look at the bright side. Your > statement "...I seemed to keep moving forward..." is key. The fact you were > able to avoid a stall is important. I believe controlling this exam is about > rhythm and finding what config approach helps you establish a sustainable and > consistent rhythm. Speed on any individual task is critical but rhythm is > king in my opinion. > > Like others (most?), I follow the device-based approach. It has been around > since pre 3.0 blueprint (contrary to popular opinion) and is a proven > strategy. However, I have found that you will need to customize that approach > to suit your needs. For me, it is about managing the transitions. Again, I > believe focusing on establishing and maintaining a rhythm is absolutely key. > Smoothing the transitions and/or stacking tasks that help ease transitions is > important. Also, you won't maintain the same rhythm throughout the exam. Some > tasks you will bang out (or should) very fast. Others, you will need to pay > close attention to what you are doing. > > So, suggestion #2 is find your rhythm. > > Establishing your rhythm is a product of repetition. Practice, practice, > practice as Mr. Sears puts it. You may also need some face time with the real > lab to help you come into your rhythm. For example, some of the "weak spots" > I had (or maybe still have) and adjustments I made. > > > 1. Transitioning from read-through to config. The read through is/was the > worst for me. Most people I have spoken with (who have passed or come close) > are able to get through the read-through in 30 minutes. Some say less. I was > taking a whole lot more time than 30 minutes. My budget for this task is 30m > today. > > Adjustments I made: > > Dial Plan. I was building out my dial plan (on paper) during the read > through. My logic was that "you have to do it at some point, just do it now". > The flaw with that logic is that to establish a good rhythm, you need to > avoid lingering on a task for too long. I decided that I would focus on > getting the tasks mapped out as quick as possible and the task of mapping out > a dial plan could wait. So, I added a section in my table to track the > DP-related tasks by task ID (e.g. 4.1) only. > Skim. I already know that I am going to do a thorough read on the questions > at least once (during config) and likely twice (during validation). No sense > in reading the question in detail 3 times. So, I mainly focus on what > devices/apps are affected by the question and put the ID in the table. > > How I use this task: > I build a table (like the dev-based approach table) to track tasks > I build a table to track what the PSTN wants to see for off net calls (this > is key because I can build an entire h323 config just on that info) > I track phone/user features/buttons/etc. This goes to speed when customizing > phones > I build a basic.txt text file to capture IP addresses, vlans, interface > assignments, etc. I keep this very short. Note that with the new exam, the > instructions are electronic. This kinda de-emphasizes the need to store some > of this info. > > > 2. Where to stick in QoS. QoS is clearly infrastructure and all of the action > happens in the router config. However, for me there is a "slow down" if I try > to stick QoS config in with banging out vlan, ntp, dhcp, rsvp, mrm, h323, > etc. I can do all of the other IOS configs very quickly in notepad. QoS is > noticeably "slower" for me. > > Adjustment I made: > I avoid auto qos on the LAN switch if I can. I have found the LAN QoS > questions to be "incomplete". Meaning, they don't reflect reality in any way. > So, if I can I just bang out the minimum config w/o auto-qos and I do it as > part of my regular infrastructure. > I push WAN QoS until after I get phones to auto-register. I do all of the > switch, HQ, SB, and SC infrastructure and I come back to WAN QoS after device > registration. Lately, I have been practicing with WAN QoS happening after > CUCM base config (MGCP, MRG, phones, etc.). So, somewhere around the 3 hour > mark. Others like to tackle it earlier on and that works to. There is no > absolute here. Just pick a hole that works with your rhythm. > > 3. Site C and CUE. CUE is a real pain and can really mess with your rhythm. > The key is to attack it early and check on it often. I treat CUE as > background noise. It doesn't get dedicated face time with me until I have the > users configured and need to customize the experience per requirement. I also > have a goal to get CUE (and CUC) done before lunch. > > Approach: > I configure IS Engine interface (loopback, routing, etc.) on SC as one of the > first things I do on that device. I then reset the module to ensure my IP > addressing is applied. > I then work on SC configs in notepad and watch CUE in the background > When CUE is up, I'll do the software license install (if needed/applicable) > and then restore factory defaults > I'll usually have SC configs done (except maybe SRST) before CUE comes up the > first time. While CUE is reloading a second time I am: > working on SC-SRST configs in notepad > starting my CUCM work > watching CUE labor through it's start up process (I say labor because, it > does seem like a lot of effort to boot up a device that doesn't do all that > much. It's like watching a 90 year old man climb steps. I digress.) > > Bottom Line: CUE is one of those items that can mess up your rhythm. Find a > way to handle it that works for you. > > 4. Transitioning from the router configs to the CUCM. You can get a head a > steam behind you on the IOS-configs and then BLAM, you are in clickety-click > land with a GUI. This transition always threw off my rhythm. > > I found that figuring out how I needed to deal with CUE helped me with > addressing the transition to GUI-land. At the time I am working on Site C, I > am working on a couple of things in parallel and am constantly busy. Which > helps me carry the rhythm from the CLI-based configs forward. > > > 5. Where to put the dial plan. I was in the mind set of trying to get the > dial plan done sooner rather than later. However, since I decided to remove > the task of mapping out the dial plan during the read through. I found that > picking a place to stick it was pretty key. I decided to wait until after > lunch to config the dial plan since lunch forces a "natural" transition > period upon you. Also, I found that your mind could use a moment to collect > itself before dorking with the dial plan. Coming back from lunch I start the > afternoon the same way I did the morning. I plan. > > 6. SRST. There are so many freakin' bugs involving SRST in this lab that I > found you want to do it sooner rather than later. I actually build the SRST > configs during infrastructure phase. I don't apply the configs until I have > phones registered and configured. I test SRST once and only once. I do it > after I have completed all of the lab config requirements. It is the first > thing I "validate". > > 6. Transitioning from "doing" to "checking". The area I am still working on. > Over the months of prep I am putting into this thing, I have come to the > realization that a validation strategy is just as important as a config > strategy. I am not talking about know what commands to use to validate a > task. I am talking about how you stack the validation approach. I have found > that while it is more efficient to do a dev-based approach for configuration, > it is not a good approach for validation. So, I do a tech-based validation. I > also do some minimum validation in-line with the configuration. But > definitely keep that at a minimum or you bleed minutes. > > -Bill > > > -- > William Bell > blog: http://ucguerrilla.com > twitter: @ucguerrilla > > > > On Mar 26, 2013, at 7:40 PM, Dane Warner wrote: > >> To All, >> >> I took my second attempt on Monday, March 25 and did not pass. >> I was hoping for some insight on concrete suggestions to get faster. >> I didn’t get hung up on any one task, I seemed to keep moving forward and >> tried to type as fast as I could, using CLI shortcuts, etc. >> I used the device-based methodology and I feel pretty confident of my >> technical knowledge. >> Yet I didn’t even get to many tasks at all, I would have needed another 2-3 >> hours to complete all tasks. >> I hear of candidates completing all tasks in 6-7 hours, which means I would >> need to become twice as fast as my last attempt. >> It almost sounds insurmountable. Do I need to take typing classes? >> >> Any recommendations that don’t break the NDA would be greatly appreciated. >> >> Regards, >> >> Dane Warner, CCVP >> Sr. Network Engineer >> Epoch Universal, Inc. >> (909)226-0755 >> dwar...@epochuniversal.com >> <image001.png> >> _______________________________________________ >> For more information regarding industry leading CCIE Lab training, please >> visit www.ipexpert.com >> >> Are you a CCNP or CCIE and looking for a job? Check out >> www.PlatinumPlacement.com > > > _______________________________________________ > For more information regarding industry leading CCIE Lab training, please > visit www.ipexpert.com > > Are you a CCNP or CCIE and looking for a job? Check out > www.PlatinumPlacement.com >
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
