CCIE Candidate

Well I can’t explain the nuances of queue management in WFQ versus CBWFQ yet, but I got through IE Vol 1’s QoS section. I was a little bummed there weren’t more MQC tricks in there, but it punched pretty hard on FRTS, and went through the various nesting tricks you can really get tripped up on, so I’m happy. Some of the new and/or weirder things I encountered:

• It’s pretty well understood that any bandwidth reservations made via CBWFQ (”bandwidth”) or Low-Latency Queueing (LLQ) are subtracted from the max-reserved-bandwidth, not the interface bandwidth. But I created a policy-map that used Generic Traffic Shaping (GTS) to shape an interface (”shape average” in the class-default), then from that policy-map called another policy-map that enabled LLQ for VOIP traffic … and it circumvented the max-reserve logic check. Interesting. Specifically I pushed the CIR down to 56k on the interface then set LLQ to reserve and prioritize 48k for VOIP. When I applied the LLQ policy-map directly to the interface it errored as expected. When I took the exact same policy-map and nested it within a policy-map that used GTS to shape the interface to 56k, it took the 48k reservation without a problem.
• There was a lot of material on Frame-relay fragmentation, which was nice. I’ve always known there were several flavors but not quite gotten around to examining them. Turns out the differences (for the purpose of basic differentiation and configuration) are pretty easy.
  • FRF.11 is puts a fragment header on all packets, while FRF.12 doesn’t bother with the fragment header if the payload size is less than the fragment size.
  • FRF.11 and Cisco’s proprietary fragmentation never fragment voice packets.
  • The way you determine which type of fragmentation you’re using is via a simple command under the DLCI - vofr = FRF.11, vofr cisco = … well, Cisco, and not specifying leaves the default of FRF.12.
• One thing I didn’t even know existed was Frame Relay PVC Interface Priority Queueing (FR PIPQ). This allows you to classify entire DLCIs into the old-school priority queues on an interface. It’s just a simple matter of enabling the feature via the interface level “frame interface-queue” command (I always wondered what that did…) and writing a quick map-class for a specific DLCI, using the same interface-queue command.

Other than that, they went over many of the bewildering numbers of ways to accomplish the same task in QoS. I believe that this is a large part of why QoS is so confusing. If you want to match and prioritize VOIP, for example, you can:

• Use priority queueing to match an ACL for the UDP ports
• Use FRTS to call the same PQ
• Use FRTS with the ip rtp priority statement
• Use LLQ with CBAC
• Use LLQ with the match ip rtp statement
• Use LLQ with an ACL
• Use FRTS to call the LLQ policy-map
• Send all VOIP traffic down a specific DLCI and prioritize *that* via PIPQ

To be honest I’m probably missing a couple. Fortunately it’s usually pretty easy to figure out which one they’re asking for, but only if you know all of them.

So on to Narbik’s QoS section, which is rather daunting, but something I’m looking forward to conquering, which I have about 1 hour to do before my wife gets annoyed enough to throttle ME.

If you truly understand something, you should be able to explain it to a child.

QoS is a fractal topic in that it’s not terribly difficult, but you can break it down into many sub-topics, each of which are of equal complexity to the whole, and each of which can be further reduced to smaller, equally complex sub-topics. After returning to QoS after a couple of months focusing on other technologies, I had some brushing up to do, and spent about 3 hours debating and arguing the usage of the term “queue” in the WFQ and CBWFQ sections of Odom’s QoS book. His interchange of the words queue and flow really confused the bejeezum out of me until I remembered that packets are never moved around from buffer to buffer, the pointers to those memory locations are. Like I said, not terribly difficult, but about four fractal layers deep in the quest to understand the inability to use WFQ with WRED on an interface while making sense of the ability to mix CBWFQ and WRED.

Hopefully I’ll complete this understanding through today’s session and have a solid enough understanding to explain the nuances with 100% clarity.

I’m looking into Cisco’s Embedded Event Manager to proactively monitor Catalyst 6500 system health.  The idea is to schedule GOLD tests (and perhaps query other system attributes), and have EEM react to any bad news that comes up.

My question - are any you using EEM/GOLD to do proactive Catalyst 6500 monitoring?  If so, what are you checking?  What thresholds have you set to trigger an EEM reaction?  Has EEM saved your network from catastrophe?  I am aware of the EEM community, but I also want to see what you folks have to say.

You’ve noticed the left and right columns of information on this blog.  Because they’re always there, they might hit your noise filter.  Well, check the info out once in a while, as I do I keep them updated.  For instance, I just added Matt Hill’s blog, a CCSI in Australia just starting the journey.

If you are an active CCIE blogger and want a link from here, I’m glad to do so.  Unicast me your URL, and I’ll check it out.

If you don’t want the hassle of maintaining your own blog (maybe you only blog once in a while), consider blogging here.  Send me a URL example of your writing.  I’d love to add more authors to the CCIE Candidate blog.

Fights are won in the gym …

I finished Narbik’s workbook on BGP this morning.  It’s taking me a long time to get through them because I’m actually going through IE Volume 1, then Narbik’s book on every subject.  It makes for a slow, plodding pace, but ensures that you cover everything possible (I hope!) at least once, and if there is gratuitous overlap you just skip it or practice again if you think you need it.

This approach has been working for me.  IEv1 covers a lot of basics, and their excellent Class-On-Demand (COD) really delves into some common, yet weird, things you run into and can truly tank your Saturday study session.  I’m sure most candidates have spent an hour or more banging their heads on the wall trying to figure something out only to find out it was a ridiculous mistake (like using contextual help on PPP authentication setup and accidentally appending a space to your password … but only on one side).  Then you look back at how little you got through that day and it’s really frustrating.  That’s where the COD really helps - I put mine on mp3 and listen to it while I commute.*

Where Narbik’s books come in is to bridge the gap between IEv1 and IEv2.  I’ve found that many of the more advanced features are covered in IEv2 and discussed in the COD, but not covered in IEv1.  This means that they really are comprehensive, but not in one spot.  I wanted to hit a single technology so friggin hard that there’s nothing I could get that I haven’t at least seen before … before I do mock labs.  I believe that fights are won in the gym, meaning you train like hell, and hopefully your opponent (the mock labs, and ultimately the real lab) are a walk in the park because of it.  And if they aren’t … you’ll be glad you trained so hard.

Also, Narbik’s exercises have great explanations.  IE has great material, but many of the explanations are on the COD, and most of the time there’s a gap between running into something during CLI time, and running into the same thing on the COD.  So between the two of them I start off doing basic things, go more in-depth, switch workbooks, and get really really deep, and then in the car listen to the subject matter on the radio.

This has paid off handsomely.  If you read my posts on the Unitek bootcamp, you might remember me saying that I didn’t have that much trouble with the IGPs, BGP, or anything L2 outside of QoS (ug…).  Well there’s a reason.  Those are exactly the topics I’ve done deep dives on with IEv1 and Narbik’s books (I was about 90% done with BGP when I went).  I previously did 16 IEv2 labs, read a lot, and listened to the COD, so I was able to function in the other areas, but I couldn’t own them like the ones I focused on for a week or so at a time, and I ended up looking a lot of things up in command references (or trying to…).  My goal is to be able to configure any technology’s FACE OFF, not just function or get it done.

