PHPKB Knowledge Base Software Logo  
Guru Corner
Online Knowledgebase System  
Knowledge Base Home Knowledge Base Home
Home > All Categories > Cisco Systems > Routing > Understanding Redistribution
Question Title Understanding Redistribution

Abstract: Describe the purpose of redistribution and the issues involved.
Prerequisites: Good understanding of IGP routing protocols (OSPF, EIGRP, RIPv2).

Let’s start straight with a rolling out a group of definitions. Redistribution is a process of passing the routing information from one routing domain to another. The ultimate goal of redistribution is to provide full IP connectivity between different routing domains. Another goal (not always required, though) is to provide redundant connectivity, i.e. backup paths between routing domains. Routing domain is a set of routers running the same routing protocol. Redistribution process is performed by border routers - i.e. routers belonging to more than one routing domain. On the contrary, internal routers belong just to one routing domain. Redistribution may be one-way (from one domain to another but not vice-versa) or two-way (bi-directional). Next, internal routes are the IGP prefixes native to a routing protocol; i.e. they are originated by IGP’s natural method, and their respective subnets belong to the IGP routing domain. External routes are the IGP prefixes injected into IGP routing domain via a border router - they have no corresponding IP subnets in the routing domain. They appear to be “attached” somehow to the border router that has originated them, and detailed information about their reachability is “compressed” and lost during the redistribution. Transit routing domain is the domain used as path to transport packets between two other routing domains. Domain becomes transit when two border routers perform bi-directional redistribution with two other routing domains. Stub routing domain is configured not to transit packets (effectively by blocking transit redistribution) between two other domains.

Let’s look at a picture to clarify the concepts.

Fig 1.1

The routing domains on the picture are described in the following table:

Table 1.1

Domain Routers
OSPF R2,R3,R4
EIGRP 123 R1,R2,R3
RIPv2 R4,R5,BB2
EIGRP 356 R3,R5,R6

Examples of internal routers are R1, R6, BB2. The border routers on the picture are reflected in the following table:

Table 1.2

Protocol OSPF EIGRP 356 EIGRP 123 RIPv2
OSPF N/A R3 R2,R3 R4
EIGRP 356 R3 N/A R3 R5
EIGRP 123 R2,R3 R3 N/A NONE
RIPv2 R4 R5 NONE N/A

We will further use the figure and the tables for reference. Note that each domain on Fig 1.1 may be configured to be either transit or stub. For example, if we configure bi-directional redistribution on R3 between RIPv2 and OSPF and also on R2 between EIGRP 123 and OSPF, the OSPF domain will become transit point between two other domains. However, if we take R2 and R3, and configure R2 and R3 to send default routes into EIGRP 123, while redistributing EIGRP 123 into OSPF, we will make EIGRP 123 a stub domain.

What is redistribution needed for?

As we mentioned, the goal is to provide full connectivity between different routing domains. Usually, redistribution is needed when you merge two networks or migrate your network from one routing protocol to another. As such, redistribution is usually deemed to be a temporary solution. However, in reality, we often find that there is nothing more permanent than a temporary solution. And with the respect to CCIE lab exam, you are simply forced to face the redistribution, since the lab scenarios almost anytime involve a number of IGPs running on the topology. Note a very important “functional” property of redistribution: effectively, redistribution is used to “broadcast” the complete routing information among all the routing domain in a given topology.

What are the problems with redistribution?

a) Suboptimal routing

As it has been mentioned already, the external routes have no detailed information about their reachability. Even more, their original routing metric (e.g. cost) has to be converted to the native metric (e.g. to hop count). This is where a concept of seed metric appears. Seed metric is the initial metric assigned to external routes, redistributed into internal protocol (e.g. under RIP routing process: redistribute ospf 1 metric 1). In effect, external prefixes appear to be “attached” to the advertising border router, with “native” seed metric assigned. Due to such “simplifications”, and loss of detailed information, suboptimal routing may occur.

Example:

For our example, take EIGRP 123 routing domain. If RIPv2 routes enter EIGRP 123 domain by transiting OSPF and EIGRP 356 domains, packets from R1 to BB2 may take path R1->R2->R4->BB2 (if R2 sets better seed metric). In some worse cases, this route may even take path R1->R2->R3->R5->BB2 (if R2 thinks RIPv2 external routes transiting EIGRP 356 and redistributed into OSPF are better than RIPv2 injected into OSPF by R4) . Sometimes, due to asymmetric redistributions packets may take one path in forward direction and the other in the backward (e.g. packets from R1 to BB2 flow R1->R2->R4->BB2 and packets from BB2 to R1 flow BB2->R5->R3->R1).

b) Routing Loops

The other, more dangerous problem, is possibility that routing loops they may appear due to redistribution. Every routing protocol is able to converge to a loop-free routing only if it has full information on the existing topology. OSPF needs a complete link-state view of the intra-area topologies and star-like connectivity of non-backbone area to Area0. EIGRP requires a to carry out diffusing computations on all the routers in order to provide a loop free routing. RIP slow converges by executing a Bellman-Ford algorithm (gradient-driven optimization) on a whole topology. Since redistribution squashes and hides the original information, no IGP could guarantee a loop-free topology. Loops usually occur when IGP native information (internal routes) re-enter the routing domain as external prefixes due to use of two-way redistribution. The last important thing to note: external routes are always redistributed in a “distance-vector” fashion - i.e. advertised as a vector of prefixes and associated distances, even with link-state protocols.

Example:

Imagine that R4, R5 and R3 are configured for bi-directional redistribution between OSPF, RIPv2 and EIGRP 356 respectively. In effect, RIPv2 routes may transit EIGRP and OSPF, and appear on R4 as OSPF routes. Due to OSPF higher AD, they will be preferred at R4 over native routes, and will leak into RIPv2 domain. Further, BB2 may prefer those “looped back” routes (if say R4 is closer to BB2 than R5) and try to reach R5 connected interfaces via R4->R3. But thanks to two-way redistribution R3 will think R5 is better being reached via R4 - a loop is formed.

Is there a way to overcome those issues?

The answer is - “yes, by using a carefully designed redistribution policy”. Since routing protocols could not find and isolate the inter-domain loops, we either need to invent a new “super-routing” protocol, running on top of all IGPs (they call it BGP actually, and use to redistribute routing information between autonomous systems), or configure redistribution so that no routing loops would potentially occur and (hopefully) routing become “somewhat” optimal. We are going to describe a set of heuristics (rules of thumb) that could help us designing loop-less redistribution schemes. We start with the concept of administrative distance.

Administrative distance is a special preference value that allows selection of one protocols prefixes over another. This feature definitely needed on border routers (running multiple IGPs), which may receive the same prefixes via different IGPs. Cisco has assigned some default AD values to it’s IGPs (EIGRP, OSPF, RIPv2: 90, 110, 120), but we’ll see how this should be changed in accordance with policy. For now, we should note that two protocols - OSPF and EIGRP - offer capability to assign different administrative distance values to internal and external prefixes, thanks to their property to distinguish internal and external routes. This is a very powerful feature, which we are going to use extensively during our redistribution policy design.

Here comes our first rule of thumb. Rule 1: Router should always prefer internal prefix information over any external information. Clearly this is because external information is condensed and incomplete. For our example, if R4 receives a native prefix via RIPv2 and the same prefix via OSPF, it should prefer RIPv2 information over OSPF, even though OSPF has better AD than RIPv2 by default. This is easy to implement, thanks to the fact that we can change OSPF external AD independently of OSPF internal AD. The same rule holds true for any internal router: (not just for border routers) always prefer internal information over external for the same prefix. For example if R2 Loopback0 is advertised as native into EIGRP 123 and OSPF, and then redistributed into OSPF via R3 somehow, R4 should be configure so that OSPF external AD is higher than internal AD, and so that internal prefix is always preferred. This rule also eliminates suboptimal routing, by making sure no “dubious” paths are selected to reach a prefix. Effectively it is implemented so that all protocol external ADs are greater than any protocol internal AD (e.g. OSPF External AD > RIP Internal AD, EIGRP External AD > RIP Internal AD etc). However, RIPv2 has no notion of external routes.

