How to Reach Devices in Other Domains with IGP Route Redistribution

One size does not always fit all.

At times there’s a need to run more than one routing protocol and have more than one routing domain: multivendor shops, migration from one protocol to another, scalability issues of a single protocol, political or personal preference, production versus test networks, mergers, and acquisitions.

Redistribution is the process of passing routing information from one routing protocol to another to have reachability for devices that live in different routing domains. Each routing protocol will contribute unique information into the routing tables within its domain, but there can be a desire or need to reach devices in another domain. Redistribution is done on one or more boundary routers between a source routing domain or protocol into a target domain or protocol.

There are three options to get full reachability between domains:

1. Default routes from a boundary router. You can pass a default route from a router that touches all routing domains (boundary router) to those routers that only participate within one domain (internal router). That would cover unknown routes from any domain that the internal routers are unaware of and have the internal routers forward to the boundary router, which would have a complete routing table since it would be participating in all the routing domains. This process works best if there is only one point of contact between the routing domains.


2. One-way redistribution, with a default. One or more boundary routers pass a default route into one domain, but redistribute into another domain. Typically, you would pick a core protocol to redistribute into and the other protocols that get the default route would be looked at as edge protocols. One-way redistribution is used to scale up to larger numbers of routes, such as in a large multinational company. The core protocol could be BGP (Border Gateway Protocol) and the edge protocol(s) could be any IGP (Interior Gateway Protocol), such as OSPF, EIGRP, RIP or IS-IS, or even multiple instances of the same IGP. It works well with acquisitions and mergers, since the “new” part of the company doesn’t have to be running the same routing protocol as the rest, or have to change in the short term. It just adds a connection to the core.


3. Two-way or mutual redistribution passes some or all of the routing information of one protocol into another. This is the most complex option, especially if there is more than one point of contact between the routing domains. It should be used when there are destinations that need to be reachable from one domain to another. But specific policy has to be applied to show how the traffic reaches those destinations or how the traffic has to be treated based on security policies. The common concerns with two-way distribution are routing loops, asymmetric routing and suboptimal routing.

a. Asymmetric routing is where the forwarding path is different than the return path. Issues can arise if there’s a security policy in place for how traffic is forwarded or if there are a set of firewalls in place. Load balancers can also be disrupted by asymmetric routing. Load balancers, which distribute load to specific devices based on a shared address, expect the forwarding and return paths to be predictable.

b. Suboptimal routing is where the most preferred path in a forwarding table is not really the most direct route. This happens when the boundary router “hears” about routes from the originating protocol and also through another routing protocol as an external route. If the administrative distance for the external route protocol is more trustworthy than the originating protocol, the router will prefer the external route over the native route. The fix is to manipulate the administrative distance of the routes in question. This is not the most straight-forward process and varies from platform to platform, even within a single vendor’s product line.

c. Routing loops, or a feedback loop, can occur when the routing information is redistributed into one protocol at one point of contact and then redistributed back into the originating protocol at another point of contact. In order to fix a routing loop, you have to create a feedback filter. The filter would deny the routes originating in the target protocol from being advertised back into that same protocol. You have to build the filter for direction. For example, if you have OSPF and EIGRP domains connected at two or more points, you would build one filter for all the OSPF routes and filter them on the redistribution from EIGRP into OSPF.  Another filter would be built for all the EIGRP routes, filtering them on the redistribution from OSPF into EIGRP. This filtering has to be done on all boundary routers between the two protocols to be effective. You can match on the prefixes or you can use tags, which is my preference. The tags can be assigned as part of the process of redistributing the routes into the target protocol, then you can look for the tags to filter on. You have to create a policy that first looks for the tags and denies them and if they’re not there, then tags the routes to identify the source protocol. This is done for direction, so two polices would have to be created.  All routing protocols, including RIPv2, can support tags.

Let’s look at IGP route redistribution on Cisco devices. When redistributing from one protocol into another, there are a few things to remember:

• The redistribution process pulls from the routing table, not the protocols database. If you are going to redistribute RIP into OSPF, then the process looks for those routes labeled as RIP in the routing table. There is one exception: the connected routes that the protocol is running on.


• On the Cisco routers for IPv4, the connected routes will automatically redistribute as well. This is true as long as you don’t redistribute when connected into that same target protocol, which would cause the feature to stop.


• On the Cisco routers for IPv6, the redistribution process does not redistribute those connected routes that the protocol is running on, unless you add the include-connected option on the redistribution line.

Some Cisco OS requires a policy applied to the redistribution command for routes to be passed from one protocol to another. When redistributing into a protocol, you have to supply metrics for the routes so they’re in the correct format relative to the target protocol. The metric for one protocol doesn’t necessarily look correct for another. There is a seed metric that has to be tied to the external routes going into the target protocol. The table in Figure 1 displays each protocol with some slight variations.

Source	into RIP	into EIGRP	into OSPF	into IS-IS	into BGP (MED)
Connected	1	Interface metric	20 (E2)	0	0
Static	1	Interface metric	20 (E2)	0	0
RIP		Infinite	20 (E2)	0	IGP metric
EIGRP	Infinite	Other process metric	20 (E2)	0	IGP metric
OSPF	Infinite	Infinite		0	IGP metric
IS-IS	Infinite	Infinite	20 (E2)		IGP metric
BGP	Infinite	Infinite	1 (E2)	0

Figure 1: Protocol Variations

If the seed metric is infinite, the route is not useable. You have to supply the seed metric when redistributing the source protocol into the target either on the redistribution line or through the default metric command under the target routing protocol. The seed metric is in the format for that target protocol: hops for RIP, cost for OSPF and IS-IS, and the composite metric for EIGRP (bandwidth, delay, reliability, load and MTU).

One last consideration—if the source is BGP, then only the external BGP routes will be redistributed into the IGP. This is a loop prevention mechanism. If you need to redistribute the internal BGP routes, then configure under the BGP process (not the target protocol) bgp redistribute-internal command.

So, if you’re running more than one routing protocol and you need full or partial reachability, you’ll have to redistribute between those protocols. There are a few things to consider and plan for before you start configuring. Redistribution can be very simple (one pair of protocols, one point of contact) and can be very complex.

Related Courses
ROUTE - Implementing Cisco IP Routing v2.0
CIERS1 – Cisco Expert-Level Training for CCIE Routing and Switching v5.0
SPROUTE - Deploying Cisco Service Provider Network Routing

This blog has been verified by Rise: R67a58c87bbf53e0c5fa1787e8a3e585b