Configuring Route Filters
| Route filtering is accomplished by one of the following methods :
Case Study: Filtering Specific RoutesFigure 13.2 shows a portion of an internetwork running RIPv2. Barkis is providing connectivity to the rest of the internet via Traddles. In addition to the 700 specific routes within BigNet, Traddles is advertising a 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:
Figure 13.2. A route filter at Barkis will accept only the default route from Traddles and will reject all other BigNet routes. 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. Figure 13.3 shows the resulting routing table at Barkis.
Figure 13.3. 0.0.0.0 is the only route accepted from Traddles. 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:
Here the filter configuration looks almost the same except that it is filtering outgoing routes instead of incoming routes. Figure 13.4 shows that only the default route is being advertised across the serial link from Traddles. Figure 13.4. The filter at Traddles allows only the default route to be advertised to Barkis. 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 routing 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.
In Figure 13.5, another group of routers has been connected. This internetwork 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 mis-routed into ThemNet. A black hole would exist. Figure 13.5. The internetwork ThemNet is not under the control of the BigNet administrator. To allow only the routes necessary for communication with ThemNet, Heep's configuration is:
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 may be incorrectly inserted into the routing 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 RedistributionAny time a router performs mutual redistribution, the potential for route feedback exists. For example, a route from the RIP side in Figure 13.6 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.6. 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.6 is speaking both RIP and OSPF on several interfaces. Cruncher's configuration is:
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:
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 is 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 . The small access lists shown are possible because the subnet addresses in Figure 13.6 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 following configuration allows only certain routes in Figure 13.6 to be redistributed:
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. 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 specifying which routes will be redistributed, it is not a good method for preventing route feedback. For example, consider the following configuration for Cruncher in Figure 13.6:
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. Although the distribute list under the RIP configuration will prevent the route from being advertised back into the RIP domain, the list does nothing to prevent the route from being entered into Cruncher's routing table as originating within the OSPF domain. In fact, the filter assumes that the route has already been entered into the table by OSPF. 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 MigrationThe distance command, when used without any optional parameters, specifies the administrative distance to be assigned to routes learned from a particular routing protocol. On first consideration, this action may not seem to be a route filtering function, but it is. When multiple routing protocols are running, routes are accepted or rejected based on their administrative distances. The internetwork in Figure 13.7 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 internetwork like the one in Figure 13.7, the downtime can be impractical in larger internetworks. Figure 13.7. 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 internetwork will converge to the new protocol as the routers are converted, and after the entire internetwork 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 routing tables, the internetwork 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 reconfiguration. The five routers in Figure 13.7 can be reconfigured and reconverged in a matter of minutes, so looping may not be as much of a concern here as it would be in a larger internetwork. 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:
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:
Because EIGRP has a default administrative distance of 90, the RIP routes are preferred (Figure 13.8). 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 for accuracy before the conversion. Figure 13.8. The RIP routes, which have been assigned an administrative distance of 70, are preferred over the EIGRP routes. Finally, the conversion is performed by revisiting each router and changing the RIP distance back to the default of 120. Network downtime should 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 (Figure 13.9). At 210 seconds, the RIP routes will be declared invalid (Figure 13.10), and finally the EIGRP routes will be preferred (Figure 13.11). Figure 13.9. 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. Figure 13.10. At 3.5 minutes, the RIP routes are declared down. Figure 13.11. The EIGRP routes, with their default distance of 90, replace the RIP routes. 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. Once 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 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% to 60%, careful lab testing and modeling should be performed prior to 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 may be the only option. A variant on this procedure is to increase the administrative distance of the new protocol, rather than decrease the distance of the old protocol, and then lower 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:
The 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 PointsFigure 13.12 shows an internetwork 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 routing table (Figure 13.13) shows that it is routing to network 192.168.6.0 through Blathers, rather than using the preferable route through Monks. Figure 13.12. When mutual redistribution is performed at more than one point, as in this internetwork, administrative distances can cause sub-optimal routing, route loops, and black holes. Figure 13.13. 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. One 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: Bumble
Grimwig
In both configurations, access list 1 allows only networks within the OSPF domain to be accepted by OSPF, and access list 2 allows only networks within the RIP domain to be accepted by RIP. Figure 13.14 shows Bumble's route table after the route filter has been configured. Figure 13.14. After the route filters are configured, Bumble is using the preferred route to reach network 192.168.6.0. The problem with this configuration is that it eliminates the redundancy inherent in multiple redistribution points. In Figure 13.15, Bumble's Ethernet link has been disconnected. Because routes to the RIP networks are being filtered in OSPF, all of those routes are now unreachable. Figure 13.15. 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. A better approach is to use two forms of the distance command to set preferred routes. The configurations of Bumble and Grimwig are: Bumble
Grimwig
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. [4] OSPF routes from all routers that are permitted by access list 1 are assigned a distance of 110; all other routes are given a distance of 130.
The result appears in Figure 13.16. 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 Monk, with a distance of 120, will replace the OSPF advertisements with a distance of 130. Figure 13.16. Grimwig's route table, before and after its Ethernet link to Monks is disconnected. If one of the serial links in Figure 13.12 fails, the opposite will happen. The networks within the OSPF domain will become reachable through the RIP domain, again with a distance of 130 (Figure 13.17). 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. Figure 13.17. Grimwig's route table, before and after its serial link to Duff is disconnected. The solution to this problem is to disable split horizon on Monk'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. 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. Case Study: Using Distances to Set Router PreferencesSuppose policy states that Monks in Figure 13.12 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 (Figure 13.18). Figure 13.18. Monks sees all of the networks in the OSPF domain as equidistant through Bumble and Grimwig. Monks can be configured to prefer Grimwig by lowering the distance of all routes from that router:
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. Figure 13.19 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). Figure 13.19. Monks' route table, before and after its Ethernet link to Grimwig is disconnected. |
![Routing TCP[s]IP (Vol. 11998)](/icons/blank_book.jpg "Routing TCP[s]IP (Vol. 11998)"){kind=icon}