So starting tomorrow I go deep on QoS (L3, with a revisit of L2).  QoS is the last major topic left, then it’s multicast, security, IOS features/management and IPv6.  As soon as I pummel those technologies until they say my name, it’s on to the IEv2 mock labs again, where I’ll need to work on speed, accuracy, strategy, and all the other things I need to polish before the big day.  As per Narbik, I’ll know I’m ready when I walk in there and I don’t care *what* they give me. 

* Don’t ask for it, I don’t give it out even to co-workers.  And I haven’t used p2p file-sharing for anything at all since about 2002, so IE can rest easy - no one is getting it for free, deliberately or otherwise.

I’ll preface this post with the statement that I feel like the class was worthwhile, because while my opinion of the class is not entirely negative, it isn’t what I might consider marketing material.  So to be clear I’m glad I went.

It is often said that the ISC2 CISSP certification is, “a mile wide and an inch deep.”  To develop a class that covers the CCIE R&S Lab exam must be especially challenging as it’s a mile wide … and a mile deep.  To this end it’s really hard for a one-week class to succeed OR fail entirely as the IGPs, BGP, and QoS could each easily command a week-long bootcamp.

Format and Class Structure

That said, I would not recommend this class to anyone who was not already at least 75% through their lab preparation.  The reason being there isn’t much guidance, there is practically no lecture, and there is nothing built into the curriculum or schedule to deepen a student’s understanding of a given technology.  This is a six-day marathon of hands-on lab work, where you are presented with problems and YOU, the student, pound through them.  If you are not already comfortable enough with OSPF to rattle off exactly which LSA types are allowed in each area type, this is not the place for you to be.  You can certainly ask Rahim questions, and I saw him working patiently with each student individually (myself included), but you can’t ask him for in-depth explanations on everything, there just isn’t enough time in a week.  This is very much a polishing up class.

For contrast I will look to Narbik’s class, as it’s the only other lab prep class I have attended.  Narbik’s class has a lot of lecture.  The hours were just as long in each class, but the difference was that Narbik spent the face-to-face time doing deep dives on all the major topics (except IPv6, but that’s probably the easiest area on the blueprint), then assigned the lab work as homework via in-depth books he developed and gave out during class.  These books reinforced the lectures directly, and Narbik was very open about there being no way a student would finish the workbooks that week, or even the week after.  In fact he estimated the workbooks would take at least three weeks to complete, and a candidate would have to work through them multiple times.  Then he told us to use a different vendor at least a little bit to see the different approaches, wording, etcetera.

Focus of the Class

Another key difference that I alluded to but deserves explicit attention is the focus on test versus technology.  Narbik is quite adamant about learning the technology; learning it down to the nook and cranny, and in some cases trying to get in the code developer’s head.*  This was also pretty heavy for someone just starting out on the CCIE Lab path, but the emphasis on fundamentals and the lab books with their detailed explanations made the class more helpful to people who weren’t going to take the exam within a month.  This underscored Narbik’s philosophy that if you really get your hands dirty with every topic on the exam and know it inside and out, the test will be easy - therefore that should be your goal and, hence, your focus.

The Unitek class did not go into fundamentals.  Rahim went over tips and tricks, but never actually explained how anything worked unless you asked, and even then the focus was really on passing the exam.  For example, I’m still a bit shaky on some of the nuances of QoS, and Rahim was able to clarify that “shape peak” does the same basic thing as “shape average”, but you get to burst up to twice the amount you specify with “shape peak”.  Ok, fair enough.  Now I can remember that forever because that made perfect sense, but I have to look up the mechanics of the traffic shaping via “average” versus “peak” on my own.  I’m alright with that, but others might not be. 

There was a little bit of lecture on Saturday afternoon, but it was random.  It covered things Rahim felt we would see on the exam, jumping from one point to another in a very staccato manner, and was mostly him telling us to make sure we understood the topics he mentioned, with some light explanation. 

Preparing for the Exam - the Long, Lonely Road

One thing I found conspiciously absent from the class was preparation advice.  There was some on Saturday afternoon, but it held the same staccato rhythm** as the technology poking we got (it wasn’t actually a lecture on anything).  There was no mention of finding a vendor workbook to study from (or an alternate method if you don’t want to), preparation strategy, order in which to study material, suggested books, how to build or rent a lab, study schedule, how to gauge readiness, etcetera.  The few students I talked to about vendors didn’t know what I was talking about when I asked them which vendor they were primarily using, and I think they could have really benefitted from a quick rundown of the logistics of getting this done.  I know I personally wasted about three months milling about when I started and I wish someone had grabbed me by the shoulders and pointed me in the right direction (someone eventually did, thanks Craig Hammond).  Since this was a class on how to pass the exam I think it’s fair to expect this kind of information.

Just as important, there was nothing to prepare students’ minds and spirits for the ordeal ahead.  This isn’t some weird, new-age Los Angeles trophy-wife voodoo - there is every chance that a candidate will spend a year of dedicated study time preparing for the exam, and fail.  It’s important to be prepared for the brutal sacrifice that this takes.  Telling students they can accomplish this feat is nice, but not warning them what lies ahead is the same as sending colonists on LV-426 into an alien ship without telling them of the potential dangers, and look how that turned out. 

Summary

To summarize, the Unitek bootcamp seems far more geared toward people who are pretty much done studying and just want to do several proctored mock labs a few weeks before they test.  If that is your strategy then I would actually recommend this class.  Unitek has a bundle package where you pay extra for the class and stay in a nearby hotel (which has a passable breakfast buffet), get shuttled back and forth to class every day, and get your lunches and dinners provided every day (various foods, you get to pick from the menus of nearby sandwich joints, and they were all fine).  This was nice in that it freed us up to focus on beating on the material, and it also allows a candidate’s manager to pay for the entire trip, minus air fare, via Cisco Learning Credits, which might make it easier to get you out there.

A couple of other students seemed unhappy with the class, and one told me that he could have done this all on his own.  True enough, and the $4,000 price tag (without the hotel deal) seemed steep to me for a week of proctored lab work since you can get take proctored labs via the major CCIE training vendors for far less, but for me the true joy was getting to focus 100% on my studies for 6 days straight.

I hope this helps. 

* A quick side note.  I was flipping through John Moy’s “OSPF: Anatomy of a Routing Protocol” again a few weeks ago (it’s been years) and after truly learning the protocol and labbing it up 100 times, some of the things he said, like ABRs without an area 0 database being prohibited from using type-3 summary LSAs to make routing decisions, tied so many things together it brought a tear to my eye.  I immediately and enthusiastically shared that specific epiphany with my wife, with predictable results.

** I’d like to take a moment and recognize the word “rhythm” as my nominee for the grossest violation of phonetics in the English language.

