Introduction to Route Redistribution 

Until there is one routing protocol to rule them all, there is a need to have multiple routing protocols peacefully coexist on the same network. Perhaps Company A runs OSPF, and Company B runs EIGRP, and the two companies merge. Until the newly combined IT staff agrees on a standard routing protocol to use (if they ever do), routes known to OSPF need to be advertised into the portion of the network running EIGRP, and vice versa.

Such a scenario is possible thanks to route redistribution, and that’s the focus of this blog post. Other reasons you might need to perform route redistribution include: different parts of your own company’s network are under different administrative control; you want to advertise routes to your service provider via BGP; or perhaps you want to connect with the network of a business partner. Consider the following basic topology.

In the simple topology show above, we’re wanting OSPF and EIGRP to advertise the routes they know about to one another. This concept is called mutual route redistribution. Since router R2 has one interface in the OSPF autonomous system (AS) and one interface in the EIGRP AS, it bears the responsibility of performing the route redistribution.

Seed Metrics

The primary challenge we run into when redistributing routes between different routing protocols is the different approaches routing protocols use to measure their metrics. For example, OSPF uses a metric of cost, which is based on bandwidth, while EIGRP uses a metric based on bandwidth and delay, by default, but might also consider reliability and/or load (and even use a Maximum Transmission Unit (MTU) value as a tie breaker). The issue isn’t as simple as something like converting currencies between two countries, because in that scenario, there’s a ratio describing the relationship of the two currencies. However, with route redistribution, no such relationship exists. So, what do we do?

We, as administrators, can configure the metric assigned to routes coming in from one AS, which are being redistributed into another AS. If we don’t bother to manually configure a metric to be used for route redistribution, then a seed metric is used. The following table shows the seed metrics used by various routing protocols.

Based on the above table, we can see that, by default, a route redistributed into OSPF will be assigned a metric of 20, unless the route is being redistributed into OSPF from BGP, in which case the route would be assigned a metric value of 1. Interestingly, both RIP and EIGRP have default seed metrics of infinity, meaning that any route redistributed into those routing protocols will be considered unreachable, by default, and therefore not advertised to any other routers. BGP, however, redistributes a route learned from an interior gateway protocol (IGP) using that route’s original metric.

Basic Configuration Example

Certainly, there’s lots more to consider regarding route redistribution, such as the routing loops that can occur when we have more than one router interconnecting our autonomous systems, or how we selectively filter specific routes from being redistributed, but we’ll get to all that in upcoming blog posts. For now, let’s get an understanding of how to perform a basic route redistribution configuration. Consider the previous topology, this time with network and interface information added:

In this topology, router R2 is learning routes from R1 via OSPF and from R3 via EIGRP, as shown in the following output from the show ip route command issued on R2:

However, neither router R1 nor router R3 has learned any routes, because router R2 is not yet performing route redistribution. This is evidenced in the output of the show ip route command issued on R1 and R3:

Let’s now add a route redistribution configuration to router R2. To reinforce the earlier statement that the seed metric for routes redistributed into EIGRP is infinity, we’ll initially not configure any metrics and let the seed metrics take effect.

The redistribute command was issued under router configuration mode for each routing protocol, and no metric was specified. It’s also interesting to note what when we entered the redistribute eigrp 1 command above, we did not include the subnets keyword in the command, which causes both classful and classfuless networks to be redistributed into OSPF. However, as seen in the output below, the subnets keyword was automatically added for us:

While this behavior of having the subnets keyword automatically added is seen in recent versions of Cisco IOS, some older versions of Cisco IOS do not automatically include the subnets keyword, and you might need to manually add it to your redistribute command.

Let’s now take a look at the IP routing tables on routers R1 and R3 to see what routes they’ve learned (and haven’t learned).

The above output shows us that router R2 successfully redistributed routes known to EIGRP into OSPF, which were then learned by router R1. Notice the redistributed routes known to router R1 have a metric of 20, which is OSPF’s seed metric. However, router R3 did not learn any new routes, because when router R2 redistributed routes into EIGRP, it used EIGRP’s seed metric of infinity (meaning unreachable). As a result, those routes were not advertised to router R3.

To resolve this issue, we need to assign a metric to routes being redistributed into EIGRP. There are three primary ways we can assign a non-default metric to routes being redistributed into a routing protocol.

1. Set a default metric for all routing protocols being redistributed into a specific routing protocol.
2. Set a metric as part of the redistribute command.
3. Set a metric using a route-map.

To illustrate the first option, let’s configure the metric to assign to all routes being redistributed into EIGRP.

