NMC DOiT Vol.2 Scenario 5 Day 4 – Route Redistribution – UPDATED 09/14/2007

1,122 Words. Plan about 5 minute(s) to read this.

Tonight I completed mutual route redistribution for the IGPs. That doesn’t sound like much, but tonight, I did it all by myself and it works correctly. It’s like staying dry on your first day of wearing briefs! (Can you tell I had small children in the house not that long ago?)

So, what was the magic in this go-around for route-redistribution? Well, the scenario wasn’t that picky about HOW the redistribution was accomplished. It just told me which routes and IGPs to perform mutual redistribution on, and then forbid me to do any other redistribution except for connected where needed and not otherwise forbidden by the scenario. There were some strange challenges here.

  1. OSPF NSSA area. None of the NSSA routers were redistribution points, so how was I going to get those routers to talk to external routes? In an NSSA router, external routes leave, but aren’t allowed in. My solution was to throw an “area 0 range 172.16.0.0 255.255.0.0” onto the ABR that would advertise a summary route into the NSSA area. Nothing in the scenario said I couldn’t do THAT, although static routes and quad zero routes were forbidden. So that was my answer to that. I think there’s got to be something I’m missing there, though, because the reference NSSA router on NMC’s site doesn’t show either the external routes, or a summary route. So how does the router have reachability? I’m not sure…UPDATE 9/14/2007 – I figured this out. The way NMC worked around the issue of reachability for the NSSA router is to use a policy that forwards locally-originated traffic to a next-hop that knows how to get everywhere; it was actually a step to configure this earlier in the lab that I’d forgotten about. Frankly, I think that’s a lousy solution to the problem, as it would resolve the problem for the lab where all you’re really talking to is the router itself, but NOT resolve the issue for hosts that this router would be supporting. Even with an “ip local policy”, that router would still be dropping packets on the floor for transit traffic. But I guess it’s a trick worth knowing for the CCIE lab. Understanding HOW something works is the key; whether doing that something is a good idea in the real world is a different issue.
  2. 2 RIP domains. The scenario created 2 RIP domains, even though the 4 RIP routers all connected to the wire and ran RIP in the same ethernet segment. The scenario called for unicast RIP, where CAT1 and FRS were a RIP pair, and CAT2 and R5 were a RIP pair. But the 2 pairs didn’t exchange RIP routes. So effectively, I had to export the RIP routes for CAT1-FRS out of RIP, into EIGRP, then into OSPF, and into the CAT2-R5 RIP. And then do the same thing the other way. Not hard, once I got my little brain thinking that what was on paper was really 2 smaller RIP domains, even though the diagram made it look like one big RIP domain. THEY LIED TO ME!
  3. Avoiding routing loops. To avoid routing loops due to redistribution, I went with the tried-and-true route-map approach, whereby you define an ACL with all the routes that are native to a protocol, and then redistribute those native routes into another protocol. The idea is that by defining an access-list of routes, you very tightly control which routes make it from one protocol to another. You eliminate the risk of convergence loops due to mutually redistributed routes. For example, let’s say you are doing mutual redistribution of RIP->OSPF on R1 and OSPF->RIP on R2. R1 and R2 sit on the edges of the same RIP and OSPF domains. So RIP route 10.10.10.0/24 gets redistributed by R1 into OSPF. Then R2 learns 10.10.10.0/24 as an O E2 route, right? Then R2 wants to redistribute that 10.10.10.0/24 O E2 route he thinks of as a native OSPF route back into RIP. Yuck. Now we have a problem. By using access-lists with route-maps on R1 and R2, you can make sure that routes don’t get redistributed back into the IGP they came from. Well…that’s ONE way to do it. There’s other ways, such as route tagging, tweaking distance, filtering for internal-only routes, and other methods I hope to be getting better at as the scenarios wear on.

I still have a long way to go on this lab, but I wanted to take extra-special care to focus on redistribution. I didn’t pay enough attention to it in the first 4 labs. I more or less allowed route-redistribution to wash over me. I made it work, kind of like you can hammer a square peg into a round hole if you use a big enough hammer. But this time around, I decided I had to understand the nuances, so I took it one router at a time, one step of redistribution at a time, and checked key router routing tables along the way to make sure everything was behaving like I expected. That was WELL worth the effort. I feel that I made a big leap forward in my redistribution thinking tonight.

I should mention that I worked through roughly the first hour of the InternetworkExpert.com route QoS on-demand lecture today, and the entire redistribution lecture a day or so ago. There’s about 2.5 hours yet to go in QoS. Well, tonight, I ran into a significant issue that was talked about in the earlier redistribution lecture. The issue is this: when you redistribute an IGP, say OSPF, OSPF will automatically redistribute for you connected interfaces that OSPF is running on. That will continue to work UNTIL you do your own “redistribute connected”. Just as soon as you do that, what connected routes you choose to redistribute will trump whatever OSPF (or other IGP) might have been doing for you. So in my case, I tested a couple of routers for full reachability, and they worked fine. Then I got to the third router, and discovered I needed to redistribute a connected route for that router to have full reachability. So I did, using a route-map to limit redistribution of connected to the one route I was missing on that third router. Oh, man – that clobbered a bunch of other connected routes that OSPF had been doing for me. In this case, all I needed to do was not limit my “redistribute connected” with a route-map, and I was good. But yikes! What a great example of exactly what the lecture had been talking about. I knew exactly what was going on as soon as it happened, and I would not have known had it not been for that lecture. A MAJOR time-saver.


Ethan Banks writes & podcasts about IT, new media, and personal tech.
about | subscribe | @ecbanks

3 thoughts on “NMC DOiT Vol.2 Scenario 5 Day 4 – Route Redistribution – UPDATED 09/14/2007

  1. “THEY LIED TO ME!” I fell for it as well. I looked at the topology and thought “feedback loop”. So I started tagging everything, as is my preferred method of avoiding feedback. Is there any loop at all in this topology?

    I am looking for topologies that look like routing loops but are in fact broken loops. So that I can recognise them and avoid wasting time on them. So far, I can think of two: this one which we can call “RIP unicast”, and the one from another Lab which I can call “EIGRP stub-in-the-middle”.

  2. I agree with your comment about the local policy to resolve the routing issue on R2. I found out something interesting about the default next-hop in a local policy: it doesn’t work very well! Unlike “real” routing, the source address is not the IP address of the egress interface.

    I found this out when I was testing 5.5.3. I shut down R5 S1/1, and expected to be able to ping from R5 to 172.16.107.1, but it didn’t work. A debug on the FRS revealed that the ping was being sent with source address 172.16.105.1, and of course the FRS had no route back to that.

    Kevin Dorrell
    Luxembourg

Comments are closed.