Threats of Tornados and Redistribution, Oh my: The final day of Narbik’s Training Class

Today started out a typical day in Narbik’s class – lots of labbing and mind-bending topologies, today’s subject being QoS. Until today, I have never sat through a lecture on or read a book about QoS that wasn’t just a slight step up from a root canal in terms of pain and frustration. However, today’s lab demos really helped clarify what various methods of QoS were really doing, and as a bonus, I didn’t feel an overwhelming desire to be anesthetized while listening to the explanation.  My loose grasp on previously confusing terms like single rate, two color policers versus dual rate, three color policers was significantly strengthened.

We then made an attempt to talk redistribution.  Now apparently Narbik has a history with redistribution, when he tried to talk about it in Poland, they ended up with a fresh coat of snow on the ground, and today Dallas nearly took a tornado for it. The warning sirens went off, literally, and we all got to trudge down to the first floor of the hotel and cram into a small space with a few hundred other guests. As Narbik himself said, “sh** happens when you do redistribution.” Hilarious and so true!  When we got back to class, we looked at about a half dozen scenarios where redistribution sent a perfectly good network into the crapper. Incredibly fascinating to see and start to really understand the vulnerabilities inherent in the processes.

Now a typical Narbik class would not have ended after that, stories of Thursday nights are legendary – the night usually ending about 4:30am or so I am told. Since, however, we missed our window for the last mock lab attempts while slumming around in the tornado shelter, we decided to finish the lectures for the entire week and class came to an early close at a mere 7pm. Fortunately all the students get an opportunity to make up the mock lab attempt on our own within the next couple of months, so it all works out.

I can honestly characterize this class as one of the best educational experiences I have had.  Much of this stems from the philosophy of learning espoused by Narbik himself and shows in the quality of his teaching and methods. His pronounced idea that he is creating and shaping better engineers, not just folks that can pass a test really resonates with me.  He talked about how engineers are like artists and that how we do our work is our signature. He went on to say how we should pride ourselves in the quality of our work even when no one is watching or grading it. I just couldn’t agree more.

On that note, I’d like to thank Eman Conde and CCIE Flyer one last time for giving me the opportunity to sit the class, couldn’t be more grateful for the experience!

Published 5/8/2014

Disclaimer: While Eman and CCIE Flyer were very generous to grant me a seat in this class and I am very grateful for it, my opinions are totally my own, as all redheads are far too stubborn to have it any other way.

 

Runt Post: Narbik & the Bad Ass Network Topologies, Day Two of CCIE Training

Today we started off class with Narbik excitingly diving into what he humorously referred to as “bad ass networking topologies” and it certainly didn’t disappoint. We looked at OSPF from conceivable angle and then tackled the inconceivable ones.  While I may have felt at one point or another in my life that I understood OSPF, I am now convinced that someone should have handed me some crayons and safety scissors to match my elementary knowledge level.  Good news, however, there is some serious leveling up going on.

I could feel the brain cells clicking when we looked at topologies that weren’t just examples of “stupid router tricks” but instead were excellent demonstrations of how the protocol responded under given conditions and caveats.  Being able to see the problems while configuring the CLI definitely drove concepts home for me.

One of the best quotes today was Narbik saying “if Cisco says something is not supported, it becomes a puzzle for me.”  This kind of attitude makes good engineers and great teachers. I’m certainly feeling the challenge this week of the vast amount of knowledge I have yet to master, but am encouraged to see that I seem to have a knack for the troubleshooting questions.  Which is definitely good because Narbik also said “I looked at this switch and I asked myself what is everything that could possibly go wrong in this switch, and then I created your troubleshooting homework from that.” Yep, we are *way* passed kindergarten.

Time for sleep now, grateful there is at least a little rest for the weary.

Published 5/5/2014

And a bonus command for readers today – and I cannot believe I have never seen this before today – you can speed up your traceroutes by using the numeric keyword.  This keeps it from having to waiting on DNS resolution. It’s the best thing since sliced bread, and who doesn’t like sliced bread?

R1#traceroute 1.1.1.1 ?
numeric display numeric address
port specify port number
probe specify number of probes per hop
source specify source address or name
timeout specify time out
ttl specify minimum and maximum ttl

Disclaimer: While Eman and CCIE Flyer were very generous to grant me a seat in this class and I am very grateful for it, my opinions are totally my own, as all redheads are far too stubborn to have it any other way.