I went back to work last Thursday. The day started out as a normal day. Plowing through endless piles of e-mail. Trying to figure out what projects I should actually be working on. Reviewing change controls. After a while, a little problem comes up with a DSL line on one of our buildings, so I head over to take a look at it. Not 30 minutes away from my desk, my cell goes off with an “all hands on deck” call because of a problem in one of our data centers.

I speed-walk back across the campus to my desk, and hop on the conference bridge. One of our core 6500s took a nosedive, and not a graceful one. We run dual-core 6500s, and each 6500 has dual sups. We still don’t know exactly what happened, but one of the sups on one of the 6500s went into a death spiral, but not badly enough to cause an SSO/NSF failover to the hot standby sup. The failover did eventually happen, but it took about 7 minutes. During those 7 minutes, life was ugly. EIGRP adjacencies flipping out, HSRP groups confused, firewall HA clusters losing their minds, etc. But after the sup finally failed over, traffic began forwarding normally - mostly. Something about the crash took a WS-X6548 card down, too. The card showed ethernet link for everything connected, but was only showing inOctets - no outOctets. That caused some firewalls to lose their minds, because the HA between the firewalls was still all confused. Async routing through firewalls resulted, and oof…what a mess. Once the badly behaving WS-X6548 card was identified and the firewall ethernet connections moved to a different card, life settled back down.

I volunteered to open the TAC case to try to figure out what happened. I looked for the crashinfo ahead of time with a good ol’ “dir all”, but didn’t see anything. I posted a “show tech” for the TAC engineer, hoping that would help. No luck. Without the crashinfo file (which no one can explain why it wasn’t created), we have no idea why the sup took that nasty nosedive…or why it took about 7 minutes for the failover to occur.

We do know that the IOS we’re on is deferred. Obviously, it wasn’t deferred at the time the 6500s went into production - but it is now. We don’t know why it’s deferred (TAC is researching that for me, since the deferral notice for our particular IOS is not publicly available on cisco.com anymore), but deferred usually means Not Suitable For Production. An IOS upgrade was on the board for this year anyway, since we need to go higher to support the 10 gig cards we’re installing. I’ve been hoping that something in the 12.2(33)SXH family gets certified by the Safe Harbor program, since there’s a lot of advanced IOS features in there I’d like to have at my disposal on my core cats.

So my first day back at work was not a gentle easing back into things. Nope - got thrown to the wolves right on day one. <sigh> The kind of an outage we experienced certainly would have hurt less if we had the staffing levels to do more design and less implementation. On my team, we’re usually so busy making stuff go, that we rarely get the chance to do design review and get improvements on the board. We get to do redesign when Something Really Bad happens, and we’re forced to react. That’s life, I guess…but it means my life between now and our peak season (the holidays) are probably going to be a smidge more stressful than I might have liked.

The last three days of the Unitek bootcamp consisted of two full mock labs. The first one took me the full day on Thursday, and the second one actually took the full 12 hours on Friday plus about 3 hours on Saturday morning. That was the only time I failed to complete the coursework in a day, and I was pretty disappointed. I take solace from the fact that the lab was massive, but still, I believe that if you have a thorough understanding of the technologies, they can pile on as many caveats as they want and you’ll still get done in 5-6 hours.

Thursday’s lab only had one 3550 for the switching section, leading me to believe that it was an old-school lab from before they added the four-switch architecture. That didn’t bother me though, since I figured it just meant more exhaustive IGP/BGP/QOS sections. Also, I believe it’s important to remain fluid. What happens if you walk into the real lab exam and there’s two switches instead of the four you thought? How about three? What if they give you the BGP tasks mixed in throughout the entire lab? I don’t recall ever seeing any binding document from Cisco saying they would give us X, Y and Z, only that they could. Just roll with it, do your job, then go online and complain about it.

At any rate the first lab wasn’t that bad (just wait for the second one…). The interesting problems and observations:

• When you use area range, it creates a DNA type-3 summary LSA. I had never noticed this. It’s not terribly important in the scheme of things, and it certainly makes sense, but it’s nice to know for spotting things easier in the OSPF LSA database.
• I’d never filtered routes in OSPF based on route-type before. After tinkering with a task for a while I used the metric to filter OSPF E2s and let everything else go through. This worked, but technically it’s inexact. Another route could potentially have a cost of 20 and you’d zap that one too. Rahim caught that and suggested the route-type instead. I could have sworn I’d tried that and it errored, but sometimes a few hours into the heat of a pretty intense configuration things like that slip past you.
• I’d never applied WRED directly to an interface before. Sounds weird, and a little noob-ish, but I’ve always wrapped WRED up in a class-map with other stuff.
  • This is a theme I’ve noticed. If you just focus on learning the hardcore configurations like nesting two layers of policy-maps inside frame-relay traffic shaping, some task will inevitably ask you to do something like apply WRED on an interface based on IP Precedence, and you will go off the deep end, writing up some really cool 15-line, object-oriented solution when you could have just done in two lines on the interface.

interface FastEthernet0/0
random-detect
random-detect precedence 3 35 50 25

That was pretty much it for the first lab. I found it manageable but not easy. The second lab however… Ouch. My first impression was, “wow, that’s a LOT of stuff to do.” This one had four switches … kind of. Each student had a 3550 and two 3560s, and then there was a shared 3560 we couldn’t log into but was pre-configured for each of our pods to peer with, neighbor up with, route through, etcetera. As with the first lab, I could bemoan how lame this was blah blah blah, but in reality I think it kind of worked in my favor, since my home lab has the full four switches. I’ve never *not* been able to look at a switch’s configuration, and even the backbone routers aren’t running OSPF in the IE Volume 2 mock labs. This forced me to troubleshoot blindly, which is actually how network engineers are often forced to troubleshoot when faced with such detailed symptoms as, “the internet is down.” * Also, who’s to say some proctor isn’t writing up a lab right now with access to one switch removed?

Some of the more painful reminders of my humanity:

• DLCIs were deleted on hub router 5, but up on spokes 3 and 4. I nagged Rahim and he gave me the “it’s not my end”. Yeah, wrong lmi-type. Hopefully I’ll catch that before nagging the proctor so as to not embarrass myself.
• I spent the better part of an hour looking for the reason an OSPF adjacency wouldn’t form between a switch I could control and the one I couldn’t. I immediately ignored MTU on my side, but didn’t think about the other side. Turned out that the MTUs were different, and the other side was not terribly interested in ignoring MTUs. My thinking was *inside* the box on this one. After a lot of frustration this eventually occurred to me and I flipped my 1546 interface MTU to 1500; the adjacency came right up.
  • While guessing MTUs would be a cheap shot, I felt that requiring a candidate to set it back to the default was reasonable, and again it mirrors some of the garbage we have to deal with routinely, like shouting over the phone to a remote-hands technician with no Cisco experience inside a noisy data center, asking him to read the output on a screen to you.
