Becoming a CCIE is a lot about technology, but it is also a mental game. Many people forget this aspect. What do I mean with this?
Yes, we need to know the technology inside out but we also need to get to a level of thinking where we can easily identify potential issues. Look at a diagram with OSPF and see, oh that is not going to work, it is not connected to area 0. We will need a virtual link later.
If doing mutual redistribution from RIP to OSPF then there is a potential for suboptimal routing and routing loops (higher AD -> lower AD -> higher AD). BTW, don’t care about suboptimal traffic unless told to, we don’t have time for this.
If doing multicast draw out the topology, where will the source and shared tree be rooted? What interfaces are the RPF interfaces?
If I’m told to make sure BB routers does not receive routing updates, what are my options of filtering this?
So am I at a CCIE level of thinking? I’m not sure but I do know that I am a lot closer to it then when I started my journey. The learning experience has been immense. In 3 months from now we will know if I was at the right level 🙂
4 thoughts on “A CCIE level of thinking”
Hope you do well. I was at 1500 hours when I passed but that was a little over kill. I was very close at around 800 hours of study but barely missed it. I think with a better study routine it can be done in the 800-1000 hour range.
Doing all those labs in the workbooks over and over probably help a lot in getting your CCIE level of thinking working correctly or close to it. I’m sure reading thousands and thousands of pages of documents and notes does not hurt either. 🙂
Best of luck on your sit!
My experience was that the more labs I did, the more I intuitively saw the issues the practice lab was presenting to me. For the first dozen or so full-scale practice labs, I was just hanging on…I did the best I could, but it was much more about learning than doing. After that, it got easier.
There was a routine I established that helped me, in a manner of speaking, “baseline the lab” so that I knew what I was up against before even starting to configure. I could start to see potential issues before I got to them, and so my brain was able to churn on how to deal with the issues while I was doing the basics of establishing L2 and L3 adjacencies.
So are you at a CCIE level of thinking? It sounds like you’re getting there, yes. For me, the key was being able to see the entire lab in my mind in dependency layers. For application stuff to work throughout the lab environment, L3 had to be right. For L3 to be right, L2 had to be right. For L2 to be right, L1 had to be right. You get the idea.
A CCIE lab is a complex, tightly coupled system of links that you’re ready to cope with when you can “feel” it in your mind simply by opening the instruction booklet, reviewing the diagram (or making your own), and conceptualizing the various protocols all working together before you ever press a key. Towards the end of your practice hours, when you’re genuinely ready to tackle the lab, you won’t have gaps in the mental image you create of the system when you first examine what you’re being asked to do.
Great advice Ethan,
I fully agree. The first couple of labs I did I was shocked. Not only because there was a lot of technology I needed to learn but because of the topology and everything interconnecting. I like your concept of thinking in layers and I think it might be a good approach to try to configure stuff in steps. If we are configuring OSPF with authentication it might not be a bad idead to configure without authentication first. Then we will make sure if it is a L2/L3 issue before we blame authentication and so on.
I’m still trying to fight the urge to configure after reading a lab. It’s much more efficient to read it twice and maybe do some drawings etc and think through the lab. Otherwise we could get bitten by issue like doing different authentication on one interface (need virtual template) or stuff like that.