Context-sensitive help was used in the above example to show each component of the metric being assigned to routes being redistributed into EIGRP. However, the final command was default-metric 1000000 1 255 1 1500. If we were setting a default metric for OSPF, we could have used a command such as default-metric 30, to assign an OSPF cost of 30 to routes being redistributed into OSPF. However, in this example, we only specified a default metric for EIGRP. Let’s now check out the IP routing table on router R3 to see if OSPF routes have been successfully advertised into EIGRP.

Success! Router R3 has learned routes originating in the OSPF AS. We know the routes originally came from outside the EIGRP AS due to the EX code appearing in each of those routes.

The second option for setting the metric on redistributed routes was to assign the metric as part of the redistribute command, which let’s us specify different metrics for different routing protocols being redistributed into a routing process. To illustrate that approach, let’s remove the previous default-metric and redistribute commands from router R2, and enter a redistribute command that specifies the metric to be assigned.

If we now revisit router R3, we get the same result as before:

The third option for setting the metric on redistributed routes was to use a route-map. Route-maps are super powerful and can be used for a variety of configurations. Essentially, they can match specific traffic and set one or more parameters (e.g. a next-hop IP address) for that traffic. In our context though, we’re just going to use a route-map to specify a metric value, and we’ll then apply the route-map to a redistribute command. The following example, shows how we can remove our previous redistribute command from router R2, create a route-map, and then enter a new redistribute command that references our route-map:

In the above example, after removing our existing redistribute command, we created a route-map named SET-METRIC-DEMO. This was a very basic route-map that didn’t need to match any traffic. It was simply used to set a metric. However, in an  upcoming blog post, we'll see that a route-map can be used to give us more control over our route redistribution. In our current example, the route-map was then applied to our new redistribute command. Again, this gives us the same result from the perspective of router R3’s IP routing table:

OSPF E1 vs. E2 Routes

Before we wrap up this first blog post in our Route Redistribution series, let’s once again examine the IP routing table on router R1:

Notice that each of the routes redistributed into OSPF show up in router R1’s IP routing table with an E2 code. However, there’s also the option of having an E1 code, both of which indicate that the route originated from outside the router’s OSPF AS. So, what’s the difference between these two codes?

A code of E2 indicates that a route carries a metric that was assigned by the router performing the redistribution, which is known as an Autonomous System Boundary Router (ASBR). This means that no matter how many additional routers within the OSPF AS we have to cross in order to get back to the ASBR, the metric stays the same as it was when the ASBR redistributed it. When we redistribute routes into OSPF, those routes, by default, are these External Type 2 (E2) routes.

A code of E1 indicates that a route’s metric is made up of the original cost assigned by the ASBR plus the cost required to reach the ASBR. This suggests that an E1 route is generally more accurate, and in fact it is. Although, having a code of E1 doesn’t offer us any advantage in a simple topology like we have, where router R1 only has one path to reach the ASBR (i.e. R2), and where there’s only one way for EIGRP routes to be injected into our OSPF AS (i.e. via router R2).

If we want to redistribute E1 routes into OSPF instead of E2 routes, that can be accomplished with the redistribute command. In the following example, we remove our existing redistribute command for the OSPF routing process on router R2, and then reapply the redistribute command specifying that we want External Type 1 (E1) metrics applied to redistributed routes.

Let’s check out the IP routing table on router R1 to see if things have changed based on this new redistribute command issued on router R2.

In the above output, notice that the routes redistributed into OSPF have a code of E1, instead of the default code of E2. Also, notice that this causes the metric of these routes to be a bit higher. Specifically, router R2 redistributed EIGRP-learned routes into OSPF using OSPF’s seed metric of 20. However, there is an OSPF cost of 1 to get from router R1 to router R2. Therefore, since the redistributed routes were configured as E1 routes, the cost of those routes from the perspective of router R1 is the cost originally assigned by router R1, which was 20, plus the cost for R1 to get to R2, which is 1, for a total cost of 21.

Summary

In this blog post, we considered the need for route redistribution and took a look at a basic configuration. We discussed the impact of a routing protocol’s seed metric (which might be infinity) when performing route redistribution, and we saw three ways to administratively assign a metric to redistributed routes. Finally, we contrasted OSPF’s External Type 1 (E1) and External Type 2 (E2) routes. In an upcoming blog post, we’ll build on this topology and consider how we can selectively filter the routes being redistributed. Then, in yet another blog post, we’ll consider design issues surrounding topologies with multiple points of redistribution between two autonomous systems.

I hope you enjoyed this first glimpse into the world of route redistribution. If you did, please help spread the word by sharing this post with others. Here's the link you can share:

https://www.kwtrain.com/blog/route-redistribution-part-1

Until next time,

Kevin Wallace, CCIEx2 (R/S and Collaboration) #7945