My goodness Bill! Thank you for the reply and thanks to everyone else for replying. This has been outstanding feedback. Josh On Apr 3, 2013 1:19 PM, "William Bell" <b...@ucguerrilla.com> wrote:
> I separate QoS from standard infrastructure and do it later for two main > reasons: > > > 1. I typically use auto qos for LAN QoS. There is just something about the > mechanics of that process that is a shift from how I build the CLI commands > for other infrastructure bits. That shift is large enough to throw off my > rhythm. > > > 2. I like to get my phones, media resources, and GW devices registered to > CUCM before dorking with QoS. I then check registrations after QoS is in > place. This helps me avoid having too many things to check if my phones or > some other device has registration issues. If I do dev reg before QoS then > the scope of issue root cause is smaller. > > -Bill > > > > -- > William Bell > blog: http://ucguerrilla.com > twitter: @ucguerrilla > > > > On Apr 3, 2013, at 12:58 PM, Suresh Bhandari wrote: > > A real long mail to read.... But I read it entirely, not skipping a word. > > Thanks Bill for sharing the concept. I am also following the device based > approach, but I haven't thought of what you call it "basic.txt". It will be > awesome piece of information in notepad, during the lab day. > > I saw that everyone is responding QoS as the tail-ender config....... what > is the speed you can expect at the lab (thinking it might be due to the > speed/delay)? > > Thanks once again. > > > On Wed, Apr 3, 2013 at 9:42 PM, 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 >> > > > > -- > Suresh Bhandari > > > > _______________________________________________ > 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
