Mar
17

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

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:02:43, Serial0/0

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

D EX 222.22.2.0/24 [170/2560025856] via 174.9.0.5, 00:03:58, Ethernet0/1
D EX 220.20.3.0/24 [170/2560025856] via 174.9.0.5, 00:03:58, Ethernet0/1
     174.9.0.0/24 is subnetted, 3 subnets
C       174.9.234.0 is directly connected, Serial1/0
C       174.9.0.0 is directly connected, Ethernet0/1
C       174.9.123.0 is directly connected, Ethernet0/0
D EX 192.10.9.0/24 [170/2560025856] via 174.9.0.5, 00:03:58, Ethernet0/1
     150.9.0.0/24 is subnetted, 6 subnets
D       150.9.6.0 [90/409600] via 174.9.0.6, 00:08:56, Ethernet0/1
D       150.9.5.0 [90/409600] via 174.9.0.5, 00:03:58, Ethernet0/1
O       150.9.4.0 [110/782] via 174.9.234.4, 00:26:45, Serial1/0
C       150.9.3.0 is directly connected, Loopback0
O       150.9.2.0 [110/782] via 174.9.234.2, 00:26:45, Serial1/0
D       150.9.1.0 [120/409600] via 174.9.123.1, 00:26:35, Ethernet0/0
D EX 205.90.31.0/24 [170/2560025856] via 174.9.0.5, 00:03:58, Ethernet0/1

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

R    222.22.2.0/24 [120/7] via 192.10.9.254, 00:00:21, Ethernet0/0
R    220.20.3.0/24 [120/7] via 192.10.9.254, 00:00:21, Ethernet0/0
     174.9.0.0/24 is subnetted, 3 subnets
C       174.9.234.0 is directly connected, Serial0/0
R       174.9.0.0 [120/8] via 192.10.9.5, 00:00:25, Ethernet0/0
R       174.9.123.0 [120/8] via 192.10.9.5, 00:00:25, Ethernet0/0
C    192.10.9.0/24 is directly connected, Ethernet0/0
     150.9.0.0/24 is subnetted, 6 subnets
R       150.9.6.0 [120/8] via 192.10.9.5, 00:00:25, Ethernet0/0
R       150.9.5.0 [120/8] via 192.10.9.5, 00:00:25, Ethernet0/0
C       150.9.4.0 is directly connected, Loopback0
O       150.9.3.0 [110/65] via 174.9.234.3, 00:44:33, Serial0/0
O       150.9.2.0 [110/65] via 174.9.234.2, 00:44:33, Serial0/0
R       150.9.1.0 [120/8] via 192.10.9.5, 00:00:25, Ethernet0/0
R    205.90.31.0/24 [120/7] via 192.10.9.254, 00:00:21, Ethernet0/0

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

R    222.22.2.0/24 [120/7] via 192.10.9.254, 00:00:09, Ethernet0/1
R    220.20.3.0/24 [120/7] via 192.10.9.254, 00:00:09, Ethernet0/1
     174.9.0.0/24 is subnetted, 3 subnets
D EX    174.9.234.0 [170/2560025856] via 174.9.0.3, 00:05:15, Ethernet0/0
C       174.9.0.0 is directly connected, Ethernet0/0
D EX    174.9.123.0 [170/307200] via 174.9.0.3, 00:05:15, Ethernet0/0
C    192.10.9.0/24 is directly connected, Ethernet0/1
     150.9.0.0/24 is subnetted, 6 subnets
D       150.9.6.0 [90/409600] via 174.9.0.6, 00:05:15, Ethernet0/0
C       150.9.5.0 is directly connected, Loopback0
D EX    150.9.4.0 [170/2560025856] via 174.9.0.3, 00:05:15, Ethernet0/0
D EX    150.9.3.0 [170/2560025856] via 174.9.0.3, 00:05:15, Ethernet0/0
D EX    150.9.2.0 [170/2560025856] via 174.9.0.3, 00:05:15, Ethernet0/0
D EX    150.9.1.0 [170/435200] via 174.9.0.3, 00:05:15, Ethernet0/0
R    205.90.31.0/24 [120/7] via 192.10.9.254, 00:00:09, Ethernet0/1

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

D EX 222.22.2.0/24 [170/2560002816] via 174.9.0.5, 00:06:01, FastEthernet0/0
D EX 220.20.3.0/24 [170/2560002816] via 174.9.0.5, 00:06:01, FastEthernet0/0
     174.9.0.0/24 is subnetted, 3 subnets