So how could we implement this rule with RIPv2? First we should ensure that RIP AD is always greater than any other protocols external AD - on border routers, where this is needed. Next we need to configure so that RIPv2 internal routes have AD less that any other protocols external AD. To do this, we can take an access-list, enumerate all RIPv2 prefixes, and selectively assign a lower AD to those prefixes. Again, note that this procedure is needed on border routers only, and that you can re-use the access-list. Next, we need to make sure that inside a RIPv2 domain external routes are always considered worse than internal. We can effectively implement this by assigning a relatively high seed metric to redistributed (external) routes - say 8 hops. Since RIP topologies of large diameter are rare, it’s safe to assume with our policy that any prefix with metric (hop count) > 8 is an external one. (We may even use this property to distinguish RIPv2 internal prefixes in route-maps, thank to match metric feature).

Next rule of thumb is known as Rule 2: Split-Horizon - Never redistribute a prefix injected from domain A into B back to domain A. This rule is targeted to eliminate “short” loops, by preventing the routing information leaked out of a routing domain to re-enter the same domain via some other point. For out example, it R2 and R3 are doing a two-way redistribution, we may want to prohibit EIGRP routes to transit the OSPF domain and enter the EIGRP domain again. This kind of situations occurs when two routing domains have more than one point of mutual redistribution. While the rule could be implemented playing with AD values or matching only internal routs in route-maps, it’s easier and more generic to use tagged routes and filter based on tag information. For example we may tag EIGRP 123 routes injected into OSPF with the tag value of “123″ and then configure to block routes with this tag, when redistributing from OSPF into EIGRP 123. Additionally, we tag OSPF routes with tag 110 when sending them to EIGRP 123 domain, and block routes with the same tag entering back the OSPF domain. While this rule may seem to be effective on detecting only “short” loops, it could be used to develop a simple, yet loop-free redistribution strategy.

First, recall how OSPF behaves with respect to inter-area routes exchange. In essence, all areas are linked to a backbone and form a star - loop-free - topology. OSPF then safely passes down the areas summary LSA using the distance-vector behavior, and never advertises those LSA back into backbone. This way, the core knows all the routing information and redistributes it down to leaves. And thanks to a loop-free “skeleton” we are guaranteed to never face any routing loops even with distance-vector advertisements. Now we can reuse this idea among the heterogenous routing domains. Take one routing domain and make it the center of the new star - in essence, make it the only transit domain in the topology. The other domains will effectively become “stub” domains, using our previous definitions - i.e. they exchange routes only with the core routing domain. Proceed with configuring two-way redistribution on border routers (enable route prefix exchange). If a given domain has more than one point of attachment to the star core (the backbone), configure to implement Rule 2 on border routers. Next, implement Rule 1 on border routers, to avoid suboptimal routing issues. That does the trick! For our example, we may configure mutual redistribution on R2 (EIGRP 123 and OSPF), R3 (EIGRP 123 and OSPF), R4 (RIPv2 and OSPF). We will then need to implement tag-based filtering on R2 and R3, as well as tune ADs in accordance with Rule 1. The detailed configuration examples will follow in the further publications.

Okay, now what if we don’t have a “central” routing domain attached to all other domains in topology? Let’s say R3 is not running OSPF in our example, and we have all routing domains connected in “ring” fashion. In short, the same idea still may be utilized, by replacing pure “star-like” topology with “tree”. Tree is loop-less too, so there is a guarantee that no loops will form. We are going to discuss this, and other more complicated scenarios in the next publications.
 

Simple Redistribution Step-by-Step

We’re going to take our basic topology from the previous post Understanding Redistribution Part I , and configure to provide full connectivity between all devices with the most simple configuration. Then we are going to tweak some settings and see how they affect redistribution and optimal routing. This is going to be an introductory example to illustrate the redistribution control techniques mentioned previously.

 

First, we configure IGP routing per the diagram, and advertise Loopback0 interfaces (150.X.Y.Y/24, where X is the rack number, and Y is the router number) into IGP. Specifically, R2, R3 and R4 Loopbacks are advertised into OSPF Area 0. R5 and R6 Loopbacks are advertised into EIGRP 356 and R1 Loopback interface is simply advertised into EIGRP 123.

Next, we propose OSPF to be the core routing domain, used as transit path to reach any other domains. All other domains, in effect, will be connected as stub (non-transit) to the core domain. We start with EIGRP 123 and OSPF domains, and enable mutual redistribution between them on R2 and R3 routers:

R2:
!
! Metric values are chosen just to be easy to type in
! No big secret rules of thumb behind this one
!
router eigrp 123
 redistribute ospf 1 metric 1 1 1 1 1
!
router ospf 1
 redistribute eigrp 123 subnets

R3:
router eigrp 123
 redistribute ospf 1 metric 1 1 1 1 1
!
router ospf 1
 redistribute eigrp 123 subnets

In effect, we would expect both routing domains to become transit for each other. However, EIGRP has a really nice feature of assigning default AD value of 170 to external routes. This, in turn, prevents circular redistribution - all OSPF routes injected into EIGRP 123 domain have AD of 170, and are effectively stopped from being advertised back into OSPF, since native OSPF routes preempt them. Let’s see the routing table states:

Rack18R1#show ip route eigrp
     174.18.0.0/24 is subnetted, 2 subnets
D EX    174.18.234.0
           [170/2560002816] via 174.18.123.3, 00:02:03, FastEthernet0/0
           [170/2560002816] via 174.18.123.2, 00:02:03, FastEthernet0/0
     150.18.0.0/24 is subnetted, 4 subnets
D EX    150.18.4.0
           [170/2560002816] via 174.18.123.3, 00:02:03, FastEthernet0/0
           [170/2560002816] via 174.18.123.2, 00:02:03, FastEthernet0/0
D EX    150.18.2.0
           [170/2560002816] via 174.18.123.3, 00:02:03, FastEthernet0/0
           [170/2560002816] via 174.18.123.2, 00:02:03, FastEthernet0/0
D EX    150.18.3.0
           [170/2560002816] via 174.18.123.3, 00:02:03, FastEthernet0/0
           [170/2560002816] via 174.18.123.2, 00:02:03, FastEthernet0/0

Just as we would expect, R1 has two routes from each OSPF prefix, since both R2 and R3 assign the same seed metric to redistributed routes.

Rack18R2#show ip route | beg Gate
Gateway of last resort is not set

     174.18.0.0/24 is subnetted, 2 subnets
C       174.18.234.0 is directly connected, Serial0/0
C       174.18.123.0 is directly connected, FastEthernet0/0
     150.18.0.0/24 is subnetted, 4 subnets
O       150.18.4.0 [110/65] via 174.18.234.4, 00:00:19, Serial0/0
D       150.18.1.0 [90/156160] via 174.18.123.1, 00:00:13, FastEthernet0/0
C       150.18.2.0 is directly connected, Loopback0
O       150.18.3.0 [110/65] via 174.18.234.3, 00:00:19, Serial0/0

Rack18R3#show ip route  | beg Gate
Gateway of last resort is not set

     174.18.0.0/24 is subnetted, 3 subnets
C       174.18.234.0 is directly connected, Serial1/0
C       174.18.0.0 is directly connected, FastEthernet0/1
C       174.18.123.0 is directly connected, FastEthernet0/0
     150.18.0.0/24 is subnetted, 6 subnets
O       150.18.4.0 [110/782] via 174.18.234.4, 00:00:54, Serial1/0
D       150.18.5.0 [90/156160] via 174.18.0.5, 00:17:51, FastEthernet0/1
D       150.18.6.0 [90/156160] via 174.18.0.6, 00:17:49, FastEthernet0/1
D       150.18.1.0 [90/156160] via 174.18.123.1, 00:00:48, FastEthernet0/0
O       150.18.2.0 [110/782] via 174.18.234.2, 00:00:54, Serial1/0
C       150.18.3.0 is directly connected, Loopback0

