NMC DOiT Vol.2 Scenario 7 Day 2 – Basic Routing + Redistribution


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.


  • Hi Ethans,

    Just a sudden thought comes up in my mind, if there’s no mutual redistribution at R1, will it be a good idea to tune the A.D. for all those routes from EIGRP-AS103 and EIGRP-AS106 at R1.

    Say lowering the A.D. of all these routes to be under 120 at R1’s EIGRP process, so making R1 will not suboptimally route to RIP first.

    What I am thinking is, if you hide R1 with your hands, every redistribution points are fine and no suboptimal routing occurs. The only problem is at R1.

    Hope I haven’t missed something as I don’t have this workbook.

  • I think you’ve hit on the alternate strategy, and in this case the easier strategy to implement. I was going to filter routes redistributed out of OSPF and into RIP, but setting distance on my EIGRP routes would be even easier. I guess there might be a downside to that strategy, but nothing’s leaping to mind. It won’t affect anything I might be required to do with BGP later, so I think we’re good.

  • Okay, I have to take that last comment back…setting distance on my EIGRP routes to be less than RIP would have been bad. Why? Because the RIP routes would have been heading to OSPF, and OSPF to EIGRP. So when R1 learned the RIP routes via EIGRP, he would have converged the RIP routes out the EIGRP interface. I think we’re really overanalyzing this. All I needed to do was just turn on the required redistribution and be done with it. Although not required, I put a distribute-list in for RIP on R1, to deny routes originating from EIGRP 106. That really covered all the issues. This was a straightforward redistribution scenario.

By Ethan Banks

Ethan Banks is a podcaster and writer with a BSCS and 20+ years in enterprise IT. He's operated data centers with a special focus on infrastructure — especially networking. He's been a CNE, MCSE, CEH, CCNA, CCNP, CCSP, and CCIE R&S #20655. He's the co-founder of Packet Pushers Interactive, LLC where he creates content for humans in the hot aisle.