blog
    Understanding Redistribut ...
    19 February 08

    Understanding Redistribution (Part II)

    Posted byPetr Lapukhov
    facebooktwitterlinkedin
    news-featured

    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.

    Hey! Don’t miss anything - subscribe to our newsletter!

    © 2022 INE. All Rights Reserved. All logos, trademarks and registered trademarks are the property of their respective owners.
    instagram Logofacebook Logotwitter Logolinkedin Logoyoutube Logo