All seems to be fine here too; thanks to EIGRP AD value of 90, EIGRP “native” prefixes are reachable via EIGRP, and OSPF native subnets are reachable via OSPF (since EIGRP External AD value is 170). Next, we move a step further, and redistribute between OSPF and EIGRP 356 domains, i.e. attach the latter domain to the “core”:

R3:
router eigrp 356
 redistribute ospf 1 metric 1 1 1 1 1
!
router ospf 1
 redistribute eigrp 123 subnets
 redistribute eigrp 356 subnets

Since EIGRP 356 domain has just one point of attachement to the core, there should be no big problems. Look at the routing table of R1:

Rack18R1#show ip route eigrp
     174.18.0.0/24 is subnetted, 3 subnets
D EX    174.18.234.0
           [170/2560002816] via 174.18.123.3, 00:05:52, FastEthernet0/0
           [170/2560002816] via 174.18.123.2, 00:05:52, FastEthernet0/0
D EX    174.18.0.0
           [170/2560002816] via 174.18.123.2, 00:01:36, FastEthernet0/0
     150.18.0.0/24 is subnetted, 6 subnets
D EX    150.18.4.0
           [170/2560002816] via 174.18.123.3, 00:05:52, FastEthernet0/0
           [170/2560002816] via 174.18.123.2, 00:05:52, FastEthernet0/0
D EX    150.18.5.0
           [170/2560002816] via 174.18.123.2, 00:01:36, FastEthernet0/0
D EX    150.18.6.0
           [170/2560002816] via 174.18.123.2, 00:01:36, FastEthernet0/0
D EX    150.18.2.0
           [170/2560002816] via 174.18.123.3, 00:05:52, FastEthernet0/0
           [170/2560002816] via 174.18.123.2, 00:05:52, FastEthernet0/0
D EX    150.18.3.0
           [170/2560002816] via 174.18.123.3, 00:05:52, FastEthernet0/0
           [170/2560002816] via 174.18.123.2, 00:05:52, FastEthernet0/0

Ah, great. R1 sees R5 and R6 loopback as they are advertised by R2 only. Naturally, redistribution between local routing processes on R3 is non-transitive - when we inject EIGRP 356 routes into OSPF, they are not further propagated into EIGRP 123, even though OSPF is redistributed into EIGRP 123. So R1 packets would have to transit OSPF domain, in order to reach R5 and R6.

R2 sees EIGRP 356 routes reachable via R3:

Rack18R2#show ip route | beg Gate
Gateway of last resort is not set

     174.18.0.0/24 is subnetted, 3 subnets
C       174.18.234.0 is directly connected, Serial0/0
O E2    174.18.0.0 [110/20] via 174.18.234.3, 00:02:20, Serial0/0
C       174.18.123.0 is directly connected, FastEthernet0/0
     150.18.0.0/24 is subnetted, 6 subnets
O       150.18.4.0 [110/65] via 174.18.234.4, 00:06:41, Serial0/0
O E2    150.18.5.0 [110/20] via 174.18.234.3, 00:02:20, Serial0/0
O E2    150.18.6.0 [110/20] via 174.18.234.3, 00:02:20, Serial0/0
D       150.18.1.0 [90/156160] via 174.18.123.1, 00:06:35, FastEthernet0/0
C       150.18.2.0 is directly connected, Loopback0
O       150.18.3.0 [110/65] via 174.18.234.3, 00:06:41, Serial0/0

And R3 in turn sees them as EIGRP 356 native ones:

Rack18R3#show ip route | beg Gate
Gateway of last resort is not set

     174.18.0.0/24 is subnetted, 3 subnets
C       174.18.234.0 is directly connected, Serial1/0
C       174.18.0.0 is directly connected, FastEthernet0/1
C       174.18.123.0 is directly connected, FastEthernet0/0
     150.18.0.0/24 is subnetted, 6 subnets
O       150.18.4.0 [110/782] via 174.18.234.4, 00:02:47, Serial1/0
D       150.18.5.0 [90/156160] via 174.18.0.5, 00:02:36, FastEthernet0/1
D       150.18.6.0 [90/156160] via 174.18.0.6, 00:02:36, FastEthernet0/1
D       150.18.1.0 [90/156160] via 174.18.123.1, 00:02:34, FastEthernet0/0
O       150.18.2.0 [110/782] via 174.18.234.2, 00:02:47, Serial1/0
C       150.18.3.0 is directly connected, Loopback0

Fine, now to finish the picture, we redistribute between RIP and OSPF on R4

R4:
router ospf 1
 redistribute rip subnets
!
! Assign some large metric value to redistributed routes
!
router rip
 redistribute ospf 1 metric 8

Check to see the full routing table of R1:

Rack18R1#show ip route eigrp
D EX 222.22.2.0/24
           [170/2560002816] via 174.18.123.3, 00:02:16, FastEthernet0/0
           [170/2560002816] via 174.18.123.2, 00:02:16, FastEthernet0/0
D EX 220.20.3.0/24
           [170/2560002816] via 174.18.123.3, 00:02:16, FastEthernet0/0
           [170/2560002816] via 174.18.123.2, 00:02:16, FastEthernet0/0
     174.18.0.0/24 is subnetted, 3 subnets
D EX    174.18.234.0
           [170/2560002816] via 174.18.123.3, 00:05:17, FastEthernet0/0
           [170/2560002816] via 174.18.123.2, 00:05:17, FastEthernet0/0
D EX    174.18.0.0
           [170/2560002816] via 174.18.123.2, 00:08:33, FastEthernet0/0
D EX 192.10.18.0/24
           [170/2560002816] via 174.18.123.3, 00:02:16, FastEthernet0/0
           [170/2560002816] via 174.18.123.2, 00:02:16, FastEthernet0/0
     150.18.0.0/24 is subnetted, 6 subnets
D EX    150.18.4.0
           [170/2560002816] via 174.18.123.3, 00:05:17, FastEthernet0/0
           [170/2560002816] via 174.18.123.2, 00:05:17, FastEthernet0/0
D EX    150.18.5.0
           [170/2560002816] via 174.18.123.2, 00:05:14, FastEthernet0/0
D EX    150.18.6.0
           [170/2560002816] via 174.18.123.2, 00:05:15, FastEthernet0/0
D EX    150.18.2.0
           [170/2560002816] via 174.18.123.3, 00:05:20, FastEthernet0/0
           [170/2560002816] via 174.18.123.2, 00:05:20, FastEthernet0/0
D EX    150.18.3.0
           [170/2560002816] via 174.18.123.3, 00:05:20, FastEthernet0/0
           [170/2560002816] via 174.18.123.2, 00:05:20, FastEthernet0/0
D EX 205.90.31.0/24
           [170/2560002816] via 174.18.123.3, 00:02:19, FastEthernet0/0
           [170/2560002816] via 174.18.123.2, 00:02:19, FastEthernet0/0

Seems like we have connectivity to all prefixes, even the ones injected by BB2 (205.90.31.0/24 etc). All of them, with except to EIGRP 356 routes are symmetrically reachable via R2 and R3. Now, a long snapshot of all other routing tables:

Rack18R2#show ip route | beg Gate
Gateway of last resort is not set

O E2 222.22.2.0/24 [110/20] via 174.18.234.4, 00:03:29, Serial0/0
O E2 220.20.3.0/24 [110/20] via 174.18.234.4, 00:03:29, Serial0/0
     174.18.0.0/24 is subnetted, 3 subnets
C       174.18.234.0 is directly connected, Serial0/0
O E2    174.18.0.0 [110/20] via 174.18.234.3, 00:03:29, Serial0/0
C       174.18.123.0 is directly connected, FastEthernet0/0
O E2 192.10.18.0/24 [110/20] via 174.18.234.4, 00:03:29, Serial0/0
     150.18.0.0/24 is subnetted, 6 subnets
