Troubleshooting Metric Redistribution

Redistribution is a difficult topic to master. The configuration is quite easy but if you are not careful you will end up with sub-optimal routing and/or routing loops.

When it comes to redistribution issues, there are two possible problems that we can encounter:

In this lesson we’ll take a look at metric based redistribution problems and how to fix them. To demonstrate this I will use the following topology:

metric based redistribution scenario

In this topology we have 4 routers. All routers are running RIPv2 while R3 and R4 are also running OSPF on the link between them.


R1 is only used to advertise a network (1.1.1.0 /24) into RIP. This is what the routing configuration looks like right now (without redistribution):

R1#show run | section rip
router rip
 version 2
 offset-list 0 out 5
 network 1.0.0.0
 network 192.168.12.0
 no auto-summary
R2#show run | section rip
router rip
 version 2
 network 192.168.12.0
 network 192.168.23.0
 network 192.168.24.0
 no auto-summary
R3#show run | section rip
router rip
 version 2
 network 192.168.23.0
 no auto-summary
R4#show run | section rip
router rip
 version 2
 network 192.168.24.0
 no auto-summary

Each router runs RIP version 2, nothing special. Here’s the OSPF configuration of R3 and R4:

R3#show run | section ospf
router ospf 1
 log-adjacency-changes
 network 192.168.34.0 0.0.0.255 area 0
R4#show run | section ospf
router ospf 1
 log-adjacency-changes
 network 192.168.34.0 0.0.0.255 area 0

Let’s take a look what the routing tables of R2, R3 and R4 look like now. Let’s look at the RIP routes first:

R2#show ip route rip
     1.0.0.0/24 is subnetted, 1 subnets
R       1.1.1.0 [120/6] via 192.168.12.1, 00:00:09, FastEthernet1/0
R3#show ip route rip
R    192.168.12.0/24 [120/1] via 192.168.23.2, 00:00:27, FastEthernet0/0
     1.0.0.0/24 is subnetted, 1 subnets
R       1.1.1.0 [120/7] via 192.168.23.2, 00:00:27, FastEthernet0/0
R    192.168.24.0/24 [120/1] via 192.168.23.2, 00:00:27, FastEthernet0/0
R4#show ip route rip
R    192.168.12.0/24 [120/1] via 192.168.24.2, 00:00:02, FastEthernet0/0
     1.0.0.0/24 is subnetted, 1 subnets
R       1.1.1.0 [120/7] via 192.168.24.2, 00:00:02, FastEthernet0/0
R    192.168.23.0/24 [120/1] via 192.168.24.2, 00:00:02, FastEthernet0/0

R2 has learned about network 1.1.1.0 /24 from R1 with a hop count of 6. I used an offset-list on R1 to increase the hop count for this topology, I’ll show you why in a bit.

R3 and R4 also learn about this network and the links in between R1/R2, R2/R3 and R/4. Nothing special so far…

Since R3 and R4 only run OSPF on the directly connected link they don’t have any OSPF routes right now:

R3#show ip route ospf
R4#show ip route ospf

So far so good. Now we will continue by configuring redistribution. I’ll do this step-by-step so you can see what will happen. First we will redistribute RIP into OSPF on R3 and R4:

Redistribute RIP into OSPF

R3 & R4#
(config)#router ospf 1
(config-router)#redistribute rip subnets

The command above redistribute everything from RIP into OSPF. Let’see what R3 and R4 now have in their routing tables:

R3#show ip route ospf
O E2 192.168.24.0/24 [110/20] via 192.168.34.4, 00:01:02, FastEthernet0/1

R3 has now learned through OSPF to reach network 192.168.24.0 /24 with R4 as its next hop. Before we configured redistribution, it had a RIP route for this network with R2 as its next hop. The reason that the RIP route has been removed is because OSPF has a better administrative distance (120 vs 110):

R3 RIP OSPF Route Receive

