Posts Tagged ‘time-management’


Almost anyone studying for CCIE Lab has limited time resources.  Practically everyone thinks about optimum study time management. For example, take IEWB-RS VOL1, which has a tremendous amount of material to work on.  The workbook is structured in sections of different sizes. Let’s assume that you need to spend T1, T2, T3 … TN (N – number of sections) hours on section 1, 2, 3 … N but you only have T hours available for study, so that T1+T2+T3 +… +Tn > T. Of course, if T > T1+T2+…+TN, you’re a lucky person and don’t have to bother with optimizations!. But what should you do if the amount of time required is more than the amount of time you can allocate? How would you split the available time between the sections, is there an optimal approach? Read the full post in PDF format:

Notice that the method utilized in the paper corresponds to a “utilitarian” approach, maximizing the aggregate utility of all “members”. I’m going to follow this post with detailed recommendations on study time allocation for our IEWB-RS VOL1. Additionally, I’m planning on providing recommendations using the “egalitarian” apporach, which maximizes the utility of a less satisfied member.

Further Reading:

St. Petersburg Paradox
Marginal Utility
Kelly criterion

There is a separate post on spaced repetitions and memorization titled:

How to Study for your CCIE

Tags: , , ,



The CCIE Voice lab is unique in the sense that it requires you to configure diverse number of applications sharing little in common with each other. For example, you will have to use GUI to configure Call Manager and CLI to configure SRST. On top of that, it’s hard to break the Voice lab into “core” and “non-core” parts, since you are required to configure a lot of different things (e.g. register phones, add gateways, set up dial-plan, configure dial-peers) in order to place an end-to-end call and test “connectivity”. All that makes the Voice lab tougher than any other CCIE lab.

Lab Strategy Overview

Generally, we can subdivide strategy into the following sections:

I) Order of Operations. The way you want to follow through configuring the lab. Almost certainly you dont want to configure tasks in linear, sequential fashion, as it is not the fastest way possible. Speed is number one priority in any CCIE exam, and it’s especially vital in the Voice lab.
II) Time Management. The thing you definitely need to control is the amount of time you spend on each task. While this part seems so obvious, most people cant resist the urge to troubleshoot one single task for “another five minutes”. “Don’t get stuck!” should be your motto here.
III) Stress Management. Huge stress is what differentiates the real lab exam from any practice lab you’ve done. Remember, stress is your enemy and your friend at the same time – it boosts your strengths and concentration but makes you flaky. Take in account the impact of stress on your accuracy and speed.
IV) Dealing with wildcard scenarios. You cant possible learn all the voice technologies out there. So there is still a chance you can meet something scary and unfamiliar (or simply badly worded) in your real lab. Or maybe, you would face a rack or initial configuration issue. All this has to deal a lot with sections (II) and (III) of the strategy, but you should be prepared to meet the unexpected. Never panic, and try to isolate the wildcard situation as soon as possible.
V) Verifications. Many people believe they dont need a verification plan, as the verification ideas will come out by themselves. Basically if they see something working, they become assured it would last till the end of the exam. Do not make this mistake, and develop a thorough verification plan for your solutions, as stress and time can play bad jokes with you.

Lab Exam Topics Outline.

Before coming up with an order of operations, let’s make a short outline of the current (2008) CCIE Voice lab exam:

I) Infrastructure. Voice & Data VLANs, switchports. DHCP for IP address allocation, NTP for time synchronization. Other advanced tasks, pertaining to switching infrastructure (e.g. DHCP snooping).
II) Station Devices. Register ephones with CME and assign extensions. Auto-register IP and Analog endpoints with the CallManager and assign extension numbers. Phones Presentation settings (display layout, softkeys, buttons, calling number masks). Users and Directory Services.
III) Gateways & Trunks. Configure ISDN PRI settings in the routers. Register MGCP gateways (analog/digital PRI backhaul). H.323 gateways and Gatekeeper. Gatekeeper registration. SIP Trunk and IP to IP gateway.
IV) Call Routing. Plan the dialing patterns and Classes of Restriction. Create Partitions and CSSes in the CallManager, Route Groups and Route Lists. Call Hunting Constructs in CCM and CME.
V) CAC & Codecs. Regions, Locations, Gatekeeper admission, dial-peer settings, voice-class, CCM global codec settings, DTMF-relay.
VI) Media Resources. Registering NM-HDV/NM-HDV2/6608 with the CallManager. Transcoders and Conference Bridges. Software Media Resources. Music on Hold Servers, Multicast Music on Hold. Media Resource Groups and Lists, order of allocation.
VII) Applications & Services. Call Forward/Transfer, Park/Pickup/Extended Functions. Cisco IP Phone Services. IPMA (Proxy/Shared), Attendant Console, Extension Mobility. B-ACD for CME.
VIII) High Availability. AAR and SRST. HSRP/VRRP (advanced topics). Call Backup.
IX) QoS. FRTS (legacy/MQC) and CBWFQ. Link Efficiency: FRF.12 and MLPPPoFR, cRTP. LAN QoS: Classification/Policing and Marking. WRR and PQ. Marking in the gateways (IOS, ATA, VG248).
X) Voice Mail. Unity integration with CCM/CME via SCCP. CUE Integration with CME via SIP. Unity Subscribers, CallHandler, CallRouting, Schedule, Recording. CUE Groups and Subscribers, AvT. Redirecting Calls to a Voicemail system.
XI) CRS. Integration with CCM. ICD Script customization, CRS Editor.