• I tend to use the 3560 documentation for the 3550s as well because it’s more extensive, things are generally the same, and I find it more organized. This is a bad habit that bit me Friday when I set up a remote SPAN session between a 3550 and a 3560 and didn’t assign a reflector port. This is a 3550-only requirement that forces you to burn a port for SPAN to steal buffers.
• I had an ipv6 tunnel refuse to work because I had “ip ospf 8 area 0″ instead of “ipv6 …”. My troubleshooting didn’t even take me there because I couldn’t ping from one tunnel IP address to the other, so I focused on reachability, trying ipv6ip and gre. The reachability was missing because one tunnel end was “ip unnumbered fa0/0″, which I didn’t know would cause problems without a routing protocol providing reachability. I didn’t know why the encapsulation was failing in my debugs. This tells me I need to do a deep dive on ip unnumbered.
• I mis-read a BGP question again. A task wanted me to allow a neighboring AS’ routes, but not the routes of it’s directly connected peer ASes. I denied everything not directly connected, which was more than the task wanted. There were three ASes in a row, and I needed to block prefixes originating from the middle one, not everything past the first one.
• A kind of weird one was getting nailed on LACP vs PAgP. I used the correct protocols in each case, but I didn’t explicitly state “channel-protocol lacp” or pagp. I’m not sure what the point of that command is, and Rahim admitted that it’s redundant. I’m confused as to whether I would want to include this as the proctors may believe that I don’t know it’s not a required command, or whether I should leave it out and risk a script missing it or someone just wanting it in for completeness.
• I got nailed on a task asking me to drop .jpegs and .gifs. I did a “match protocol http mime gif” instead of matching “*.gif”. I haven’t done my deep dive on QoS yet so I haven’t mucked much with MIME types, but this irks me.
  • Logically if IOS is looking at the protocols, it shouldn’t matter if a GIF file has the “.gif” file extension. That it matters tells me that IOS is not really matching the MIME type. It’s matching the HTTP protocol, then looking for text strings within it. I’ll look more into this when I take a fistful of QoS, which will probably be next week. I’m also going to go hammer on some of our more talented Unixy developers for MIME information. We have some frighteningly smart developers.
• I was quite confident that I had nailed the IP Phone-based L2 QoS, and rightfully so, I got it correct.  I simply put the configuration on the wrong switch.  As far as mistakes go …

On a side note I got to configure MST again.  For some reason I find MST really elegant compared to PVST.  Maybe it’s because my production environment has 10 million STP instances running around torching the place like a bunch of drunken soccer hooligans, or maybe it’s because we’re not actually utilizing the ability to modify STP characteristics on a per-VLAN basis so we’re incurring the overhead without any benefit.  Whatever the case, I hope they give me MST on the exam, it really makes my Feng Shui sway.

* I’m been doing this since late 1999 and, all undersea cabling “accidents” aside, never have I seen the internet go down. They just occasionally put it on floppy.

I should start by saying that my first blog was inaccurate. The class was not 5.5 days, it was a full 6, and only two of the days lasted less than 11 hours for me (most the class stayed pretty much the same hours). See? I may mangle details here and there but my retractions are on page 1. Without further ado, the class.

Day 3 - BGP.  As per the format of the class there was no lecture and handouts, just pop open the workbook to the section for that day and go to work. I’ve hit the IGPs and BGP pretty hard, so I was actually happy with my performance in those areas, which is not to say I nailed them, just that the mistakes were not conceptual, and there was nothing I read and had no idea how to solve. Well, ok, one thing nailed me pretty good, but I understood the mechanics, just forgot to check for communities. Some of the more interesting problems:

• I got nailed by funky wording again. A task asked for R4 and R6 to set up one iBGP peering session each. I interpreted that to mean one iBGP peering session *with each other*. I was wondering why the design left R2 out there all lonely … it didn’t. R2 was supposed to reflect for them; this cost me about 10 minutes to undo the damage and do the right configurations.
  • This was a new experience. Thus far I’ve used IE and Narbik’s material to study, and both have just told me where to build peering relationships. I found the vague, “build two iBGP peers within AS200″ wording to be a fun distraction. That’s not the same as hoping they do that on the exam, but it was a neat thought exercise.
• One question asked me to maintain a peering session between two ebgp neighbors, but send no updates from R1 to R2. It then ruled out my ability to use ACLs, prefix-lists, as-paths (including as-path acls in filter-lists) and communities. I also had to keep sending routes to R1’s other neighbor, so that ruled out throwing the distance to 255 on all BGP table entries. After mulling this over for about 20-25 minutes I took a 5 minute break. I still couldn’t figure it out, so I asked Rahim, who tried to lead me to water, only to find me unwilling to drink. After asking me what I’ve been using all day to manipulate routes (”route-maps with various attributes tacked on”) he hinted that the route-map was the key. Clear as mud. He finally gave up and mumbled the words “empty route-map.” Doh! So obvious it was impossible to figure out. By the way, has anyone seen my sunglasses?
• The task that took me the longest asked that I send a /21 aggregate upstream without modifying the as-path, which in this case worked out with as-set. Unfortunately I couldn’t get the dang-fangled route to go upstream without taking the as-set off. It turned out that an earlier task had required me to put the “no-advertise” community on a specific route within the aggregate, which prevented the /21 from going anywhere. I knew about this problem, but just forgot to check for it. A simple “show ip bgp x.x.x.x” on the aggregate would have blasted the problem out into the open. By dropping the as-set off of the aggregate command, I did an end-run around the community stripping requirement as the attributes of the specifics were not inherited by the aggregate.
• One thing I think I could have done more elegantly was anti-transit filtering. On one neighbor I used an as-path acl, but I wasn’t allowed to use the same technique on both sides, so I used a simple acl on the other side to block the single outbound route. A more elegant solution would have been to tag incoming routes from that AS with a custom community and filter those routes out from updates to the other ASN.
  • I thought this was a key mistake. While technically fulfilling the requirements of the task, I might very well have not gotten the points because there were multiple solutions, and mine was not the best. It worked on that single route, and the task didn’t mention blocking “future prefixes” or anything like that, but there is a certain amount of subjectivity involved, even in engineering. This underscored the importance of being so dreadfully familiar with every solution to a given problem that you can list them mentally in 10 seconds, then reorder them according to validity and applicability.
• One last goofball thing I did - One requirement asked for a regex that would only allow the neighboring AS’s routes, and the routes of his directly-connected peer ASes. I was quite proud that I nailed the regex immediately, as I’ve never been that proficient at regexs (my greps are atrocious). I was so proud of myself that I managed to *deny* the routes I was supposed to permit with the regex.
  • Just another example of a silly mistake that could have been caught if I had finished faster and easier, thus giving me time to go back and re-check everything at a relaxed pace. Everything wraps back around to knowing the technology like it’s your name.

A few housekeeping items related to the CCIE Candidate blog:

