Configuring OSPF redistribution in the first place can be very overwhelming, especially when attempting to perform two-way redistribution. There are many things to consider ensuring that the intended result will be achieved without injecting unwanted routes into either network. This article takes a look at OSPF redistribution, how it is done and some things to look out for when configuring it to ensure that any potential problems are limited.
Redistribution is the exchange of routing information between two separate routing domains. These domains can be different routing protocols (EIGRP to OSPF, OSPF to EIGRP) or can be between the same routing protocols in different domains (OSPF to OSPF).
One way redistribution is used is to only move routes in a single direction and is typically much easier to configure. Problems typically occur when two-way redistribution is used and multiple redistribution points and/or multiple routing domains are used. These problems occur because it is then possible to have routes sent into a neighboring routing domain and then sent back; it is possible in these situations to have local traffic be routed through an external routing domain because the re-redistributed routes have better metrics.
Another thing to keep in mind when configuring redistribution, routes will only be redistributed if they exist within the current routing table. If the device knows of a route to a network via two different routing protocols, the route that will be inserted into the routing table is the only one that will be considered when using redistribution.
Running down all of the potential problems with redistribution is a very complex task and is well outside the scope of this article, this article will focus on the things to look for when configuring OSPF redistribution to ensure that it works as expected.
There are a couple of different things that make redistribution within OSPF a little different; these different things will be discussed in this section.
As with all Cisco device redistribution, the configuration that is needed is completed while in router configuration mode using the redistribute command. OSPF is different because it also has a subnets parameter that can be used; without this parameter the redistribute command will only redistribute classful networks and not redistribute any subnetted networks. As the majority of OSPF networks utilize subnetting, it is important that subnets be redistributed. Figure 1 below shows an example of the redistribute command being used to take all routes from EIGRP AS 1 and inject them into OSPF PID 10:
Figure 1 – OSPF redistribute command (including all subnets)
OSPF also has another feature that makes it unique, this includes the ability to change the way metrics are injected. By default, OSPF injects all routes as type E2; what this means is that the metric that is injected at the ASBR (the device connecting to the external routing domain) will be used throughout the OSPF routing domain without being altered. Of course, if this is a large OSPF network, the metric being static can be misleading especially when received on devices on the other side of the OSPF network. OSPF also has support for E1 routes. E1 routes take the metric that is configured at the ASBR and adds on the calculated OSPF metric as it is sent through the OSPF network; this makes the metric that is used much more useful when being used in a large OSPF design.
When using redistribution with OSPF (or any other routing protocol), always keep in mind the administrative distance that will be used when an external route is injected. For OSPF, the administrative distance, regardless of whether the route is internal or external is 110. As stated above, it is possible to have routes that, by default, are sent via a longer path because of the way administrative distance is used for routing table selection.
There are a large number of issues that must be considered when setting up redistribution. When multiple routing domains exist and redistribution is required it is very easy to set up domain loops that make routing very inefficient. The purpose of this article was to highlight the common OSPF redistribution issues that engineers encounter and review the information that is needed to avoid them.