O       150.18.4.0 [110/65] via 174.18.234.4, 00:03:29, Serial0/0
O E2    150.18.5.0 [110/20] via 174.18.234.3, 00:03:29, Serial0/0
O E2    150.18.6.0 [110/20] via 174.18.234.3, 00:03:29, Serial0/0
D       150.18.1.0 [90/156160] via 174.18.123.1, 00:19:36, FastEthernet0/0
C       150.18.2.0 is directly connected, Loopback0
O       150.18.3.0 [110/65] via 174.18.234.3, 00:03:29, Serial0/0
O E2 205.90.31.0/24 [110/20] via 174.18.234.4, 00:03:29, Serial0/0

Rack18R3#show ip route | beg Gate
Gateway of last resort is not set

O E2 222.22.2.0/24 [110/20] via 174.18.234.4, 00:03:56, Serial1/0
O E2 220.20.3.0/24 [110/20] via 174.18.234.4, 00:03:56, Serial1/0
     174.18.0.0/24 is subnetted, 3 subnets
C       174.18.234.0 is directly connected, Serial1/0
C       174.18.0.0 is directly connected, FastEthernet0/1
C       174.18.123.0 is directly connected, FastEthernet0/0
O E2 192.10.18.0/24 [110/20] via 174.18.234.4, 00:03:56, Serial1/0
     150.18.0.0/24 is subnetted, 6 subnets
O       150.18.4.0 [110/782] via 174.18.234.4, 00:03:56, Serial1/0
D       150.18.5.0 [90/156160] via 174.18.0.5, 00:06:58, FastEthernet0/1
D       150.18.6.0 [90/156160] via 174.18.0.6, 00:06:58, FastEthernet0/1
D       150.18.1.0 [90/156160] via 174.18.123.1, 00:06:57, FastEthernet0/0
O       150.18.2.0 [110/782] via 174.18.234.2, 00:03:56, Serial1/0
C       150.18.3.0 is directly connected, Loopback0
O E2 205.90.31.0/24 [110/20] via 174.18.234.4, 00:03:56, Serial1/0

Rack18R4#show ip route | beg Gate
Gateway of last resort is not set

R    222.22.2.0/24 [120/7] via 192.10.18.254, 00:00:19, FastEthernet0/0
R    220.20.3.0/24 [120/7] via 192.10.18.254, 00:00:19, FastEthernet0/0
     174.18.0.0/24 is subnetted, 3 subnets
C       174.18.234.0 is directly connected, Serial0/0
O E2    174.18.0.0 [110/20] via 174.18.234.3, 00:05:11, Serial0/0
O E2    174.18.123.0 [110/20] via 174.18.234.3, 00:05:11, Serial0/0
                     [110/20] via 174.18.234.2, 00:05:11, Serial0/0
C    192.10.18.0/24 is directly connected, FastEthernet0/0
     150.18.0.0/24 is subnetted, 6 subnets
C       150.18.4.0 is directly connected, Loopback0
O E2    150.18.5.0 [110/20] via 174.18.234.3, 00:05:11, Serial0/0
O E2    150.18.6.0 [110/20] via 174.18.234.3, 00:05:11, Serial0/0
O E2    150.18.1.0 [110/20] via 174.18.234.3, 00:05:11, Serial0/0
                   [110/20] via 174.18.234.2, 00:05:11, Serial0/0
O       150.18.2.0 [110/65] via 174.18.234.2, 00:05:11, Serial0/0
O       150.18.3.0 [110/65] via 174.18.234.3, 00:05:11, Serial0/0
R    205.90.31.0/24 [120/7] via 192.10.18.254, 00:00:20, FastEthernet0/0

A quick stop at R5. Since RIPv2 AD is 120, and EIGRP External AD is 170, R5 sees all non EIGRP 356 routes via RIP. Not a big problem right now, but it creates “suboptimal” paths to EIGRP 123 routes, since it’s more, well, effective to reach them over Ethernet links.

Rack18R5#sh ip route | beg Gate
Gateway of last resort is not set

R    222.22.2.0/24 [120/7] via 192.10.18.254, 00:00:25, FastEthernet0/1
R    220.20.3.0/24 [120/7] via 192.10.18.254, 00:00:25, FastEthernet0/1
     174.18.0.0/24 is subnetted, 3 subnets
R       174.18.234.0 [120/8] via 192.10.18.4, 00:00:04, FastEthernet0/1
C       174.18.0.0 is directly connected, FastEthernet0/0
R       174.18.123.0 [120/8] via 192.10.18.4, 00:00:04, FastEthernet0/1
C    192.10.18.0/24 is directly connected, FastEthernet0/1
     150.18.0.0/24 is subnetted, 6 subnets
R       150.18.4.0 [120/8] via 192.10.18.4, 00:00:04, FastEthernet0/1
C       150.18.5.0 is directly connected, Loopback0
D       150.18.6.0 [90/156160] via 174.18.0.6, 00:43:41, FastEthernet0/0
R       150.18.1.0 [120/8] via 192.10.18.4, 00:00:04, FastEthernet0/1
R       150.18.2.0 [120/8] via 192.10.18.4, 00:00:04, FastEthernet0/1
R       150.18.3.0 [120/8] via 192.10.18.4, 00:00:04, FastEthernet0/1
R    205.90.31.0/24 [120/7] via 192.10.18.254, 00:00:25, FastEthernet0/1

We may opt to craeate an access-list, select all RIP routes, and freeze their AD down to 120. Next we can rais global RIP distance to something bigger than 170, to fix this issue. Not a big deal, though! OK, so the only left are R6 and BB2:

Rack18R6#show ip route eigrp
D EX 222.22.2.0/24 [170/2560002816] via 174.18.0.3, 00:07:29, FastEthernet0/0
D EX 220.20.3.0/24 [170/2560002816] via 174.18.0.3, 00:07:29, FastEthernet0/0
     174.18.0.0/24 is subnetted, 2 subnets
D EX    174.18.234.0
           [170/2560002816] via 174.18.0.3, 00:10:31, FastEthernet0/0
D EX 192.10.18.0/24 [170/2560002816] via 174.18.0.3, 00:07:29, FastEthernet0/0
     150.18.0.0/24 is subnetted, 5 subnets
D EX    150.18.4.0 [170/2560002816] via 174.18.0.3, 00:10:31, FastEthernet0/0
D       150.18.5.0 [90/156160] via 174.18.0.5, 00:41:30, FastEthernet0/0
D EX    150.18.2.0 [170/2560002816] via 174.18.0.3, 00:10:31, FastEthernet0/0
D EX    150.18.3.0 [170/2560002816] via 174.18.0.3, 00:10:31, FastEthernet0/0
D EX 205.90.31.0/24 [170/2560002816] via 174.18.0.3, 00:07:29, FastEthernet0/0

BB2>sh ip ro rip
     174.18.0.0/24 is subnetted, 3 subnets
R       174.18.234.0 [120/8] via 192.10.18.4, 00:00:24, Ethernet0
R       174.18.0.0 [120/8] via 192.10.18.4, 00:00:24, Ethernet0
R       174.18.123.0 [120/8] via 192.10.18.4, 00:00:24, Ethernet0
     150.18.0.0/24 is subnetted, 6 subnets
R       150.18.4.0 [120/8] via 192.10.18.4, 00:00:24, Ethernet0
R       150.18.5.0 [120/8] via 192.10.18.4, 00:00:24, Ethernet0
R       150.18.6.0 [120/8] via 192.10.18.4, 00:00:24, Ethernet0
R       150.18.1.0 [120/8] via 192.10.18.4, 00:00:24, Ethernet0
R       150.18.2.0 [120/8] via 192.10.18.4, 00:00:24, Ethernet0
R       150.18.3.0 [120/8] via 192.10.18.4, 00:00:24, Ethernet0

This seems to be an easy one. We’re done, full connectivity attained, and no loops were introduced. Thanks to EIGRP External AD there is no need to manually filter routes on the border routes between EIGRP 123 and OSPF. But what if we are asked to redistribute some “native” EIGRP 123 prefixes (e.g. R1 Loopback0) instead of advertising them?