1. The main URL has been updated from “ethanbanks.net” to “cciecandidate.com”. The site will still work just fine to “ethanbanks.net” for quite a while, but if you link to this blog, I’d appreciate it if you’d take the time to update your blogroll to the new URL. That’ll hose up the Google rankings for a while, but it should recover eventually.
2. Calling all budding authors. You’ve noticed the great posts by Keith Tokash. If you have some quality content you’d like to share with the CCIE community, please unicast me with some URL examples of your writing. If I like what you’ve done, I can set you up as an author so that you can blog here. This is the most popular CCIE blog out there at the moment, at least until CCIE Pursuit’s awesome blog passes this one in the Google rankings. My point is that your voice will be heard, as there are a lot of readers here.
3. I plan to transform the CCIE Candidate site from a blog focused on me to a site that is community-oriented. How this will come about, I’m not exactly sure yet, but that’s the direction I’m headed. My vision is for the site to become a central repository for candidates who are trying to achieve the CCIE certification independently. I really, really want some quality half- and full-scale labs made freely available to candidates. Practice labs are the single greatest tool in effectively preparing for the CCIE challenge.
4. I am planning to move this site to a higher speed link within a month or so. The line this site hangs off of now needs more pipe than I can pump into my basement cost-effectively. I’ve chosen a virtual-server vendor, but I have a whole bunch of sites other than this one that I care for and feed. Moving to a new hosting platform is going to be painful for me, but it has to be done.
5. Finally, thanks for all the traffic I’ve seen over the last few days since my success in RTP. Over the last 3 days, CCIECandidate.com has seen roughly 30K hits, around twice the normal volume. You guys blew the ceiling out of my web stats…awesome.

Keith again. Yesterday I talked about the difference between the two bootcamp styles, but now that that’s out of the way, let’s get groovy on the tech-talk. This is a 5.5-day class in the Fremont facility. This evening marked the end of the fourth day, so I feel I’ve got a reasonable amount to discuss. As an aside, Fremont is the perfect place for a hardcore class like this. I think one vendor has a bootcamp in Chicago, which is far too fun a place to be studying all day and going to bed at 9pm. Fremont on the other hand … it’s like no one has ever seen a grown man with a mohawk. Weirdos.

Day 1 comprised of what felt like a couple of half-labs. Nothing too fancy, do a little IGP, some redistribution, BGP, a little QoS, the normal routine. I didn’t have too much trouble, which isn’t to say I did a great job, just that I was able to dig around until I got everything done. More or less. Some of the things I ran into that gave me problems:

• I don’t run DHCP servers on routers. I haven’t since about 2000, so sometimes I have to look up simple things like option-82. Unfortunately the doccd lumps option-82 in with DHCP snooping which led me to the somewhat dubious conclusion that I needed DHCP snooping to use option 82. You don’t, and I wish the documentation was clearer on this. Maybe it’s spelled out somewhere and I just missed it?
• Another conclusion I gleefully leapt to was that the requirement for a switch to “access the MAC address even after a reboot” meant sticky port-security. They were actually looking for a static MAC entry. That one could have gone either way, but port-security also limits the number of MAC addresses on the port, so technically I went out of scope. Next time I’ll look for something alluding to MAC address limitations, ports shutting down, MAC addresses in running configs, etcetera.
• One thing I flat out did not know was that RIP disables split-horizon when applied directly to NBMA physical interfaces. Hmph. I’d like to hear a transcription of how that conversation went. At any rate I got nailed on that again Thursday. Bah.
• Another easy one that got me was mincir in Frame Relay. Mincir defaults to 50% of the CIR, and IOS has a kind of safety feature that stops you from allocating more than mincir when you’re doing bandwidth guarantees - it kicks up an error and refuses the command. The easy way around this is to increase mincir, and if a task requires that you allot the entire bandwidth of an interface it’s really your only solution.
• I configured TCP Intercept correctly … almost. This is another feature I’ve never used in production and only lab up every few months. I got everything right except I overlooked the fact that by default it is in watch-mode, meaning it is not a proxy. I set up all the timers but forgot to set it to intercept mode.

Day 2 hit OSPF pretty hard, and covered some easy multicast areas. I was surprised to see that there were no RPF failures in any of the multicast configurations. My primary study material thus far has been IE Volume 2, and RPF failures are a favorite torture device of theirs. I was actually fresh enough after finishing day 2’s work to start looking it over before Rahim gave me what-for, and I managed to catch a few stupid things like forgetting to advertise a couple of loopbacks into OSPF and leaving off the “no-summary” on a stub area ABR. Easy points there. Some things I *didn’t* catch were:

• I neglected to apply the authentication key to an interface. I alias “show ip ospf” to the letter “o” because I use it so much, and I checked “show ip ospf neighbor” and “show ip ospf interface” multiple times, even grepping out things like “then” (that picks up “Authentication”), but this half-way up neighbor eluded me because it was on a broadcast network, and in my rushing to and fro’ I just assumed that the 2-way state was two DROTHERs being themselves. Meh. Assumptions really kill you. A simple clear ip ospf process with debugging turned on would have shown exactly who did *not* neighbor up after the smoke cleared.
• Rahim admonished me for using differing OSPF network types. I made an NBMA hub router p2m, and the spokes p2p, and just changed the timers on the hub. Rahim said this would result in a corrupted route table. Other vendors have repeatedly and confidently said that this will work just fine, but if they don’t ask for different type or mention timers, I’ll just do all p2m next time.
• It turns out PPP Chap authentication is even easier than I thought. I had R6 authenticate to BB3 via PPPoFR and added the line “ppp chap password cisco” to the virtual-template interface. This turned out to be unecessary as I already had “username BB3 password 0 cisco” in the global configuration. This was new to me - I always thought that the username was for one-way authentication only. I still had to specify the hostname on the virtual template, but after removing the password line and flapping the interface with ppp authentication debugging on it worked fine.
• L2 QoS on the 3550 … Rahim showed me a great trick today. I spent about 45 minutes on five simple QoS tasks, and I still missed a command on one of them. I trusted a cisco IP phone on a switchport with “mls qos trust device cisco-phone”, but forgot to “mls qos trust cos”. I also spent a lot of time remembering and looking up how to change COS and IPP maps. Rahim popped on the box, went to an unused port and did a “auto qos voip cisco-phone”. This created a bunch of crap, some asked for, most not. But it had all the required commands that you can manipulate in notepad and paste into your target port. Then simply default your dummy interface. BAM! 10 minutes or more saved.
• WCCP on a L2 device confused me again by being too easy. I only configure it every few months, and I always forget that there are only two commands. You just tell the SVI with the web clients to “ip wccp web-cache redirect in”, then enable it globally. The *output* interface is determined by the protocol, so I need to stop searching the docs for how to configure it.
• Multicast helpers threw me again with a couple of small details that the docs didn’t cover, or covered wrong. Specifically you only need the ip directed-broadcast on the first incoming interface, but the docs have it on the outgoing as well. Worse is the doc showing the multicast-to-broadcast conversion configuration on the outgoing interface, when it should be on the interface on which the multicast stream is entering the last-hop router.
• IPv6 was really frustrating. It wasn’t hard, it was just that I needed to change a neighbor discovery timer and wanted to check it in the docs first, only to find that the IPv6 command references for 12.3, 12.3T and 12.4 are all gone. This includes the master index AND the command reference. All links point to some stupid documentation index page. I hope Cisco fixes this before I take the lab.

