Chapter 11, “Route Redistribution,” presents several situations in which redistribution causes unwanted or inaccurate routes to exist in a particular router. For instance, in Figure 11-3 and the associated discussion, one or more routers choose a suboptimal route through a network. The problem in that example is that the routers prefer the lower administrative distance of Interior Gateway routing Protocol (IGRP) to the administrative distance of Routing Information Protocol (RIP). More generally, any time routes to the same destination are being redistributed into a routing domain by more than a single router, the potential for inaccurate routing exists. In some cases, routing loops and black holes might occur.
Example 11-17 shows another example of an unwanted or unexpected route. In this case, the summary route 192.168.3.128/25 is advertised into Open Shortest Path First (OSPF) but is redistributed into the EIGRP domain—where the summarized subnets exist. This phenomenon, in which a route is advertised in the wrong direction across a redistributing router, is called route feedback.
Route filtering enables the network administrator to keep tight control over route advertisements. Any time a router is redistributing routes from one protocol to another, route filters give the network administrator the power to control what routes are redistributed. And any time a router is performing mutual redistribution—the mutual sharing of routes between two or more routing protocols—route filters should be used to ensure that routes are advertised in only one direction.
Figure 13-1 shows another use for route filters. Here, a routing domain is broken into subdomains, each containing multiple routers. The router connecting the two domains is filtering routes so that the routers in subdomain B know only a subset of the routes in subdomain A. This filtering might be done for security, so that the B routers only recognize authorized subnets. Or the filtering might be a part of a larger traffic-engineering plan, to manage the flow of packets. Or it might be done simply to manage the size of the route tables and updates of the B routers by eliminating unnecessary routes.
Figure 13-1. Route filters can be used to create routing subdomains, into which only some of the routing domain’s addresses are advertised.
Yet another common use of route filters is to create a “route firewall.” Frequently, corporate divisions or government agencies must be interconnected while they remain under separate administrative control. If you do not have control of all parts of the network, you are vulnerable to misconfigured or even malicious routing. Route filters at the interconnecting routers will ensure that routers accept only legitimate routes. This approach is again a form of security, but in this case, incoming routes, instead of outgoing routes, are regulated.
Whatever the application, route filters are a fundamental building block for creating routing policies: A set of rules that govern how packets are forwarded in a network or change the default packet forwarding behavior.
Route filters work by regulating the routes that are entered into, or advertised out of, the route table. They have somewhat different effects on link-state routing protocols than they do on distance-vector routing protocols. A router running a distance-vector protocol advertises routes based on what is in its route table. As a result, a route filter will influence which routes the router advertises to its neighbors.
On the other hand, routers running link-state protocols determine their routes based on information in their link-state database, rather than the advertised route entries of their neighbors. Route filters have no effect on link- state advertisements or the link-state database.[1] As a result, a route filter can influence the route table of the router on which the filter is configured but has no effect on the route entries of neighboring routers. Because of this behavior, route filters are used mostly at redistribution points into link-state domains, such as an OSPF ASBR (autonomous system boundary router), where they can regulate which routes enter or leave the domain. Within the link-state domain, route filters have limited utility.
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
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.
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.
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, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
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, Serial0
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, Ethernet0
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 ::/0
The 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 - ISIS summary
O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
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.0
For 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.33) 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.202) 192.168.75.32/27 -> 0.0.0.0, metric 1, tag 0 192.168.75.196/30 -> 0.0.0.0, metric 1, tag 0 192.168.75.204/30 -> 0.0.0.0, metric 2, 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 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.
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 misrouted into ThemNet. A black hole would exist.
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 2 network 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.
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 5 passive-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 1 deny 172.16.0.0 0.0.127.255 access-list 1 permit any access-list 3 deny 172.16.128.0 0.0.127.255 access-list 3 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 advertised into 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]
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 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 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 specifying which 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 the route 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.
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.
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 in Example 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 inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
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, Ethernet0
[70/1] via 172.16.253.253, 00:00:05, Serial1
R 172.16.251.0 [70/1] via 172.16.252.253, 00:00:08, Serial0
[70/1] via 172.16.3.253, 00:00:01, Ethernet1
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 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 (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, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
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, Serial0
[70/1] via 172.16.3.253, 00:02:32, Ethernet1
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, Ethernet0
C 172.16.2.0 is directly connected, Ethernet0
C 172.16.3.0 is directly connected, Ethernet1Example 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, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
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, Ethernet1
Drummle#Example 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, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
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, Ethernet0
D 172.16.251.0 [90/2195456] via 172.16.3.253, 00:01:06, Ethernet1
D 172.16.4.0 [90/307200] via 172.16.3.253, 00:01:06, Ethernet1
D 172.16.5.0 [90/2195456] via 172.16.253.253, 00:01:11, Serial1
D 172.16.6.0 [90/2185984] via 172.16.252.253, 00:01:11, Serial0
[90/2185984] via 172.16.253.253, 00:01:11, Serial1
D 172.16.7.0 [90/2195456] via 172.16.252.253, 00:01:07, Serial0
D 172.16.1.0 [90/307200] via 172.16.2.253, 00:01:11, Ethernet0
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 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.0
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.
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, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 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, Ethernet0 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, Serial0 O 192.168.5.0/24 [110/134] via 192.168.3.2, 00:05:09, Serial0 O E2 192.168.6.0/24 [110/100] via 192.168.3.2, 00:05:09, Serial0 Bumble#
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 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, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 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:12, Ethernet0 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:00:22, Serial0 O 192.168.5.0/24 [110/134] via 192.168.3.2, 00:00:22, Serial0 R 192.168.6.0/24 [120/1] via 192.168.2.1, 00:00:13, Ethernet0 Bumble#
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, changed state to down
Bumble#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
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, Serial0
Bumble#A 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.
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.
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 are assigned a distance of 110; all other routes are given a distance of 130.
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, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 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, Ethernet0 R 192.168.2.0/24 [120/1] via 192.168.6.1, 00:00:19, Ethernet0 O 192.168.3.0/24 [110/134] via 192.168.5.2, 00:15:06, Serial0 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, changed state to down Grimwig#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 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, Serial0 O E2 192.168.2.0/24 [130/100] via 192.168.5.2, 00:00:08, Serial0 O 192.168.3.0/24 [110/134] via 192.168.5.2, 00:16:23, Serial0 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, Serial0 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, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 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, Ethernet0 R 192.168.2.0/24 [120/1] via 192.168.6.1, 00:00:04, Ethernet0 O 192.168.3.0/24 [110/134] via 192.168.5.2, 00:00:12, Serial0 O 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, changed state to down %LINK-3-UPDOWN: Interface Serial0, changed state to down Grimwig#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 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, Ethernet0 R 192.168.2.0/24 [120/1] via 192.168.6.1, 00:00:07, Ethernet0 R 192.168.3.0/24 [130/3] via 192.168.6.1, 00:00:07, Ethernet0 R 192.168.4.0/24 [130/3] via 192.168.6.1, 00:00:07, Ethernet0 R 192.168.5.0/24 is possibly down, routing via 192.168.6.1, Ethernet0 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 routes from being redistributed back into the originating routing protocol. Tags are set using route maps and are discussed further in Chapter 14, “Route Maps.”
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, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
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, Ethernet0
[120/2] via 192.168.6.2, 00:00:23, Ethernet1
R 192.168.4.0/24 [120/2] via 192.168.2.2, 00:00:26, Ethernet0
[120/2] via 192.168.6.2, 00:00:23, Ethernet1
R 192.168.5.0/24 [120/2] via 192.168.2.2, 00:00:26, Ethernet0
[120/2] via 192.168.6.2, 00:00:23, Ethernet1
C 192.168.6.0/24 is directly connected, Ethernet1
Monks#Monks 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, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 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, Ethernet1 R 192.168.4.0/24 [100/2] via 192.168.6.2, 00:00:12, Ethernet1 R 192.168.5.0/24 [100/2] via 192.168.6.2, 00:00:12, Ethernet1 C 192.168.6.0/24 is directly connected, Ethernet1 Monks# %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet1, changed state to down Monks#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 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, Ethernet0 R 192.168.4.0/24 [120/2] via 192.168.2.2, 00:00:00, Ethernet0 R 192.168.5.0/24 [120/2] via 192.168.2.2, 00:00:00, Ethernet0 R 192.168.6.0/24 [120/2] via 192.168.2.2, 00:00:00, Ethernet0 Monks#
Route filters are very useful tools for controlling the behavior of your network. In large networks, route filters are nearly indispensable. Yet for all their utility, they still can only allow or disallow routes. Chapter 14, introduces route maps, powerful tools that not only identify routes but also actively modify them.
Command | Description |
|---|---|
access-list access-list-number{deny| permit} source[source-wildcard] | Defines a line of a standard IP access list |
distance weight [address mask[access-list-number| name]] | Defines an administrative distance other than the default |
distance eigrp internal-distance external-distance | Defines the administrative distances other than the default of internal and external EIGRP routes |
distance ospf{[intra-area dist1] [inter-area dist2] [external dist3]} | Defines the administrative distances other than the default of intra-area, inter-area, and external routes |
distribute-list{access-list-number| name} in [interface-name] | Filters the IPv4 routes in incoming updates |
distribute-list{access-list-number| name} out [interface-name| routing- process| autonomous-system-number] | Filters the IPv4 routes in outgoing updates |
distribute-list prefix-list list_name[in| out] | Filters the IPv6 routes in incoming or outgoing updates |
ipv6 prefix-list list_name [seq num] {deny| permit} prefix/length[ge length | le length] | Defines a line of an IPv6 prefix list, specifying a prefix or group of prefixes to permit or deny |
redistribute protocol[process-id] {level-1| level-1-2| level-2} [metric metric-value] [metric-type type-value] [match{internal| external 1| external 2}] [tag tag-value] [route-map map-tag] [weight weight] [subnets] | Configures IPv4 redistribution into a routing protocol and specifies the source of the redistributed routes |
The routing configuration for Router A in Figure 13-7 is displayed in Example 13-33. Configure a route filter at A that will prevent subnet 172.16.12.0/24 from being known by any router other than E. Example 13-33. Router A’s configuration for the network shown in Figure 13-7. router rip redistribute eigrp 1 metric 3 passive-interface Ethernet0 passive-interface Ethernet1 network 172.16.0.0 ! router eigrp 1 redistribute rip metric 10000 1000 255 1 1500 passive-interface Ethernet2 passive-interface Ethernet3 network 172.16.0.0 | |||||||||||||||||||||||||||||
Configure a route filter at A in Figure 13-7 that will prevent D from learning about subnet 172.16.10.0/24. | |||||||||||||||||||||||||||||
Configure a route filter at A in Figure 13-7 that will allow only subnets 172.16.2.0/24, 172.16.8.0/24, and 172.16.9.0/24 to be advertised into the RIP domain. | |||||||||||||||||||||||||||||
Configure a route filter at A in Figure 13-7 that will prevent B from learning about any of the subnets in the RIP domain. | |||||||||||||||||||||||||||||
OSPFv3 for IPv6 is added to Routers A, B and C. RIPng is added to Routers A, D, and E. IPv6 prefixes 2001:db8:0:1::/64, 2001:db8:0:2::/64, and 2001:db8:0:3::/64 are connected to Router B. Prefixes 2001:db8:0:a::/64, 2001:db8:0:b::/64, and 2001:db8:0:c::/64 are connected to Router E. Configure a route filter at A in Figure 13-7 that prevents the prefixes 2001:db8:0:a::/64 and 2001:db8:0:b::/64 from being advertised to D. | |||||||||||||||||||||||||||||
Table 13-1 shows the interface addresses for all routers in Figure 13-8. Routers A and B are running EIGRP, and Routers E and F are running IS-IS. C and D are redistributing. Configure distance commands for C and D that will prevent loops and route feedback but will still allow redundant paths. Table 13-1. The interface addresses of the routers in Figure 13-8.
| |||||||||||||||||||||||||||||
Using the distance command, configure Router D in Figure 13-8 to accept EIGRP routes only from Router A. If the link to A fails, D should not accept routes from Router B, although D should still advertise routes to B. | |||||||||||||||||||||||||||||
Remove the configuration added to D in Configuration Exercise 7. Configure Router C in Figure 13-8 to route to all destinations, including the networks and subnets of the IS-IS domain, via Router A. C should route through E and F only if the link to A fails. |
A router has the configuration in Example 13-34. Example 13-34. A router configuration attempting to filter the default route. router eigrp 1 network 10.0.0.0 distribute-list 1 in Ethernet5/1 ! access-list 1 deny 0.0.0.0 255.255.255.255 access-list 1 permit any The intention is to deny the incoming default route at interface E5/1 and to permit all other routes incoming on that interface. However, no routes are being accepted on E5/1. What is wrong? | |
Grimwig in Figure 13-6 has the configuration in Example 13-35. Example 13-35. Grimwig’s configuration for troubleshooting Exercise 2. router ospf 1 redistribute rip metric 100 network 192.168.5.1 0.0.0.0 area 0 distance 255 distance 110 0.0.0.0 255.255.255.255 1 ! router rip redistribute ospf 1 metric 2 network 192.168.6.0 distance 255 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 What effect will this configuration have on the routes at Grimwig? | |
The routers in Figure 13-9 are running OSPF. Router B has the configuration in Example 13-36. Example 13-36. Router B’s OSPF configuration from Figure 13-9. router ospf 50 network 0.0.0.0 255.255.255.255 area 1 distribute-list 1 in ! access-list 1 deny 172.17.0.0 access-list 1 permit any The intention is to prevent Routers B and C from having a route entry for network 172.17.0.0. This plan seems to be working at Router B, but Router C still has an entry for 172.17.0.0. Why? | |
The routers in Figure 13-9 are running RIP. Router B has the configuration in Example 13-37. Example 13-37. Router B’s RIP configuration. router rip network 172.19.0.0 network 172.20.0.0 distribute-list 1 out Ethernet0 distribute-list 2 out Ethernet1 ! access-list 1 permit 172.18.0.0 access-list 2 permit 172.22.0.0 The intention is to advertise only network 172.22.0.0 to Router A and to advertise only network 172.18.0.0 to Router C. However, A and C have no RIP entries in their route table. What is wrong? |
[1] Remember that a basic requirement of link-state protocols is that all routers in an area must have identical link-state databases. If a route filter blocked some LSAs, this requirement would be violated.
[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.
[3] The out keyword can be used in association with a routing protocol, as discussed in the next case study.
[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.
[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.
[6] The same “any” address can be used with RIP. A specific address was used for demonstration purposes.