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

See?

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’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.

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.

The configs:

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

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

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?

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.

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.

The result on R2:

Our redistribution is a success!

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 172.12.34.0 /24 network.

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

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

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:

“unroutable” is the tipoff to what’s happening here.  The packets are coming in just fine from 172.12.123.2, 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.

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 172.12.123.0 /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.

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:

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.

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

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 20.1.1.0 /24 route in the previous lab (after removing the previous redistribute commands).

The result on R3 is a successful change in the 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?