R1:
router eigrp 123
 redistribute connected
 network 174.18.123.1 0.0.0.0

See what happens:

Rack18R2#show ip route | beg Gate
Gateway of last resort is not set

O E2 222.22.2.0/24 [110/20] via 174.18.234.4, 00:15:13, Serial0/0
O E2 220.20.3.0/24 [110/20] via 174.18.234.4, 00:15:13, Serial0/0
     174.18.0.0/24 is subnetted, 3 subnets
C       174.18.234.0 is directly connected, Serial0/0
O E2    174.18.0.0 [110/20] via 174.18.234.3, 00:15:13, Serial0/0
C       174.18.123.0 is directly connected, FastEthernet0/0
O E2 192.10.18.0/24 [110/20] via 174.18.234.4, 00:15:13, Serial0/0
     150.18.0.0/24 is subnetted, 6 subnets
O       150.18.4.0 [110/65] via 174.18.234.4, 00:15:13, Serial0/0
O E2    150.18.5.0 [110/20] via 174.18.234.3, 00:15:13, Serial0/0
O E2    150.18.6.0 [110/20] via 174.18.234.3, 00:15:13, Serial0/0
D EX    150.18.1.0 [170/156160] via 174.18.123.1, 00:01:49, FastEthernet0/0
C       150.18.2.0 is directly connected, Loopback0
O       150.18.3.0 [110/65] via 174.18.234.3, 00:15:13, Serial0/0
O E2 205.90.31.0/24 [110/20] via 174.18.234.4, 00:15:13, Serial0/0

R2 sees R1 Loopback0 as EIGRP external route reachable via R1. However, the situation is different on R3:

Rack18R3#show ip route | beg Gate
Gateway of last resort is not set

O E2 222.22.2.0/24 [110/20] via 174.18.234.4, 00:16:10, Serial1/0
O E2 220.20.3.0/24 [110/20] via 174.18.234.4, 00:16:10, Serial1/0
     174.18.0.0/24 is subnetted, 3 subnets
C       174.18.234.0 is directly connected, Serial1/0
C       174.18.0.0 is directly connected, FastEthernet0/1
C       174.18.123.0 is directly connected, FastEthernet0/0
O E2 192.10.18.0/24 [110/20] via 174.18.234.4, 00:16:10, Serial1/0
     150.18.0.0/24 is subnetted, 6 subnets
O       150.18.4.0 [110/782] via 174.18.234.4, 00:16:10, Serial1/0
D       150.18.5.0 [90/156160] via 174.18.0.5, 00:19:12, FastEthernet0/1
D       150.18.6.0 [90/156160] via 174.18.0.6, 00:19:12, FastEthernet0/1
O E2    150.18.1.0 [110/20] via 174.18.234.2, 00:02:46, Serial1/0
O       150.18.2.0 [110/782] via 174.18.234.2, 00:16:10, Serial1/0
C       150.18.3.0 is directly connected, Loopback0
O E2 205.90.31.0/24 [110/20] via 174.18.234.4, 00:16:10, Serial1/0

Thanks to R1 Loopback0 being redistributed into OSPF, R3 prefers it via R2, not R1, due to AD values. Not a very big problem in this scenario, but in more complex cases this may lead to routing loops, since suboptimal path may be chosen. In order to fix this, we may adjust AD for the EIGRP prefix. However, there is a problem here - we can’t change EIGRP external AD selectively, only for all prefixes at once.

This why we may choose to play with AD under OSPF. We may simply adjust AD for R1 Loopback0 prefix to a value of 171. However, we may go further, and simulate the feature of EIGRP with OSPF - speficically, make sure OSPF internal routes have AD different from the external prefixes. For EIGRP the values are 90 and 170. What values should we pick up for OSPF? Well, since OSPF is the core routing domain, it has more information available on what’s going around. Okay, and it’s the only transit domain, so we should make sure it has the highest preference among others. So it makes sense to set internal/external AD for OSPF to 80 and 160 - lower than the EIGRP values. This ensure that internal routes are always preferred over external, but core routing protocol is always the most trusted one.

R2 & R3:
access-list 1 permit 150.18.1.0
!
router ospf 1
distance ospf intra-area 80
distance ospf inter-area 80
distance ospf external 160
distance 171 0.0.0.0 255.255.255.255 1

See how this works on R2 and R3:

Rack18R2#show ip route | beg Gate
Gateway of last resort is not set

O E2 222.22.2.0/24 [160/20] via 174.18.234.4, 00:00:07, Serial0/0
O E2 220.20.3.0/24 [160/20] via 174.18.234.4, 00:00:07, Serial0/0
     174.18.0.0/24 is subnetted, 3 subnets
C       174.18.234.0 is directly connected, Serial0/0
O E2    174.18.0.0 [160/20] via 174.18.234.3, 00:00:35, Serial0/0
C       174.18.123.0 is directly connected, FastEthernet0/0
O E2 192.10.18.0/24 [160/20] via 174.18.234.4, 00:00:35, Serial0/0
     150.18.0.0/24 is subnetted, 6 subnets
O       150.18.4.0 [80/65] via 174.18.234.4, 00:00:35, Serial0/0
O E2    150.18.5.0 [160/20] via 174.18.234.3, 00:00:35, Serial0/0
O E2    150.18.6.0 [160/20] via 174.18.234.3, 00:00:35, Serial0/0
D EX    150.18.1.0 [170/156160] via 174.18.123.1, 00:03:10, FastEthernet0/0
C       150.18.2.0 is directly connected, Loopback0
O       150.18.3.0 [80/65] via 174.18.234.3, 00:00:35, Serial0/0
O E2 205.90.31.0/24 [160/20] via 174.18.234.4, 00:00:07, Serial0/0

OK, just as it was before, next comes R3:

Rack18R3#show ip route | beg Gate
Gateway of last resort is not set

O E2 222.22.2.0/24 [160/20] via 174.18.234.4, 00:00:55, Serial1/0
O E2 220.20.3.0/24 [160/20] via 174.18.234.4, 00:00:55, Serial1/0
     174.18.0.0/24 is subnetted, 3 subnets
C       174.18.234.0 is directly connected, Serial1/0
C       174.18.0.0 is directly connected, FastEthernet0/1
C       174.18.123.0 is directly connected, FastEthernet0/0
O E2 192.10.18.0/24 [160/20] via 174.18.234.4, 00:01:14, Serial1/0
     150.18.0.0/24 is subnetted, 6 subnets
O       150.18.4.0 [80/782] via 174.18.234.4, 00:01:14, Serial1/0
D       150.18.5.0 [90/156160] via 174.18.0.5, 00:37:14, FastEthernet0/1
D       150.18.6.0 [90/156160] via 174.18.0.6, 00:37:14, FastEthernet0/1
D EX    150.18.1.0 [170/156160] via 174.18.123.1, 00:03:58, FastEthernet0/0
O       150.18.2.0 [80/782] via 174.18.234.2, 00:01:14, Serial1/0
C       150.18.3.0 is directly connected, Loopback0
O E2 205.90.31.0/24 [160/20] via 174.18.234.4, 00:00:56, Serial1/0

All seems to look great, with except to the fact that EIGRP 123 and EIGRP 356 have to transit OSPF domain in order to reach each other. Though this is only true for R1, still we need to find out a way to resolve this issue. What if we start exhanging routes on R3 between EIGRP 123 and EIGRP 356? This will not cause any new domain to become transit - because EIGRP external AD will block the external routes from being re-injected into the core domain. This is why we may safely turn on mutual redistribution between the two domains.

R3:
router eigrp 123
 redistribute eigrp 356
!
router eigrp 356
 redistribute eigrp 123

Observe the effect on R1 now. Note the metrics assigned to R5 and R6 Loopback prefixes - they are taken directly from EIGRP 356 native prefixe metric values.

