Troubleshooting Metric Redistribution

Lesson Contents

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:

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
network 192.168.34.0 0.0.0.255 area 0``````
``````R4#show run | section ospf
router ospf 1
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.

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.

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

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!
• Content created by Rene Molenaar (CCIE #41726)

100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.

Tags: ,

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 Thomas,

Glad to hear you like it! In my example, R4 was advertising the route with the lower better but it could also been R3 (depends on which router converges first) so yes, you should also apply the offset-list to the interface facing R2.

R3 and R4 can never advertise anything useful about network 1.1.1.0 /24 to R2 so we should ignore anything they send.

Rene

3. Hi

I was creating this topology in GNS 3 (version 3.10) . The routers I am using are C-3725 .

When I configure the fa interfaces between R1 and R2 . I get the following message “IP addresses may not be configured on L2 links”.

Could some one guide me where I am going wrong.

Thank You

romesh

4. Hi Romesh,

You probably “inserted” the switch module in the router instead of the routed interfaces.

The interfaces on the switch module are always L2, routed interfaces are L3. Try one of the other interfaces in the slots and it should work.

Rene

5. Dear Rene,

Referring to your “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.,”

I have tried the following:

`R2(config)#router rip`

`R2(config-router)#offset-list LOOPBACK_R1 in 6 fa0/0`

but the hop count is still one from R2 result.

Thanks.

Makara NGY

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