There’s even more excitement where that came from, but my eyes sting and this post is already pretty long. Overall I’ve been able to finish the material every day so far, but had some reasonably large problems with my finished configurations. The good part is I’m out of my comfort zone - the same chair, the same keyboard, the same cat, the same interface numbers going to the same places, etcetera. Being on-site somewhere else makes it feel like a test too, and it drives me even harder than normal. And while I’m getting punished on IOS features and L2 QoS, I can take solace in the sound drubbing I’ve handed BGP and the IGPs.

Hi *, I’m Keith, Keith Tokash, although I’ve always been partial to “Genghis” (my wife refuses to oblige me).  Just wanted to add an introduction so no one wonders why Ethan is taking a bootcamp after he passed the exam.  I’m about a year into prepping for the R&S lab and would like to contribute a little, so here I sit, sharpening my tongue.  Thanks to Ethan for letting me do this, and of course a we’ll hoist a frothy mug in salute of his triumph.

I’ve been fortunate enough to be able to sign up for two CCIE R&S Lab bootcamps at no charge to myself - work paid for Narbik’s camp*, and VARs gave us enough Cisco Learning Credits to pay for the Unitek camp, where I find myself this week. I decided to write about the bootcamp experience because the two camps have been extremely different, and both helpful.

Starting with Narbik’s camp. There has been some furor over Narbik and his class on the groupstudy.com mailing list in recent months, but to be honest I don’t feed the drama llama unless someone gives me beer first. Narbik’s class was, as professed by many, excellent. I won’t go into too much detail here regarding it because Ethan and many others on groupstudy have already done so.

The format was a solid mixture of lab time and lecture, with Narbik giving us a thorough working over of most major topics on the lab exam. I say most because he notably skipped IPv6, and no one can cover everything on the lab in a week. Prior to attending his class I had banged through 16 of the IE Volume 2 mock labs, and spent a few months self-studying before that. I had also listened to most of the IE class-on-demand, many several times, and read a mountain of material. Narbik still managed to clarify a lot of things, and his lab exercises covered things I hadn’t seen elsewhere. Overall I learned a ton and felt that I was just advanced enough to get my money’s worth.

Unitek has a bit of a poor reputation from my inquiries. No one could really give specifics, but everyone was really hesitant and dodgy when I asked about Unitek. I believe I know why now and it’s not because the class is of low quality. The format is what appears to be more typical of bootcamps. After asking around about various camps, most seem to give you a lab or set of labs and the instructor hovers around the students while they work on the material. There is no lecture in the Unitek class, we show up and start banging away on the lab material at 8am, and stay until you feel like you’ve had enough. Tonight I left at 7pm, Monday and Tuesday, 8pm.

The instructor is a CCIE R&S/Security named Rahim Raoufi who has been consulting and teaching for years and does just fine. I’ve heard of bootcamps where the instructor pretty much tosses the students the material and leaves them to it, but Rahim seems to spend about 60-70% of the day working one-on-one with students. I haven’t asked him for anything unless I’m either done with the section and want him to review it with me or, like today, was just plum stuck. In both cases he cleared things up for me and was able to go into solid depth so I understood what was happening rather than just remembering to use a certain keyword.

My hypothesis on why Unitek has a less than stellar name is two-pronged.

1. It is run as a company first and a school second. I’ve always enjoyed martial arts, and I’ve noticed the same thing in that realm. Every school has to make a profit, and every profitable school should strive to provide an enthusiastic, dedicated educational experience. It’s just a matter of which the school in question prioritizes.

2. Although Rahim is an excellent and tireless instructor (I also took his CCIE R&S written boot camp, which was almost all lecture), his name is not attached to the course. I looked all over the Unitek web site and couldn’t find it, although I must admit I was blocking Javascript because the site has a truly irritating pop-up menu that follows you as you scroll up and down if you don’t.** Narbik teaches from a typical-looking IT school as well (as opposed to the specialist CCIE schools like IE and IPExpert), but no one even looks at the school’s name because they’re going to see *him*.

To conclude this meandering mental stroll, neither camp is going to make you a CCIE, but neither is a waste of time or money. To some people the Unitek style of leaving students to do the lab work and only intervening to check work or help with problems is a silly use of time/money because they can pound on labs at home. Fair enough. I personally haven’t had a week where I was able to spend 11-12 hours every day doing lab work in the presence of someone who could answer every question I had and point out things I didn’t even realize I missed or could have optimized, but that’s not enough to justify the expense for some, and I get that. On the other hand if you’re about to take the exam and just want to get some last-minute CLI polish without lecture, the Unitek class works better than Narbik’s. Personally I’m glad I’ve got a cool manager that let me take both.

* At the time Narbik did not accept Learning Credits, I believe he does now.

** In 2008? Seriously. Whoever made that menu needs at least one solid kick in the liver.

Allow me to offer a heartfelt “thank you” for your congratulatory blog comments and unicasts over the last several hours. I have received dozens of messages from readers around the globe. To hear accolades from fellow candidates and titleholders is especially sweet. We have a unique bond, having shared in the sacrifice of time and sanity that is required in the quest for the digits.

Before I relate my lab experience, I must thank my wife from the bottom of my heart for her support throughout the last 16 months. My wife is my best friend, closest companion, and understands me like no other. To say that I love her is thoroughly true, but somehow an inadequate expression of how strongly I feel about her. From the beginning, she fully supported my effort, and not out of ignorance. She was there with me through all of my previous certifications, and knew they were a walk in the park when compared to the CCIE. My wife, an award-winning textile artist who competes all over America, put some of her own aspirations on hold to allow me to focus on my own quest.

During the week before my lab exam, my wife was scheduled to go to Kentucky for a show, where she had entered a garment of her own design and construction. As the kids were on school vacation, I was to have them Thursday, Friday, and Saturday while she was out of town. She surprised me by announcing that she had decided to drive down to Kentucky from New Hampshire with the kids instead of fly by herself. She wanted me to have the time to study and focus. She spent 4 days in a vehicle plus had 2 kids in tow while she attended the show (where she took first in her division), just to give me the time I needed to bring this quest to an end. Gentlemen, if you can find someone even half as devoted, you’ve found someone very special. Treat her like the gold that she is.

COMMENTS ABOUT THE LAB FACILITY