Order of Operations

The most import part of you plan – essentially this is the core of your strategy.

Step 1: Planning (20 – 25 mins)

It’s the beginning of your lab exam. You are probably all excited and nervous, and open your lab workbook. Take a couple of deep breaths and locate the lab diagrams. You will probably have a topology diagram and supplementary drawings/tables describing your connectivity and PSTN/WAN settings. Redraw the major diagram real quick – you will enhance your drawings as you read through the lab after that. Also, drawing will probably calm you down a little bit. Next start with reading through the whole lab. You heard that before, now it’s time to hear it again :) Do not underestimate the importance of reading the lab as a whole. This will give you all the connections between the tasks, and probably insights on possible issues.

As you read through the lab, locate the following information and put it on your diagram: Extension Numbers, Site DID patterns, WAN settings (CIRs, port speeds), IP addressing (servers, loopbacks, voice vlan subnets). Dont spend too much time on the Call Routing/Dialplan sections for the CallManager, and don’t stick with analyzing advanced Call Routing tasks like call backup, TEHO etc. However, locate the dialing pattern for CallManager Express and SRST systems (if you have them in your lab). Spot whether you will need a gatekeeper in your configuration, and whether it’s a backbone device you your internal pod router.

Using “show cdp neighbor” command verify that you see all your IP Phones. Record the last four digits of each MAC address and draw it next to the respective phone on your diagram. At the same time, perform a quick connectivity test to ensure your equipment is set up properly, and you can reach the CallManager and Unity servers.

As you finished with reading over, unbind the paper sheets, and re-arrange them in the order you find comfortable.

Step 2: IOS and CLI configurations (1,5 – 2 hours)

This is the part where you configure all IOS-relevant applications, starting with infrastructure and finishing with CME/CUE and SRST (if needed). As much as you can, try to type all your configurations in notepad first and than paste into command line. This requires a lot of practice, but it really worth it. Remember to use consistent names: I recommend using all uppercase separated by underscores like “class-map VOICE_BEARER”.

Start with configure VLANs and switchports, DHCP servers (IOS/Windows) and NTP. Ensure all devices obtain IP addresses (check the DHCP bindings) and are pingable (A small side-step will be required to configure Windows DHCP server, but it’s OK). Set up NTP if required, and synchronize the CallManager time if they ask for that. Ensure your time is synchronized. If you get some small issues like devices not getting IP addresses, don’t spend more than 5 minutes trying to troubleshoot it. Take note if it fails, and go on.

Multicast & QoS
Configure multicast routing if needed for multicast MoH later. Verify multicasting by joining groups on routers and pinging end-to-end. Configure FRTS and CBWFQ in routers per the requirement of your QoS section. If you have LAN QoS requirements, apply the most basic configs here (trusting, basic CoS->DSCP remarking) but don’t spend a lot of time coping, editing and pasting long crazy QoS configurations from the DocCD here. You can do that later in the exam if you have enough time, and your goal right now is speed. If you really hate LAN QoS, just disable “mls qos” and move on here. It wont probably cost you many points, but will win you a lot of time and nerves.

CallManager Express and CUE
You first big task. Set up CallManager Express phones – register them and configure buttons/layout/call-forwarding/transferring. Set up all necessary telephony-service settings here (dialplan-pattern if needed, time-zone, etc) . Set up the basic dial-plan to reach PSTN destinations. Call between PSTN phone and CME Phones to validate your configuration. If you have any other tasks in your lab pertaining CME (like B-ACD, call-hunting, local-directory etc) do them all here.

