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 1 Day 6

244 Words. Plan about 1 minute(s) to read this.

I didn’t get much lab time in tonight, due to the intrusion of, you know, having a life that sometimes requires my attention.  But, I did get far enough to figure out what I had done wrong in my IGP redistribution.  I was not filtering my redistributed routes such that only the native routes from one protocol were being redistributed into the other one.  Just bad design on my part, due to some bad assumptions.  Going forward, I’m going to make a habit of only redistributing the routes that originate within a certain IGP, and not all routes, which is the lazy approach.  I knew better, too, but I was taking the scenario instructions a little too literally.

Once I fixed my redistribution, my converged routing tables looked just like the answer key said it should…which allowed me to poke at my multicast problem some more.  I actually had a more fundamental problem in my multicast scenario than I thought I did.  I was trying to ping from a router whose upstream neighbor wasn’t running PIM, and therefore wasn’t a part of the multicast tree.  Duh.  As soon as I lit that interface up with PIM, I was able to ping and get back responses.  So tomorrow, I’ll verify that I’m getting back all the responses I’m expecting, and that the static mroute I put in to workaround the RPF issue is doing what I think it is.

And then, hopefully, finish scenario 1.