D EX    174.9.234.0 [170/2560002816] via 174.9.0.3, 00:10:59, FastEthernet0/0
C       174.9.0.0 is directly connected, FastEthernet0/0
D EX    174.9.123.0 [170/284160] via 174.9.0.3, 00:10:59, FastEthernet0/0
D EX 192.10.9.0/24 [170/2560002816] via 174.9.0.5, 00:06:01, FastEthernet0/0
     150.9.0.0/24 is subnetted, 6 subnets
C       150.9.6.0 is directly connected, Loopback0
D       150.9.5.0 [90/156160] via 174.9.0.5, 00:06:01, FastEthernet0/0
D EX    150.9.4.0 [170/2560002816] via 174.9.0.3, 00:10:59, FastEthernet0/0
D EX    150.9.3.0 [170/2560002816] via 174.9.0.3, 00:10:59, FastEthernet0/0
D EX    150.9.2.0 [170/2560002816] via 174.9.0.3, 00:10:59, FastEthernet0/0
D EX    150.9.1.0 [170/412160] via 174.9.0.3, 00:10:59, FastEthernet0/0
D EX 205.90.31.0/24 [170/2560002816] via 174.9.0.5, 00:06:02, FastEthernet0/0

Shutdown VLAN 356 links of R3 and R5 next, to test the “backup” core links and check the routing tables again:

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

D EX 222.22.2.0/24 [170/2560028160] via 174.9.123.3, 00:00:59, FastEthernet0/0
                   [170/2560028160] via 174.9.123.2, 00:00:59, FastEthernet0/0
D EX 220.20.3.0/24 [170/2560028160] via 174.9.123.3, 00:00:59, FastEthernet0/0
                   [170/2560028160] via 174.9.123.2, 00:00:59, FastEthernet0/0
     174.9.0.0/24 is subnetted, 2 subnets
D EX    174.9.234.0
           [170/2560002816] via 174.9.123.3, 00:30:07, FastEthernet0/0
           [170/2560002816] via 174.9.123.2, 00:30:07, FastEthernet0/0
C       174.9.123.0 is directly connected, FastEthernet0/0
D EX 192.10.9.0/24 [170/2560028160] via 174.9.123.3, 00:00:59, FastEthernet0/0
                   [170/2560028160] via 174.9.123.2, 00:00:59, FastEthernet0/0
     150.9.0.0/24 is subnetted, 4 subnets
D EX    150.9.4.0 [170/2560002816] via 174.9.123.3, 00:30:07, FastEthernet0/0
                  [170/2560002816] via 174.9.123.2, 00:30:07, FastEthernet0/0
D EX    150.9.3.0 [170/2560002816] via 174.9.123.3, 00:30:09, FastEthernet0/0
                  [170/2560002816] via 174.9.123.2, 00:30:09, FastEthernet0/0
D EX    150.9.2.0 [170/2560002816] via 174.9.123.3, 00:30:09, FastEthernet0/0
                  [170/2560002816] via 174.9.123.2, 00:30:09, FastEthernet0/0
C       150.9.1.0 is directly connected, Loopback0
D EX 205.90.31.0/24
           [170/2560028160] via 174.9.123.3, 00:01:00, FastEthernet0/0
           [170/2560028160] via 174.9.123.2, 00:01:00, 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:01:12, Serial0/0
O E2 220.20.3.0/24 [190/20] via 174.9.234.4, 00:01:12, Serial0/0
     174.9.0.0/24 is subnetted, 2 subnets
C       174.9.234.0 is directly connected, 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:01:12, Serial0/0
     150.9.0.0/24 is subnetted, 4 subnets
O       150.9.4.0 [110/65] via 174.9.234.4, 00:48:06, Serial0/0
O       150.9.3.0 [110/65] via 174.9.234.3, 00:48: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:47:53, FastEthernet0/0
O E2 205.90.31.0/24 [190/20] via 174.9.234.4, 00:01:12, Serial0/0

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

O E2 222.22.2.0/24 [180/20] via 174.9.234.4, 00:01:40, Serial1/0
O E2 220.20.3.0/24 [180/20] via 174.9.234.4, 00:01:40, Serial1/0
     174.9.0.0/24 is subnetted, 2 subnets
C       174.9.234.0 is directly connected, Serial1/0
C       174.9.123.0 is directly connected, Ethernet0/0
O E2 192.10.9.0/24 [180/20] via 174.9.234.4, 00:01:40, Serial1/0
     150.9.0.0/24 is subnetted, 4 subnets