If required by the lab, reset the CUE module, and perform integration with the CallManager Express system. Don’t forget to enable HTTP server in the CME and perform the CUE web-init dialog. Create subscribers and complete advanced CUE tasks. Take care if they ask you to route VoIP calls to CUE, as you will need the transcoder registered with the CME.

SRST, PVDMs, Gatekeeper and MGCP PRI backhaul
If required by your scenario, configure all MGCP PRI backhaul in IOS routers right now. Although you will configure gateways in the CallManager later, it makes sense to complete all IOS stuff right now. Configure NM-HDV to register with the CallManager if your scenario requires this as well.

If you they ask you to do SRST, configure the respective router. Set up everything, including the dialplan and incoming calls handling for SRST. Verify SRST to CME calling by using “csim start” command in SRST and “debug isdn q931” command in both CME and SRST systems.

If you need to set up a gatekeeper in a routers inside your pod, and/or register with a backbone gatekeeper, do it now as well. If needed, register CME system with the gatekeeper too. Use “debug h225 asn1” for advanced debugging.

When you’re done with Step 2, you should have almost all IOS parts configured. Endpoints obtained IP addresses, switches impose marking, CME/CUE integration works and you should be able to test basic calling. By now you probably have 30mins-1hour gap before the lunch break.

Step 3: CallManager Setup (1 hour)

Follow the Top-Down, Left-to-Right approach with the CallManager set up.

System Settings
You should already know your time-zone, presentation settings, regions, locations and device pool requirements. Start by configuring the CCM servers, replacing names with IP addresses everywhere, adding regions, AAR groups, locations (if required). Always rename the default entities (like default Date/Time Group, default Device pool) and re-use them. Try to stick with consistent naming scheme mentioned above. For example, use “DP_HQ, DP_BR1” names for device pools, “REG_HQ”, “REG_BR1” for regions, “LOC_HQ” for locations etc. Make the names self-explaining and keep the number of device pools minimal. As you’ve done with “System” settings, start the CallManager services, if they are not started already. Ensure you don’t start unnecessary services, like IPMA/EM, if they are not mentioned in your scenario. Less services means less worries!

Media Resources
As you finished with basic system settings, proceed to media resources configuration. Configure the software media resources first. Ensure you set the proper codec’s for MoH and assigned a location/device pool to MoH servers. You may need a separate device pool for MoH servers to control codec’s precisely. Set up Multicast MoH settings in servers and sources. Ensure you have Annunciators and MTPs running on both servers. As you’ve finished with the Software Resources, proceed to transcoders and conference bridge registration. Add the respective devices that you probably already configured in the IOS systems. Complete your Media Resources configuration by creating MRGs and MRGLs and assigning the latter to device pools created before.

Gateways and Trunks
Before you start this section, create a partition for all internal extensions (e.g. “PT_INTERNAL”) and a default CSS for each site. Default CSS is the one which will be mostly used by your respective site internal devices. Give it a name like (“CSS_HQ_DEFAULT” or “CSS_BR1_DEFAULT”). Now proceed with creating gateways in the CallManager (H.323, MGCP, SIP). Assign a proper device pool, incoming CSS and other settings per your PSTN requirements. If you have a gatekeeper in your scenario, add a gatekeeper to the CallManager and create a Gatekeeper-controlled Trunk. Ensure the CallManager registers with the Gatekeeper.

Station Devices & Users
If needed, create new softkey template and button template before you start with the phones. Then, perform auto-registration for all IP and Analog Endpoints. This is probably the most time-consuming section, which requires a lot of accuracy. Pickup up the default CSS, Partition and External Phone Number Mask for auto-registration carefully, to minimize the number of changes later. Ensure all your endpoints registered (you may need to lift handsets on the VG248 devices or switch it to manual enable mode). List all the phones registered with the CallManager and configure them all, starting with VG248 and ATA186 phones, since they are easy to spot on the screen. For all other phones, use your diagram with the last 4 digits of the MAC addresses to spot the phones. Don’t forget to set up Display ID, External Phone Number Mask, AAR Group, AAR CSS, Softkey/Button template, Directory Number, etc. As you’ve done, check the phones layout and try calling between phones real quick.

After that, create users in Global Directory (if needed) and associate them as required per your lab scenario. To finish with basic verifications, call internal phones from the PSTN phone. Do not attempt to configure any advanced CallManager applications here