Rack18R1#show ip route eigrp
D EX 222.22.2.0/24
           [170/2560002816] via 174.18.123.3, 00:20:05, FastEthernet0/0
           [170/2560002816] via 174.18.123.2, 00:20:05, FastEthernet0/0
D EX 220.20.3.0/24
           [170/2560002816] via 174.18.123.3, 00:20:05, FastEthernet0/0
           [170/2560002816] via 174.18.123.2, 00:20:05, FastEthernet0/0
     174.18.0.0/24 is subnetted, 3 subnets
D EX    174.18.234.0
           [170/2560002816] via 174.18.123.3, 00:35:22, FastEthernet0/0
           [170/2560002816] via 174.18.123.2, 00:35:22, FastEthernet0/0
D EX    174.18.0.0 [170/30720] via 174.18.123.3, 00:00:37, FastEthernet0/0
D EX 192.10.18.0/24
           [170/2560002816] via 174.18.123.3, 00:20:33, FastEthernet0/0
           [170/2560002816] via 174.18.123.2, 00:20:33, FastEthernet0/0
     150.18.0.0/24 is subnetted, 6 subnets
D EX    150.18.4.0
           [170/2560002816] via 174.18.123.3, 00:20:33, FastEthernet0/0
           [170/2560002816] via 174.18.123.2, 00:20:33, FastEthernet0/0
D EX    150.18.5.0 [170/158720] via 174.18.123.3, 00:00:38, FastEthernet0/0
D EX    150.18.6.0 [170/158720] via 174.18.123.3, 00:00:38, FastEthernet0/0
D EX    150.18.2.0
           [170/2560002816] via 174.18.123.3, 00:20:25, FastEthernet0/0
           [170/2560002816] via 174.18.123.2, 00:20:25, FastEthernet0/0
D EX    150.18.3.0
           [170/2560002816] via 174.18.123.3, 00:20:37, FastEthernet0/0
           [170/2560002816] via 174.18.123.2, 00:20:37, FastEthernet0/0
D EX 205.90.31.0/24
           [170/2560002816] via 174.18.123.3, 00:20:09, FastEthernet0/0
           [170/2560002816] via 174.18.123.2, 00:20:09, FastEthernet0/0

R6 also learns EIGRP 123 routes via R3:

Rack18R6#show ip route eigrp
D EX 222.22.2.0/24 [170/2560002816] via 174.18.0.3, 00:23:59, FastEthernet0/0
D EX 220.20.3.0/24 [170/2560002816] via 174.18.0.3, 00:23:59, FastEthernet0/0
     174.18.0.0/24 is subnetted, 3 subnets
D EX    174.18.234.0
           [170/2560002816] via 174.18.0.3, 01:00:18, FastEthernet0/0
D EX    174.18.123.0 [170/30720] via 174.18.0.3, 00:04:15, FastEthernet0/0
D EX 192.10.18.0/24 [170/2560002816] via 174.18.0.3, 00:27:22, FastEthernet0/0
     150.18.0.0/24 is subnetted, 6 subnets
D EX    150.18.4.0 [170/2560002816] via 174.18.0.3, 00:27:22, FastEthernet0/0
D       150.18.5.0 [90/156160] via 174.18.0.5, 01:31:17, FastEthernet0/0
D EX    150.18.1.0 [170/158720] via 174.18.0.3, 00:04:15, FastEthernet0/0
D EX    150.18.2.0 [170/2560002816] via 174.18.0.3, 00:24:18, FastEthernet0/0
D EX    150.18.3.0 [170/2560002816] via 174.18.0.3, 01:00:18, FastEthernet0/0
D EX 205.90.31.0/24 [170/2560002816] via 174.18.0.3, 00:23:59, FastEthernet0/0

R3 will not transit OSPF backbone, due to our choice of administrative distances:

Rack18R3#show ip route | beg Gate
Gateway of last resort is not set

O E2 222.22.2.0/24 [160/20] via 174.18.234.4, 02:22:45, Serial1/0
O E2 220.20.3.0/24 [160/20] via 174.18.234.4, 02:22:45, Serial1/0
     174.18.0.0/24 is subnetted, 3 subnets
C       174.18.234.0 is directly connected, Serial1/0
C       174.18.0.0 is directly connected, FastEthernet0/1
C       174.18.123.0 is directly connected, FastEthernet0/0
O E2 192.10.18.0/24 [160/20] via 174.18.234.4, 02:23:04, Serial1/0
     150.18.0.0/24 is subnetted, 6 subnets
O       150.18.4.0 [80/782] via 174.18.234.4, 02:23:04, Serial1/0
D       150.18.5.0 [90/156160] via 174.18.0.5, 02:59:03, FastEthernet0/1
D       150.18.6.0 [90/156160] via 174.18.0.6, 02:59:04, FastEthernet0/1
D EX    150.18.1.0 [170/156160] via 174.18.123.1, 02:25:48, FastEthernet0/0
O       150.18.2.0 [80/782] via 174.18.234.2, 02:23:04, Serial1/0
C       150.18.3.0 is directly connected, Loopback0
O E2 205.90.31.0/24 [160/20] via 174.18.234.4, 02:22:45, Serial1/0

So we come up with (mostly) optimal redistribution configuration for our topology. What we learned so far, is that Split-horizon rule may also be implemented using the Administrative Disatnces. EIGRP implements this extremely useful feature automatically, while OSPF should be manually tuned for that. However, as we will learn in further examples, some additional work is needed for RIP. Also, now we remember that redistribution is non-transitive on local router. Finally, we learned a way to introduce a kind of hierarchy of administrative distances for a star-like routing domain topology (core transit domain, and stub edge domains). More complicated examples are to follow this post.
 

Please, refer to the previous parts of this article, for information on the diagram and terms. For this scenario, called “dual-core”, we want the “fast” Ethernet connections (VLAN 356) to be used as primary transport for packet exchange between the routing domains. The Frame-Relay cloud should only be traversed, if the primary (“fast”) connections fail for some reason. That obviously means we will need to configure two transit domains: the OSPF and EIGRP 356. Plus, routes traversing EIGRP 356 should be given higher preference inside other routing domains, since it’s going to be the primary transit path.

 

To accomplish this goal, we are going to develop a technique based on the use of access-list a route-maps for route-filtering. It may look somewhat cumbersome at first sight, but this method allows for implementing any redistribution scheme. To start with, we need to enumerate and group all the IGP prefixes into access-lists per the respective routing domain. We have 4 domains in our scenario - therefore we need to configure 4 access-lists. Those access-lists should be configured on every border router (R2, R3, R4 and R5).

R2,R3,R5 and R5:
!
! All prefixes native to the RIP domain
!
ip access-list standard RIP_PREFIXES
 permit 192.10.9.0
 permit 222.22.2.0
 permit 220.20.3.0
 permit 205.90.31.0

!
! All Loopbacks (R2, R3 and R4) belong to OSPF
!
ip access-list standard OSPF_PREFIXES
 permit 174.9.234.0
 permit 150.9.3.0
 permit 150.9.4.0
 permit 150.9.2.0

!
! EIGRP 123 native prefixes
!
ip access-list standard EIGRP_123_PREFIXES
 permit 174.9.123.0
 permit 150.9.1.0

!
! EIGRP 356 native prefixes
!
ip access-list standard EIGRP_356_PREFIXES
 permit 174.9.0.0
 permit 150.9.6.0
 permit 150.9.5.0

Next, both EIGRP 356 and OSPF are elected as core (transit) routing domain. Other domains should remain stub, and don’t pass-through any routing information. How could this be accomplished? First, recall the rule of Split Horizon: never advertise a route back to the domain of it’s origin. In our case, this rule could be enforced by the use of route-maps and access-lists for redistribution control. For example, when redistributing routes from the RIP domain into OSPF, we can use access-list to permit only the RIP prefixes, and block all others.

However, the main question is how to set up redistribution flows. Well, it’s obvious, that both EIGRP 356 and OSPF are directly connected to the other remaining routing domains (including each-other). Because of that fact, they both could effectively provide full connectivity, by letting the other prefixes transit their domains. In addition, some route exchange should be established among the “core” domains.