Is this an issue? For this particular topology right now it won’t cause any issues. R3 can reach this network through R2 or R4. Let’s take a look at R4 now:

R4#show ip route ospf
O E2 192.168.12.0/24 [110/20] via 192.168.34.3, 00:01:14, FastEthernet0/1
     1.0.0.0/24 is subnetted, 1 subnets
O E2    1.1.1.0 [110/20] via 192.168.34.3, 00:01:14, FastEthernet0/1
O E2 192.168.23.0/24 [110/20] via 192.168.34.3, 00:01:14, FastEthernet0/1

The output of R4 is a bit more interesting. Take a close look at the first two entries:

  • 192.168.12.0 /24 with R3 as its next hop.
  • 1.1.1.0 /24 with R3 as its next hop.

R4 used to have RIP routes for these two networks but they have been replaced with these OSPF entries. Is this a problem? It won’t cause any issues in this topology but this is what we call sub-optimal routing:

metric based redistribution before after

We have connectivity but since R4 prefers OSPF (AD 110) over RIP (AD 120) we will send all traffic destined for 192.168.12.0 /24 and 1.1.1.0 /24 through R3. It works, but it’s not optimal.

Why did R4 learn about these routes through R3 and not the other way around (R3 learning those two networks from R4)? R3 and R4 are both redistributing all RIP routes into OSPF so why is there a difference in the output of their routing tables?

It depends on which router has converged first. In my example I started with the redistribution configuration on R3. In this case, R3 will redistribute the RIP routes into OSPF and advertises them to R4. R4 will remove its RIP routes for these networks and installs the OSPF routes.

Since R4 doesn’t have a RIP route for 192.168.12.0 /24 and 1.1.1.0 /24 in its routing table, they can’t be redistributed into OSPF and advertised to R3. If I would have configured R4 first (or reset the OSPF process on R3) then R3 would learn about the redistributed RIP routes through OSPF.

We will forget about this sub-optimal routing issue for now, it won’t cause any issues for this topology and the goal of this lesson is to explain you the redistribution metric problem. In my second post I will explain how to fix this issue. In case you are curious, the short answer is that you have to set the AD of the OSPF entries for 192.168.12.0 /24 and 1.1.1.0 /24 to a value higher than 120. This causes R3 and R4 to use the RIP routes instead of the OSPF routes.

Let’s continue by redistributing OSPF into RIP, that’s where the real fun starts. We’ll do this on R3 and R4:

R3 & R4#
(config)#router rip
config-router)#redistribute ospf 1 metric 1

We redistribute everything from OSPF into RIP. Now take a look what happens with R2:

R2#show ip route rip
     1.0.0.0/24 is subnetted, 1 subnets
R       1.1.1.0 [120/1] via 192.168.24.4, 00:00:05, FastEthernet0/1
R    192.168.34.0/24 [120/1] via 192.168.24.4, 00:00:05, FastEthernet0/1
                     [120/1] via 192.168.23.3, 00:00:01, FastEthernet0/0

Take a good look at the entry for 1.1.1.0 /24. R2 installed this route with R4 as its next hop…this will cause issues, check out this traceroute:

R2#traceroute 1.1.1.1

Type escape sequence to abort.
Tracing the route to 1.1.1.1

  1 192.168.24.4 1388 msec 620 msec 744 msec
  2 192.168.34.3 2552 msec 2308 msec 1904 msec
  3 192.168.23.2 56 msec 48 msec 48 msec
  4 192.168.24.4 76 msec 76 msec 72 msec
  5 192.168.34.3 112 msec 124 msec 100 msec
  6 192.168.23.2 96 msec 100 msec 92 msec
  7 192.168.24.4 124 msec 140 msec 124 msec
  8 192.168.34.3 156 msec 168 msec 176 msec
  9 192.168.23.2 152 msec 136 msec 156 msec
 10 192.168.24.4 176 msec 184 msec 172 msec

That’s not looking good, we now have a routing loop! Traffic is sent like this:

