IPv6: Route Control - Route Filtering Konfigurasi
Configuring Route Filters Route filtering is accomplished by one of the following methods: Filtering specific routes, using the distribute-list command Manipulating the administrative distances of routes, using the distance command Case Study: Filtering Specific Routes Figure 13-2 shows a portion of a network running RIPv2 and RIPng. Barkis is providing connectivity to the rest of the Internet via Traddles. In addition to the 700 specific IPv4 routes within BigNet, Traddles is advertising an IPv4 default route to Barkis. Because of the default route, Barkis, Micawber, Peggotty, and Heep do not need to know the other 700 routes in BigNet. So the objective is to configure a filter at Barkis that will accept only the default route from Traddles and reject all other routes. Barkis' configuration is displayed in Example 13-1. Figure 13-2. A route filter at Barkis will accept only the default route from Traddles and will reject all other BigNet routes. [View full size image]Example 13-1. The route filter on Barkis permits the default route and rejects all other addresses. router rip version 2 network 192.168.75.0 distribute-list 1 in Serial1 ! ip classless access-list 1 permit 0.0.0.0 This route filter examines incoming routes at S1, which is the interface connected to Traddles. It specifies that the only routes accepted by Barkis's RIP process are those permitted by access list 1, and access list 1 specifies that only 0.0.0.0 is permitted. [2] All other routes are implicitly denied by the access list. Example 13-2 shows the resulting route table at Barkis. [2] Note that no inverse mask is shown. An access list's default inverse mask is 0.0.0.0, which is correct for this configuration.Example 13-2. 0.0.0.0 is the only route accepted from Traddles. Barkis#show ip route rip Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inte N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external E1 - OSPF external type 1, E2 - OSPF external type 2, E i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - c U - per-user static route, o - ODR Gateway of last resort is 192.168.75.198 to network 0.0.0.0 192.168.75.0/24 is variably subnetted, 5 subnets, 2 masks C 192.168.75.32/27 is directly connected, Ethernet0 R 192.168.75.64/27 [120/1] via 192.168.75.201, 00:00:23, Se C 192.168.75.196/30 is directly connected, Serial1 C 192.168.75.200/30 is directly connected, Serial0 R 192.168.75.204/30 [120/1] via 192.168.75.34, 00:00:13, E R* 0.0.0.0/0 [120/10] via 192.168.75.198, 00:00:03, Serial1 Barkis# IPv6 routes can be filtered in the same way. Barkis accepts only the IPv6 default route from Traddles. Barkis's configuration is displayed in Example 13-3. Example 13-3. Barkis filters IPv6 routes to accept only the default route. ipv6 router rip emily distribute-list prefix-list copperfield in Serial1 ! ipv6 prefix-list copperfield permit ::/0The only difference between the IPv4 and the IPv6 configuration is that the IPv4 distribute-list command references an access list, and the IPv6 distribute-list command references a prefix list. The prefix list permits or denies IPv6 prefixes. Example 13-4 shows the IPv6 route table at Barkis. Example 13-4. ::/0 is the only IPv6 RIP route accepted from Traddles. Barkis#show ipv6 route rip IPv6 Routing Table - 11 entries Codes: C - Connected, L - Local, S - Static, R - RIP, B BGP U - Per-user Static route I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - IS O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2 R
- /0 [120/2]
via FE80::205:5EFF:FE6B:50A0, Serial1 R 2001:DB8:0:40::/64 [120/2] via FE80::2B0:64FF:FE30:1DE0, Serial0 R 2001:DB8:0:CC::/64 [120/2] via FE80::204:C1FF:FE50:F1C0, Ethernet0 Barkis# In Example 13-5, Barkis's configuration is changed to accept 2001:db8:0:100::/64 through 2001:db8:0:103::/64, rather than the default IPv6 route. The prefix list is modified to accept this range of addresses only. Example 13-5. Barkis is configured to accept a range of IPv6 addresses into RIPng.ipv6 router rip emily distribute-list prefix-list copperfield in Serial1 ! ipv6 prefix-list copperfield permit 2001:db8:0:100::/62 le 64 A range of IPv6 prefixes is specified by using the ge or the le option to the prefix-list command. ge is "greater than or equal to" and le is "less than or equal to." Barkis's prefix list specifies the prefix 2001:db8:0:100::/62 and any other prefixes that have the same first 62 bits and any value in the bits 63 or 64. This correctly allows 2001:db8:0:100::/64, 2001:db8:0:101::/64, 2001:db8:0:102::/64, and 2001:db8:0:103::/64. Prefix lists are discussed further in Appendix B, "Tutorial: Access Lists." Of course, advertising 700 routes across a serial link only to discard them at the far end is a waste of bandwidth. So a better configuration would be to place the filter at Traddles, allowing only the default route to be advertised to Barkis, as shown in Example 13-6. Example 13-6. Traddles is configured to filter outgoing RIP IPv4 routes. router rip version 2 network 192.168.63.0 network 192.168.75.0 network 192.168.88.0 distribute-list 1 out Serial0 ! ip classless access-list 1 permit 0.0.0.0For IPv6, the configuration at Traddles is as displayed in Example 13-7. Example 13-7. Traddles is configured to filter outgoing IPv4 RIPng routes. ipv6 router rip emily distribute-list prefix-list copperfield out Serial0 ! ipv6 prefix-list copperfield permit 2001:db8:0:100::/62 le 64 Here, the filter configuration looks almost the same, except that it is filtering outgoing routes instead of incoming routes. Example 13-8 shows that only the default route is being advertised across the serial link from Traddles. Example 13-8. The filter at Traddles allows only the default route to be advertised to Barkis. Barkis#debug ip rip RIP protocol debugging is on Barkis# RIP: received v2 update from 192.168.75.198 on Serial1 0.0.0.0/0 -> 0.0.0.0 in 10 hops RIP: sending v2 update to 224.0.0.9 via Ethernet0 (192.168.75.3 192.168.75.64/27 -> 0.0.0.0, metric 2, tag 0 192.168.75.196/30 -> 0.0.0.0, metric 1, tag 0 192.168.75.200/30 -> 0.0.0.0, metric 1, tag 0 0.0.0.0/0 -> 0.0.0.0, metric 11, tag 0 RIP: sending v2 update to 224.0.0.9 via Serial0 (192.168.75.2020.0.0.0/0 -> 0.0.0.0, metric 11, tag 0 RIP: sending v2 update to 224.0.0.9 via Serial1 (192.168.75.197 192.168.75.32/27 -> 0.0.0.0, metric 1, tag 0 192.168.75.64/27 -> 0.0.0.0, metric 2, tag 0 192.168.75.200/30 -> 0.0.0.0, metric 1, tag 0 192.168.75.204/30 -> 0.0.0.0, metric 2, tag 0 RIP: received v2 update from 192.168.75.34 on Ethernet0 192.168.75.64/27 -> 0.0.0.0 in 2 hops 192.168.75.204/30 -> 0.0.0.0 in 1 hops RIP: received v2 update from 192.168.75.201 on Serial0 192.168.75.64/27 -> 0.0.0.0 in 1 hops 192.168.75.204/30 -> 0.0.0.0 in 2 hops In both configurations, Barkis will advertise the default route to Micawber and to Peggotty. Neither configuration affects the routes that Barkis advertises to Traddles. When the distribute-list command is configured under link-state protocols such as OSPF, the out keyword cannot be used in association with an interface. [3] Because link-state protocols do not advertise routes from their route table as do distance-vector protocols, there are no updates to filter. A command such as distribute-list 1 out Serial1 under a link-state protocol is meaningless. [3] The out keyword can be used in association with a routing protocol, as discussed in the next case study. In Figure 13-3, another group of routers has been connected. This network section, ThemNet, is under separate administrative control, as is the Router Creakle. Because the BigNet administrator has no access to or control over the routers in ThemNet, route filters should be used to minimize the potential of bad routing information being sent into BigNet from Creakle. For example, notice that ThemNet is using a default route (perhaps to access an internal Internet connection). If this default route should be advertised into BigNet, it could cause packets to be misroutedinto ThemNet. A black hole would exist. Figure 13-3. The network ThemNet is not under the control of the BigNet administrator. [View full size image] To allow only the routes necessary for communication with ThemNet, Heep's configuration is displayed in Example 13-9. Example 13-9. Heep's configuration filters RIP routes to and from Creakle. router rip version 2network 192.168.75.0 distribute-list 2 out Serial1 distribute-list 1 in Serial1 ! ip classless access-list 1 permit 192.168.73.0 access-list 1 permit 192.168.65.0 access-list 1 permit 192.168.62.0 access-list 1 permit 10.5.187.208 access-list 2 deny 0.0.0.0 access-list 2 permit any Distribute list 1 allows only the routes specified in access list 1 to be accepted from Creakle. It blocks the default route and any other routes that might be inserted incorrectly into the route tables of ThemNet. Distribute list 2 is in place to ensure that BigNet is a good neighbor. It blocks the BigNet default route, which would cause problems in ThemNet, and allows all other BigNet routes. Case Study: Route Filtering and Redistribution Any time a router performs mutual redistribution, the potential for route feedback exists. For example, a route from the RIP side in Figure 13-4 can be redistributed into OSPF and, from there, be redistributed back into RIP. Therefore, using route filters to control the direction of route advertisements is a wise approach. Figure 13-4. Cruncher is redistributing RIP routes into OSPF, and OSPF routes into RIP. Route filters should be used to prevent route feedback.Cruncher in Figure 13-4 is speaking both RIP and OSPF on several interfaces. Cruncher's configuration is displayed in Example 13-10. Example 13-10. Cruncher is configured to run both OSPF and RIP, and filters are configured to control which routes are advertised into each protocol. router ospf 25 redistribute rip metric 100 network 172.16.8.254 0.0.0.0 area 25 network 172.16.50.254 0.0.0.0 area 25 distribute-list 3 in Ethernet0/0 distribute-list 3 in Ethernet0/1 distribute-list 3 in Ethernet0/2 ! router rip version 2 redistribute ospf 25 metric 5passive-interface Ethernet0/0 passive-interface Ethernet0/1 passive-interface Ethernet0/2 network 172.16.0.0 distribute-list 1 in Ethernet0/3 distribute-list 1 in Ethernet2/0 distribute-list 1 in Ethernet2/1 ! ip classless access-list 1 permit 172.16.128.0 0.0.127.255 access-list 3 permit 172.16.0.0 0.0.127.255 In this configuration, the logic of the access lists is to permit certain routes and deny all others. The logic can also be reversed to deny certain routes and allow all others, as shown in Cruncher's modified configuration in Example 13-11. Example 13-11. Cruncher's access list could be modified to deny specific routes and permit all others. access-list access-list access-list access-list 1 1 3 3 deny 172.16.0.0 0.0.127.255 permit any deny 172.16.128.0 0.0.127.255 permit any The effect of this second access list configuration is the same as the first. In both cases, routes to destinations in the OSPF domain will not be advertised into OSPF from RIP, and routes to destinations in the RIP domain will not be advertised into RIP from OSPF. However, this second access list configuration needs to be carefully administered to minimize problems in the future. If a new address is added into the RIP domain, for instance, without modifying the route filter, the route will get advertisedinto OSPF and re-advertised back into RIP, causing a potential route loop. A new deny statement needs to be added to the route filter to control the loop. If the first access list is being used instead of the second, and a new address is added to the RIP domain, it will not be advertised into OSPF until the access lists are modified. No route loops will occur and routing within the RIP domain to the new address will be successful. The second access list configuration is also not as easy to administer, because of the permit any at the end. To add new entries to the list, the entire list must first be deleted so that the new entry can be placed before the permit any. [4] [4] In some IOS versions, access-list entries can be added to specific places in the access list using sequence numbers, making the lists easier to administer. The small access lists shown are possible because the subnet addresses in Figure 13-4 were carefully assigned for easy summarization. The trade-off is a loss of specificity. More precise control over the routes means larger, more precise access lists at the price of increased administrative attention. An alternative method of configuring route filters at redistribution points is to filter by route process instead of by interface. For example, the configuration in Example 13-12 allows only certain IPv4 routes in Figure 13-4 to be redistributed. Example 13-12. Cruncher filters routes at the route process. router ospf 25 redistribute rip metric 100 network 172.16.1.254 0.0.0.0 area 25 network 172.16.8.254 0.0.0.0 area 25 network 172.16.50.254 0.0.0.0 area 25 distribute-list 10 out rip ! router ripversion 2 redistribute ospf 25 metric 5 passive-interface Ethernet0/3 passive-interface Ethernet2/0 passive-interface Ethernet2/1 network 172.16.0.0 distribute-list 20 out ospf 25 ! ip classless access-list 10 permit 172.16.130.0 access-list 10 permit 172.16.145.0 access-list 10 permit 172.16.240.0 access-list 20 permit 172.16.23.0 access-list 20 permit 172.16.9.0 access-list 20 permit 172.16.75.0 The route filter under the OSPF configuration allows OSPF to advertise RIP-discovered routes only if access list 10 permits them. Likewise, the filter under the RIP configuration allows RIP to advertise routes discovered by OSPF 25 only if access list 20 permits them. In both cases, the filters have no effect on routes discovered by other protocols. For example, if OSPF were redistributing both RIP and EIGRP routes, the distribute list shown would not apply to EIGRP-discovered routes. The same configuration can apply to IPv6 prefixes. For RIPng and OSPFv3 for IPv6, the distribute-list references a prefix-list rather then an access-list, and the prefix-list permits or denies IPv6 prefixes rather than IPv4 addresses. When filtering by route process, only the out keyword is allowed. After all, it makes no sense to specify something like distribute-list 10 in rip under OSPF. The route has already been entered into the route table by RIP, and OSPF either advertises it ("out") or it does not. Note that although filtering by routing protocol is useful for specifyingwhich routes will be redistributed, it is not a good method for preventing route feedback. For example, consider the configuration in Example 13- 13 for Cruncher in Figure 13-4. Example 13-13. Cruncher's configuration filters routes advertised by the OSPF and RIP processes but does not filter routes added into Cruncher's route table. router ospf 25 redistribute rip metric 100 network 172.16.1.254 0.0.0.0 area 25 network 172.16.8.254 0.0.0.0 area 25 network 172.16.50.254 0.0.0.0 area 25 distribute-list 1 out rip ! router rip version 2 redistribute ospf 25 metric 5 passive-interface Ethernet0/3 passive-interface Ethernet2/0 passive-interface Ethernet2/1 network 172.16.0.0 distribute-list 3 out ospf 25 ! ip classless access-list 1 permit 172.16.128.0 0.0.127.255 access-list 3 permit 172.16.0.0 0.0.127.255 Suppose a route from the RIP domain, such as 172.16.190.0/24, redistributed into the OSPF domain, were to be advertised back to Cruncher because of a misconfigured router. Although the distribute list under the RIP configuration would prevent the route from being advertised back into the RIP domain, the list does nothing to prevent theroute from being entered into Cruncher's route table as originating within the OSPF domain. In fact, the filter assumes that the route has already been entered into the table by OSPF. Because OSPF has a lower administrative distance than RIP, Cruncher will prefer the OSPF learned route, and Cruncher will route traffic destined to 172.16.190.0 to the OSPF router rather than to RIP. To prevent route feedback, routes must be filtered as they are incoming on an interface, before they are entered into the route table. Case Study: A Protocol Migration The distance command, when used without any optional parameters, specifies the administrative distance to be assigned to routes learned from a particular IPv4 or IPv6 routing protocol. On first consideration, this action might not seem to be a route filtering function, but it is. When multiple routing protocols are running, routes are accepted or rejected into the route table based on their administrative distances. The network in Figure 13-5 is running RIP, and there is a plan to convert to EIGRP. Several methods exist for conducting such a protocol migration. One option is to turn off the old protocol and turn on the new protocol at each router. Although this option is valid for a small network such as the one in Figure 13-5, the downtime can be impractical in larger networks. Figure 13-5. These routers are running RIP and are to be converted to EIGRP.Another option is to add the new protocol without removing the old protocol. If the default administrative distance of the new protocol is lower than that of the old, each router will prefer the routes advertised by the new protocol as they are added. The network will converge to the new protocol as the routers are converted, and after the entire network has converged on the new protocol, the old one can be removed from all routers. Referring to Table 11-1, the default administrative distance of RIP is 120, and the default administrative distance of EIGRP is 90. If EIGRP is added to each router in addition to RIP, the router will begin preferring the EIGRP routes as its neighbors begin speaking EIGRP. When all RIP routes have disappeared from all route tables, the network has reconverged on EIGRP. The RIP processes can then be removed from the routers. The problem with this approach is that the potential for routing loops and black holes exists during the transition period. The five routers in Figure 13-5 can be reconfigured and reconverged in a matter of minutes, so looping might not be as much of a concern here as it would be in a larger network. A modification of this dual-protocol method is to use the distance command to ensure that the routes of the new protocol are rejected until all routers are ready for conversion. The first step in this procedure is to lower the administrative distance of RIP in all routers, as shown inExample 13-14. Example 13-14. Each router in the network in Figure 13-5 is reconfigured to lower the administrative distance of RIP. router rip network 172.16.0.0 distance 70 Note that the administrative distance is relevant only to the routing process of a single router. While RIP is still the only protocol running, the change of administrative distance will have no effect on routing. Next, each router is revisited, and the EIGRP process is added. The EIGRP configuration in Example 13-15 is added to each router. Example 13-15. EIGRP configuration is added to each router in Figure 13-5. router eigrp 1 network 172.16.0.0 ! router rip network 172.16.0.0 distance 70 Because EIGRP has a default administrative distance of 90, the RIP routes are preferred (Example 13-16). No routers are preferring EIGRP, so no network downtime has to be scheduled while the configurations are changed. This approach gives the network administrator time to re-examine the new configurations in each router and to check the EIGRP topology database for accuracy before the conversion. Example 13-16. The RIP routes, which have been assigned an administrative distance of 70, are preferred over the EIGRP routes. Drummle#show ip route D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inte N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external E1 - OSPF external type 1, E2 - OSPF external type 2, E i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - c U - per-user static route, o - ODR Gateway of last resort is not set 172.16.0.0/24 is subnetted, 11 subnets C 172.16.252.0 is directly connected, Serial0 C 172.16.253.0 is directly connected, Serial1 R 172.16.254.0 [70/1] via 172.16.2.253, 00:00:16, Ethernet [70/1] via 172.16.253.253, 00:00:05, Serial R 172.16.251.0 [70/1] via 172.16.252.253, 00:00:08, Serial [70/1] via 172.16.3.253, 00:00:01, Ethernet R 172.16.4.0 [70/1] via 172.16.3.253, 00:00:01, Ethernet1 R 172.16.5.0 [70/1] via 172.16.253.253, 00:00:05, Serial1 R 172.16.6.0 [70/1] via 172.16.252.253, 00:00:08, Serial0 [70/1] via 172.16.253.253, 00:00:05, Serial1 R 172.16.7.0 [70/1] via 172.16.252.253, 00:00:08, Serial0 R 172.16.1.0 [70/1] via 172.16.2.253, 00:00:17, Ethernet0 C 172.16.2.0 is directly connected, Ethernet0 C 172.16.3.0 is directly connected, Ethernet1 Drummle# The next step in the conversion process is to revisit each router and change the RIP distance back to the default of 120. Network downtimeshould be scheduled for this step. The RIP routes with the administrative distance of 70 will begin to age out because the new RIP updates will be assigned an administrative distance of 120 (Example 13-17). At 210 seconds, the RIP routes will be declared invalid (Example 13-18), and finally the EIGRP routes will be preferred (Example 13-19). Example 13-17. After the RIP administrative distance is changed back to 120, the routes with a distance of 70 begin to age out. Here, all the RIP routes are more than two minutes old. Drummle#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inte N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external E1 - OSPF external type 1, E2 - OSPF external type 2, E i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - c U - per-user static route, o - ODR Gateway of last resort is not set 172.16.0.0/24 is subnetted, 11 subnets C 172.16.252.0 is directly connected, Serial0 C 172.16.253.0 is directly connected, Serial1 R 172.16.254.0 [70/1] via 172.16.2.253, 00:02:31, Ethernet0 [70/1] via 172.16.253.253, 00:02:18, Serial1 R 172.16.251.0 [70/1] via 172.16.252.253, 00:02:27, Serial [70/1] via 172.16.3.253, 00:02:32, Ethernet R 172.16.4.0 [70/1] via 172.16.3.253, 00:02:32, Ethernet1 R 172.16.5.0 [70/1] via 172.16.253.253, 00:02:19, Serial1 R 172.16.6.0 [70/1] via 172.16.252.253, 00:02:27, Serial0 [70/1] via 172.16.253.253, 00:02:19, Serial1 R 172.16.7.0 [70/1] via 172.16.252.253, 00:02:27, Serial0 R 172.16.1.0 [70/1] via 172.16.2.253, 00:02:32, Ethernet0Example 13-18. At 3.5 minutes, the RIP routes are declared down. Drummle#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inte N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external E1 - OSPF external type 1, E2 - OSPF external type 2, E i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - c U - per-user static route, o - ODR Gateway of last resort is not set 172.16.0.0/24 is subnetted, 11 subnets C 172.16.252.0 is directly connected, Serial0 C 172.16.253.0 is directly connected, Serial1 R 172.16.254.0/24 is possibly down, routing via 172.16.253.253, Serial1 R 172.16.251.0/24 is possibly down, routing via 172.16.252.253, Serial0 R 172.16.4.0/24 is possibly down, routing via 172.16.3.253, Ethernet1 R 172.16.5.0/24 is possibly down, routing via 172.16.253.253, Serial1 R 172.16.6.0/24 is possibly down, routing via 172.16.253.253, Serial1 R 172.16.7.0/24 is possibly down, routing via 172.16.252.253, Serial0 R 172.16.1.0/24 is possibly down, routing via 172.16.2.253, Ethernet0 C 172.16.2.0 is directly connected, Ethernet0 C 172.16.3.0 is directly connected, Ethernet1Example 13-19. The EIGRP routes, with their default distance of 90, replace the RIP routes. Drummle#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inte N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external t E1 - OSPF external type 1, E2 - OSPF external type 2, E - i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - ca U - per-user static route, o - ODR Gateway of last resort is not set 172.16.0.0/24 is subnetted, 11 subnets C 172.16.252.0 is directly connected, Serial0 C 172.16.253.0 is directly connected, Serial1 D 172.16.254.0 [90/2195456] via 172.16.2.253, 00:01:11, Et D 172.16.251.0 [90/2195456] via 172.16.3.253, 00:01:06, Et D 172.16.4.0 [90/307200] via 172.16.3.253, 00:01:06, Ether D 172.16.5.0 [90/2195456] via 172.16.253.253, 00:01:11, Se D 172.16.6.0 [90/2185984] via 172.16.252.253, 00:01:11, Se [90/2185984] via 172.16.253.253, 00:01:11, Se D 172.16.7.0 [90/2195456] via 172.16.252.253, 00:01:07, Se D 172.16.1.0 [90/307200] via 172.16.2.253, 00:01:11, Ether C 172.16.2.0 is directly connected, Ethernet0 C 172.16.3.0 is directly connected, Ethernet1 Drummle# Although routing loops and black holes are still a possibility with this method, the conversion should be faster and less prone to human error because the single change of administrative distance is all that is required. Another advantage of this method is that a back-out, in case of problems, is easy. The RIP processes are still in place on all the routers, so changing the administrative distances back to 70 is all that is needed to return to RIP. After the new EIGRP configuration has been tested andreturn to RIP. After the new EIGRP configuration has been tested and proven stable, the RIP processes can be deleted from all routers without further service disruptions. One thing to consider before using the dual-protocol method is the impact that running two protocols concurrently on each router will have on memory and processing. If the utilization of memory or processing or both is averaging above 50 percent to 60 percent, careful lab testing and modeling should be performed before committing to the conversion, to ensure that the routers can handle the additional load. If they can't, a more complex procedure of removing the old protocol before configuring the new protocol might be the only option. A variant on this procedure is to increase the administrative distance of the new protocol, rather than decreasing the distance of the old protocol, and then lowering the distance of the new protocol at conversion time. However, be sure to enter the distance command before any network commands so that the new protocol won't first activate at its default distance. Looking again at Table 11-1, notice that EIGRP has two default administrative distances: 90 for internal routes and 170 for external routes. Therefore, the distance command is also different for EIGRP. For example, to raise the EIGRP distance instead of lowering the RIP distance, the configuration is as displayed in Example 13-20. Example 13-20. EIGRP's internal administrative distance is raised. This could be done in all routers in Figure 13-5 rather then lowering the RIP administrative distance. router eigrp 1 network 172.16.0.0 distance eigrp 130 170 ! router rip network 172.16.0.0The keyword eigrp is added to indicate that EIGRP distances are specified. The administrative distance of internal EIGRP routes is changed to 130, and the distance of external routes is left at 170. One final note on using the dual-protocol procedure to migrate to a new routing protocol: Be sure you understand the behavior of both protocols. For example, some protocols, such as EIGRP, do not age out their route entries. Therefore, if EIGRP is being replaced, an additional step of the conversion process is to clear the route tables with the clear ip route * command after the distances have been changed. Case Study: Multiple Redistribution Points Figure 13-6 shows a network very similar to the one depicted in Figure 11-3. Recall from the associated discussion in Chapter 11 that the problem with multiple redistribution points is that administrative distances can cause routers to choose undesirable paths. In some cases, route loops and black holes can result. For example, Bumble's route table (Example 13-21) shows that it is routing to network 192.168.6.0 through Blathers, rather than using the preferable route through Monks. Figure 13-6. When mutual redistribution is performed at more than one point, as in this network, administrative distances can cause suboptimal routing, route loops, and black holes.Example 13-21. The route Bumble is using to reach to network 192.168.6.0 via Blathers (192.168.3.2) involves crossing two serial links and a token ring. Bumble#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inte N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external E1 - OSPF external type 1, E2 - OSPF external type 2, E i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - c U - per-user static route, o - ODR Gateway of last resort is not set R 192.168.1.0/24 [120/1] via 192.168.2.1, 00:00:00, Etherne C 192.168.2.0/24 is directly connected, Ethernet0 C 192.168.3.0/24 is directly connected, Serial0 O 192.168.4.0/24 [110/70] via 192.168.3.2, 00:05:09, Serial O 192.168.5.0/24 [110/134] via 192.168.3.2, 00:05:09, Seria O E2 192.168.6.0/24 [110/100] via 192.168.3.2, 00:05:09, SeriaOne solution to this problem is to use the distribute-list command to control the source of the routes at the redistribution points. The configurations of Bumble and Grimwig are displayed in Example 13-22 and Example 13-23, respectively. Example 13-22. Bumble's configuration permits only addresses in the OSPF domain to be accepted into the OSPF process and permits only addresses in the RIP domain to be accepted into the RIP process. router ospf 1 redistribute rip metric 100 network 192.168.3.1 0.0.0.0 area 0 distribute-list 1 in ! router rip redistribute ospf 1 metric 2 network 192.168.2.0 distribute-list 2 in ! ip classless access-list 1 permit 192.168.4.0 access-list 1 permit 192.168.5.0 access-list 2 permit 192.168.1.0 access-list 2 permit 192.168.6.0 Example 13-23. Grimwig's configuration permits only addresses in the OSPF domain to be accepted into the OSPF process and permits only addresses in the RIP domain to be accepted into the RIP process.router ospf 1 redistribute rip metric 100 network 192.168.5.1 0.0.0.0 area 0 distribute-list 1 in ! router rip redistribute ospf 1 metric 2 network 192.168.6.0 distribute-list 2 in ! ip classless access-list 1 permit 192.168.3.0 access-list 1 permit 192.168.4.0 access-list 2 permit 192.168.1.0 access-list 2 permit 192.168.2.0 In both configurations, access list 1 allows only addresses within the OSPF domain to be accepted by OSPF, and access list 2 allows only addresses within the RIP domain to be accepted by RIP. Example 13-24 shows Bumble's route table after the route filter has been configured. Example 13-24. After the route filters are configured, Bumble is using the preferred route to reach network 192.168.6.0. Bumble#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inte N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external E1 - OSPF external type 1, E2 - OSPF external type 2, E i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * -R 192.168.1.0/24 C 192.168.2.0/24 C 192.168.3.0/24 O 192.168.4.0/24 O 192.168.5.0/24 R 192.168.6.0/24 Bumble# [120/1] via 192.168.2.1, 00:00:12, Ethernet is directly connected, Ethernet0 is directly connected, Serial0 [110/70] via 192.168.3.2, 00:00:22, Serial0 [110/134] via 192.168.3.2, 00:00:22, Serial [120/1] via 192.168.2.1, 00:00:13, Ethernet The problem with this configuration is that it eliminates the redundancy inherent in multiple redistribution points. In Example 13-25, Bumble's Ethernet link has been disconnected. Because routes to the RIP networks are being filtered in OSPF, all those routes are now unreachable. Example 13-25. When Bumble's Ethernet link fails, the RIP networks become unreachable. The route filters prevent OSPF from entering the alternative routes into the route table. Bumble# %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0, chan Bumble#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inte N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external E1 - OSPF external type 1, E2 - OSPF external type 2, E i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - c U - per-user static route, o - ODR Gateway of last resort is not set C 192.168.3.0/24 is directly connected, Serial0 O 192.168.4.0/24 [110/70] via 192.168.3.2, 00:06:45, Serial0 O 192.168.5.0/24 [110/134] via 192.168.3.2, 00:06:45, SeriaA better approach for IPv4 is to use two forms of the distance command to set preferred routes. [5] The configurations of Bumble and Grimwig are displayed in Example 13-26 and Example 13-27, respectively. [5] IPv6 routing protocols also support the distance command to change the administrative distances. The IPv6 form of the command only has the option of changing the distance value. There are currently no options for specifying neighbor addresses or prefix-lists. Example 13-26. Bumble uses the distance configuration command to alter the administrative distance of IP routes. router ospf 1 redistribute rip metric 100 network 192.168.3.1 0.0.0.0 area 0 distance 130 distance 110 0.0.0.0 255.255.255.255 1 ! router rip redistribute ospf 1 metric 2 network 192.168.2.0 distance 130 distance 120 192.168.2.1 0.0.0.0 2 ! ip classless access-list 1 permit 192.168.4.0 access-list 1 permit 192.168.5.0 access-list 2 permit 192.168.1.0 access-list 2 permit 192.168.6.0 Example 13-27. Grimwig uses the distance command to alter the administrative distances of IP routes.alter the administrative distances of IP routes. router ospf 1 redistribute rip metric 100 network 192.168.5.1 0.0.0.0 area 0 distance 130 distance 110 0.0.0.0 255.255.255.255 1 ! router rip redistribute ospf 1 metric 2 network 192.168.6.0 distance 130 distance 120 192.168.6.1 0.0.0.0 2 ! ip classless access-list 1 permit 192.168.3.0 access-list 1 permit 192.168.4.0 access-list 2 permit 192.168.1.0 access-list 2 permit 192.168.2.0 The first distance command in both configurations sets the default distance of both OSPF and RIP routes to 130. The second distance command sets a different distance according to the advertising router specified and the referenced access list. For instance, Grimwig's RIP process assigns a distance of 120 to routes advertised by Monks (192.168.6.1) that are permitted by access list 2. All other routes are given a distance of 130. Notice that an inverse mask is used with the address of the advertising router. OSPF is more problematic. The address of the advertising router is not necessarily the interface address of the next-hop router. Rather, it is the Router ID of the router originating the LSA from which the route is calculated. Therefore, the address and inverse mask for the distance command under OSPF is 0.0.0.0 255.255.255.255, specifying any router. [6] OSPF routes from all routers that are permitted by access list 1 areassigned a distance of 110; all other routes are given a distance of 130. [6] The same "any" address can be used with RIP. A specific address was used for demonstration purposes. The result appears in Example 13-28. The first route table shows that Grimwig is routing to all networks in the OSPF domain via Duff and to all networks in the RIP domain via Monks. The normal distances of 110 for OSPF and 120 for RIP are assigned to the routes. Next, Grimwig's Ethernet connection fails. The second route table shows that all networks are now reachable via Duff. The routes to the networks in the RIP domain have a distance of 130. When the Ethernet connection is restored, the RIP advertisements from Monks, with a distance of 120, will replace the OSPF advertisements with a distance of 130. Example 13-28. Grimwig's route table before and after its Ethernet link to Monks is disconnected. Grimwig#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inte E1 - OSPF external type 1, E2 - OSPF external type 2, E i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - c U - per-user static route Gateway of last resort is not set R 192.168.1.0/24 [120/1] via 192.168.6.1, 00:00:19, Ethernet R 192.168.2.0/24 [120/1] via 192.168.6.1, 00:00:19, Ethernet O 192.168.3.0/24 [110/134] via 192.168.5.2, 00:15:06, Serial O 192.168.4.0/24 [110/70] via 192.168.5.2, 00:15:06, Serial0 C 192.168.5.0/24 is directly connected, Serial0 C 192.168.6.0/24 is directly connected, Ethernet0 Grimwig# %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0, chan Grimwig#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF intE1 - OSPF external type 1, E2 - OSPF external type 2, E i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - c U - per-user static route Gateway of last resort is not set O E2 192.168.1.0/24 [130/100] via 192.168.5.2, 00:00:08, Serial O E2 192.168.2.0/24 [130/100] via 192.168.5.2, 00:00:08, Serial O 192.168.3.0/24 [110/134] via 192.168.5.2, 00:16:23, Serial O 192.168.4.0/24 [110/70] via 192.168.5.2, 00:16:23, Serial0 C 192.168.5.0/24 is directly connected, Serial0 O E2 192.168.6.0/24 [130/100] via 192.168.5.2, 00:00:08, Serial Grimwig# If one of the serial links in Figure 13-6 fails, the opposite will happen. The networks within the OSPF domain will become reachable through the RIP domain, again with a distance of 130 (Example 13-29). However, unlike the speedy reconvergence of OSPF, the RIP side will take several minutes to reconverge. This slow reconvergence is due to RIP's split horizon at Monks. That router will not advertise the OSPF routes to Bumble or Grimwig until the same routes have ceased to be advertised from one of those routers and the existing routes have timed out. Example 13-29. Grimwig's route table before and after its serial link to Duff is disconnected. Grimwig#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inte E1 - OSPF external type 1, E2 - OSPF external type 2, E i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - c U - per-user static route Gateway of last resort is not set R 192.168.1.0/24 [120/1] via 192.168.6.1, 00:00:04, Ethernet R 192.168.2.0/24 [120/1] via 192.168.6.1, 00:00:04, Ethernet O 192.168.3.0/24 [110/134] via 192.168.5.2, 00:00:12, SeriaO 192.168.4.0/24 [110/70] via 192.168.5.2, 00:00:12, Serial0 C 192.168.5.0/24 is directly connected, Serial0 C 192.168.6.0/24 is directly connected, Ethernet0 Grimwig# %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, change %LINK-3-UPDOWN: Interface Serial0, changed state to down Grimwig#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inte E1 - OSPF external type 1, E2 - OSPF external type 2, E i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - c U - per-user static route Gateway of last resort is not set R 192.168.1.0/24 [120/1] via 192.168.6.1, 00:00:07, Ethernet R 192.168.2.0/24 [120/1] via 192.168.6.1, 00:00:07, Ethernet R 192.168.3.0/24 [130/3] via 192.168.6.1, 00:00:07, Ethernet R 192.168.4.0/24 [130/3] via 192.168.6.1, 00:00:07, Ethernet R 192.168.5.0/24 is possibly down, routing via 192.168.6.1, C 192.168.6.0/24 is directly connected, Ethernet0 Grimwig# The solution to this problem is to disable split horizon on Monks's two Ethernet interfaces with the command no ip split-horizon. Although disabling split horizon is trading some loop protection for shorter reconvergence times, it is a good trade in this case. The distance-based route filters at Bumble and Grimwig will prevent all multi-hop loops, and the split horizon function on the same two routers' Ethernet interfaces will break single-hop loops. There is another option that can assist in filtering addresses between routing protocols that are mutually redistributing routes. This is route tagging. As routes are being redistributed into a routing protocol, the routes can be tagged. The tag is a number that the administrator sets, that will uniquely identify the set of routes that have been redistributed at this router. The tag can be used at another router to filter these routesfrom being redistributed back into the originating routing protocol. Tags are set using route maps and are discussed further in Chapter 14, "Route Maps." Case Study: Using Administrative Distances to Set Router Preferences Suppose policy states that Monks in Figure 13-6 will use Grimwig as its primary gateway to the OSPF domain and route through Bumble only if Grimwig becomes unavailable. Presently, Monks is performing equal-cost load balancing between Grimwig and Bumble to reach the OSPF networks (Example 13-30). Example 13-30. Monks sees all of the networks in the OSPF domain as equidistant through Bumble and Grimwig. Monks#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inte N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external E1 - OSPF external type 1, E2 - OSPF external type 2, E i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - c U - per-user static route, o - ODR Gateway of last resort is not set C 192.168.1.0/24 is directly connected, Ethernet2 C 192.168.2.0/24 is directly connected, Ethernet0 R 192.168.3.0/24 [120/2] via 192.168.2.2, 00:00:26, Ethernet [120/2] via 192.168.6.2, 00:00:23, Ethernet R 192.168.4.0/24 [120/2] via 192.168.2.2, 00:00:26, Ethernet [120/2] via 192.168.6.2, 00:00:23, Ethernet R 192.168.5.0/24 [120/2] via 192.168.2.2, 00:00:26, Ethernet [120/2] via 192.168.6.2, 00:00:23, EtherneMonks can be configured to prefer Grimwig by lowering the distance of all routes from that router, as in Example 13-31. Example 13-31. Monks is configured to lower the administrative distance for all routes advertised from Grimwig. router rip network 192.168.1.0 network 192.168.2.0 network 192.168.6.0 distance 100 192.168.6.2 0.0.0.0 Here, the distance command makes no reference to an access list. All routes advertised by Grimwig (192.168.6.2) will be assigned an administrative distance of 100. All other routes (meaning routes from Bumble) will be assigned the default RIP administrative distance of 120. Therefore, Grimwig's routes will be preferred. Example 13-32 shows the results. The first route table shows that Monks is now routing to Grimwig only. After a failure of the connection to Grimwig, the bottom route table shows that Monks has switched to Bumble (192.168.2.2). Example 13-32. Monks's route table before and after its Ethernet link to Grimwig is disconnected. Monks#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF intN1 - OSPF NSSA external type 1, N2 - OSPF NSSA external E1 - OSPF external type 1, E2 - OSPF external type 2, E i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - c U - per-user static route, o - ODR Gateway of last resort is not set C 192.168.1.0/24 is directly connected, Ethernet2 C 192.168.2.0/24 is directly connected, Ethernet0 R 192.168.3.0/24 [100/2] via 192.168.6.2, 00:00:12, Ethernet R 192.168.4.0/24 [100/2] via 192.168.6.2, 00:00:12, Ethernet R 192.168.5.0/24 [100/2] via 192.168.6.2, 00:00:12, Ethernet C 192.168.6.0/24 is directly connected, Ethernet1 Monks# %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet1, chan Monks#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inte N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external E1 - OSPF external type 1, E2 - OSPF external type 2, E i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - c U - per-user static route, o - ODR Gateway of last resort is not set C 192.168.1.0/24 is directly connected, Ethernet2 C 192.168.2.0/24 is directly connected, Ethernet0 R 192.168.3.0/24 [120/2] via 192.168.2.2, 00:00:00, Ethernet R 192.168.4.0/24 [120/2] via 192.168.2.2, 00:00:00, Ethernet R 192.168.5.0/24 [120/2] via 192.168.2.2, 00:00:00, Ethernet R 192.168.6.0/24 [120/2] via 192.168.2.2, 00:00:00, Ethernet Monks#