We could illustrate the “dual-core” redistribution, by thinking of the routing domain as BGP routers, connected by imaginary iBGP links (redistribution paths on the respective routers). The “core” domains (EIGRP 356 an OSPF) could be represented as iBGP route-reflectors, and the other domains – as iBGP route-reflector clients. Using this illustration, we may quickly realize that iBGP rules of split-horizon effectively apply to the route-redistribution. Say when EIGRP 356 receives a route from the RIP domain, it should reflect it to EIGRP 123 plus send a copy to the OSPF domain. When a route is received from the OSPF domain by EIGRP 356 domain, that route should be replicated to the EIGRP 123 and the RIP domains (route-reflector clients). When the RIP domain receives a prefix from the OSPF domain, it should not send it to other domains (BGP split-horizon). This imaginary technique could be generalized to the case of many “core” routing topology, provided that full-mesh route exchange relationships could be established among then.

But enough of illustrations, let’s start implementing our configuration right away, beginning with R3 as the first border router (the remaining border routers to be configured are R2, R4 and R5). The OSPF and EIGRP 356 domains are both transit. That means, when redistributing from the OSPF domain to EIGRP 356 we should accept the OSPF native prefixes (per the ACLs configured above) in addition to the transit RIP and EIGRP 123 prefixes. The latter prefixes could also be injected into EIGRP 356 natively, from the respective routing domains. Therefore, when accepting the transit routes from the OSPF domain, we should give them the metric value, which makes the prefixes less preferable. For out example, we will use EIGRP metric “1 100 1 1 1” for the “non-native” injected prefixes, which is less preferable than our default “1 1 1 1 1” due to the higher “delay” component value:

R3:
!
! OSPF -> EIGRP 356
!
route-map OSPF_TO_EIGRP_356 permit 10
 match ip address OSPF_PREFIXES
 set metric 1 1 1 1 1
!
route-map OSPF_TO_EIGRP_356 permit 20
 match ip address EIGRP_123_PREFIXES
 set metric 1 100 1 1 1
!
route-map OSPF_TO_EIGRP_356 permit 30
 match ip address RIP_PREFIXES
 set metric 1 100 1 1 1

In the opposite direction, from EIGRP 356 toward the OSPF domain, we can only inject EIGRP 356 native prefixes, in addition to the transit RIP prefixes (which should be given some “less preferable” metric, compared to the native RIP routes that are to be injected into OSPF on R4 later). The EIGRP 123 prefixes will not transit EIGP 356 on their way to OSPF domain, so they could not be redistributed via EIGRP 356 process.

R3:
!
! EIGRP 356 -> OSPF
!
route-map EIGRP_356_TO_OSPF permit 10
 match ip address EIGRP_356_PREFIXES
!
route-map EIGRP_356_TO_OSPF permit 20
 match ip address RIP_PREFIXES
 set metric 100

Next, we have EIGRP 123 and EIGRP 356 domain. While EIGRP 123 could only advertise native prefixes into EIGRP 356, the latter could also inject the transit RIP prefixes into EIGRP 123. Note, that we don’t set metric when redistributing native EIGRP prefixes, retaining their original metric, which is way much better than our default “1 1 1 1 1”. For the transit RIP prefixes we set metric to the default “1 1 1 1 1” keeping in mind, that the same prefixes injected via OSPF should be given a worse metric value later.

R3:
!
! EIGRP 123 -> EIGRP 356
!
route-map EIGRP_123_TO_EIGRP_356 permit 10
 match ip address EIGRP_123_PREFIXES

!
! EIGRP 356 -> EIGRP 123
!
route-map EIGRP_356_TO_EIGRP_123 permit 10
 match ip address EIGRP_356_PREFIXES
!
route-map EIGRP_356_TO_EIGRP_123 permit 20
 match ip address RIP_PREFIXES
 set metric 1 1 1 1 1

For OSPF and EIGRP 123 relations, we could inject the OSPF native and the transit RIP prefixes from the OSPF domain to EIGRP 123. For the RIP prefixes, we should set value worse than it was for the RIP prefixes transiting EIGRP 356 injected into EIGRP 123. In the reverse direction, we simply inject EIGRP 123 routes into the OSPF domain with the default metric value.

R3:
!
! OSPF -> EIGRP 123
!
route-map OSPF_TO_EIGRP_123 permit 10
 match ip address OSPF_PREFIXES
 set metric 1 1 1 1 1
!
route-map OSPF_TO_EIGRP_123 permit 20
 match ip address RIP_PREFIXES
 set metric 1 100 1 1 1

!
! EIGRP 123 -> OSPF
!
route-map EIGRP_123_TO_OSPF permit 10
 match ip address EIGRP_123_PREFIXES

The redistribution is finally set up, using the route map configured above.

R3:
!
! Redistribution
!
router ospf 1
 redistribute eigrp 356 route-map EIGRP_356_TO_OSPF subnets
 redistribute eigrp 123 route-map EIGRP_123_TO_OSPF subnets
!
router eigrp 123
 redistribute ospf 1 route-map OSPF_TO_EIGRP_123
 redistribute eigrp 356 route-map EIGRP_356_TO_EIGRP_123
!
router eigrp 356
 redistribute eigrp 123 route-map EIGRP_123_TO_EIGRP_356
 redistribute ospf 1 route-map OSPF_TO_EIGRP_356

Our next stop is R2. Here the OSPF domain meets EIGRP 123 domain. We need to inject the OSPF native routes into EIGRP 123 domain, plus the transit routes from EIGRP 356 and the RIP domains. Note, that the RIP prefixes may enter the OSPF domain either through R4 or R3 (transiting EIGRP 356). Therefore, to avoid suboptimal routing and possible loops, we should give the “native” RIP prefixes better metric in the OSPF domain, compared to the RIP routes injected via R3. This is a side note, which is to be implemented on R4 later. In the opposite direction, from EIGRP 123 to the OSPF, we need to inject EIGRP 123 native prefixes only, with the default (most preferred in our scheme) metric value.

R2:
!
! OSPF -> EIGRP 123
!
route-map OSPF_TO_EIGRP_123 permit 10
 match ip address OSPF_PREFIXES
 set metric 1 1 1 1 1
!
route-map OSPF_TO_EIGRP_123 permit 20
 match ip address RIP_PREFIXES
 set metric 1 100 1 1 1
!
route-map OSPF_TO_EIGRP_123 permit 30
 match ip address EIGRP_356_PREFIXES
 set metric 1 1 1 1 1

!
! EIGRP 123 -> OSPF
!
route-map EIGRP_123_TO_OSPF permit 10
 match ip address EIGRP_123_PREFIXES

!
! Redistribution
!
router eigrp 123
 redistribute ospf 1 route-map OSPF_TO_EIGRP_123
!
router ospf 1
 redistribute eigrp 123 route-map EIGRP_123_TO_OSPF subnets

OK, now for the RIP and OSPF junction point. Obviously, we only need to accept the RIP native prefixes into the OSPF domain. As it has been configured above, the RIP prefixes entering the OSPF domain on R3, will have OSPF metric value of 100. So now all we need is to redistribute RIP into OSPF with the default metric value. For the opposite direction, from the OSPF into the RIP domain, we set metric value of 8 to the native OSPF routes (our convention for the RIP external prefixes). For the transit prefixes (EIGRP 123 and EIGRP 356) we set metric to 12, so that later we could import the same prefixes from EIGRP 356 on R5 with a better metric value.

R4:
!
! RIP->OSPF
!
route-map RIP_TO_OSPF permit 10
 match ip address RIP_PREFIXES 

!
! OSPF -> RIP
!
route-map OSPF_TO_RIP permit 10
 match ip address OSPF_PREFIXES
 set metric 8
!
route-map OSPF_TO_RIP permit 20
 match ip address EIGRP_123_PREFIXES
 set metric 12
