Lab Strategy Update


My lab strategy keeps changing in little bits. Here’s my approach as it stands today, based on my experiences the last few weeks, where I’ve been doing one entire practice lab at a whack.

  • I read the entire lab, every task, looking at the diagram and making notes if some tasks affect others. Most often, OSPF tasks will affect frame-relay choices, and vice-versa.
  • I diagram the BGP scenario and the redistribution. I might diagram the multicast.
    • The BGP diagram is something I have to work from, period. I’m essentially useless without it. The BGP diagram helps me keep visual track of the AS layout, allows me to check off neighbor adjacencies as they come up, and more readily spot issues where I might need “next-hop-self”, that kind of thing. If my BGP isn’t settling like I need it to, that diagram is critical to quickly troubleshooting the problem. Without it, problems take too long to resolve.
    • My redistribution diagram serves the same purpose. I need it to visualize how the IGP domains are flowing into one another. I’m comfortable with my redistribution diagrams. I have a specific system with IGP “circles”, routers attached to specific IGP circles, and arrows that represent the flow of redistributed routes. It’s a simplistic system, but it’s exactly what I need to be able to see what routers might be affected by which AD, what routers will end up as preferred paths, etc. My approach has gotten me to the point where most of the time, I can commit to a redistribution design in 15 or 20 minutes.
    • The multicast diagram is still early in the works. But what I’m trying to do with it is help me visualize the shared and source path trees better. I need to work on this a lot more.
  • Reading the entire lab and making those diagrams takes me about 30 – 40 minutes. At first, it scared me to take that much time up without writing a line of IOS code. However, I am convinced that doing this work up front greatly reduces errors down the road. Early on doing these practice scenarios, I made the mistake of immediately hammering away at task number 1, only to find out later that I had to rip it out because of the requirements of a different task, or to discover that I could have saved myself a bunch of time by combining a couple of tasks.
  • I write code in an offline text editor. Early on, I was coding right on the routers, typing like a madman. That’s an insanely bad idea. Now, I take a logical chunk (say, all the frame-relay code), draft it all up in the editor, then paste it in one device at a time, watching the device closely to make sure IOS didn’t reject anything.
    • This is a great approach, because a lot of the code is cookie-cutter. For example, a frame interface is a frame interface. So if you have 6 of them to build, you can copy ‘n’ paste all of your “no frame-relay inverse-arp”, “frame-relay interface-dlci”, “encapsulation frame-relay”, etc. statements, and then just tweak what you need to tweak for a particular interface (ip address, DLCI number, map statements, etc.). BGP is the same way, especially if you’re doing something like a confederation where you may have several statements that are the same from router to router.
    • Using copy ‘n’ paste also makes sure that if you get a paragraph correct once, it’ll be correct for everywhere else you paste it. (By the same token, if you get it wrong, it’ll be wrong everywhere too, but it’s then easy to correct with a find ‘n’ replace.)
    • Another big advantage of doing the IOS code offline is that you get to review each device against the scenario task list and make sure you didn’t skip anything. There’s no “at-a-glance” way to do this sanity check if you’re coding right on the device.
  • I take one logical section at a time and apply it to the routers, usually making one text file per section. Then I do a sanity check to make sure that code is doing what I expect.
    • I start with physical layer connectivity.
      • I get frame-relay and PPP up first, then check that all the links are pingable.
      • I move next to the ethernet, getting all VLANs and trunking working. If there is a complicated spanning-tree scenario, I’ll usually get this out of the way here, too. Then I verify this connectivity.
    • Next I move onto IGPs, one IGP at a time, I don’t care what order necessarily. The way NetMasterClass.com lays it out, it’s usually OSPF first, then RIP, then EIGRP. When I’ve done one IGP, I sanity check that all my adjacencies came up and that routing tables look like I’d expect based on the configuration I did. If there were any special requirements for summarization or path preference, I make sure that’s good as well.
    • When the IGPs are done, I then implement IGP redistribution. Now, it’s true that you may need to do additional redistribution of BGP into an IGP later on, but I’ve found that more often than not, you need to have full reachability for all IGP prefixes to be sure that all your BGP adjacencies are going to form.
    • I’ll do a number of sanity checks here, including monitoring for route stability and spot-checking for reachability from one to domain to another. I don’t check every single route for reachability at this point, but enough to be highly confident that everything is working properly.
    • After IGP redistribution, I move on to BGP. In my mind, the BGP is layered on top of the IGP domains. That’s kind of how I think of BGP – over the top of everything else.
    • Once the BGP is up and working as expected, then I’ll do a full reachability test with a TCL script. If I’ve done my work above correctly, I won’t have an issue. Most often, the part that messes me up is some group of loopback addresses that need to be redistributed. If the loopbacks weren’t specifically mentioned in a task, they might get forgotten until my reachability check reminds me of the problem. Full IPv4 reachability is the ultimate sanity check. If that’s all good, then I can move on to the remaining tasks with confidence.
    • From there, I pick and choose. Many of the tasks are isolated. Sometimes I do them in order presented. Sometimes I cherry-pick. Overall, I tend to go for the QoS first (because I like it and I keep getting better at it), then Catalyst specialties (because if you don’t know how to do whatever it is, the task is usually easy to find on http://www.cisco.com/univercd since nearly all the 3550 and 3560 information can be found from one well-indexed HTML page), then router maintenance and security. I usually leave IPv6 and multicast to last, and I’m not 100% sure if that’s a good idea at this point. I’m fine with the basics of both IPv6 and multicast. Setting up IPv6 routing protocols and multicast routing is fine. Troubleshooting IPv6 or multicast problems tend to eat up the clock for me. And, I guess that’s really why I leave them until the last thing. I want to knock out all the tasks I am highly confident in knowing how to do, the idea being to build as many sure points as I can, before working on the tasks I’m less confident with, where I suspect I may lose a few points if I get hung up on something I can’t figure out.

So how close am I to walking in to the actual lab and passing? Wow – I wish I knew the answer to that question. I was reading through CCIE Pursuit’s post about lab scoring, and based on that information, I’m doing better than I thought I was. Knowing I can get partial credit for OSPF is pretty heartening, since there’s a chance I could get an odd task that I can’t figure out. It’s not “get ALL the OSPF tasks or lose all your OSPF points”, so that’s good. It will be easier for me to build a points total in that sense. It also means that if I’m still not hardcore on IPv6 or multicast by the time I take the actual lab, I will at least get some credit. I won’t get blown away completely. Even so, I guess I still don’t really know how close I am.

There are days when I feel like I could pass, and other days where every scenario I’ve had trouble with comes flooding to mind in an imaginary Super Killer CCIE Actual Lab Designed Just To Fail Me. :) That lab would include IRB, q-in-q tunneling, ppp over frame-relay, EIGRP variance, MSTP, NAT-PT, and I’m not sure what all else. All stuff I can deal with, but stuff that takes me a little longer to knock out than I’d like at this point. So yeah, I think that even today I have a realistic shot of passing. But I have just as realistic a shot at failing because of being asked some esoteric questions that wad me up for an hour and keep me from moving on because the rest of the lab depends on getting that task done.

