ROUTE – Redistribution Nuance #1 – Admin Distance FTW

I just got back from Global Knowledge’s ROUTE class, and I must say that it was a great class.  John Barnes puts on quite the show and is the best instructor I’ve ever had.  I digress, though.

One of the topics we covered was route redistribution, so I went back to the hotel one night and fired off this network in GNS3 to study a bit.

The object was to see how redistributing statics into OSPF and into EIGRP differ.  It was also an opportunity to see how EIGRP redistributes into OSPF (and OSPF into EIGRP, but I didn’t make it that far).  To do that, I redistributed 10.10.10.0/24 from R1 into OSPF and 10.10.20.0/24 from R4 into EIGRP.  I then had R2 and R5 redistribute all EIGRP routes into OSPF.  It’s a nice mix, but I saw some weirdness in the paths to 10.10.20.0/24.

Here’s the simple config from R4 that shows the redistribution. I’m just shoving the static routes into EIGRP without touching the K-values.

Nothing out of the ordinary going on there.  I can see the route on R3 and R2 as a “D EX”.

It’s not the case for R5, though.  Check this out.

That, my friend, is an external OSPF route (Type-5 LSA for those scoring at home) going through R2.  Why the heck does that happen?  The physical path is shorter through R4, but it really comes down to administrative distance.  EIGRP has an AD of 90, but external EIGRP routes (D EX) have an AD of 170.  Since OSPF routes have an AD of 110, the OSPF route wins.   Even though you may have a much “better” route through one protocol, simply having a route in another protocol with a lower AD will be enough to win.

I found another nuance with R1, as well, but that will have to wait until next time.

Send any Android Twitter clients questions my way.

Audio commentary:
[audio:http://aconaway.com/wp-content/uploads/2010/05/ROUTE-Redistribution-Nuance-1.mp3|titles=ROUTE – Redistribution Nuance #1]

So, why didn’t R2 see the route via OSPF through R5?  I experimented a bit by reloading each router to see what would happen.  When I reload R2, R5 quickly picks up the EIGRP route, but, from there, things seem a little random to me.  Sometimes, R5 picks the OSPF route through R2 again.  Sometimes, R2 picks R5 as the best path and leaves R5 to route via EIGRP.  The same happens when I reload R5; sometimes the route goes one way and sometimes it goes the other.  Can one of you higher-ups shed any light on why this happens like it does?

Aaron Conaway

I shake my head around sometimes and see what falls out. That's what lands on these pages.

More Posts

Follow Me:
Twitter

5 comments for “ROUTE – Redistribution Nuance #1 – Admin Distance FTW

  1. Jason
    May 25, 2010 at 4:09 pm

    It all comes down to OSPF link-state advertisements (LSAs). When R2 is reloaded and the OSPF adjacency re-establishes with R5, depending on whether R2 sends the LSAs to R5 first or R5 sends the LSAs to R2 first, determines whether R2 will end up with the EIGRP route or the OSPF route respectively. The same holds true for R5. Let me explain using two different scenarios.

    Start state for both scenarios:
    R2 – EIGRP route for 10.10.20.0/24 in routing table
    R5 – OSPF route for 10.10.20.0/24 in routing table

    Scenario 1:
    1. R2 is reloaded.
    2. R5 withdrawals the OSPF route from the routing table and installs the EIGRP route.
    3. R2 establishes EIGRP adjacency with R4.
    4. R2 installs the EIGRP route for 10.10.20.0/24 learned from R4 in the routing table.
    5. R2 establishes OSPF adjacency with R5.
    6. R2 sends LSAs to R5.
    7. R5 replaces the EIGRP route in the routing table with the OSPF route learned from R2 (OSPF route has a lower AD).
    8. R5 sends LSAs to R2.
    9. R2 does not install the OSPF route for 10.10.20.0/24 received from R5 in the routing table because the received route has a higher cost/metric. *

    * Remember that R2 already has the 10.10.20.0/24 route in the EIGRP topology table, the OSPF database (because of redistribution of EIGRP into OSPF), and the routing table. When R2 receives the LSA for 10.10.20.0/24 from R5, it compares the route with the entry in the OSPF database, NOT the entry in the routing table. The entry in the OSPF database on R2 has a cost of 20 (the default cost is 1 when redistributing BGP into OSPF; 20 for all other protocols), and the route received from R5 has a cost of 21 (20 + the cost of the FastEthernet interface on R2, which is 1).

    End state for Scenario 1 (same as start):
    R2 – EIGRP route for 10.10.20.0/24 in routing table
    R5 – OSPF route for 10.10.20.0/24 in routing table

    Scenario 2:
    1-5. Same as Scenario 1.
    6. R5 sends LSAs to R2.
    7. R2 replaces the EIGRP route in the routing table with the OSPF route learned from R5 (OSPF route has a lower AD).
    8. R2 sends LSAs to R5.
    9. R5 does not install the OSPF route for 10.10.20.0/24 received from R2 in the routing table because the received route has a higher cost/metric.

    End state for Scenario 2 (reversed):
    R2 – OSPF route for 10.10.20.0/24 in routing table
    R5 – EIGRP route for 10.10.20.0/24 in routing table

    Similar tests can be run by clearing the OSPF process on R2 or R5 instead of reloading the router. When reloading the router, you should always see the EIGRP adjacencies establish before the OSPF adjacencies, because EIGRP has a faster convergence time.

  2. May 26, 2010 at 8:56 pm

    Wow, Jason. Thanks for the thorough explanation. I figured it was something to the effect of whoever talks first is the OSPF-based path to 10.10.20.0/24, but I wasn’t sure if there was some other “higher match” going on as well.

    Thanks again!

Leave a Reply

Your email address will not be published. Required fields are marked *