CCNP ROUTE Course: Route Redistribution Between RIP And OSPF

In the first lab in this free CCNP ROUTE redistribution course, we worked with a single protocol.   Now it’s time to make things a little more complex and get two protocols involved.

NOTE:  RIP for IPv4 was removed from the CCNP Route exam in 2015.   Since its Admin Distance of 120 makes it perfect to illustrate route redistribution details regarding OSPF and EIGRP, and since RIP is still in use in real-world networking, I’ve included RIPv2 in this section’s labs.

Using RIPv2 also allows me to introduce you to the seed metric.

RIP And The Seed Metric


Seriously, folks, configuring RIPv2 is as simple as it gets, and redistributing routes into RIP is just as simple – as long as you remember the seed metric!

RIP seed metric

RIP’s sole metric is hop count.  If we redistribute an OSPF route with a cost of 74 into RIP, RIP will not accept the route, since RIP considers a metric of 16 to be unreachable.   Anything higher than that is really unreachable, and not many OSPF routes have a metric of less than 16.

RIP Can't Handle OSPF Metrics

We have to give RIP a value it understands, and that’s where the seed metric comes in.   That seed metric will increment as the route travels through its new domain, just as it would for a route not learned via route redistribution.

Let’s see all of this in action on the following network.

Route Redistribution Lab Topology

The configs:

R1 Config

R2 Config

R3 Config

As you’d expect, R1 has the /24 network in its OSPF routing table via its adjacency with R3.

R1's Routing Table

We’ll try to redistribute that route into the RIP domain without specifying a seed metric, along with R1’s connected route of /24.

Route Redistribution Config On R1

While the IOS made us put in the OSPF process number with the routes to be redistributed, we were not required to enter a seed metric.  The result on R2?

show ip route rip on R2

This is one of those rare occasions where the IOS didn’t let us know the config we just entered isn’t actually going to accomplish anything.  Maybe it’s assuming we’ll add a seed metric later.   We’d have to, because without it we’re not getting any route redistribution into RIP.

No RIP Route For You!

Let’s try that same redistribution while adding a seed metric to each redistribute statement.   To keep things nice and neat (the way we like them), we’ll remove the two previous redistribution statements.    Adding the new ones we’re about to write would not overwrite those, so we’ll delete them.

Redistribution with seed metric

The result on R2:

RIP Routes Appear On R2

Our redistribution is a success!

RIP routes successfully redistributed

Or… IS it?

I’m about to give you one of the most important pieces of networking advice you’ll ever receive from me or anyone else.  Just because you see a network in the routing table, it doesn’t mean you have two-way connectivity to hosts in that destination network.  To show you what I mean, let’s send pings to both interfaces on the segment connecting R1 and R3, along with R3’s interface on the /24 network.

One Good Ping, Two Bad Pings

R2 can ping R1’s interface on the /24 network, but can’t ping either of R3’s interfaces.

What We Can Ping

Time to troubleshoot. We’ll see what’s up by using extended ping to send 10,000 pings from R2 to, and then go to R3 to run debug ip packet to see what happens with those incoming packets.

Ping And Debug Results

Chris Bryant's CCNP ROUTE Study Guide

I received several screens of output from that command before turning the debug off (and then going back to R2 to terminate the extended ping by hitting ctrl-shift-6 twice).  This info showed up over and over on R3:

Debug Results

“unroutable” is the tipoff to what’s happening here.  The packets are coming in just fine from, but R3 has no idea how to send the echo replies back to that address.   Those replies are unroutable because there’s no entry in the IP routing table for that network.

No Return Route On R3

We could put a static route on R3 to resolve that issue, but since we’re in the redistribution business right now, let’s do that instead!  R3 needs to see the /24 network, and that route is a connected route on R1.  No seed metric needs to be specified with OSPF; we’ll stick with that protocol’s default seed metric of 20.

Route Redistribution Into OSPF

What OSPF does require is the inclusion of the subnets option if you want subnets to be redistributed!   (And it’s likely you do.)

R3’s OSPF table:

R3's OSPF Routing Table

There are two important OSPF defaults in that single route, one of which we already know. The default seed metric of 20 is right behind the AD in those brackets, and the other is that curious “O E2” code.  That’s the default code for a route redistributed into OSPF.  An E2 metric reflects only the cost from the ASBR (R1) to the destination (R2).  It does not include the cost from the local router to the ASBR.

OSPF E2 Code Meaning

Let’s send some pings from R3 to R2, and vice versa.

Ping Results All Positive

R3 can ping R2’s interface, and R2 can ping both of R3’s interfaces.  We’re in business!

Before we proceed, a quick review of the default seed metrics (or lack of same) for our dynamic routing protocols:

EIGRP and RIP have a seed metric of “infinity,” and no route with a metric of “infinity” is ever going to make it into our routing table.  Both RIP and EIGRP require a default seed metric.

OSPF has a default seed metric of 20 and a default route type of E2.  Exception: BGP routes redistributed into OSPF are given a seed metric of 1.

The link state protocol ISIS has a default seed metric of zero, but it does allow a route to be redistributed into an ISIS domain without a defined seed metric.  (You won’t see ISIS on the Routing & Switching Cisco exam tracks.)

If you need to change OSPF’s default seed metric, you can do so in the redistribution command itself.  To illustrate, I’ll double the OSPF default seed metric for the /24 route in the previous lab (after removing the previous redistribute commands).

Changing OSPF Seed Metric

The result on R3 is a successful change in the OSPF seed metric.

New OSPF Seed Metric

There’s a value that we haven’t yet mentioned in our route redistribution discussion, and it can have a huge impact on the success of our redistribution.  That value is administrative distance, and we’ll put that into play in our next CCNP ROUTE redistribution lab.

May I also humbly suggest you grab a copy of my CCNP ROUTE Study Guide on Amazon?

Chris Bryant's CCNP ROUTE Study Guide