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.

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: Metric based Administrative Distance


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 662 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

519 Sign Ups in the last 30 days

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

Tags: ,


Forum Replies

  1. Hey René,
    you missed something in the command syntax. After I have read your lesson, I tried the example. With the shown syntax John still doesn’t advertise the Loopback addresses and the connected network. You probably wrote it in the lesson, but I had to complete:

    John(config)#router eigrp 12
    John(config-router)#redistribute rip
    John(config-router)#redistribute connected
    
    John(config)#router rip
    John(config-router)#redistribute eigrp 12
    John(config-router)#redistribute connected
    

    With this syntax, John started to advertise the Loopback and his directly connec

    ... Continue reading in our forum

  2. Hi Sascha,

    That’s right, this tutorial is just an overview of redistribution but I didn’t show the full config. Here’s the configuration example for those 3 routers:

    ... Continue reading in our forum

  3. Hi Lazaros,
    When we do redistribution from Eigrp to OSPF vice versa, which exactly routes are advertised, the best routes in routing table it self OR all routes of EIGRP (or OSPF) before comparing the Admin Distance between different Protocols in routing table.?

  4. Lazaros,
    Many thanks for your usual support

  5. Hi Waleed,

    That would prevent routes from looping around but it also means you have a single point of failure. Redistribution on two routers is no problem but you have to understand and deal with potential issues. For example, take a look at route tagging:

    ... Continue reading in our forum

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