Step 4: Unity Integration (20 – 30 minutes)

Set up Unity side first and then run the integration wizard in the CallManager. Ensure you can reach the Unity General Greeting. Take in account possible AAR requirements when configuring integration, as you should have AAR groups created already. Account for any subscribers calling from the PSTN. Create Subscribers (disable self-enrollment dialog, set simple password etc) per the requirements of your lab. Ensure you can send and receive messages, and MWI is working. Since Unity is usually simple, complete all other Unity tasks here as well (CallHandlers, Live Recording etc).

Step 5: CallManager Applications (20 – 30 minutes)

Configure IPMA, EM, AC and other CallManager application here, if required by your lab scenario. Remember you should start any advanced configuration only after you’ve done with all the basic configurations. Test your applications and assess the current situation. If you feel like you have enough time, proceed to IPCC Express Integration and script customization. If not, skip directly to Call Routing section.

Step 6: CRS/IPCCX (20 – 30 minutes)

IPCCX is not a big part of the lab exam, but it requires considerable amount of time to complete and verify. So start working on this part only if you are feeling sure about yourself and want to earn some “hard” points. Integrate IPCCX with the CallManager and verify the default script. You may want to configure IPPA single-sign on to ease the verification process. Skip the script part if you don’t know how to do it, just complete and verify that your integration is “IN_SERVICE”.

Step 7: Call Routing (40 minutes – 1 hour)

This is probably the next (after Auto-Registration) most time consuming part of the lab. To accomplish it, read the Call Routing section of the lab scenario now. Outline the dialing patterns, classes of restriction and corresponding partitions and Calling Search Spaces. Use consistent and self-explaining names like “PT_HQ_PSTN_DEFAULT”, “PT_BR1_PSTN_RESTRICTED” and “CSS_HQ_PREMIUM” to outline the classes of restriction used in your scenario. It’s useful to type all patterns and corresponding partitions in the notepad first, to get better understanding of the Call Routing. Take special care with respect to presentation settings (CLIDs, Calling Names) and other additional requirements.

Create route groups for all your gateways (e.g. “RG_HQ”, “RG_BR1” etc) and a route-list for each type of call-routing behavior. Again, stick with names which make sense, like “RL_HQ_INTL_GW_HQ_BAK_GW_BR1” – attempt an international call from HQ using the local gateway and using BR1 gateway as a backup. Create all your route-lists first, and design DDIs as required per your scenario. Prefer to implement DDIs inside Route Lists and not at pattern level.

Next, create the additional partitions required and start adding dialing patterns one by one. As you add each pattern, use “debug isdn q931” where possible to trace the paths your call is taking. Call the PSTN phone or any other site’s phone as appropriate to verify each pattern. Start with basic dialing (e.g. 911, Local calls) and end with more complex routing rules like TEHO and calls across the gatekeeper. Be very accurate with each pattern, since it doesn’t take much to make a mistake here. This is why it’s crucial to verify every piece while you progress.

You may also need to implement additional dialing rules in the IOS routers (e.g. in the CME system). Use the same step-by-step approach and verify every a new pattern as soon as you configure it.


You should be able to finish your lab in 5-6 hours and have about 2 hours to verify everything you’ve done. Now for verification part, you need to check the following

b) PSTN Phone can Call everyone
c) Every Phone adheres to it’s class of restriction
d) Calls between sites work
e) Voice Mail works (Unity and CUE)
f) Applications work (e.g. IPMA/EM, B-ACD etc)
g) Media Resources Work (MoH, Transcoding, Conferencing)
h) QoS Marking and Enforcement
i) Time synchronization and other infrastructure stuff
k) Redundancy: CCM Subscriber disabled, everything falls to the Publisher

Remember, it’s vital to have a clear verification plan in mind, as well as practice it during your preparations. As you progress with verifications, mark each section of the lab as “verified”. It never hurts to do verification twice, but be careful and don’t do any drastic changes to your configurations even if you think this should fix the situation. Always apply small changes – one change at time.

Stress Management

There is a lot of things to say about stress management. The idea is: there is no easy way to defeat stress and anxiety in the day of your lab, unless you are prepared to face the stress. Build your stress tolerance through the whole process of preparations. Observe strict day regiment, go to bed and wake up at the same time every day. Try not to work at nights, as this way is against your body physiology. Don’t forget regular physical exercises – if you cant afford everyday trainings, at least try to make short breaks during your work and get a walk around. Eat healthy food and avoid cold drinks and food that is hard to digest. All those things are plainly about physiology and body functions, but you’ll be surprised to see how much does it help. If feel like it, learn any meditation or relaxation technique (usually breathing exercises) – it really helps to deal with sleep issues and helps you combating anxiety. And last, but probably most important advice (quite obvious too) – the best thing to reduce stress in the day of the lab is to be well prepared..

