Archive for February, 2009
This document is an attempt to rework the old paper I wrote back in 2006. You can still find the old document here Original Scary Draft. Both documents attempt to present a structured approach for taking the CCIE lab exam. The following is a quick list of the generic core concepts you need to master in order to be successful with the exam:
- Control your psychological state.
- Analyze the lab exam using a systematic approach.
- Follow the strict time-management procedure.
- Apply repetitive and planned verification scheme.
3.4 You are concerned about the convergence times and CPU resources consumed in the backbone OPSF area. Configure all routers in the backbone so that they only recalculate a portion of the Shortest Path Tree when they receive local link state advertisements.
For the solution, visit:
In the first part of this blog series, we made it clear that you will face simulation questions in the CCENT exam, and we provided a link so you could practice with the interface before your big day. In this blog post, I wanted to cover some frequently asked questions that we receive about these simulations.
How do you use our new CCENT materials in order to ace your exam? Here is my recommended study approach…
Attention Professional and Expert Level Engineers!
Are you tired of interviewing entry-level staff with no real world knowledge or troubleshooting skills… the so-called “paper CCNA”? Instead of letting your associate engineers rely on brain dumps and memorization to pass their exams, help them build a solid foundation for the advancement of their careers with our new CCENT Class-on-Demand!
Developed from the ground up this course teaches core networking theory and configuration fundamentals through a structured approach, and develops real-world troubleshooting skills.
Using the same hands-on learning approach offered in our CCIE-level products, our CCENT Class-on-Demand will not only provide candidates with everything they need to pass the 640-822 ICND1 exam, but also allow them to hit the ground running in production network support roles.
Students will receive the following with our CCENT Class-on-Demand:
- Over 12 Hours of Class-on-Demand Video
- Over 120 Practice Exam Questions
- Hands-On Practice Labs
- Short, Focused, Self-Paced Sessions Led By A CCIE Instructor!
- Interactivity In Every Session
- Constant Review Through Assessments
- 24×7 Interactive Online Community Access
Visit http://www.internetworkexpert.com/ccent.htm to view sample videos and practice tests, and figure out if you are smarter than a CCENT!
And we’re back for an exciting conclusion to the CCIE Troubleshooting series. Just what fate is in store for our heroes? Well, if we’re anything like the Friday the 13th movies, you may need to wait about 20+ years to find out!
You’re probably asking yourself, “With the amount of stuff we’ve gone through already, you’re really telling me there’s more to be concerned about?”
Yup, that’s exactly what I’m talking about. So what next then? How about little unexpected zingers that may just confuse, confound and otherwise astound you?
Have you ever rebooted your router/switch and had it reply to you “Would you like to enter basic management setup?” Of course you have. All the time in practice labs! But what if it happened in the middle of your actual lab exam? You DID save your configuration, right? You didn’t see any error messages pop up did you? Well, how about that?
How about a bit of preventive medicine? When you start the day, in SecureCRT that you’ll be using in the lab, I would click on the Session Options and then on the Emulation (under Terminal in the left-hand pane). See the part about Scrollback buffer. Set that to AT LEAST 5000 lines. Gives you the ability to review things you’ve typed or what the router has said, or recreate your steps in case of an emergency.
But back to this dilemma. What do you do? Run in circles, scream and shout? While that may be entertaining, it would scare everyone else in the room and not be overly helpful to your cause! Whatever you do, DO NOT enter the setup mode. Before completely panicking, just do a “show start” and see whether your config was really saved or not!
If it did not save, go check your scrollback and see what error you missed. Then hope you have enough scrollback to reconstruct your configuration. THEN run in circles, scream and shout!
The BGP section for Internetwork Expert’s CCIE R&S Lab Workbook Volume 1 Version 5 is underway. A sample of it can be viewed here. The preliminary topics covered are as followed, but will be expanded before the final revision is released. Expect updates to be posted on this section bi-weekly until completion.
- Establishing iBGP Peerings
- Establishing EBGP Peerings
- BGP Update Source Modification
- Multihop EBGP Peerings
- Neighbor Disable-Connected-Check
- Authenticating BGP Peerings
- iBGP Route Reflection
- Large Scale iBGP Route Reflection with Clusters
Thanks for tuning in again! We’re back for more of the excitement known as Troubleshooting! Today we’re going to look at little more at some of the more nefarious (my word for the day) things that may come your way. How simple little commands can certainly change the way your lab is going!
In case you haven’t noticed by now, the CCIE lab is a largely psychological event. Technical knowledge is a very good thing, but if you can’t handle the pressure then it doesn’t help much! I still remember my first lab exam. Or more importantly the weeks leading up to my first lab exam, and I couldn’t make simple things work correctly! Stuff I’d been doing for years. And it was all in my head.
So what kinds of things can be on your lab which may have an impact on this stuff? Some are very simple, some are not.
So in the last post, I mentioned a little about process. The process by which we troubleshoot things (or how we even start our lab) may make a tremendous amount of difference in what our outcome, or at least our psychological state may end up being. Remember, you are there for the proctor’s entertainment. And sometimes they are very entertained!
Let’s take an obvious one. What if “no ip routing” was in one of your routers? “What?” you say… “Something THAT obvious, any CCNA could figure out, that’s just plain (insert appropriate word of shock or exasperation here).”
There are two types of troubleshooting that you’ll run into on the CCIE lab:
1. The “Proctor is Evil” Troubleshooting
2. The “Self-Induced” Troubleshooting
The latter type is by far the more time-consuming but also the most important. Basically you messed something up, therefore you have to fix it! (At least if you want the points) The reason it is the most time-consuming is because it could be ANY silly mistake or combination of silly mistakes along the way, and there is no predicting what kinds of things can be done to mess with your own head!
The most important rule with this kind of troubleshooting is time management. Set a time limit of 15 minutes. If you can’t figure something out in 15 minutes (no, I don’t care how “close” you think you are!) go do something else. Whether this involves a bathroom break, a soda/snack break, standing on your head on the high-quality lab chairs or simply moving on to another “service” or “security” task of your lab makes no difference. The idea is to separate your brain from staring at the same thing over and over.
The longer you stare at something, the more you see what you want and not what’s really there. Most self-induced errors are really small, and fairly inane. You know. Those “DUH!” moments once we figure it out. But time management is the consequence we suffer due to silly mistakes. Avoid it!
Anyway… on to the more exciting things. The unpredictable nature of the “Proctor is Evil” Troubleshooting. Having started my training career specializing in the old CIT (Cisco Internetwork Troubleshooting) class, I can greatly appreciate some of the humorous things that MAY get thrown into lab exams. The question becomes, if I don’t know what they are and there are many different things that could go wrong… What the heck do I do about it?!?!
Excellent question! Process, my dear. It’s all about process.
The leading question:
“Is it possible (and if so, how) to redistribute or originate a default route based on time of day?”
The short answer is “Sure, why not?”… But the longer answer has to do with how do we warp the forces of the universe to make that happen???
Well, start with what we know. We know we can do time-ranges in access-lists, right? Can we do them in standard access-lists (what we see used for redistribution all the time)?
Rack1R1(config-if)#exit Rack1R1(config)#access-list 1 permit 172.16.0.0 0.15.255.255 ? log Log matches against this entry <cr> Rack1R1(config)#
Nope. There’s a bummer. So we will need to use EXTENDED ACL’s in order to make this work. So now we are reaching the point of “Yes, it can be done, but it will make my head hurt.” as the answer.
First, as a little review, check out a blog we did last year providing some information on that sort of thing in conjunction with a distribute-list in different routing protocols.