Feb
19

UPDATE: For more information on Redistribution see the video series Understanding Route Redistribution – Excerpts from CCIE R&S ATC

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.

About Petr Lapukhov, 4xCCIE/CCDE:

Petr Lapukhov's career in IT begain in 1988 with a focus on computer programming, and progressed into networking with his first exposure to Novell NetWare in 1991. Initially involved with Kazan State University's campus network support and UNIX system administration, he went through the path of becoming a networking consultant, taking part in many network deployment projects. Petr currently has over 12 years of experience working in the Cisco networking field, and is the only person in the world to have obtained four CCIEs in under two years, passing each on his first attempt. Petr is an exceptional case in that he has been working with all of the technologies covered in his four CCIE tracks (R&S, Security, SP, and Voice) on a daily basis for many years. When not actively teaching classes, developing self-paced products, studying for the CCDE Practical & the CCIE Storage Lab Exam, and completing his PhD in Applied Mathematics.

Find all posts by Petr Lapukhov, 4xCCIE/CCDE | Visit Website


You can leave a response, or trackback from your own site.

25 Responses to “Understanding Redistribution (Part II)”

 
  1. Fernando says:

    Great Post!!! Seldom i’ve seen such a clear and structured explanation.

  2. Barooq says:

    After banging my head on almost each redistribution task in IEWB first 7 labs and not understanding anything, (I partly blame the WB. Man it goes to lengths explaining CCNA level stuff, like frame relay mappings or spanning tree but almost mute on redistribution) I am finally getting a bit understanding. And since I can’t afford COD, this blog is the greatest resource I have.
    Cant wait for your next post, rather all the posts on redistribution:)

  3. [...] is a link to a great read regarding redistribution I had a look at this week: Understanding Redistribution (Part 2) by Petr Lapukhov, CCIE #16379 @ Internetwork [...]

  4. Oluwaseyi says:

    This is awesome, even CiscoPress cannot explain it better than this.

  5. chukabume says:

    Just wanted to clarify if the distance ospf external command is in 12.4 release , which will be in the routers for the lab ?

  6. Omarept says:

    Good post, I replicated the scenario, and I noticed that before of change the R1 loopback from advertise to redistribute you wrote down:

    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.

    however full connectivity is not reached because R6 cannot get R1 loopback.
    in your R6 routing table R1 loopback is not present:

    it was copied directly from your post (I got the same result):

    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

    Rgds.

  7. Alex says:

    Excellent article – thanks! Question: what do you guys use or recommend for a lab simulations? I heard of gns3 but I was wondering if there is something better out there…

    Thank you in advance.

    CheerS!

  8. ruhann says:

    Omarept you are right.
    The reason though is simple.
    A redistributed route cant be redistributed again on the same router. Here it being R3 (EIGRP123> OSPF >x> EIGRP356).

    Easy fix as Petr did, Redistribute between EIGRP123 EIGRP356 directly :)

  9. khalid malik says:

    hi
    Thank It is really good ways to understand.
    Q1) In which router interface you defined
    222.22.2.0/24 these ?
    If it loopback then it should start with 150.X.X.X ? I am confuse Please help me ?

  10. Abdo says:

    Hi Peter ,

    I just want to know ,R3 is not runing RIP and in part I you have this (if we configure bi-directional redistribution on R3 between RIPv2 and OSPF ) is this right ???

  11. [...] Understanding Redistribution: Part 2 [...]

  12. jdr says:

    Hello,

    I am reproducing this lab scenario on my gear.
    I noticed, that to achieve output like this:

    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

    after mutual redistribution betweend EIGRP123 and OSPF on R2 and R3 you need to configure loopback0 interfaces on all ospf routers to ip ospf network point-to-point.

  13. jdr says:

    Actually, there is another hidden snag, just before:

    “This seems to be an easy one. We’re done, full connectivity attained, and no loops were introduced.”

    As Omarept said before, we do not have reachability to R1′s loopback from the R6 router.

    This is true, and also we does not have reachability to 174.18.123.0/24 network.

    This is due to redistibution thing on R3.

    As you remember, the redistribution on router is non-transitive, and routes redistributed on R3 from EIG 356 to OSPF1 are not redistributed to EIG 123 even if we have redistribution from OSPF1 to EIG 123 on the same device, and vice-versa.

    The reason we can see them in EIG123 domain is that R2 knows that routes from R3 over OSPF1, and can redistribute it to EIG123.

    Here, in EIG 356 situation is slightly different. As we know, the router won’t redistribute from EIG123 through ospf 1 to EIG356. R3 knows that routes by the EIG123 routing process, and since EIG123 AD (90) is better than OSPF1 AD (110), it will use routes received from EIG123. That’s the reason why it cannot redistribute it over to the EIG356.

  14. jdr says:

    Just another note on changing ospf ad.
    On my lab, when I copy and paste to the router:

    Rack1R2(config-router)#router ospf 1
    Rack1R2(config-router)#distance ospf intra-area 80
    Rack1R2(config-router)#distance ospf inter-area 80
    Rack1R2(config-router)#distance ospf external 160

    The result of prefixes imported from rip is unpredictable, very often it ends up looping this prefixes between R2 and R3:

    Rack1R2#show ip route | b Gate
    Gateway of last resort is not set

    D EX 222.22.2.0/24 [170/2560002816] via 174.1.123.3, 00:05:26, FastEthernet0/0
    D EX 220.20.3.0/24 [170/2560002816] via 174.1.123.3, 00:05:26, FastEthernet0/0

    via 174.1.123.3? Oh, that’s bad.

    Rack1R3#show ip route | b Gate
    Gateway of last resort is not set

    O E2 222.22.2.0/24 [160/20] via 174.1.234.2, 00:05:40, Serial0/0
    O E2 220.20.3.0/24 [160/20] via 174.1.234.2, 00:05:40, Serial0/0

    via 174.1.234.2? Yeah, even worse.

    Rack1R4#show ip route | b Gate
    Gateway of last resort is not set

    O E2 222.22.2.0/24 [110/20] via 174.1.234.2, 00:05:55, Serial0/0
    O E2 220.20.3.0/24 [110/20] via 174.1.234.2, 00:05:55, Serial0/0

    Whoops…

    Rack1R4#traceroute 222.22.2.2

    Type escape sequence to abort.
    Tracing the route to 222.22.2.2

    1 174.1.234.2 28 msec 28 msec 28 msec
    2 174.1.123.3 28 msec 28 msec 28 msec
    3 174.1.234.2 36 msec 36 msec 36 msec
    4 174.1.123.3 36 msec 36 msec 40 msec
    5 174.1.234.2 44 msec 44 msec 48 msec
    6 174.1.123.3 48 msec 48 msec 48 msec
    7 174.1.234.2 56 msec 60 msec 56 msec
    8 174.1.123.3 60 msec 56 msec 56 msec
    9 174.1.234.2 64 msec 68 msec 68 msec
    10 174.1.123.3 68 msec 68 msec 68 msec
    11 174.1.234.2 76 msec 76 msec 76 msec
    12 174.1.123.3 80 msec 76 msec 80 msec
    13 174.1.234.2 88 msec 88 msec 88 msec
    14 174.1.123.3 88 msec 88 msec 88 msec
    15 174.1.234.2 100 msec 96 msec 100 msec
    16 174.1.123.3 96 msec 96 msec 96 msec
    17 174.1.234.2 108 msec 108 msec 108 msec
    18 174.1.123.3 108 msec 104 msec 104 msec
    19 174.1.234.2 120 msec 116 msec 120 msec
    20 174.1.123.3 116 msec 120 msec 116 msec
    21 174.1.234.2 132 msec 124 msec 128 msec
    22 174.1.123.3 128 msec 128 msec 128 msec
    23 174.1.234.2 140 msec 136 msec 136 msec
    24 174.1.123.3 136 msec 136 msec 140 msec
    25 174.1.234.2 148 msec 148 msec 148 msec
    26 174.1.123.3 148 msec 148 msec 144 msec
    27 174.1.234.2 160 msec 156 msec 160 msec
    28 174.1.123.3 156 msec 160 msec 156 msec
    29 174.1.234.2 168 msec 168 msec 168 msec
    30 174.1.123.3 196 msec 168 msec 164 msec

    Not so cool, after all. We have routing loop in progress.
    I can’t actually figure out whats happening, guess it is somehow connected to copying and paste distance configuration to the ospf process.
    Couldn’t reproduce this behaviour if I change distance using one single command under ospf:

    distance ospf intra-area 80 inter-area 80 external 160

    After reloading R2 and R3 everything is Okay.
    I tried to do some debugs, on ip ospf rib, and here’s what I got:

    [blablabla]
    *Oct 6 22:23:24.971: OSPF-RIB-LOCAL: Sync’ed 222.22.2.0/255.255.255.0 type 16 – added 1 paths, deleted 0 paths, change flag 0×4, spf 26, route instance 26
    *Oct 6 22:23:24.971: OSPF-RIB-GLOBAL: Network update succeeded 220.20.3.0/255.255.255.0, via 174.1.234.4 on Serial0/0, distance 20, flags 0×0, source 4.4.4.4, tag 0×0, type 16, return: 0
    *Oct 6 22:23:24.971: OSPF-RIB-LOCAL: Sync’ed 220.20.3.0/255.255.255.0 type 16 – added 1 paths, deleted 0 paths, change flag 0×4, spf 26, route instance 26
    *Oct 6 22:23:24.971: OSPF-RIB-GLOBAL: Network update succeeded 205.90.31.0/255.255.255.0, via 174.1.234.4 on Serial0/0, distance 20, flags 0×0, source 4.4.4
    [blablabla]
    *Oct 6 22:23:25.003: OSPF-RIB-GLOBAL: Network update succeeded 222.22.2.0/255.255.255.0, via 174.1.234.4 on Serial0/0, distance 20, flags 0×0, source 4.4.4.4, tag 0×0, type 16, return: 0
    *Oct 6 22:23:25.003: OSPF-RIB-LOCAL: Sync’ed 222.22.2.0/255.255.255.0 type 16 – added 1 paths, deleted 0 paths, change flag 0×4, spf 27, route instance 27
    *Oct 6 22:23:25.003: OSPF-RIB-GLOBAL: Network update succeeded 220.20.3.0/255.255.255.0, via 174.1.234.4 on Serial0/0, distance 20, flags 0×0, source 4.4.4.4, tag 0×0, type 16, return: 0
    *Oct 6 22:23:25.003: OSPF-RIB-LOCAL: Sync’ed 220.20.3.0/255.255.255.0 type 16 – added 1 paths, deleted 0 paths, change flag 0×4, spf 27, route instance 27
    [blablabla]
    *Oct 6 22:23:25.495: OSPF-RIB-GLOBAL: Route delete succeeded 222.22.2.0/255.255.255.0 via 174.1.234.4 on Serial0/0, source 4.4.4.4, type 16, return: 2
    *Oct 6 22:23:25.495: OSPF-RIB-LOCAL: No more paths for 222.22.2.0/255.255.255.0 type 16 – delete route from local RIB
    *Oct 6 22:23:25.495: OSPF-RIB-LOCAL: Sync’ed 222.22.2.0/255.255.255.0 type 16 – added 0 paths, deleted 1 paths, change flag 0×5, spf 30, route instance 28
    *Oct 6 22:23:25.495: OSPF-RIB-GLOBAL: Route delete succeeded 220.20.3.0/255.255.255.0 via 174.1.234.4 on Serial0/0, source 4.4.4.4, type 16, return: 2
    *Oct 6 22:23:25.495: OSPF-RIB-LOCAL: No more paths for 220.20.3.0/255.255.255.0 type 16 – delete route from local RIB
    *Oct 6 22:23:25.495: OSPF-RIB-LOCAL: Sync’ed 220.20.3.0/255.255.255.0 type 16 – added 0 paths, deleted 1 paths, change flag 0×5, spf 30, route instance 28
    *Oct 6 22:23:25.495: OSPF-RIB-GLOBAL: Route delete succeeded 205.90.31.0/255.255.255.0 via 174.1.234.4 on Serial0/0, source 4.4.4.4, type 16, return: 2
    *Oct 6 22:23:25.495: OSPF-RIB-LOCAL: No more paths for 205.90.31.0/255.255.255.0 type 16 – delete route from local RIB
    *Oct 6 22:23:25.495: OSPF-RIB-LOCAL: Sync’ed 205.90.31.0/255.255.255.0 type 16 – added 0 paths, deleted 1 paths, change flag 0×5, spf 30, route instance 28
    *Oct 6 22:23:25.535: OSPF-RIB-REDIST: Callback for 222.22.2.0/255.255.255.0 redistributed from process OSPF Router
    *Oct 6 22:23:25.535: OSPF-RIB-REDIST: 222.22.2.0/255.255.255.0, metric -1734964480, tag 0×0, attributes 0×0, will be advertised
    *Oct 6 22:23:25.535: OSPF-RIB-REDIST: Callback for 220.20.3.0/255.255.255.0 redistributed from process OSPF Router
    *Oct 6 22:23:25.535: OSPF-RIB-REDIST: 220.20.3.0/255.255.255.0, metric -1734964480, tag 0×0, attributes 0×0, will be advertised
    *Oct 6 22:23:25.535: OSPF-RIB-REDIST: Callback for 205.90.31.0/255.255.255.0 redistributed from process OSPF Router
    *Oct 6 22:23:25.535: OSPF-RIB-REDIST: 205.90.31.0/255.255.255.0, metric -1734964480, tag 0×0, attributes 0×0, will be advertised
    [blablabla]

    Anyway, I think that is it somehow connected to internal ospf mechanisms responsible for changing routing table after ospf distances was changed.
    R2 drops routes from ospf peers just to reload them after a while with another AD.
    In the meantime, eigrp 123 injects it’s routes to rip networks to the ospf1 process on R2:
    Rack1R2#show ip route 222.22.2.0
    Routing entry for 222.22.2.0/24
    Known via “eigrp 123″, distance 170, metric 2560002816, type external
    Redistributing via eigrp 123, ospf 1
    Advertised by ospf 1 subnets
    Last update from 174.1.123.3 on FastEthernet0/0, 00:21:23 ago
    Routing Descriptor Blocks:
    * 174.1.123.3, from 174.1.123.3, 00:21:23 ago, via FastEthernet0/0
    Route metric is 2560002816, traffic share count is 1
    Total delay is 110 microseconds, minimum bandwidth is 1 Kbit
    Reliability 1/255, minimum MTU 1 bytes
    Loading 1/255, Hops 1
    and then R2 advertises those to all other routers in the ospf1 area0.
    Unfortunatly, AD for whole ospf process on R4 is still 110, so it preempts valid routes, learned from rip.
    After R4 route cache is poisoned with those informations, there is no possibility to break this loop, since valid informations are lost.
    Finally, R3 lose its route to RIP prefixes from R4, and learn invalid informations from R2, next it redistributes that invalid information to eig123 process.
    Then again, R2 redistribute this information to OSPF all over again.

    Rack1R3#show ip route 222.22.2.0
    Routing entry for 222.22.2.0/24
    Known via “ospf 1″, distance 160, metric 20, type extern 2, forward metric 64
    Redistributing via eigrp 123, eigrp 356
    Advertised by eigrp 123 metric 1 1 1 1 1
    eigrp 356 metric 1 1 1 1 1
    Last update from 174.1.234.2 on Serial0/0, 00:25:31 ago
    Routing Descriptor Blocks:
    * 174.1.234.2, from 2.2.2.2, 00:25:31 ago, via Serial0/0
    Route metric is 20, traffic share count is 1

    Rack1R4#show ip route 222.22.2.0
    Routing entry for 222.22.2.0/24
    Known via “ospf 1″, distance 110, metric 20, type extern 2, forward metric 64
    Redistributing via rip
    Advertised by rip metric 8
    Last update from 174.1.234.2 on Serial0/0, 00:25:56 ago
    Routing Descriptor Blocks:
    * 174.1.234.2, from 2.2.2.2, 00:25:56 ago, via Serial0/0
    Route metric is 20, traffic share count is 1

    Possible solution to break that loop is to set OSPF distances on R4 just like we did on R2 and R3 (particularly the external one):

    Rack1R4#conf t
    Enter configuration commands, one per line. End with CNTL/Z.
    Rack1R4(config)#router ospf 1
    Rack1R4(config-router)#distance ospf intra-area 80
    Rack1R4(config-router)#distance ospf inter-area 80
    Rack1R4(config-router)#distance ospf external 160
    Rack1R4(config-router)#^Z

    Rack1R4#show ip route 222.22.2.0
    Routing entry for 222.22.2.0/24
    Known via “ospf 1″, distance 160, metric 20, type extern 2, forward metric 64
    Redistributing via rip
    Advertised by rip metric 8
    Last update from 174.1.234.2 on Serial0/0, 00:00:22 ago
    Routing Descriptor Blocks:
    * 174.1.234.2, from 2.2.2.2, 00:00:22 ago, via Serial0/0
    Route metric is 20, traffic share count is 1

    a little bit later:

    Rack1R4#show ip route 222.22.2.0
    Routing entry for 222.22.2.0/24
    Known via “rip”, distance 120, metric 7
    Redistributing via ospf 1, rip
    Advertised by ospf 1 subnets
    Last update from 192.10.1.254 on FastEthernet0/0, 00:00:04 ago
    Routing Descriptor Blocks:
    * 192.10.1.254, from 192.10.1.254, 00:00:04 ago, via FastEthernet0/0
    Route metric is 7, traffic share count is 1

    And R2 shows some debugs:

    Rack1R2#
    *Oct 6 22:51:49.475: OSPF-RIB-LOCAL: Add 205.90.31.0/255.255.255.0, area dummy area, type 16, dist 20, forward 64, tag 0×0, via 174.1.234.4 Serial0/0, route flags 0×800, path flags 0×0, source 4.4.4.4, spf 33, list-type 3
    *Oct 6 22:51:49.479: OSPF-RIB-REDIST: Callback for 205.90.31.0/255.255.255.0 redistributed from process OSPF Router
    *Oct 6 22:51:49.479: OSPF-RIB-REDIST: 205.90.31.0/255.255.255.0, metric -1734964480, tag 0×0, attributes 0×0, will be flushed
    *Oct 6 22:51:49.479: OSPF-RIB-GLOBAL: Network update succeeded 205.90.31.0/255.255.255.0, via 174.1.234.4 on Serial0/0, distance 20, flags 0×0, source 4.4.4.4, tag 0×0, type 16, return: 0
    *Oct 6 22:51:49.479: OSPF-RIB-LOCAL: Sync’ed 205.90.31.0/255.255.255.0 type 16 – added 1 paths, deleted 0 paths, change flag 0xE, spf 33, route instance 33
    *Oct 6 22:51:49.575: OSPF-RIB-LOCAL: Add 220.20.3.0/255.255.255.0, area dummy area, type 16, dist 20, forward 64, tag 0×0, via 174.1.234.4 Serial0/0, route flags 0×800, path flags 0×0, source 4.4.4.4, spf 36, list-type 3
    *Oct 6 22:51:49.575: OSPF-RIB-REDIST: Callback for 220.20.3.0/255.255.255.0 redistributed from process OSPF Router
    *Oct 6 22:51:49.575: OSPF-RIB-REDIST: 220.20.3.0/255.255.255.0, metric -1734964480, tag 0×0, attributes 0×0, will be flushed
    *Oct 6 22:51:49.575: OSPF-RIB-GLOBAL: Network update succeeded 220.20.3.0/255.255.255.0, via 174.1.234.4 on Serial0/0, distance 20, flags 0×0, source 4.4.4.4, tag 0×0, type 16, return: 0
    *Oct 6 22:51:49.575: OSPF-RIB-LOCAL: Sync’ed 220.20.3.0/255.255.255.0 type 16 – added 1 paths, deleted 0 paths, change flag 0xE, spf 36, route instance 36
    *Oct 6 22:51:49.575: OSPF-RIB-LOCAL: Add 222.22.2.0/255.255.255.0, area dummy area, type 16, dist 20, forward 64, tag 0×0, via 174.1.234.4 Serial0/0, route flags 0×800, path flags 0×0, source 4.4.4.4, spf 36, list-type 3
    *Oct 6 22:51:49.575: OSPF-RIB-REDIST: Callback for 222.22.2.0/255.255.255.0 redistributed from process OSPF Router
    *Oct 6 22:51:49.575: OSPF-RIB-REDIST: 222.22.2.0/255.255.255.0, metric -1734964480, tag 0×0, attributes 0×0, will be flushed
    *Oct 6 22:51:49.575: OSPF-RIB-GLOBAL: Network update succeeded 222.22.2.0/255.255.255.0, via 174.1.234.4 on Serial0/0, distance 20, flags 0×0, source 4.4.4.4, tag 0×0, type 16, return: 0
    *Oct 6 22:51:49.575: OSPF-RIB-LOCAL: Sync’ed 222.22.2.0/255.255.255.0 type 16 – added 1 paths, deleted 0 paths, change flag 0xE, spf 36, route instance 36

    ip routes from R2&R3:

    Rack1R2#show ip route ospf | i E2
    O E2 222.22.2.0/24 [160/20] via 174.1.234.4, 00:02:48, Serial0/0
    O E2 220.20.3.0/24 [160/20] via 174.1.234.4, 00:02:48, Serial0/0
    O E2 174.1.0.0 [160/20] via 174.1.234.3, 00:31:12, Serial0/0
    O E2 192.10.1.0/24 [160/20] via 174.1.234.4, 00:31:12, Serial0/0
    O E2 150.1.6.0 [160/20] via 174.1.234.3, 00:31:12, Serial0/0
    O E2 150.1.5.0 [160/20] via 174.1.234.3, 00:31:12, Serial0/0
    O E2 205.90.31.0/24 [160/20] via 174.1.234.4, 00:02:48, Serial0/0

    Rack1R3#show ip route ospf | i E2
    O E2 222.22.2.0/24 [160/20] via 174.1.234.4, 00:03:20, Serial0/0
    O E2 220.20.3.0/24 [160/20] via 174.1.234.4, 00:03:20, Serial0/0
    O E2 192.10.1.0/24 [160/20] via 174.1.234.4, 00:41:43, Serial0/0
    O E2 205.90.31.0/24 [160/20] via 174.1.234.4, 00:03:20, Serial0/0

    much better now. :-)

  15. [...] Understanding Redistribution: Part 2 [...]

  16. kevin says:

    Hi,
    This is probably something that’s obvious to all of you, but I am hoping someone could help me understand something here.

    After R3 has been configured to mutually redistribute EIGRP356 and EIGRP123, shouldn’t R1 have two routes to R5 and R6′s loopback?

    For example, R6′s loopback interface (150.18.6.0) is redistributed into OSPF and EIGRP123 via R3. R2 would see ospf E2 route for 150.18.6.0 with AD of 160 at this time and and redistribute it into EIGRP123. Why doesn R1 see this redistribution from R2?

    Thank you.

    • kevin says:

      Ah, I figured it out… I forgot that EIGRP356′s metric is carried over into EIGRP123 whereas in R2′s case it’s using an arbitrary metric 1 1 1 1 1 when it’s redistributing the prefix into EIGRP123.

  17. [...] use feature X or Y I should know how to do it using feature Z. So here is part second part in the route redistribution [...]

  18. cedric says:

    wit wew!!! no exact word how Im thankful for this post, I really gained my confidence in redistribution. all I can say is more power to you Petr and God bless you always.

  19. Kenneth Ratliff says:

    I’m a tad bit confused on the R1 loopback thing, and changing the OSPF AD.

    If the OSPF AD is 160, and R2 and R3 are both redistributing eigrp 123 into OSPF, what I would expect to happen is that either R2 or R3 are learning the route as an AD 170 EIGRP external prefix. Then that prefix is getting injected into OSPF. When the other router learns it, it should still be preferring the OSPF External prefix with an AD of 160 over the EIGRP external prefix of AD 170.

    So i’m a little confused as to how raising the OSPF external distance from 110 to 160 on both R2 and R3 all of a sudden make them both start preferring an AD170 prefix, there should be no change.

    • RobM says:

      There was an additional step taken to make the R1 loopback address (only) have an AD of 171 on R3.

      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

      This way, the OSPF learned route for 150.18.1.0 is AD 171 which loses to the route from EIGRP (170). The route from R1 is therefore installed.

  20. ls says:

    I’m with Kenneth, I’m not quite sure the solution is right in regards to R1s lo0 being redistributed into EIGRP causing sub-optimal routing.

    The first solution was to increase the AD of R1s lo0 to 171 in OSPF on R2 and R3, this makes sense as this would cause the EIGRP external route to it to be preferred (170 vs 171). The second solution to increase the AD of OSPF external routes to 160 would have no effect as the EIGRP external is still less prefered (160 vs 170).

    The first solution seems to run opposite to the suggestion that we should make the transit domain trusted i.e. by setting the AD to 171 we are saying it’s less trusted than EIGRP external routes for R1s lo0.

    I think because once we turn on redist connected for R1s lo0 in EIGRP 123 we are kind of turning EIGRP 123 into a transit domain as well and because of that the idea that the OSPF domain should be trusted completely isn’t exactly true.

  21. Andy says:

    I don’t understand why do you need to change OSPF AD distances on R2 and R3. OSPF will labeled redistributed routes as E2 (by default) already.

    router ospf 1
    distance ospf intra-area 80
    distance ospf inter-area 80
    distance ospf external 160

 

Leave a Reply

Categories

CCIE Bloggers