But, I have 12 more NMC DOiT’s to do. And I can do a CHECKiT or 2. (I’d hoped to do a CHECKiT this month, but it doesn’t look like the money will be there.) And I have 10 internetworkexpert.com scenarios I can do, assuming I can scrounge some more gear since their labs need more equipment than NMC’s. And there’s lots more cisco.com reading I can do. Plus work projects that are making me smarter, like the frame-relay and ATM QoS solution we’re going to take for a test-drive on Monday in production at work.

I’m getting there, slowly but surely.

About the author

Ethan Banks

Most people know me because I write & podcast about IT on the Packet Pushers network. I also co-authored "Computer Networks Problems & Solutions" with Russ White.

Find out more on my about page.


  • Notepad editing is the interesting approach. I’ll try it while doing my next lab.
    I also re-verify all sections after completing all lab tasks. I always find couple of mistakes in lab, during verifying all lab tasks.

  • Ethan,

    You easily have the most sophisticated CCIE Candidate blog on the net. Keep pluggin’ away, partner.

  • Thanks, Mark. You know what’s funny? For all the stuff I’ve been posting, I have to go back and read what I wrote to remember it all! Some of the stuff I wrote, when I go back and read it, it’s like seeing it for the first time. That’s really intimidating, getting ready for the Big Day.

  • Writing configurations to a notepad before putting applying them to the equipment is a great thing to do for two reasons:

    1 – You can verify the actual syntax
    2 – Configurations and parameters will stick into our brains
    3 – Will save you time and prevents errors when appliying the same configuration multiple times…


Most people know me because I write & podcast about IT on the Packet Pushers network. I also co-authored "Computer Networks Problems & Solutions" with Russ White.

Find out more on my about page.

Subscribe via Email

Receive complete, ad-free posts in your inbox as I publish them here.