• The Cisco facility at RTP is easy to find based on the directions on the web site. I flew in to the Raleigh/Durham, North Carolina airport (RDU) the day before my exam. I drove right from the airport to the Cisco campus, just to make sure I could find the building without trouble. There was no issue - the campus is clearly signed, and there is ample parking. One caveat - the Cisco site tells you to drive into the campus via the main entrance, as distinguished by the flagpoles. Well, there were no flagpoles, at least not on my visit; they were laying on the ground nearby, I discovered later. The main campus entrance is the first one on your left. You turn right off of Davis Drive onto Kit Creek Road, and then turn left almost immediately onto the Cisco campus. But if you miss that first entrance, there are at least 2 other left-turn entrances to the campus further on down Kit Creek Road. Once you’re on the campus (no matter which entrance you used), you can follow the signs to building 3.
• I did not bring anything to the lab with me, other than my wallet (containing the required photo ID), car keys, and ear plugs. I left my cell phone in the car. I did not bring pencils, pens, or paper. The proctor made us leave car keys (and cell phones for those who brought them) on a bookcase at one end of the lab room. At my desk, paper and a whole little basket full of a rainbow’s worth of colored pencils (and one regular pencil) were provided.
• Be on time. Better yet, be early. The official RTP start time is 7:15am, but you want to be there more like 7:00am. The proctor will come out sometime before 7:15am to introduce himself, photo ID everyone, give everyone visitor tags, tell everyone their rack numbers, and recite the facility ground rules. Everything moves quickly once the proctor shows up in the lobby. The lab proctor did not wait past 7:15am to tell us what was up, usher us from the lobby to the lab room, note the time, and tell us to go for it.
• The lab exam room is nothing special. It’s just a room. There’s several racks of equipment in front and back, and islands of low-walled cubicles in the middle. The rush of air flowing through equipment fills the place - the exam room sounds like any computer room or data center you’ve ever been in. Or your basement, as the case may be. The room was well-lit. I was comfortable in a t-shirt, but I had brought a sweatshirt just in case. As you might expect, the room was well air-conditioned.
• In addition to the “computer room” sound, there were other audible distractions. Someone’s mobile kept going off, I think a proctor’s, although I never looked up long enough to check. There was also some minor foot traffic in the room, as various candidates would pop up to ask questions of the proctors, and as various Cisco employees would come in to work on equipment racks. I wore earplugs, and for me that was very important. If you’re good at tuning out noise, great, but I focus better without noise. I cleared them with the proctor first, just so that he was aware I had them.
• You’ll be sitting in a island of 4 cubicles, but the walls are very low. Your head is clearly visible from your cube. You can’t see your neighbor’s screen or work material, but you can see him/her and everything else in the room.
• You get a three ring binder with your exam in it. You can take the exam out of the binder if you like, although you’ll be required to re-assemble the binder at the end of the exam. The exam sheets are all in protected sleeves. You are not allowed to write on the exam sheets. You can write on the provided paper, and you can request more paper from the proctor if you like. I had only 2 sheets, which for me was enough. I filled three sides with diagrams, and the fourth side with my to-do/completed/point tracker lists.
• Aside from your exam binder, paper, and pencils, you have a full English keyboard, mouse, and monitor on your desk. I had a CRT, not a flat-panel. The monitor was probably a 17″ running 1280×1024 - I’m not certain. It was adequate to the task, but nothing exciting. The mouse was an optical with scroll wheel. The keyboard had a “clicky” feel to it. There was not a ton of room to work at the desk, but there was enough to comfortably open the binder on the one side of the keyboard, and still have horizontal room to move the mouse on the other side. The desk was also deep enough so that you could put papers behind the binder and not be crammed up against the back cubicle wall. So while you couldn’t exactly “spread out”, there was enough room so as not to be a frustration while working.
• The desktop OS was Windows 2000, but completely locked down by security software. On the desktop, you have shortcuts to launch direct terminal sessions to individual pieces of equipment. You have a web browser that automatically opens to the Doc CD when you launch it. That’s it.
• I was able to use the Doc CD without a problem. There were no PDFs available (as I’d heard was a possibility a while ago). However, everything I needed on the Doc CD was available to me via the web browser as I clicked through. All of the redirects to the “new and improved” Cisco documentation worked without a hitch.
• My rack wasn’t in the room. I have no idea where it was, and it didn’t matter.
• Lunch was a half-hour, and unremarkable. We sat in a conference room attached to the lab and ate some sort of spaghetti with meatball dish. It wasn’t great. I ate a small amount of that, and a piece of dessert. Basically, I was looking for a quick calorie hit, but not a heavy meal. There was a nice salad too, although I didn’t have any of it.
• You can get up and use the restroom anytime you like. Clipped to a bookcase near the door entrance, there’s security badge you use to get back into the lab room attached with nylon zip ties to (of all things) an old soda bottle.

COMMENTS ABOUT THE LAB EXAM

• Obviously, I can’t write up a list of what I got on the lab exam. Was it easy? No. Was it hard? Well, the lab was about the level of difficulty I was anticipating, after working with NetMasterClass.com and InternetworkExpert.com practice labs. In my opinion, the difficulty ratings put together by NMC and IE are accurate. In IE-land, a “7″ is considered to be as difficult as an actual lab. In NMC-land, a DOiT rated “moderate” would be comparable.
• I spent about 30 minutes reading through the lab, before touching the keyboard. I didn’t read every little nuance, or try to figure out how I was going to accomplish certain tasks. I just wanted to get a feel for where the lab was going, and correlate tasks to the provided diagrams.
• I know some people like to do their own complete topology diagram before starting the lab. I didn’t. I found the diagrams provided by Cisco to be easily comprehensible, and an adequate reference. I used 2 of Cisco’s provided diagrams constantly throughout the exam. I made several small diagrams of my own along the way (BGP, redistribution, switching domain, multicast, WAN), but I never did a complete topology diagram.
• I checked the IP addressing of every device, which was a proctor request. You need to sanity check your rack to make sure it matches what’s in your lab binder. At lunch, one of the guys told me he had rack problems in a previous attempt. Cisco had to work on the rack to resolve them, so he ended up staying late so that he’d get his full 8 hours on the rack. It’d be easy to assume that if you travel all that way and spend all that money to take the lab exam, everything would be perfect. But again, the proctors themselves told us all to check our equipment before getting into any configuration. So - it’s not safe to assume that your rack will be perfect.
• I adjusted my workstation’s task bar so that I could fit 2 rows of icons down there. Then I kept individual windows open to all my devices, all day long, just clicking in the task bar to bring up the device I needed, when I needed it. I know that approach might make some people nuts, but it’s how I practiced, and it worked for me.
• I tracked all of my tasks by number and point value. When I completed AND DOUBLE-VERIFIED my tasks, I wrote the task down, and the point value beside it on the right side of a piece of paper. If I was unsure of how to complete a task, I put it on the left side of the paper, so that I would not forget to go back to it. I kept a running total of the points that I believed I had earned.
• I needed to reference the Doc CD for six tasks only. A seventh task I figured out without the Doc CD, but since I’d never seen it before I went to the Doc CD to verify it anyway.
• I was able to complete every task on the exam with about an hour to spare. I spent the last hour going right back to the very beginning, verifying one task at a time, making no assumptions, and taking nothing for granted. I only found one error, but that was 2 easy points I would have otherwise lost. I don’t know if I passed with an 80 or a 98, so finding that error might have been the 2 points that put me over the top. You never know.
• Although everybody told me to ask the proctors questions, I did not ask the proctors any questions. Not that I was against it, it just didn’t work out that way. Yes, some of the tasks were vague. However, I found that if I re-read a task, taking in each and every word, the desired configuration for some of the vague tasks became clear. How well you understand a technology will go a long way towards interpreting those sorts of vague tasks correctly. On the other hand, some of the tasks just weren’t explicit. You were to accomplish “x”, but how you accomplished “x” wasn’t stipulated. To me, if I knew of 3 ways to accomplish “x”, I picked the way with the least amount of code (or the least error-prone) that was compatible with other lab tasks, verified that my choice of solution was working, and then moved on.
• I did not read into the overall lab requirements or task requirements. If the lab said to make sure these specific routes are reachable from everywhere, then that’s exactly what I did. I didn’t worry about the rest of the routes. Now that said, some required configuration was implied. In other words, while the lab might not have explicitly stated to do “x”, you might have had to do “x” for everything to work right. I had to make a few judgment calls along the way like that.
• Don’t make the mistake of thinking “this is too weird to show up on the lab so I’m not going to study it.” I got some stuff that I think was pretty weird, and highly unlikely to be used in production networks of today - and yet, every single one of those “weird” features is covered in the lab blueprint, however sparingly. I did not get anything that I felt was unfair or out-of-scope. I got one thing I don’t recall seeing before, but I found it in the Doc CD, configured it, and verified it in minutes. My point is that you should understand the weird technologies, do some lab work with them, take a few notes, and move on. Yes, take the time to understand the weird stuff and go through it, but don’t let it overwhelm you. If you know your core technologies well enough, the weird stuff will be easy to figure out. The weird stuff is usually so specific, that once you take a look at the Doc CD, you’ll probably have a canned IOS config right there on the screen in front of you to adapt to the lab requirements.