O       150.9.4.0 [110/782] via 174.9.234.4, 00:30:59, Serial1/0
C       150.9.3.0 is directly connected, Loopback0
O       150.9.2.0 [110/782] via 174.9.234.2, 00:30:59, Serial1/0
D       150.9.1.0 [120/409600] via 174.9.123.1, 00:30:49, Ethernet0/0
O E2 205.90.31.0/24 [180/20] via 174.9.234.4, 00:01:40, Serial1/0

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

R    222.22.2.0/24 [120/7] via 192.10.9.254, 00:00:13, Ethernet0/0
R    220.20.3.0/24 [120/7] via 192.10.9.254, 00:00:13, Ethernet0/0
     174.9.0.0/24 is subnetted, 2 subnets
C       174.9.234.0 is directly connected, Serial0/0
O E2    174.9.123.0 [190/20] via 174.9.234.3, 00:01:41, Serial0/0
                    [190/20] via 174.9.234.2, 00:01:41, Serial0/0
C    192.10.9.0/24 is directly connected, Ethernet0/0
     150.9.0.0/24 is subnetted, 5 subnets
R       150.9.5.0 [120/8] via 192.10.9.5, 00:00:10, Ethernet0/0
C       150.9.4.0 is directly connected, Loopback0
O       150.9.3.0 [110/65] via 174.9.234.3, 00:48:25, Serial0/0
O       150.9.2.0 [110/65] via 174.9.234.2, 00:48:25, Serial0/0
O E2    150.9.1.0 [190/20] via 174.9.234.3, 00:01:41, Serial0/0
                  [190/20] via 174.9.234.2, 00:01:41, Serial0/0
R    205.90.31.0/24 [120/7] via 192.10.9.254, 00:00:13, Ethernet0/0

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

R    222.22.2.0/24 [120/7] via 192.10.9.254, 00:00:07, Ethernet0/1
R    220.20.3.0/24 [120/7] via 192.10.9.254, 00:00:07, Ethernet0/1
     174.9.0.0/24 is subnetted, 2 subnets
R       174.9.234.0 [200/8] via 192.10.9.4, 00:00:27, Ethernet0/1
R       174.9.123.0 [200/12] via 192.10.9.4, 00:00:27, Ethernet0/1
C    192.10.9.0/24 is directly connected, Ethernet0/1
     150.9.0.0/24 is subnetted, 5 subnets
C       150.9.5.0 is directly connected, Loopback0
R       150.9.4.0 [200/8] via 192.10.9.4, 00:00:27, Ethernet0/1
R       150.9.3.0 [200/8] via 192.10.9.4, 00:00:27, Ethernet0/1
R       150.9.2.0 [200/8] via 192.10.9.4, 00:00:27, Ethernet0/1
R       150.9.1.0 [200/12] via 192.10.9.4, 00:00:27, Ethernet0/1
R    205.90.31.0/24 [120/7] via 192.10.9.254, 00:00:07, Ethernet0/1
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.

7 Responses to “Understanding Redistribution (Part III)”

 
  1. uri says:

    Hi Petr!

    First of all I’d like to thank you for very systematic description! Just a little correction for R2′s routing policy:

    [snip]
    !
    route-map OSPF_TO_EIGRP_123 permit 30
    match ip address EIGRP_356_PREFIXES
    set metric 1 *100* 1 1 1
    !
    [snip]

    This prevents R1 to do ECMP towards EIGRP356′s pfxs and choose R3 as the best exit point.

  2. uri says:

    …sorry: didn’t see that R3 performs transparent metric translation EIGRP356 -> EIGRP123 instead of doing metric reset by “set metric 1 1 1 1 1″.

  3. [...] This is the final post by Petr on route redistribution. If you have read all three of them you should have a much better understanding of route redistribution. Also, INE has released a few videos on route redistribution from ther ATC. These videos are very good and I recommend you watch them. [...]

  4. Roger says:

    If we change the distance of EIGRP 123(120, 190) in R3 and the distance of OSPF external to 180, R3 will install in the routing table the route to 150.18.1.0 (R1′s Loopback) using OSPF via R2 and not from R1 with EIGRP 123.

  5. [...] en bloggpost om hur olika ”redistribueringsproblem” kan lösas och finns att hitta här. Kommer använda hans post som guide för att ha en chans att slutföra detta, med förhoppning att [...]

 

Leave a Reply

Categories

CCIE Bloggers