Gustavo, Having failed the lab many times, I can sincerely say I feel your pain (Actually, until Tuesday I could honestly say I've been feeling your pain for the past 2 years). So, what I'm about to say is for those people like yourself, who have enough knowledge and skill to pass the lab but still fail anyway. Personally, I believe there are 4 primary reasons people who should pass the lab don't. 1. Task mis-interpretation 2. Insufficient organization during the lab 3. Not seeing the implied requirement 4. Insufficient checking and verification Here are the some of the things I did to overcome the first problem. I think there are 3 reasons people mis-interpret the task requirements: 1. Cisco, by design and with malice of intent, often writes the tasks in a vague or misleading way. For example, if you've been following GS posts over the past couple of weeks, you may have noticed questions regarding Mobile IP. However, Mobile IP is not on the lab. This was a response to a question re: forwarding Mobile IP registration broadcasts. "Ip forward protocol with IP helper is what I would use...you can forward mobile-ip registrations which are udp...I'm not sure about your configuration but that's what it appears to me what you are trying to do.." Reading between the lines, it seems to me that a task could be written with the words Mobile IP in it where the solution has nothing to do with configuring Mobile IP. Now, I can't speak for anyone but myself but I know that if I read a task with the words Mobile IP in it, I would AUTOMATICALLY think about having to configure Home Agents or Foreign Agents or something related to that. Not in a million years would it occur to me that the solution was really calling for the ip forward udp command. Could it possibly be that the proctors who write these labs would be so wicked? I think the answer is definitely YES. On the other hand, there are ways to combat this wickedness. First of all, DON'T ALLOW YOURSELF TO BE SUCKED INTO THE BLACK HOLE OF WASTED TIME. Losing the points of one or two non-layer connectivity tasks won't automatically cause you to fail the lab. I had at least 2 tasks on my lab which I didn't even attempt to answer and I still passed. 2. Reading the task too quickly (or not carefully enough) To combat the scourge of task mis-interpretation, slow down. Yes, I said it. Slow down. Read the complete set of bulleted sub-tasks slowly and multiple times. Here's what often happens when you don't slow down. You read the task too quickly and realize you know how to do that and you configure the task using the most common method or the way you're most familiar with - and you're wrong. You make the assumption that just because you know A way to fulfill the task requirements, you are fulfilling the task in THE correct way. Of course, it doesn't appear that you're wrong because you verify reachability and you have reachability but you didn't fulfill all the conditions of the task. Bingo !!! At least another 2 or 3 points lost. (You might also lose points for subsequent tasks because of dependencies.) Here's another example. "Allow pings to bring up the isdn link" which is not exactly equal to "Allow icmp traffic to bring up the isdn link". Consider this. Does "Allow pings..." mean "Allow ONLY pings..."? If your acl is like this: access-list 100 icmp permit any any This acl does in fact "Allow pings..." to bring up the link but it also allows other traffic as well. What should you do? Will the acl above cause points to be lost? I don't know for sure but I suspect that it's better to be as specific as the task allows. This brings me to next KEY reason people mis-interpret the task: 3. Not knowing every way to accomplish a given task. Of course, the best to deal with this problem is easily said but not that easily done. KNOW EVERY WAY TO ACCOMPLISH A GIVEN TASK. The lab is FAMOUS for restricting your choices for how something is done. For example, there are 3 ways to advertise a loopback in OSPF without a 32 bit mask. There are 3 ways to advertise the ip address assigned to an interface in IS-IS. There are multiple ways (at least 3 that I know of) to assign an ip or ipv6 address to an interface. There are a gzillion ways to configure isdn to back up lost connectivity somewhere else in the network. There are multiple ways to overcome reachability problems. Here's my list: 1. Redistribution 2. NAT 3. Default network 4. Static route 5. Tunnel 6. Policy based Routing 7. Summary Addressing 8. Virtual-links When you don't know every way to accomplish a given task, it's easy to be faced with the dilemma of thinking, "They must mean ...". So, then you configure something that seems to be pretty close to what they were asking for but not 100% exactly what they were asking for. Bingo !!! Another 2 or 3 points down the drain. Now, I'll talk about the 2nd reason I think people fail the lab. Insufficient organization during the lab This could also be referred to as STUPID MISTAKES. We all make them and I suspect I do much more than most people. For example, let's say early in the lab (in the section on bridging and switching), you have to configure f/r end-to-end keepalives. So, that's what you do. You check it. It works. You go on your merry way. Later on, you're working on the QoS sections and you have to configure FRTS. So, that's what you do. You check it. It works. You go on your merry way. But, if you're anything like me, you didn't notice that the interface you applied the FRTS to were the same ones already configured for FREEK. Whoops !!! Another 2 or 3 down the drain. You can probably think of hundreds of examples like this where you do something early in the lab only to do something later in the lab that breaks your earlier configurations. To address this problem which probably caused me to fail multiple times, I started getting in the habit of making lists during the lab. If I have to create an acl or map-class, I write it down on the scratch paper they hand out at the beginning of the lab. Then, if at any later point in the lab, I need to create another acl or map-class, I first check to see if I've already had to create one before and on which interface. I also used to create a list of every loopback interface and make a note of which IGP it's in. When I'm done with the IGP section I check to see if I've advertised every loopback. I don't do that anymore. Now, I use a tcl script to check that. But, the list method worked fairly well before I was comfortable with using TCL scripts. Reason # 3 people fail: MISSING THE IMPLIED TASKS Let's assume for a moment you take the lab and only do what they explicitly tell you. If they didn't EXPLICITLY tell you to do something, you didn't do it. How many points would you lose? My guess is at least 6 to 9 points. Of course, they did tell you full reachability was required at all times perhaps in the general directions but not in any of the numbered sections of the lab. Hmmm. How do you combat this challenge? The way I tried to address this challenge was by making lists. For example, I have a short list of things to check for ospf and bgp. Before leaving the IGP section, I looked at my IGP diagram and looked for any potential virtual-link or gre tunnel requirement. Not only do I look for the obvious v-link requirement but also a potential requirement if the frame relay cloud went down. It's amazing how often a v-link or gre tunnel becomes required when the f/r link goes down. For another example, with BGP, I always used to forget configuring the neighbor ... next-hop-self command. Before moving from BGP, I always check, do I need to configure next-hop-self. As my last example, if there's any task that has anything to do with time, I automatically think "SET CLOCK". This includes acl's with time-ranges, logging, ntp, etc. Now, I know there's been extensive discussion her on GS about whether or not it necessary to set the clock if the routers are rebooted anyway at the end of the lab and those routers without hardware clocks will reset the clock to the default after a reboot. But, if I see any task that relates to time in any way, I make a beeline to the proctor. And, of course, look for tunnel and NAT requirements. Refer to the reachability list shown earlier. So, make your list of potential implied requirements and look for them. Let this list be your mental trigger. TOP REASON # 4 people fail the lab: Insufficient checking and verification I used to assume that if I knew how to do something and then did it, I did it correctly. Experience has painfully and expensively taught me that's the wrong assumption. I now assume when it comes to configuring routers and switches that anything I've configured IS in some way large or small, WRONG. In other words, I nominate myself as the world's number one ccie most likely to make configuration mistakes. Maybe I'm a bit dyslexic. Maybe it's because I hate configuring routers and switches. Maybe it's because my mental wiring just isn't configured properly for configuring routers and switches. Whatever the reason, I suck at configuring routers and switches and make loads of mistakes while doing so. But, yet on Wednesday I became a ccie. Having a deep awareness of my weakness in this area and yet being determined and convinced of my ability to join the club, I had to figure out a way to overcome this handicap. It wasn't easy. But, here's what I did. I practiced finding mistakes by using various show and debug commands. For example, I would misconfigured a dlci or ip address in a frame relay map and then study how that would affect the output of the show fram map command. I did the same for every technology covered by the lab. Slowly, painfully, tortuously, I got reasonably competent at finding my mistakes reasonably quickly. I still don't consider myself very good at troubleshooting but, what the hell, I'm still a ccie. So, my final words of advice to anyone wanting to be a ccie is this. Ask yourself, "What is your level of determination to become a ccie?" If your answer is, "I am 100% committed to this.", then figure out what your weaknesses are and how you're going to overcome them. If I can do this, so can you. Tim --- SPF loopback appearing with configd mask: 1- ip ospf network 2 - area range - requires the loopback be on a different area 3 - redistribute connected IPV6 address 1 EUI-64 2 Link Local 3 Specify address entirely (I think there's a fourth if you configure a prefix on a router and announce it to the network - auto config.) IPv4 address 1 - Static 2 - DHCP 3 - ppp (IPCP) I think it covers it all --- Try this: IP DOMAIN-LOOKUP LINE CON 0 transport preferred none Regards, Gary -----Original Message----- From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of BALAKRISHNAN Balaji Sent: September 29, 2005 3:10 PM To: ccielab@groupstudy.com Subject: DNS lookup on the router All, I want to configure ip domain-lookup so that the router can do reverse DNS lookup to resolve IPs in the trace-route. But I don't want the router to do DNS for all mis-typed commands as it will be very annoying. Can anybody know how to achieve this. --- Subject: Re: About CCIE lab To say the announce in the lab of getting results which will be block use the following search technique: keyword +univercd Very handy for narrowing down the results use it all the time. Regards Kevin On 10/6/05, Niche wrote: > Hi Guys, > > Is the search function enabled in the DocCD during the real lab exam? I hope > the search function is enabled or I have to get familar with the DocCD the > other way around. =/ ---- --------- Forwarded message ---------- From: "Arun Arumuganainar" To: "Cisco certification" Date: Thu, 6 Oct 2005 18:38:37 +0530 Subject: Arun Proposed Cisco Disposed !!!! Oops I may catching up with a Older thread !!! Never the less I wanted to share my experience !!!I attended my Lab in Brussels a week ago only to fail It was my first attempt and I still wonder how I could fail when the question paper that I got was so very easy !!! Never the less I just managed to fail !!! But the fact is failure teaches you lot more than what success can teach you Well when I sit up and traced back questions only to realize that I made simple and stupid mistakes that could have been well avoided...if my strategy was right !!! Even after failing on two exams ( SP and R&S) I sill believe that I am strong in Networking Technologies but I made a mess up with my preparation . I am sending out 3 important things we should do if we have thoughts about passing in the first time . FYI : I did not do any of these and failed . I came to know all about this when I did my post-martum !!! Here are my learning's . 1) Strategy before and during exams are very much important ...As important as your command ( or knowledge ) over Networking Topics . I would suggest every one to go through Brians( both Brians ) VOD on strategy !!! I too did went through the VOD ...but I never followed it and I paid the price . 2) Practice Sufficiently ( Pls. Note : Sufficient should not be interpreted as too much practice ) ~~~~~~~~~~~~~~~ R&S is stream has been the most researched track among all the CCIE Track . CCIE Proctor will find it difficult to set questions that are outside the things discussed in common workbooks available in the market such as ( IPEXPERT , IE and NMC DoIT labs ) This does not mean we need to manually do 50 or 100 Labs covered by all the vendors . I would say 10 Labs in any of the above vendors ( I used NMC and IP Expert and few labs in IE too ) is just sufficient . But we need to ensure we are fully aware of all the minor variation in each scenario on a particular technology . In this aspect I would strongly recommend going through Stuffs like IE's Advanced Tech Lab or NMC's Tech Lib . Of which NMC Tech Lib needs a special mention . As they have a special sections added as " SPOT the ISSUE " .. I like the way they documented the Tech Lib ...in the sense that they think the way of CCIE Candidate thinks and look for area where we can go wrong and document those !!! This is beautiful reference which I did not notice until my first Lab attempt got over . 3) Attend Mock Labs and Work on the results: ----