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:

• Metric based
• Administrative Distance based

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:

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:

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):

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:

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.

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 to 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:

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 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:

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:

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…