IPv6: Route Control - Route Redistribution
Principles of Redistribution The capabilities of the IP routing protocols vary widely. The protocol characteristics that have the most bearing on redistribution are the differences in metrics and administrative distances, and each protocol's classful or classless capabilities. Failure to give careful consideration to these differences when redistributing can lead to, at best, a failure to exchange some or all routes or, at worst, routing loops and black holes. Metrics The routers of Figure 11-1 are redistributing static routes into OSPF, which then advertises the routes to other OSPF-speaking routers. Static routes have no metric associated with them, but every OSPF route must have a cost. Another example of conflicting metrics is the redistribution of RIP routes into EIGRP. RIP's metric is hop count, whereas EIGRP uses bandwidth and delay. In both cases, the protocol into which routes are redistributed must be able to associate its own metrics with those routes. So the router performing the redistribution must assign a metric to the redistributed routes. Figure 11-2 shows an example. Here EIGRP is being redistributed into OSPF, and OSPF is being redistributed into EIGRP. OSPF does not understand the composite metric of EIGRP, and EIGRP does not understand OSPF cost. As a result, part of the redistribution process is that the router must assign a cost to each EIGRP route before passing it to OSPF. Likewise, the router must assign a bandwidth, delay, reliability, load, and MTU to each OSPF route before passing it to EIGRP. If incorrect metrics are assigned, redistribution will fail. Figure 11-2. When routes are redistributed, a metric that is understandable to the receiving protocol must be assigned to the routes.Case studies later in this chapter show how to configure routers to assign metrics for purposes of redistribution. Administrative Distances The diversity of metrics presents another problem: If a router is running more than one routing protocol and learns a route to the same destination from each of the protocols, which route should be selected? Each protocol uses its own metric scheme to define the best route. Comparing routes with different metrics, such as cost and hop count, is like comparing apples and oranges. The answer to the problem is administrative distances. Just as metrics are assigned to routes so that the most preferred route may be determined, administrative distances are assigned to route sources so that the most preferred source may be determined. Think of an administrative distance as a measure of believability. The lower the administrative distance, the more believable the protocol. For example, suppose a router running RIP and EIGRP learns of a route to network 192.168.5.0 from a RIP-speaking neighbor and another route to the same destination from an EIGRP-speaking neighbor. Because ofto the same destination from an EIGRP-speaking neighbor. Because of EIGRP's composite metric, that protocol is more likely to have determined the optimum route. Therefore, EIGRP should be believed over RIP. Table 11-1 shows the default Cisco administrative distances. EIGRP has an administrative distance of 90, whereas RIP has an administrative distance of 120. Therefore, EIGRP is deemed more trustworthy than RIP. Table 11-1. Cisco default administrative distances. Route Source Administrative Distance Connected interface [*] 0 Static route 1 EIGRP summary route 5 External BGP 20 EIGRP 90 IGRP 100 OSPF 110 IS-IS 115 RIP 120 EGP 140 External EIGRP 170 Internal BGP 200 Unknown 255Unknown 255 [*] Recall from Chapter 3, "Static Routing," that when a static route refers to an interface instead of a next-hop address, the destination is considered to be a directly connected network. Although administrative distances help resolve the confusion of diverse metrics, they can cause problems for redistribution. For example, in Figure 11-3, both Gehrig and Ruth are redistributing RIP-learned routes into IGRP. Gehrig learns about network 192.168.1.0 via RIP and advertises the network into the IGRP domain. As a result, Ruth learns about network 192.168.1.0 not only from Combs via RIP, but also from Meusel via IGRP. Figure 11-3. Network 192.168.1.0 is being advertised to Ruth via both RIP and IGRP.Example 11-1 shows Ruth's route table. Notice that the route to 192.168.1.0 is an IGRP route. Ruth has chosen the IGRP route because, compared to RIP, IGRP has a lower administrative distance. Ruth will send all packets to 192.168.1.0 over the "scenic route" through Meusel, instead of sending them directly to Combs. Example 11-1. Although the optimal route to network 192.168.1.0 from Ruth is through Combs, out S0, Ruth is instead routing to that network through Meusel, out S1. Ruth#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 I 192.168.1.0/24 [100/16100] via 192.168.5.1, 00:00:00, Seri I 192.168.2.0/24 [100/12576] via 192.168.5.1, 00:00:00, Seri I 192.168.3.0/24 [100/12476] via 192.168.5.1, 00:00:01, Seri I 192.168.4.0/24 [100/10476] via 192.168.5.1, 00:00:01, Seri C 192.168.5.0/24 is directly connected, Serial1 C 192.168.6.0/24 is directly connected, Serial0 Ruth# Split horizon prevents a routing loop in the network of Figure 11-3. Both Gehrig and Ruth initially advertise subnet 192.168.1.0 into the IGRP domain, and the four IGRP routers eventually converge on a single path to that subnet. However, the convergence is unpredictable. This condition can be seen by rebooting routers Lazzeri and Meusel. After the reboot, Ruth's route table shows that it is using Combs as the next-hop router toreach 192.168.1.0 (Example 11-2). Example 11-2. The convergence of the network in Figure 11-3 is unpredictable. After a reboot of the routers, Ruth is now routing to 192.168.1.0 through Combs. Ruth#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.2, 00:00:23, Serial0 I 192.168.2.0/24 [100/12576] via 192.168.5.1, 00:00:22, Seri I 192.168.3.0/24 [100/12476] via 192.168.5.1, 00:00:22, Seri I 192.168.4.0/24 [100/10476] via 192.168.5.1, 00:00:22, Seri C 192.168.5.0/24 is directly connected, Serial1 C 192.168.6.0/24 is directly connected, Serial0 Ruth# Convergence after the reboot is not only unpredictable but also slow. Example 11-3 shows Gehrig's route table approximately three minutes after the reboot. It is using Lazzeri as a next-hop router to subnet 192.168.1.0, but pings to a working address on that link fail. Lazzeri's route table (Example 11-4) shows the problem: Lazzeri is using Gehrig as a next-hop router. A routing loop exists. Example 11-3. Soon after the reboot, Gehrig is routing packets to 192.168.1.0 via Lazzeri. Gehrig#show ip routeCodes: 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 I 192.168.1.0/24 [100/16100] via 192.168.3.2, 00:02:38, Seri C 192.168.2.0/24 is directly connected, Ethernet0 C 192.168.3.0/24 is directly connected, Serial0 I 192.168.4.0/24 [100/10476] via 192.168.3.2, 00:00:29, Seri I 192.168.5.0/24 [100/12476] via 192.168.3.2, 00:00:29, Seri I 192.168.6.0/24 [100/14476] via 192.168.3.2, 00:00:39, Seri Gehrig#ping 192.168.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 sec ..... Success rate is 0 percent (0/5) Gehrig# Example 11-4. Lazzeri is routing packets to 192.168.1.0 via Gehrig, creating a routing loop. Notice the age of the route. Lazzeri#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 I 192.168.1.0/24 [100/12100] via 192.168.3.1, 00:04:21, Seri I 192.168.2.0/24 [100/8576] via 192.168.3.1, 00:00:33, SeriaC 192.168.4.0/24 is directly connected, Serial1 I 192.168.5.0/24 [100/10476] via 192.168.4.2, 00:00:53, Seri I 192.168.6.0/24 [100/12100] via 192.168.3.1, 00:02:32, Seri Lazzeri# Here's the sequence of events leading to the loop: 1. While Lazzeri and Meusel are rebooting, both Gehrig and Ruth have route table entries showing network 192.168.1.0 as reachable via Combs. 2. As Lazzeri and Meusel become active, both Gehrig and Ruth send IGRP updates that include subnet 192.168.1.0. Simply by the "luck of the draw," Ruth sends its update slightly earlier than Gehrig does. 3. Meusel, receiving Ruth's update, makes Ruth the next-hop router and sends an update to Lazzeri. 4. Lazzeri, receiving Meusel's update, makes Meusel the next-hop router. 5. Lazzeri and Gehrig send updates to each other at about the same time. Lazzeri makes Gehrig the next-hop router to 192.168.1.0 because its route is metrically closer than Meusel's route. Gehrig makes Lazzeri the next-hop router to 192.168.1.0 because its IGRP advertisement has a lower administrative distance than Combs RIP advertisement. The loop is now in effect. Split horizon and the invalid timers will eventually sort things out. Lazzeri is advertising 192.168.1.0 to Meusel, but Meusel continues to use the metrically closer route via Ruth. And since Ruth is the next-hop router, split horizon is in effect for 192.168.1.0 at Meusel's S1 interface. Meusel is also advertising 192.168.1.0 to Lazzeri, but Lazzeri sees Gehrig as metrically closer. Lazzeri and Gehrig see each other as the next-hop router to 192.168.1.0,so they will not advertise the route to each other. The route will age in both of their route tables until the invalid timer expires (Example 11-5). Example 11-5. When the invalid timer for the route to 192.168.1.0 expires, the route is declared unreachable and the holddown timer is started. Lazzeri#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 I 192.168.1.0/24 is possibly down, routing via 192.168.3.1, I 192.168.2.0/24 [100/8576] via 192.168.3.1, 00:00:57, Seria C 192.168.3.0/24 is directly connected, Serial0 C 192.168.4.0/24 is directly connected, Serial1 I 192.168.5.0/24 [100/10476] via 192.168.4.2, 00:01:25, Seri I 192.168.6.0/24 is possibly down, routing via 192.168.3.1, Lazzeri# When Lazzeri's invalid timer expires, the route to 192.168.1.0 will be put into holddown. Although Meusel is advertising a route to that network, Lazzeri cannot accept it until the holddown timer expires. Example 11-6 shows that Lazzeri has finally accepted the route from Meusel, and Example 11-7 shows that Gehrig is successfully reaching 192.168.1.0 through Lazzeri. It took more than nine minutes for these two routers to converge, and the route they are using is still not the optimal route. Example 11-6. After the holddown timer for 192.168.1.0 expires, Lazzeri accepts the route advertised by Meusel.Lazzeri#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 I 192.168.1.0/24 [100/14100] via 192.168.4.2, 00:00:27, Seri I 192.168.2.0/24 [100/8576] via 192.168.3.1, 00:00:02, Seria C 192.168.3.0/24 is directly connected, Serial0 C 192.168.4.0/24 is directly connected, Serial1 I 192.168.5.0/24 [100/10476] via 192.168.4.2, 00:00:28, Seri I 192.168.6.0/24 [100/12476] via 192.168.4.2, 00:00:28, Seria Lazzeri# Example 11-7. Gehrig can now reach subnet 192.168.1.0 via Lazzeri. Gehrig#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 I 192.168.1.0/24 [100/16100] via 192.168.3.2, 00:00:32, Seri C 192.168.2.0/24 is directly connected, Ethernet0 C 192.168.3.0/24 is directly connected, Serial0 I 192.168.4.0/24 [100/10476] via 192.168.3.2, 00:00:33, Seri I 192.168.5.0/24 [100/12476] via 192.168.3.2, 00:00:33, Seri I 192.168.6.0/24 [100/14476] via 192.168.3.2, 00:00:33, SeriType escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 sec !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 52/ Gehrig# Administrative distances can cause even worse problems than the sub- optimal routes, unpredictable behavior, and slow convergence of the previous example. For example, Figure 11-4 shows essentially the same network as in Figure 11-3, except that the links between the IGRP routers are Frame Relay PVCs. By default, IP split horizon is turned off on Frame Relay interfaces. As a result, permanent routing loops will form between Lazzeri and Gehrig and between Meusel and Ruth. Subnet 192.168.1.0 is unreachable from the IGRP domain. Figure 11-4. Because IP split horizon is turned off by default on Frame Relay interfaces, permanent routing loops will form in this network.Several tools and strategies exist to prevent routing loops when redistributing. The administrative distances can be manipulated, and route filters or route maps can be used. Chapter 13 covers route filters, and Chapter 14 covers route maps. These chapters also demonstrate techniques for changing administrative distances. Redistributing from Classless to Classful Protocols Careful consideration must be given to the effects of redistributing routes from a classless routing process domain into a classful domain. To understand why, it is necessary to first understand how a classful routing protocol reacts to variable subnetting. Recall from Chapter 5, "Routing Information Protocol (RIP)," that classful routing protocols do not advertise a mask with each route. For every route a classful router receives, one of two situations will apply: The router will have one or more interfaces attached to the major network. The router will have no interfaces attached to the major network. In the first case, the router must use its own configured mask for that major network to correctly determine the subnet of a packet's destination address. In the second case, only the major network address itself can be included in the advertisement because the router has no way of knowing which subnet mask to use. Figure 11-5 shows a router with four interfaces connected to subnets of 192.168.100.0. The network is variably subnettedtwo interfaces have 27- bit masks, and two interfaces have 30-bit masks. If the router is running a classful protocol such as IGRP, it cannot use the 27-bit mask to derive30-bit subnets, and it cannot use the 30-bit mask to derive 27-bit subnets. So, how does the protocol cope with the conflicting masks? Figure 11-5. If this router is running a classful routing protocol, what mask should it choose? In Example 11-8, debugging is used to observe the IGRP advertisements sent by the router in Figure 11-5. Notice that subnet 192.168.100.128/27 is advertised out interface E0, which has a 27-bit mask, but neither 192.168.100.4/30 nor 192.168.100.8/30 is advertised out that interface. Similarly, 192.168.100.8/30 is advertised out interface S1, which has a 30-bit mask, but neither 192.168.100.96/27 nor 192.168.100.128/27 is advertised out that interface. The same situation applies to all four interfaces. Only subnets of 192.168.100.0 whose masks match the interface mask are advertised. As a result, IGRP-speaking neighbors on interfaces E0 and E1 will have no knowledge of the 30-bit subnets, and IGRP-speaking neighbors on interfaces S0 and S1 will have no knowledge of the 27-bit subnets. Example 11-8. A classful routing protocol will not advertise routes between interfaces whose masks do not match. O'Neil#debug ip igrp transactions IGRP protocol debugging is onO'Neil# IGRP: sending update to 255.255.255.255 via subnet 192.168.100.128, metric=1100 IGRP: sending update to 255.255.255.255 via subnet 192.168.100.96, metric=1100 IGRP: sending update to 255.255.255.255 via subnet 192.168.100.4, metric=8476 IGRP: sending update to 255.255.255.255 via subnet 192.168.100.8, metric=8476 O'Neil# Ethernet0 (192.168. Ethernet1 (192.168. Serial0 (192.168.10 Serial1 (192.168.10 This behavior of only advertising routes between interfaces with matching masks also applies when redistributing from a classless routing protocol into a classful routing protocol. In Figure 11-6, the subnets of the OSPF domain are variably subnetted, and Paige is redistributing OSPF-learned routes into IGRP. Figure 11-6. Paige is redistributing its OSPF-learned routes into IGRP. As Example 11-9 shows, Paige knows about all of the subnets in both the OSPF and the IGRP domain. And because OSPF is classless, the router knows which masks are associated with each subnet connected to Gibson. Paige's IGRP process is using a 24-bit mask; therefore, 172.20.113.192/26 and 172.20.114.48/28 are not compatible and are not advertised (Example 11-10). Notice that IGRP does advertise172.20.112.0/24 and 172.20.115.0/24. The result is that the only subnets within the OSPF domain that Leonard knows of are the ones with a 24-bit mask (Example 11-11). Example 11-9. Paige knows about all six subnets of Figure 11-6, either from OSPF, IGRP, or a direct connection. Paige#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.20.0.0/16 is variably subnetted, 6 subnets, 3 masks O 172.20.113.192/26 [110/74] via 172.20.112.1, 00:01:35, C 172.20.112.0/24 is directly connected, Ethernet1 O 172.20.115.0/24 [110/80] via 172.20.112.1, 00:01:35, Et I 172.20.110.0/24 [100/1600] via 172.20.111.1, 00:00:33, C 172.20.111.0/24 is directly connected, Ethernet0 O 172.20.114.48/28 [110/74] via 172.20.112.1, 00:01:35, E Paige# Example 11-10. Only the OSPF-learned routes with a 24-bit mask are successfully redistributed into the IGRP domain, which is also using a 24-bit mask. Paige#debug ip igrp transactions IGRP protocol debugging is on Paige# IGRP: received update from 172.20.111.1 on Ethernet0subnet 172.20.110.0, metric 1600 (neighbor 501) IGRP: sending update to 255.255.255.255 via Ethernet0 (172.20.1 subnet 172.20.112.0, metric=1100 subnet 172.20.115.0, metric=1100 Paige# Example 11-11. The only subnets within the OSPF domain known at Leonard are the ones with a 24-bit mask. 172.20.113.192/26 and 172.20.114.48/28 are unreachable from here. Leonard#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.20.0.0/24 is subnetted, 4 subnets I 172.20.112.0 [100/1200] via 172.20.111.2, 00:00:48, Eth I 172.20.115.0 [100/1200] via 172.20.111.2, 00:00:48, Eth C 172.20.110.0 is directly connected, Ethernet0 C 172.20.111.0 is directly connected, Ethernet1 Leonard# The configuration section includes case studies that demonstrate methods for reliably redistributing from a classless routing protocol to a classful routing protocol.