Redistribution is basically the injection of routes learned from one routing domain, static routes or directly connected routes to another routing domain. The reason for redistribution is to have end to end connectivity between routing domains which then could serve different purposes such as backup path to a specific destination for instance. Redistribution can be done “One Way” or “Two Way” which we will see in a second. Typically, running a single routing protocol throughout an IP internetwork is common practice. However, redistribution is essentially necessary when 2 companies merge for instance or in a multi vendor environment. Redistributing routes across is logically a simple process but what you get once your routes make it across is what we need to worry about. Routing protocols differ in terms of metric values, administrative distances, classful or classless capabilities which can affect your routing greatly.

Each routing protocol uses different metric:

*EIGRP: K-Values
*OSPF: Cost
*RIP: Hop Count

When redistributing, we have to let the router know what metric value to use based on what routing protocol we are dealing with. If we fail to do so, our routes won’t be propagated across. We will see that in one of our scenarios.

For the purpose of this topic, we will go through different scenarios and analyze the output once redistribution is done.

Scenario 1

Here, we have 2 routers and we will configure OSPF as our IGP. Only Loopback 1 and Loopback 11 need to be redistributed into the routing domain. All IP addresses are pre-configured so let’s hop right onto the consoles and start configuring…

Here, we have OSPF running ! Now, let’s only redistribute Loopback 1 and Loopback 11 into OSPF on R1…

Here, we used a route-map to accomplish the task. First we created a route-map called “LOOPBACK_2_OSPF”. Note how the route-map name is in capital and plainly divulge its purposes. It is a preference of mine to capitalize route-map names or ACLs and so on when configuring IOS devices. It actually comes in handy when troubleshooting.

We then matched the interfaces we needed to redistribute; In this case, Loopback 1 and Loopback 11. Then, we made a road trip to the OSPF process and redistribute the connected routes while calling the route-map. This way, we made sure we only redistributed what’s specified under the route-map. Noticed the keywork “subnets” ? If the keyword “subnets” is not specified, then only classful networks will be redistributed.

Let’s now check to make sure we see Loopback 1 and Loopback 11 as OSPF routes at the Core. We should not see Loopback 111 in the routng table…

Here, we can clearly see the loopback prefixes we wanted to send across. Notice how Loopback 111 is NOT in the routing table.

Let’s now make it a bit more interesting and add another router to the mix !

Scenario 2

Here, we will configure RIPv2 between R2 and Core. We will then redistribute the OSPF routes we’ve learned at the Core from R1 into RIP. Let’s configure RIP and redistribute the routes…

The configuration at the core here is pretty straight forward. Let’s do the same on R2…

Let’s now redistribute OSPF into RIP at the Core…

All right ! Let’s check R2 routing table…

As you notice here, the routes are NOT there ! That’s because the default seed metric is “infinity”. A metric need to be specified in order for the route to be installed. Let’s do that…

We just chose a metric of 2 in this case. Typically, I just count the number of hop between the devices and use that as a metric. In our case, let’s say we have a Layer 2 switch in between R2 and Core… Then, the number of hop is 2… So, I’m just configuring the metric to be 2. The hop count is now set to 2. Let’s check the routing table again…

Excellent ! Here we can clearly see the loopback prefixes on R2.

Let’s make it even more interesting by adding an EIGRP node into the mix !

Scenario 3

Let’s configure EIGRP between R3 and Core. Let’s also create a couple of Loopbacks on R3 and advertise them into EIGRP…

All right ! Configuration at the core is pretty straight forward. Let’s configure R3…

Here, we’ve specified a route-map and matched the interfaces we needed to redistribute. Also notice how we have to set the metric values when redistributing any routes into EIGRP. This is because by default, EIGRP Seed Metric is “Infinity” which implies your routes will not make it across if not statically defined.

Here we arbitrarily chose 10000 for the bandwidth, 100 for the delay, 255 for reliability, 1 for load and 1500 for MTU.

Let’s check the routing table of the Core router…

As expected, we can clearly see the loopback prefixes at the core. Notice how the administrative distance here is 170 for the loopback prefixes and that they are marked as “D EX” to reference EIGRP external routes.

Let’s now redistribute EIGRP into RIP at the Core router…

Let’s check the routing table of R2 now…

Here, we can clearly see the loopback prefixes of R3 in the routing table but we can not get to them. This is simply because we’ve done a “One Way” redistribution. Meaning we only redistributed EIGRP into RIP so that the RIP domain knows about the prefixes residing in the EIGRP domain but not the other way around. If we wanted ping to work, we could then redistribute RIP into EIGRP at the Core router which would be a “Two Way” redistribution.

But let’s do something else instead… Let’s look at the routing table of R3 and make sure we do not see prefixes in the RIP domain.

Here, we do not see any RIP prefixes… Well, when redistributed they should show up as EIGRP external routes…

Let’s configure a default route at the Core and redistribute it into EIGRP so R3 can route out for destination unknown and then we will try our ping test again…

Here, we create a default route pointing to Null 0. This is a special case because we can’t obviously create a static route pointing to a local interface at the Core. Since we want to redistribute the static route, all we care about is the route to be advertised to R3 by Core. Noticed the keyword “static” ? Let’s take a peak at R3 routing table to see if the default route made it there or not…

Great ! It is there and the forwarding interface is Eth1/2. This is what we wanted ! So let’s try our ping test again from R2 perspective…

Excellent ! This is now working.

There are interesting scenarios which you have dual border routers for example performing similar bidirectional redistribution. The outputs of the routing tables is quite interesting in some cases and can result in suboptimal routing.

That’s all for today. Please let me know if you have any questions ! Thank you for checking in !