From the blog.

Managing Digital Racket
The more I tune out, the less I miss it. But that has presented me with some complex choices for a nuanced approach to curb
Complexity – My Friend, My Enemy
Over my years of network engineering, I've learned that the fewer features you can implement while still achieving a business goal, the better. Why? Fewer

NMC DOiT Vol.2 Scenario 18 – Early Comments About Scenario Difficulty

617 Words. Plan about 4 minute(s) to read this.

I started NetMasterClass.com DOiT v2 scenario 18 today. I’m not done this beast yet, but I clocked almost 6h 30m on it. I’ve made it all the way through IGP redistribution (mostly) and BGP, with security, QoS, multicast, IPv6 and I’m not sure what else still to go. NMC says that the lab difficultly is “high”, and they aren’t kidding. Any difficulty that may have lacked in the last few scenarios is made up for here. So what’s been so tough so far?

  • I spent a lot of time troubleshooting a connectivity issue between two devices involved in a dual IRB scenario. R1 and R3 were both doing IRB to bridge VLANs 20 and 30 together. The IP network was common to both VLAN 20 and 30, necessitating IRB. But no matter what I tried, I couldn’t get R5 (VLAN30) and CAT1 (VLAN20) to ping one another. I assumed a spanning tree issue, but I drew it all out, and couldn’t find a forwarding problem. Long story short, there’s a 3550 bug that prevents the 2 devices from pinging one another. I felt redeemed in the sense that I wasn’t missing something I should have known. On the other hand, it was frustrating to burn time troubleshooting a bug.
  • Redistribution was brutal.
    • There were a lot of specific requirements to making the redistribution happen the way that they want, and my brain wasn’t in top form today. I just handled it all wrong, and I don’t know why. I think the requirements spooked me. If I’d done it the way I always do redistribution (one router at a time, one protocol at a time, reviewing routing tables at each step), life would have gone easier for me. Instead, I lit up all redistribution on all routers in all protocols all at once. Wrong, wrong, wrong. Wrong. Totally, completely wrong. (You get the point.)
    • Not only that, I tried a real cowboy move with route tags for redistribution filtering that I wasn’t sure was going to work like I’d hoped! Nothing like abandoning your tried-and-true approach, and then throwing a technique you think would be cool but don’t use often enough to be competent with. I might as well have been holding lit firecrackers in my teeth just to see what would happen, because, as you might have guessed, it all blew up in my face.
    • I had total IGP meltdown due to dual mutual redistribution points I didn’t handle properly. I did get it all stable and reachable after abandoning my route tags and using prefix filtering, but instead of the usual 20 minutes it takes to light up redistribution and sanity check, it took about 80. Ugh. Never minding that, as I’m sitting here typing, I’m remembering that there was a funky “prefer this IGP before this IGP before this other IGP” thing for some router or another. I’m not sure I dealt with that or not. I think it’s in the VPN/IPSEC tunneling section I haven’t done yet. Hooray. <sigh>
  • BGP had a bizarre synchronization requirement relating to the OSPF and BGP RIDs. I’ll get into it tomorrow or Monday when I blog the tech notes. I understood the issue well enough to see it coming if it shows up in a task list again, but I’m too weary of brain to explain it right now. I also learned that you can apply a BGP route-map to a BGP network statement, to apply attributes to those BGP NLRIs. Seems like I should have known that before, but I didn’t. Ergo, I wasted time trying to meet the requirements of a task in the wrong way.

I plan to finish the scenario tomorrow, and blog tomorrow afternoon or Monday, just depending.