FINDING OUT MY SCORE

The proctors jokingly told us before we started that if we configure the equipment correctly, it’s a whole lot easier for them to grade. Uh-huh. They didn’t make any promises about when we’d get the score, and didn’t even promise who would be doing the scoring. It could have been any proctor from around the world, if I understood the process correctly.

My score rolled in about 9:00pm, a little over 5 hours after the lab exam was completed. Now, all I brought with me was my BlackBerry. My Berry is tied to 4 of my e-mail accounts and my Facebook account, so I can stay in touch with everyone. I didn’t bring my laptop with me on the trip, because I wanted to travel as light as possible. Besides, my laptop does not have built-in wireless, and my company runs security software that disables the USB ports (so no external wireless adapter, either). There just wasn’t any point in hauling the brick down with me.

So about 9pm, as I’m coming back up the stairs to my hotel room having killed a few hours at the Southpoint Mall nearby, I check the Berry to see I’ve got a message from “ccie@cisco.com” stating that my score report was available. My heart was racing, just POUNDING in my chest. I popped open the e-mail, expecting to know the deal. Nope. The e-mail doesn’t tell you. You just get a link to go online to the CCIE site and check. Grr.

I texted my wife to see if she was still up - and she was. She called me, and I got her through the process of logging in to see my results. There I am, lying on the hotel bed, staring at the ceiling, Berry to my ear, listening to my wife click-click-click. And then she said…

“You passed.”

“I passed?!?”

“You passed.”

“What’s my number?” I wasn’t sure I believed it yet, because I was thinking she might have been looking at my written exam from last July.

“Your number is 20655.”

At which point, I lost my mind. I cried. I’d spent the last 5 hours second-guessing myself, rolling certain exam tasks over and over again in my mind, wondering if I’d handled them right, wondering if maybe I should have asked the proctors some questions, wondering what I was going to do if I didn’t pass, checking my Berry again and again and again to see if my exam had been graded, even knowing it was far too early for it to have been graded.

To finally hear that I’d passed, that I had (and have) nothing left to prove to myself…was overwhelming. I could barely, and can still barely, believe it.

So what comes next? I have some plans, but nothing I’m going to add to this lengthy post. Perhaps more tomorrow.

I suppose the post title is a dead give away, but I’ll go ahead and give you the news:  Ethan passed the lab exam is now CCIE #20655.  By now, you’ve also realized that this isn’t Ethan posting, either.  Why?  Simple: he doesn’t have the strange habit of talking about himself in the third person.  This is Ethan’s wife, posting for him.  He called me this evening to help him access the test results as he took his crackberry with him, but not his laptop.  He will be back tomorrow and will post all the about the experience for himself.�

I’m about done looking at labs, workbooks, the Doc CD, my notes, CLIs, PDFs, blogs, books, and three-ring binders. For now, at least. I need to do a quick look back at Catalyst QoS which I haven’t done much of for a while. That’s plane reading. Other than that, I’m as ready as I’m going to be for my first lab attempt. I have a fair shot at passing.

Mentally, I feel good. I am absolutely convinced that I am capable of passing this exam. If I don’t pass it this time around, I’ll take the lab again - simple as that. I feel confident, but not cocky. I’ll be surprised if I fail due to technical ignorance. If I fail, I suspect that it will be for some combination of the following weaknesses: poor time management; insufficient verification; breaking an earlier task with a later task; and/or leaving out a task requirement.

To address time management, I completed the IEWB Vol.3 workbook series. IEWB Vol.3 is a series of 10 half-labs that connect the core, add IGPs, perform redistribution and reachability checks, and finally BGP. Generally, I was completing those within 3 - 4 hours. 3 hours and change is about right for most of those labs, so I was within IE’s scope. Those labs helped automate some common tasks for me such as setting appropriate OSPF network types, IRB, summarization, IGP authentication, and PPP authentication. I don’t have to look any of that stuff up now. Aside from that, I have to make sure I’m not spending too much time on any one task.

Insufficient verification has bitten me before, where I’ll miss an ACE, forget a catch-all at the bottom of a route-map, transpose a digit, etc. I’ve even been guilty of looking at CLI “show” output, and deciding my solution was probably okay even though the router was telling me otherwise. (Can you believe that?) I’m sweating the details when I verify my solutions now. Doing labs and labs and labs will get you to that point, I guess.

I am developing a sixth sense about when I might have broken an earlier task with a later task. I wish I was better in this area. For anything my internal warning bell doesn’t sound off about, I hope that a careful run-through in the last hour will reveal the problem.

Leaving out task requirements has killed me in mock labs. I have a huge problem with not reading the task entirely, therefore missing requirements. This is not a terribly hard problem for me to deal with - I just have to read more slowly. I read FAST. I motor through sentences and paragraphs. As a kid, I won the local library reading contest one summer by reading and reporting on more books than any of the other kids. The contest wasn’t close. I was probably 7 or 8, and I decimated the competition. Fast-forward almost 30 years, and my habit of fast reading is killing me on CCIE tasks.

I have failed tasks because of things like ignoring “all traffic must be tagged” and therefore leaving off “vlan dot1q tag native” when building a trunk. Stuff like that is an inexcusable throw-away of often easy points.  I am forcing myself to slow down, read the task one word, then one sentence, then one paragraph at a time. Then I re-read it. Then I usually code the task in a text editor. Then I re-read the task a third time, and compare my code with the task requirements. That helps me with this particular problem, although I still could stand to do better. I hope I&#