The day before your lab, try to forget all your worries and relax. Get a life, walk around have fun – don’t think about your exam, just try to spend a good day. Try to walk a lot, to make your body physically tired. Do not take any sleeping pills the day before your lab, as they can affect you alertness the next day. This is the last day before your exam – there is nothing you can do to improve your skills now. You should have had plenty of time to do that in ahead :)

The day of the lab, try no to overload yourself with caffeine. It’s OK as long as you keep the amount reasonable, but can make you jittery if consumed in large amounts. Also, during the lunch, try to relax as much as possible and eat some warm, liquid food – it generally makes you feel energized.

Time Management

It’s quite simple to understand, but hard to implement. Have a plan in your head; know the time you need to spend on each section, and execute you plan. Build a habit of not sticking with any task for more than 15 minutes, unless you’re doing a big and complex task like IPMA. But if you got something not working, don’t spend desperate minutes trying to troubleshoot it for 30 minutes. During the preparations, I found it really useful to run a widget playing chimes every 15 minutes – just to keep me on track. Another benefit of time management – seeing your lab progressing in accordance with the amount of time planned in advance generally helps you reduce the level of stress.

Wildcard Scenarios

There are different types. First, and most harmless – you get an unfamiliar topic in the lab. Skip it the first time, and then refer to the DocCD if you have enough time left in the end of your lab. No big deal, unless you think most of the tasks are unfamiliar to you :) Usually that means you were preparing to a different exam. OK, so the next wildcard – hardware and software issues in your rack. This is a type of issue you should battle with proctor – just make sure those are real issues. If that didn’t help much – prepare a complain letter to Cisco, and ask for a free lab attempt – and it’s no joke! ;) Proctor is yet another wildcard. They are merely humans, so you can’t expect 100% courteous service all the time; occasionally, you can meet an unhappy or unfriendly guy, so be prepared to use all your social skills. The last and most uncommon wildcard – some accidental situations like building fire or earthquake. But those are the things you need to worry less about.

The things you should probably take care of are unexpected issues with your health. Like a cold flu, or sudden headache, or something of that kind. Ensure you have minimal amount of medicine necessary to suppress pain and other unpleasant syndromes for the duration of the lab exam.


That was just a sample of a lab strategy. Remember, you goal is to come up with your own, personal strategy, that fits you best. There is no universal solution that fits everyone. But as long as you try to plan and approach your preparations systematically, you are on the right track. Good luck with your lab!

Tags: , , , , ,


First off be sure to arrive at the lab at least 15 minutes early. I’ve done both arrived early and arrived late. I can tell you from personal experience that arriving early is the best option. ;) When you arrive you will be waiting in the lobby until the proctor comes out to escort you into the lab. When you get into the lab the proctor will give you a quick introduction before starting. This introduction will cover the facilities (i.e. restrooms, break room, etc), the start and stop times and then the proctor will normally ask if anyone has any questions before starting. If you have any general questions I would recommend that you clear them up with the proctor now. For any questions related to the lab itself (i.e. do I need to ping myself over Frame Relay) I would recommend that you wait until you read over the lab before asking as most of these types of question will be answered in the lab itself. After this introduction the lab will officially start. You can now go to your assigned seat and start the lab.

Bring earplugs (the small disposable type) as the lab can in some locations be a little noisy (routers and switches buzzing, phones ringing from the voice racks, etc). Dress in layers (i.e. light jacket or sweater) so that you can remain comfortable. Leave your cellphone, pager and any other electronic devices at your hotel or in your rental car. If you do bring them with you to the lab they will have a place for you to store them. This also holds true for your luggage. If you are going to the airport after the lab you can bring your luggage to the lab and they will have a place for you to store it during the exam. You may want to bring a certain drink or snack. Officially the policy is that you can not bring anything into the lab but normally the proctors will allow you to bring a drink or snack in. If you are taking the lab in RTP the lunch will be catered. You will not have a big choice as to what to eat. This being the case you may want to bring your own lunch if you are a very picky eater or on a special diet. Personally I’ve found the food to be just fine but to be honest what’s for lunch in the lab is the least of my worries as it should be for you.