!
route-map OSPF_TO_RIP permit 30
 match ip address EIGRP_356_PREFIXES
 set metric 12

!
! Redistribution
!
router rip
 redistribute ospf 1 route-map OSPF_TO_RIP
!
router ospf 1
 redistribute rip route-map RIP_TO_OSPF subnets

The last border router is R5. We inject the native RIP prefixes into EIGRP 356 with our default metric value (which is the most preferred, compared with the other artificial metric values). Next, from EIGRP 356 into the RIP we permit the native EIGRP 356 prefixes (with our “default” seed metric value of 8), the OSPF prefixes with metric 12 (to reflect the fact that the RIP domain should prefer the closest path via R4), and finally the native EIGRP 123 prefixes (to be more preferred than the same prefixes injected into the RIP via the OSPF core domain):

R5:
!
! RIP -> EIGRP 356
!
route-map RIP_TO_EIGRP_356 permit 10
 match ip address RIP_PREFIXES
 set metric 1 1 1 1 1
!
! EIGRP 356 -> RIP
!
route-map EIGRP_356_TO_RIP permit 10
 match ip address EIGRP_356_PREFIXES
 set metric 8
!
route-map EIGRP_356_TO_RIP permit 20
 match ip address OSPF_PREFIXES
 set metric 12
!
route-map EIGRP_356_TO_RIP permit 30
 match ip address EIGRP_123_PREFIXES
 set metric 8

!
!  Redistribution
!
router eigrp 356
 redistribute rip route-map RIP_TO_EIGRP_356
!
router rip
 redistribute eigrp 356 route-map EIGRP_356_TO_RIP

We’re done with disseminating the routing information. However, one other thing should also be completed. We need to set route preferences on the border routers (which run more than one routing protocol). As per our general rules, core protocol routes should be preferred over edge routes; and external routes should be always less preferred than internal. According to this, we should (generally) prefer EIGRP 356 routes over the OSPF prefixes; prefer the OSPF prefixes over EIGRP 123 and RIP prefixes; And always prefer internal routing information over external. Let’s see how this could be implemented on all the border routes.

For R2, we set OSPF external routes distance to 190 (110+80, to reflect the EIGRP rule of external AD 170=90 (internal AD)+80). However, we should also tune EIGRP 123 to be less preferred than OSPF, setting it’s AD values to 120/200.

R2:
!
! External routes should be less preferred all the times
!
router ospf 1
 distance ospf external 190

!
! EIGRP 123 should be less preferred than OSPF
!
router eigrp 123
 distance eigrp 120 200

R3 is the junction point for three protocols. We set EIGRP 123 to be less preferred than OSPF, and OSPF to be less preferred than EIGRP 356, to reflect the “primary core”, “secondary core” and “edge” routing domain relationships.

R3:
!
! EIGRP 123 < OSPF
!
router eigrp 123
 distance eigrp 120 190
!
! OSPF < EIGRP 356
!
router ospf 1
 distance ospf external 180

R4 is interesting case, because here we should be setting OSPF external routes to be less preferred than RIP external routes (injected from EIGRP 356). However, EIGRP 356 is the primary routing domain, so we need to make sure R4 prefers all the routes (except for the OSPF native) via the EIGRP 356 domain. This is why we are going to set the OSPF process external AD to 190, and make the RIP external routes more preferred on R4:

R4:
router ospf 1
 distance ospf external 190

Finally, R5. Here, we should make sure that the RIP external routes are less preferred than EIGRP external prefixes. However, since RIP protocol has no notion of external routes, we need to use the access-list RIP_PREFIXES to selectively set AD to 120 for the RIP native prefixes, and set the administrative distance of the whole RIP process to 200 (greater than 170):

R5:
router rip
 distance 200
 distance 120 0.0.0.0 255.255.255.255 RIP_PREFIXES

We’re done with redistribution. So far, we implemented the split-horizon rule by carefully filtering routes using the access-list enumerating each protocol’s native prefixes. We set metrics on redistribution so that routes traversing EIGRP 356 domain are always preferred over the routes traversing the OSPF routing domain. Finally, we tuned AD values on border routers, to force them choosing the optimal path.

To verify our implementation, you may run a Tcl verification script, and additionally look at the “show ip route” command output.

Rack9R1#sh ip route | beg Gate
Gateway of last resort is not set

D EX 222.22.2.0/24 [170/2560002816] via 174.9.123.3, 00:02:18, FastEthernet0/0
D EX 220.20.3.0/24 [170/2560002816] via 174.9.123.3, 00:02:18, FastEthernet0/0
     174.9.0.0/24 is subnetted, 3 subnets
D EX    174.9.234.0
           [170/2560002816] via 174.9.123.3, 00:24:55, FastEthernet0/0
           [170/2560002816] via 174.9.123.2, 00:24:55, FastEthernet0/0
D EX    174.9.0.0 [170/284160] via 174.9.123.3, 00:07:18, FastEthernet0/0
C       174.9.123.0 is directly connected, FastEthernet0/0
D EX 192.10.9.0/24 [170/2560002816] via 174.9.123.3, 00:02:18, FastEthernet0/0
     150.9.0.0/24 is subnetted, 6 subnets
D EX    150.9.6.0 [170/412160] via 174.9.123.3, 00:07:16, FastEthernet0/0
D EX    150.9.5.0 [170/412160] via 174.9.123.3, 00:02:18, FastEthernet0/0
D EX    150.9.4.0 [170/2560002816] via 174.9.123.3, 00:24:55, FastEthernet0/0
                  [170/2560002816] via 174.9.123.2, 00:24:55, FastEthernet0/0
D EX    150.9.3.0 [170/2560002816] via 174.9.123.3, 00:24:55, FastEthernet0/0
                  [170/2560002816] via 174.9.123.2, 00:24:56, FastEthernet0/0
D EX    150.9.2.0 [170/2560002816] via 174.9.123.3, 00:24:56, FastEthernet0/0
                  [170/2560002816] via 174.9.123.2, 00:24:56, FastEthernet0/0
C       150.9.1.0 is directly connected, Loopback0
D EX 205.90.31.0/24
           [170/2560002816] via 174.9.123.3, 00:02:19, FastEthernet0/0

Rack9R2#sh ip route | beg Gate
Gateway of last resort is not set

O E2 222.22.2.0/24 [190/20] via 174.9.234.4, 00:02:43, Serial0/0
O E2 220.20.3.0/24 [190/20] via 174.9.234.4, 00:02:43, Serial0/0
     174.9.0.0/24 is subnetted, 3 subnets
C       174.9.234.0 is directly connected, Serial0/0
O E2    174.9.0.0 [190/20] via 174.9.234.3, 00:07:43, Serial0/0
C       174.9.123.0 is directly connected, FastEthernet0/0
O E2 192.10.9.0/24 [190/20] via 174.9.234.4, 00:02:43, Serial0/0
     150.9.0.0/24 is subnetted, 6 subnets
O E2    150.9.6.0 [190/20] via 174.9.234.3, 00:07:41, Serial0/0
O E2    150.9.5.0 [190/20] via 174.9.234.3, 00:02:43, Serial0/0
O       150.9.4.0 [110/65] via 174.9.234.4, 00:43:06, Serial0/0
O       150.9.3.0 [110/65] via 174.9.234.3, 00:43:06, Serial0/0
C       150.9.2.0 is directly connected, Loopback0
D       150.9.1.0 [120/156160] via 174.9.123.1, 00:42:53, FastEthernet0/0

O E2 205.90.31.0/24 [190/20] via 174.9.234.4, 00				
Authored by: Guru Corner
Click Here to View all the questions in Routing category.
File Attachments File Attachments
There are no attachment file(s) related to this question.
Article Information Additional Information
Article Number: 28
Created: 2008-10-05 3:06 PM
Rating: No Rating
 
Article Options Article Options
Print Question Print this Question
Export to Adobe PDF Export to PDF File
Export to MS Word Export to MS Word
 
Search Knowledge Base Search Knowledge Base
 
 

Powered by Guru Corner