R2 R3 R4 routing loop

So why exactly is this happening? This is the metric redistribution issue that this lesson is named after. Let’s zoom in on R2:

R2 receives two rip routes

R2 is receiving a routing update for network 1.1.1.0 /24 on two interfaces. The update from R1 has a hop count of 6 while the update from R3 has a hop count of 1. R2 selects the route with the lowest hop count so it installs the route towards R3.

RIP doesn’t see the difference between an “internal” and “redistributed” route so it just selects the one with the lowest metric. What about other protocols like OSPF or EIGRP? Are they also vulnerable to this “metric” problem?

  • OSPF doesn’t have this issue because it always prefers internal “O” and “O IA” routes over O “E1” and “E2” routes.
  • EIGRP doesn’t have this issue because it always prefers “internal” routes (AD 90) over “external” routes (AD 170). The only exception to this rule is when the original route is an EIGRP external route. In this case, both routes have an AD of 170.

Before we start looking at different solutions to fix this problem, let’s pause for a moment, take a deep breath and think about the “core” issue of the problem that we have here. The problem with the metric that R2 is facing happens because we redistributed the 1.1.1.0 /24 network from RIP into OSPF and then back into RIP:

Redistribution OSPF RIP R3 R4

Advertising a prefix from one routing protocol into another and then back into the first routing protocol is a bad idea. There’s no point feeding this information back into the routing protocol that originated the prefix.

You should never redistribute prefixes like this:

Routing Protocol X > Y > X

This is a very important redistribution rule, in fact it’s so important that I’ll add it extra large:

Redistribution Rule: Never advertise prefixes from routing protocol X into Y and then back into X.

If we would prevent R4 (and R3) from redistributing the 1.1.1.0 /24 network back into RIP then R2 would never learn this network with that low hop count and there would be no routing loop.

Keep this redistribution rule in mind while we look at the different solutions to fix this problem…

Solutions

There are many different methods to solve the “metric” redistribution issue that you just witnessed. I’ll show you the different methods and their (dis)advantages. It’s important to know some of the different methods if you are preparing for the CCIE R&S lab. Let’s look at the first method…

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 651 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

567 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Forum Replies

  1. Rene,
    Hi. Great explanations as always. One quick clarification - in the offset list example towards the end of the network lesson you show applying the offset list to the F0/1 interface. of R2. I assume that you must also apply it to the F0/0 as well (like you did in the example following using distribute-lists)?

    Many thanks,
    Thomas

  2. Hi Rene, there is actually something even deeper to this that you may not have realised. Let’s say the network is stuck in the loop currently, and R2’s best path is via R4 to reach 1.1.1.0/24. Okay? So since R4 told R2 this is the best path via RIP, this ALSO means that since RIP is distance vector, it means split-horizon would then suppress advertisements of 1.1.1.0/24 from R2 towards R4. So EVEN IF you change the AD on R4, once the loop is active, lowering the AD of RIP or increasing the AD of OSPF external routes should not affect anything. Since R4’s RI

    ... Continue reading in our forum

  3. Hi Stephen,

    The “core” of this problem is that R2 is learning the 1.1.1.0/24 route through R4, something that should never happen since it’s a route that went from RIP > OSPF > RIP. We call it a metric redistribution issue since RIP doesn’t have any way to differentiate between an internal or external route…the lower metric from R4 wins. This really is a routing loop which is bad :slight_smile:

    Once R2 installs the route through R4, it will no longer advertise 1.1.1.0/24 to R4 so the only way for R4 to get to 1.1.1.0/24 is R3…keep in mind that this is not much of an issue…it

    ... Continue reading in our forum

  4. Hi Rene,

    Please disregard my above post / question. After reviewing it carefully, i noticed it’s all about metric, not AD. It’s my bad!
    Sry for taking your time.

    Respectfully,
    Syed

  5. u r the best :+1: well explained i swear to GOD

7 more replies! Ask a question or join the discussion by visiting our Community Forum