But before even stepping into the lab you should have a detailed plan. This plan should include what you are going to do when you first arrive. Below is my recommended plan as to what to do when you first arrive in the lab.

1 ) After taking your seat remove the lab and diagrams from the binder. You don’t want to be flipping through the binder all day. The pages themselves will be in plastic sheet covers. Do not remove the pages from the sheet covers. I normally make two stacks for the lab material. One for the pages I haven’t completed or am still working on and the other the pages I have completed.

2 ) The pencils (colored and regular) and pens that they supply will be on your desk. Pick out the ones you will be using and sharpen any if needed. Since they are supplying you with the colored pencils you may end up with different colors then you are used to. This being the case don’t use the same colors all the time and mix it up a little between labs. Now you may try to bring your own colored pencils into the lab and sometimes the proctor will allow them but the official policy is that you can’t bring them in. In that case just use whatever they are supplying and don’t worry about it. But if you feel you can’t pass the lab without your own “magical” set of colored pencils you may want to stop preparing for the lab now and just use your $1400 for a good psychiatrist ;)

3 ) Draw out your own diagrams. Drawing out your own diagrams has two big advantages. First off, you can’t write on the diagrams they give you without being suspended from the lab for one year. By being able to write on your own diagram you can make lots of little notes when working through the lab. Secondly by drawing out the network it will help you learn the network and remember what the network looks like when reading the tasks without the need to repeatedly look back at the diagrams. I can’t tell you how many people I see during the mock lab classes make little simple mistakes like configuring a feature on the wrong device or on the wrong interface. Just one little mistake like this can be the difference between passing or failing.

4 ) Take a quick read over the entire lab to get a general idea of what you are going to be doing throughout the day. Don’t spend time trying to figure out the solution to each task but just get a feel for what they are looking for. You may also find that the order they give you the tasks in is not the ideal order in which you should do the task and you want to figure that out now. I see people in the mock lab workshop make the mistake of just starting with the first task without reading over the lab. By doing this they run into issues when a solution they implemented in an earlier task causes problems with a later task.

5 ) Now log onto your rack using the Windows XP PC provided. You will have shortcuts on the desktop to your devices. By just click on the SecureCRT shortcuts on the desktop you can connect either to the console of the access server or the individual lines. This is the same way we have our rental rack access setup. If you connect directly to the console of the access server you can then reverse telnet (i.e. R1, R2, etc) to the console of the devices. If you want to connect directly to the device’s consoles you can do so but be forewarned that you will need to have ten SecureCRT windows open. Newer versions of SecureCRT support the concept of tabs but the version of SecureCRT in the CCIE lab will not support tabs. This means that you shouldn’t use tabs during the last month or so before your lab date if you plan to connect to the devices directly. Personally I think that working with ten windows is awkward to say the least but it’s going to boil down to a personal preference.

6 ) Now that you are connected to the devices in your rack take a quick minute to ensure that the initial configurations loaded on them match the diagrams provided. To do this just compare the IP addressing on your devices with the ones on the diagram to ensure you have the correct initial configurations loaded. Although rare it does happen that someone either gets the wrong lab or initial configurations loaded.

7 ) Next open three Internet Explorer windows. The first one for the IOS 12.4 documentation, the second one for the 3550 documentation and finally the last one for the 3560 documentation. Do not expect to have a version of Internet Explorer that supports tabs. If the administrative privileges on the PC do not allow you to open multiple instances of Internet Explorer you can go to the one that you could open and then do “File->New Window”.

8 ) Using one of the scratch sheets of paper that they give you make a quick table with the following columns: Task, Point Value and Notes. Use this to document your progress as you do the lab. Also note on here when you complete each section. Include the number of points you achieved in the section, the total points you feel you have and the time you completed the section. Remember that time is not your friend in the lab so you need to make sure don’t loose track of it and you know exactly where you are in the lab at all times.

9 ) If you want to apply additional configuration (alias, logging synchronous, etc) create them in notepad now. Then paste them into the devices. A few I personally would recommend are below:

a) clock set (set the clock on all devices if they are not already set)
b) ensure the logging level for the console is set to debugging
c) logging buffered
d) ip tcp syn-wait 5
e) no ip domain-lookup
f) line con 0
history size 256

Personally I don’t use aliases other than the default ones in the IOS but its a personal preference.

Do not take more than 30 to 35 minutes to get to this point. You should be ready to start the lab now. In the next part I will cover getting up to full reachability in the lab exam.

Tags: , , , ,


CCIE Bloggers