Ethan Banks On productivity.

Building Speed


I said in an earlier post that ignorance was my greatest enemy.  For sure, I’m still fighting ignorance.  I don’t know every feature that I might possibly need to know…but doing all these labs has exposed me to a lot of concepts and commands. I don’t think it’s ignorance that’s hurting me right now as much as it is just not being able to get labs done quickly enough.

I need to build speed.  I have to get faster.  I was looking over’s comments on how to become a CCIE.  They were talking about how on the first 2 mock labs, you should pull off between a 60% and 80% before going on to mock labs 3 & 4.  Well, I pulled off a sad little 47% on IE mock lab #2, mostly because I just ran out of time.  I knew how to do some of what I’d ran out of time on, but I’d killed a ton of other time trying to get other stuff going.  I just had too much going on, and not enough time.  I was overloaded with tasks, or felt that I was.

So I have to build speed.  How am I going to do this?

  • Practice.  I know there is nothing that’s going to help me more than practicing the labs.  Putting in rack time is going to make me faster, no question about it.
  • Do write-ups on small, troublesome topics.  And then I just have to memorize that stuff.  Off the top of my head, here’s a list:
    • BGP bestpath algorithm.  I can do all the basic neighboring, route-reflectors, and confederation on autopilot.  However, I need to know bestpath automatically so that I know how tweaking weight, local pref, metric, etc. will factor into BGP forwarding decisions.
    • Multicast sparse-mode.  I don’t know the commands relating to RPs or BSR without looking them up.  I need to.
    • PPP authorization, including PPP over frame-relay.
    • 802.1x.  I don’t know any of these commands without looking them up.
    • Q-in-Q tunneling.  I have a mental block about this topic I need to get by.
    • IRB.  I know this reasonably well, but I don’t have the commands memorized.
    • Security.  I need to go through the IOS security command set, and write down summaries of the commands I’ve been running into on the lab.  A lot of the security tasks are easy, if you know that one simple command and how to apply it.
    • IPv6 tunneling.  There’s several methods of IPv6 tunneling.  I don’t know why I’d want to use one over the other or the differences between them.
    • MSTP.  There’s some terminology here I need to work through, and tweak on different settings.
    • Oh, there’s probably more.  But this is stuff that floats to the top as I’m contemplating my weak areas.
  • Streamlining my process.
    • I’m considering doing a hybrid of Notepad and live router/switch configs, rather than doing everything in Notepad for every scrap of code.  I need to decide where Notepad is saving me time and reducing errors, and where hacking IOS live is smarter.
    • I can fly confidently through frame-relay, most ethernet/etherchannel/VLAN kind of stuff, STP, RIP, OSPF, EIGRP, and redistribution.  But even with that layer 2 and IGP stuff, I need to be better.  Somehow, I have to find about 45 – 60 minutes in there.  I’m usually at the 4 hour mark by the time I’m done redistribution; I need to get that down to more like the 3 hour mark.  Maybe I need to cut back on my diagramming?  I’m not sure; diagrams take time, but they cut down on errors for me.

I was going to try to move my April 29 lab date ahead.  Now I’m not so sure.  That is only 4 months away…I feel like I need a ton more rack time than I’ve completed so far.  I think I’ve done about 250 hours of rack time by now.  That’s a guess, but it’s around that mark.  Another 250 wouldn’t hurt my feelings, not at all.

A couple of weeks ago I wanted to bump my lab date up, but as of today, I’m scared that I’m not going to be ready for the April date in time. <sigh>

By Ethan Banks
Ethan Banks On productivity.

You probably know Ethan Banks because he writes & podcasts about IT. For example, he co-authored "Computer Networks Problems & Solutions" with Russ White.

This site is Ethan on productivity--not tech so much.

Find out more on his about page.