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).
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:
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.
To verify our implementation, you may run a Tcl verification script, and additionally look at the “show ip route” command output.
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.0Next, 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 1In 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 100Next, 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 1For 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_PREFIXESThe 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_356Our 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 subnetsOK, 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 subnetsThe 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_RIPWe’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 200R3 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 180R4 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 190Finally, 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_PREFIXESWe’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/0Shutdown 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
0 comments:
Post a Comment