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 7 Day 2 – Basic Routing + Redistribution

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

I think I’ve found a huge time-saving key for me. If I generate configs in Notepad, and then apply them, it’s saving me a ton of time. This may sound obvious, but I wasn’t doing the configs that way before. Previously, I was going into each router, and doing a bit at a time. Now, I just take everything for say, OSPF, and do up the OSPF config for every device that’s participating in the OSPF domain. I get to copy ‘n’ paste much faster this way, catch typos without having IOS tell me how dumb I was, and add features without having to shuttle back and forth between devices. For me, doing the configs this way is cutting my time in half, maybe more.

Tonight I threw on the RIP, OSPF and EIGRP configs, and got a good start thinking through the redistribution. I did something different in the redistribution this time, too. I need a visual way that I can spot the redistribution issues that I might run into. NetMasterClass.com’s approach is to use a big matrix with lots of colors. Frankly, that doesn’t do it for me. I don’t know why. I’ve studied their diagrams, and nothing clicks. And that’s a bummer, because pretty much all of the NMC stuff has clicked with me immediately, one of the big reasons I chose them as a vendor for my practice labs.

So, I’m stepping out, trying to get a scheme down to do redistribution “my way”. Which is to say, in a way that I can quickly visualize how the redistribution is going to work, and spot what issues may come up because of looping routes, sub-optimal routes due to administrative distance, and the like. What I’m trying is a simple diagram, where I draw the IGPs as big circles. Then, I draw a smaller circle overlapping IGPs of redistribution, and the router(s) that will be performing the redistribution. Then I add arrows so that I know which way the redistribution is going. One arrow for one direction, two arrows for mutual redistribution. Then, I draw in the remaining routers that may participate in an IGP or multiple IGPs, but may not be used as redistribution points. I need to see them, so that I can think about how they will react when redistributed routes hit their routing table.

Redistribution Diagram

I think I’m on the right track with this idea. Sorry it’s kind of a nasty picture, but you get the idea. Looking at this, I can see some potential trouble spots.

  1. R1 may have some challenges with sub-optimal routing, where routes he’ll know as 170’s in EIGRP, he’ll also learn as 120’s in RIP. That means he’s only going to route via EIGRP for the internal 90 routes, and any external EIGRP routes will converge on the RIP domain, since they are 120’s. Possible solution: don’t redistribute EIGRP routes into RIP at all. Only redistribute OSPF native routes into RIP. R1 is the only RIP router that would benefit from EIGRP routes being injected into RIP…but R1 is also an EIGRP speaker. So what’s the point of the EIGRP routes ever hitting the RIP domain? The only reason I can think is that R1 would need a redundant path the EIGRP domain via RIP – but that’s not a scenario requirement (and it is in others). So no worries.
  2. R3 is redistributing routers from EIGRP AS103 into two different systems, OSPF and EIGRP AS30. That means that R4 and R3 are both going to be advertisting the EIGRP AS103 routes. Is this a problem? Might be. I have to think about it.
  3. One thing that ISN’T a problem is that R1 isn’t doing mutual redistribution between RIP and EIGRP AS30. So that’s good. I’d be really scratching my head trying to nail it down.

No other problems are leaping off the page at me, but it’s highly possible I’m missing something. So, I’ll think about it some more, and then implement a solution, hopefully tomorrow. We’ll see how it goes.