Configuring Redistribution
| Redistribution is configured in two steps:
For example, the IGRP configuration of Paige in Figure 11.14 is:
This configuration redistributes routes discovered by OSPF process 1 into IGRP process 1. The metric portion of the command assigns IGRP metrics to the routes. In order, the numbers specify:
The OSPF configuration of Paige is:
This configuration redistributes routes discovered by IGRP process 1 into OSPF process 1. The metric portion of the command assigns an OSPF cost of 30 to each redistributed route. The redistribution makes Paige an ASBR in the OSPF domain, and the redistributed routes are advertised as external routes. The metric-type portion of the command specifies that the external type of the routes is E1. The subnets keyword, used only when redistributing routes into OSPF, specifies that subnet details will be redistributed. Without it, only major network addresses are redistributed. More will be said about the subnets keyword in the case studies. An alternative method of specifying the metrics to be assigned to redistributed routes is to use the default-metric command. For example, the previous OSPF configuration can also be written as follows :
The results of this configuration are exactly the same as the previous configuration. The default-metric command is useful when routes are being redistributed from more than one source. For example, suppose router Paige in Figure 11.14 was running not only IGRP and OSPF but also RIP and EIGRP. The OSPF configuration might be:
Here an OSPF cost of 30 will be assigned to all IGRP-, RIP- and EIGRP-learned routes. The two methods of assigning metrics can also be used with each other. For example, suppose Paige were to be configured to redistribute OSPF, RIP, and EIGRP into IGRP, but that RIP routes were to be advertised with a different set of metrics than the OSPF and EIGRP routes. The configuration might be:
Note Default metric quantities for redistribution The metrics assigned using the metric keyword with the redistribute command take precedence over metrics assigned with the default-metric command. RIP-learned routes will be advertised into IGRP with the metrics specified on the redistribute rip line, and the OSPF- and EIGRP-learned routes will be advertised with the metrics specified by the default-metric command. If neither the metric keyword nor the default-metric command specifies a metric, the metric will default to 20 for routes redistributed into OSPF and to 0 for routes redistributed into other protocols. The 0 metric will be understood by IS-IS, but not by RIP, whose hop count must be between 1 and 16. The 0 metric is also incompatible with the IGRP and EIGRP multi-metric format. These three protocols must have the appropriate metrics assigned to any redistributed routes, or redistribution will not work. The following case studies examine techniques for configuring redistribution into the various IP IGPs. In addition, they are arranged so that the more generic issues of redistributing classful to classful, classless to classless, and classless to classful can be examined. Case Study: Redistributing IGRP and RIPIn the internetwork of Figure 11.18, Ford is running IGRP, and Berra is running RIP. Mantle's routing configuration is:
Figure 11.18. Ford is running IGRP, and Berra is running RIP. Mantle is performing redistribution. Both methods of assigning metrics are used here for demonstration purposes. In most cases, a redistribution scheme as simple as this will use one method or the other. Notice that Mantle is also connected to a stub network (192.168.10.0/24). In this case, the stub network should be advertised into the IGRP domain, but not into the RIP domain. One way to accomplish this configuration is to simply add the appropriate network statement under IGRP. However, doing so will create unnecessary IGRP broadcasts on the stub network. Another way to achieve the desired configuration is to use redistribution:
The redistribute connected command will redistribute all directly connected networks. If network 192.168.10.0/24 is to be advertised into the IGRP domain and the RIP domain, the configuration is:
Case Study: Redistributing EIGRP and OSPFThe internetwork of Figure 11.19 has an OSPF domain and two EIGRP domains. Router Hodges is running OSPF process 1. Podres is running EIGRP process 1, and EIGRP process 2 is running on Snider and Campanella. Robinson has the following configuration:
Figure 11.19. Hodges is running OSPF, and Podres is running EIGRP 1. Snider and Campanella are running EIGRP 2. Notice that although redistribution must be configured between the EIGRP processes, no metrics are configured. The processes use the same metrics, so the metrics can be tracked accurately across the redistribution boundary. Figure 11.20 shows Podres' routing table. The redistributed routes are tagged as EIGRP external routes. Figure 11.20. The routing table of Podres in Figure 11.19. Figure 11.21 shows Hodges' routing table, which has some problems. Recall from Chapter 9, "Open Shortest Path First," that routes redistributed into OSPF are either type 1 (E1) or type 2 (E2) external routes. The only route that seems to have been redistributed, indicated by the E2 tag, is the major network address 192.168.2.0/24. The reason for this is the absence of the subnets keyword in Robinson's redistribution statements. Without this keyword, only major network addresses that are not directly connected to the redistributing router will be redistributed. Figure 11.21. The routing table of Hodges contains only a single redistributed route, indicated by the E2 tag. Robinson's configuration is changed to include the subnets keyword:
As a result of this change, all subnets in Figure 11.19 are in Hodges' routing table (Figure 11.22). Figure 11.22. After the subnets keyword is added to Robinson's redistribution configuration, Hodges has knowledge of all subnets. By default, external routes are redistributed into OSPF as type 2 routes. As discussed in Chapter 9, E2 routes include only the external cost of the route. This fact can be important when a single destination is reachable by more than one external route, as shown in Figure 11.23. In this internetwork, one router is redistributing the route to 10.2.3.0/24 with a cost of 50, and the other router is redistributing a different route to the same destination with a cost of 100. If the routes are advertised as E2, the costs of the links within the OSPF domain will not be added. As a result, the router internal to the OSPF domain will choose route 1 to reach 10.2.3.0/24. Figure 11.23. If the routes to 10.2.3.0/24 are advertised as E2, route 1 will have a cost of 50 and route 2 will have a cost of 100. If the routes are advertised as E1, route 1 will have a cost of 150 and route 2 will have a cost of 110. If the routes to 10.2.3.0/24 in Figure 11.23 are redistributed as E1, the costs of the links within the OSPF domain will be added to the redistributed costs. As a result, the router internal to the OSPF domain would choose route 2, with a cost of 110 (100 + 10) over route 1, with a cost of 150 (50 + 100). Robinson, in Figure 11.19, is redistributing EIGRP 1 with a cost of 50 and redistributing EIGRP 2 with a cost of 100. Figure 11.22 shows that, at Hodges, the routes to the EIGRP 1 subnets still have a cost of 50, and the routes to the EIGRP 2 subnets still have a cost of 100. The cost of the Ethernet link between Hodges and Robinson has not been added to the routes. To redistribute routes into OSPF as E1, the keyword metric-type 1 is added to the redistribution command. In the following configuration, Robinson continues to redistribute EIGRP 1 as E2, but EIGRP 2 is redistributed as E1:
Figure 11.24 shows Hodges' routing table after Robinson is reconfigured. All the routes to destinations within the EIGRP 1 domain still have a cost of 50, but the routes to destinations within the EIGRP 2 domain now have a cost of 110 (the redistributed cost plus the default cost of 10 for the Ethernet link between Robinson and Hodges). Figure 11.24. Robinson's configuration has been changed so that the subnets of 192.168.4.0 and 172.16.0.0 are being advertised as type 1 external routes. Case Study: Redistribution and Route SummarizationCisco's EIGRP, OSPF, and IS-IS implementations have the capability to summarize redistributed routes. This case study examines summarization for EIGRP and OSPF; the following case study examines IS-IS summarization. The first thing to note is that summarization is useful only if the IP subnet addresses have been planned for summarization. For example, the subnets of 192.168.3.0 within the OSPF domain in Figure 11.19 all fall under the summary address 192.168.3.0/25. The subnets of the same major address within the EIGRP 1 domain all fall under the summary address 192.168.3.128/25. If subnet 192.168.3.0/27 were to be connected to Podres, that single destination would have to be advertised separately from the summary address. Although advertising such a single destination will have little adverse impact, advertising a large number of subnets outside of the range of the summary address will reduce the benefits of summarization. The command summary-address specifies a summary address and mask to an OSPF process. Any more-specific subnet addresses that fall within the range of the specified summary address will be suppressed. Note that this command is used only to summarize external routes at ASBRs; summarization of internal OSPF routes at ABRs is accomplished with the area range command, as discussed in Chapter 9. At Robinson in Figure 11.19, the EIGRP 1 subnets are summarized into the OSPF domain with 192.168.3.128/25, and the EIGRP 2 subnets are summarized with 172.16.0.0/16:
Compare Figure 11.25 with Figure 11.24. In Figure 11.25, Hodges' routing table contains the specified summary addresses. The subnet addresses within the summary range have been suppressed at the redistribution point. Notice, also, that no summarization was configured for 92.168.4.0/24, so the subnets of that major address are still in the routing table. Figure 11.25. Robinson is summarizing 192.168.3.128/25 and 172.16.0.0/26, so no more-specific subnets within those ranges appear in the routing table of Hodges. Summarization for EIGRP is interface-specific. That is, instead of specifying the summary address and mask under the routing process, they are specified under individual interfaces. This system provides the flexibility to advertise different summary routes out different interfaces of the same process. The command ip summary-address eigrp process-id specifies the summary address and mask and the EIGRP process into which the summary is to be advertised. In the following configuration, Robinson will advertise summary addresses 192.168.3.0/25, 172.16.0.0/16, and 192.168.4.0/24 into EIGRP 1:
Figure 11.26 shows the routing table of Podres. As with OSPF summarization, EIGRP summarization suppresses the advertisement of subnets within the summary range. Unlike OSPF, Podres' routing table shows that summary routes advertised into EIGRP are not tagged as external routes. Figure 11.26. The routing table of Podres, showing summary routes 192.168.3.0/25, 192.168.4.0/24, and 172.16.0.0/16. Robinson is advertising EIGRP summary routes of 192.168.3.0/24 to Campanella and 192.168.0.0/16 to Snider. Figure 11.27 shows Campanella's routing table, and Figure 11.28 shows Snider's routing table. Figure 11.27. Campanella's routing table after summarization is configured at Robinson. Figure 11.28. Snider's routing table after summarization is configured at Robinson. A point of interest in Snider's routing table is the entry for 192.168.4.0/24. You might expect this route to be suppressed by the summary address of 192.168.0.0/16. However, 192.168.4.0/24 is internal to the EIGRP 2 process domain; the summarization applies only to routes being redistributed into the process domain. Looking again at Figure 11.26, notice the entry for the summary route 192.168.3.128/25. This entry may surprise you because that summary address is advertised into OSPF, not EIGRP. Notice also that the route is marked as an external route, indicating that it was redistributed into the EIGRP domain. What has happened is that the summary route was advertised into OSPF and was then redistributed back into EIGRP from the OSPF domain. Hence the unexpected entry at Podres. Now suppose subnet 192.168.3.192/27 were to become inaccessible. Podres would forward packets destined for that subnet to the less-specific route 192.168.3.128/25. The packet would be sent into the OSPF domain, where you might expect the summary route 192.168.3.128/25 to cause the packet to be sent right back to Podres. Note Using null interfaces to protect against routing loops caused by summarization. In fact, this situation will not occur. Robinson's routing table (Figure 11.29) has numerous entries for summary routes that show interface Null0 as a connected interface. The null interface is a software-only interface to nowhere ”packets routed to it are dropped. With some exceptions [3] , whenever a router generates a summary address, the router will also create a route for that address that goes to the null interface. If Robinson receives a packet destined for 192.168.3.192/27 and that subnet is no longer reachable, the router will forward the packet to the null interface. The routing loop is broken in one hop.
Figure 11.29. Robinson's routing table. Because the router is originating many summary routes, there are many entries for summaries whose connected interface is Null0. This is a safeguard against routing loops. Summary routes to null interfaces are very helpful for preventing loops, and their use is described in greater detail in Chapter 12, "Default Routes and On-Demand Routing." However, the redistribution of incorrect routing information should not be allowed to happen at all. Suppose that instead of being one hop away from Robinson, Podres is 10 hops away. The misdirected packet would have to travel a long way before being dropped. This example demonstrates the need to carefully regulate route advertisements when using mutual redistribution ”that is, when two routing protocols are redistributing their routes into each other. In such cases the use of route filters, described in Chapter 13, or route maps, as described in Chapter 14, is essential. The previous scenario also demonstrates the trade-off of using summarization. Although the size of the routing table is reduced, saving memory and processor cycles, route precision is also reduced. As the internetwork grows more complex, that loss of detail increases the possibility of routing errors. Case Study: Redistributing IS-IS and RIPIn the internetwork of Figure 11.30, Aaron is running IS-IS, Williams is running RIPv1, and Mays is redistributing. Mays' IS-IS configuration is:
Figure 11.30. Router Mays is redistributing RIP into IS-IS and IS-IS into RIP. Routes may be redistributed into IS-IS as either internal or external routes (internal is the default) and as either level 1 or level 2 routes (level 2 is the default). In the example shown, the RIP routes are redistributed as internal, level 2 routes with the default metric of 0. Figure 11.31 shows the redistributed routes in Aaron's routing table. Figure 11.31. Aaron's routing table shows the redistributed RIP routes. Since the RIP routes are external to the IS-IS routing domain, it is best to reflect this by having them redistributed into the domain as external routes:
Figure 11.32 shows Aaron's routing table after the change. The only change from Figure 11.31 is that the metrics of the redistributed routes have increased to greater than 64, indicating (in this small internetwork) external routes. Figure 11.32. The metrics of the routes to 10.2.1.0/24 and 10.2.2.0/24 change to 138 after the routes are advertised as external. Another look at Figure 11.30 shows that both subnets of the RIP domain can be summarized with a single address of 10.2.0.0/16. Route summarization into IS-IS is configured with the same summary-address command that is used with OSPF. However, the level into which the summary is being sent must also be specified. In the following configuration, RIP routes are redistributed as level 1 and summarized:
Figure 11.33 shows the summary route in Aaron's routing table. Like OSPF and EIGRP, the summarization causes more-specific routes in the summary range to be suppressed. Figure 11.33. Aaron's routing table with a summary route to the subnets within the RIP domain. When IS-IS is redistributed into another protocol, the route level to be redistributed must be specified. In the examples shown so far, both level 1 and level 2 routes have been specified to be redistributed into RIP. Case Study: Redistributing Static RoutesFigure 11.34 shows the routing table of Williams in Figure 11.30. Notice that subnets 10.1.2.160/28 and 10.1.2.224/28 are missing; their subnet masks are inconsistent with the 24-bit mask configured on Mays' E1 interface, so the routes have not been included in the RIP updates sent out that interface. This scenario again illustrates the problem of redistributing variably subnetted routes from a classless protocol into a classful protocol, as discussed earlier in this chapter. Figure 11.34. The routes with subnets other than /24 are not redistributed into the RIP domain. A solution to this problem is to summarize the two 28-bit subnets with a single 24-bit address of 10.1.2.0/24. RIP does not have a summarization command, so the way to accomplish summarization is to configure a static route to the summary address and then redistribute that route into RIP:
Figure 11.35 shows Williams' routing table with the summary route included. Figure 11.35. Subnets 10.1.2.160/28 and 10.1.2.224/28 have been summarized with the address 10.1.2.0/24. As discussed in Chapter 3, "Static Routing," a variant of the static route is an entry that points to an outgoing interface instead of a next -hop address. These static routes can also be redistributed, but the configuration is somewhat different. For example, the configuration of Mays can be:
Here the static route now points to Mays' E0 interface instead of to the next-hop address 10.1.4.1. Also, the redistribute static command is no longer used under the RIP configuration, yet Williams' routing table still looks the same as in Figure 11.35. The reason this static route still gets redistributed is that when a static route points to an outgoing interface, the destination is considered by the router to be directly connected (Figure 11.36). And because a network statement for 10.0.0.0 appears under the RIP configuration, RIP will advertise this "directly connected" subnet of 10.0.0.0. Figure 11.36. Mays considers the summary address 10.1.2.0/24 to be directly connected to Ethernet 0. Suppose Williams receives a packet with a destination address of 10.1.2.5. The summary address of 10.1.2.0/24 will be matched, and the packet will be forwarded to Mays. At Mays, the destination address does not match a more-specific subnet, and therefore will match the static route. Mays will send ARP requests out E0 in an attempt to find host 10.1.2.5 (or a router that will send a Proxy ARP reply). Finding none, the router does not know what to do with the packet. An ICMP Destination Unreachable message will not be sent to the originator. Note Null interfaces should be configured in conjunction with static summary routes. Recall that when the summarization commands are used, they create an entry in the routing table to Null 0. The same can and should be done with static summary routes:
Now any destination address that doesn't find a more-specific match at Mays will be routed to the null interface and dropped, and an ICMP Destination Unreachable message will be sent to the originator. |
![Routing TCP[s]IP (Vol. 11998)](/icons/blank_book.jpg "Routing TCP[s]IP (Vol. 11998)"){kind=icon}
- The Second Wave ERP Market: An Australian Viewpoint
- Context Management of ERP Processes in Virtual Communities
- Intrinsic and Contextual Data Quality: The Effect of Media and Personal Involvement
- A Hybrid Clustering Technique to Improve Patient Data Quality
- Relevance and Micro-Relevance for the Professional as Determinants of IT-Diffusion and IT-Use in Healthcare