A router performs redistribution when it uses a routing protocol to advertise routes that were learned by some other means. Those “other means” might be another routing protocol, static routes, or a direct connection to the destination network. For example, a router might be running both an Open Shortest Path First (OSPF) process and a Routing Information Protocol (RIP) process. If the OSPF process is configured to advertise routes learned by the RIP process, it is said to be “redistributing RIP.”
Running a single routing protocol throughout the entire IP network is usually more desirable than running multiple protocols, both from a configuration management perspective and from a fault management perspective. However, the realities of modern networking frequently force the acceptance of multiprotocol IP routing domains. As departments, divisions, and entire companies merge, their formerly autonomous networks must be consolidated.
In most cases, the networks that are to be consolidated were implemented differently and have evolved differently, to meet different needs or merely as the result of different design philosophies. This diversity can make the migration to a single routing protocol a complex undertaking. In some cases, corporate politics can force the use of multiple routing protocols. And in a few cases, multiple routing protocols might be the result of network administrators who do not work and play well together.
Multi-vendor environments are another factor that can necessitate redistribution. For example, a network running the Cisco EIGRP might be merged with a network using another manufacturer’s routers, which support only RIP or OSPF. Without redistribution, either the Cisco routers would have to be reconfigured to an open protocol, or the non-Cisco routers would have to be replaced with Cisco routers.
Redistribution is necessary when multiple routing protocols are “thrown together,” but redistribution can also be part of a well-thought-out network design. Figure 11-1 shows an example. Here two OSPF process domains are connected, but the OSPF processes do not communicate directly. Instead, static routes are configured on each router to selected networks in the other OSPF domain.
Figure 11-1. In this network, static routes are configured on each router and redistributed into OSPF. As a result, the advertisement of prefixes between the two OSPF domains is carefully controlled.
For instance, router Spalding has static routes to networks 192.168.11.0 and 192.168.12.0. Spalding then redistributes these static routes into OSPF, and OSPF advertises the routes to the other routers in OSPF 10. The result is that the other networks in OSPF 20 are hidden from OSPF 10. Redistribution has allowed the dynamic characteristics of OSPF to be mixed with the precise control of static routes.
Static routes redistributed into a dynamic routing protocol are also very useful, if not essential, in dial-up environments. The periodic management traffic of a dynamic protocol can cause the dial-up line to be “always up.” By blocking routing updates or Hellos across the link and configuring static routes on each side, the administrator can ensure that the link will come up only when user traffic must traverse it. And by redistributing the static routes into the dynamic routing protocol, all routers on both sides of the dial-up link have full knowledge of all subnets on the opposite side of the link.
Note that with few exceptions,[1] the existence of more than one routing protocol on the same router does not mean that redistribution will occur automatically. Redistribution must be explicitly configured. The configuration of multiple routing protocols on a single router without redistribution is called ships in the night (SIN) routing. The router will pass routes to its peers in each process domain, but the process domains will have no knowledge of each other—like ships passing in the night. Although SIN routing usually refers to multiple routing protocols routing multiple routed protocols on the same router (such as OSPF routing IP and NLSP routing IPX), it can also refer to two IP protocols routing for separate IP domains on a single router.
The capabilities of the IP routing protocols vary widely. The protocol characteristics that have the most bearing on redistribution are the differences in metrics and administrative distances, and each protocol’s classful or classless capabilities. Failure to give careful consideration to these differences when redistributing can lead to, at best, a failure to exchange some or all routes or, at worst, routing loops and black holes.
The routers of Figure 11-1 are redistributing static routes into OSPF, which then advertises the routes to other OSPF-speaking routers. Static routes have no metric associated with them, but every OSPF route must have a cost. Another example of conflicting metrics is the redistribution of RIP routes into EIGRP. RIP’s metric is hop count, whereas EIGRP uses bandwidth and delay. In both cases, the protocol into which routes are redistributed must be able to associate its own metrics with those routes.
So the router performing the redistribution must assign a metric to the redistributed routes. Figure 11-2 shows an example. Here EIGRP is being redistributed into OSPF, and OSPF is being redistributed into EIGRP. OSPF does not understand the composite metric of EIGRP, and EIGRP does not understand OSPF cost. As a result, part of the redistribution process is that the router must assign a cost to each EIGRP route before passing it to OSPF. Likewise, the router must assign a bandwidth, delay, reliability, load, and MTU to each OSPF route before passing it to EIGRP. If incorrect metrics are assigned, redistribution will fail.
Figure 11-2. When routes are redistributed, a metric that is understandable to the receiving protocol must be assigned to the routes.
Case studies later in this chapter show how to configure routers to assign metrics for purposes of redistribution.
The diversity of metrics presents another problem: If a router is running more than one routing protocol and learns a route to the same destination from each of the protocols, which route should be selected? Each protocol uses its own metric scheme to define the best route. Comparing routes with different metrics, such as cost and hop count, is like comparing apples and oranges.
The answer to the problem is administrative distances. Just as metrics are assigned to routes so that the most preferred route may be determined, administrative distances are assigned to route sources so that the most preferred source may be determined. Think of an administrative distance as a measure of believability. The lower the administrative distance, the more believable the protocol.
For example, suppose a router running RIP and EIGRP learns of a route to network 192.168.5.0 from a RIP-speaking neighbor and another route to the same destination from an EIGRP-speaking neighbor. Because of EIGRP’s composite metric, that protocol is more likely to have determined the optimum route. Therefore, EIGRP should be believed over RIP.
Table 11-1 shows the default Cisco administrative distances. EIGRP has an administrative distance of 90, whereas RIP has an administrative distance of 120. Therefore, EIGRP is deemed more trustworthy than RIP.
Table 11-1. Cisco default administrative distances.
Route Source | Administrative Distance |
|---|---|
Connected interface[*] | 0 |
Static route | 1 |
EIGRP summary route | 5 |
External BGP | 20 |
EIGRP | 90 |
IGRP | 100 |
OSPF | 110 |
IS-IS | 115 |
RIP | 120 |
EGP | 140 |
External EIGRP | 170 |
Internal BGP | 200 |
Unknown | 255 |
Although administrative distances help resolve the confusion of diverse metrics, they can cause problems for redistribution. For example, in Figure 11-3, both Gehrig and Ruth are redistributing RIP-learned routes into IGRP. Gehrig learns about network 192.168.1.0 via RIP and advertises the network into the IGRP domain. As a result, Ruth learns about network 192.168.1.0 not only from Combs via RIP, but also from Meusel via IGRP.
Example 11-1 shows Ruth’s route table. Notice that the route to 192.168.1.0 is an IGRP route. Ruth has chosen the IGRP route because, compared to RIP, IGRP has a lower administrative distance. Ruth will send all packets to 192.168.1.0 over the “scenic route” through Meusel, instead of sending them directly to Combs.
Example 11-1. Although the optimal route to network 192.168.1.0 from Ruth is through Combs, out S0, Ruth is instead routing to that network through Meusel, out S1.
Ruth#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, 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 I 192.168.1.0/24 [100/16100] via 192.168.5.1, 00:00:00, Serial1 I 192.168.2.0/24 [100/12576] via 192.168.5.1, 00:00:00, Serial1 I 192.168.3.0/24 [100/12476] via 192.168.5.1, 00:00:01, Serial1 I 192.168.4.0/24 [100/10476] via 192.168.5.1, 00:00:01, Serial1 C 192.168.5.0/24 is directly connected, Serial1 C 192.168.6.0/24 is directly connected, Serial0 Ruth#
Split horizon prevents a routing loop in the network of Figure 11-3. Both Gehrig and Ruth initially advertise subnet 192.168.1.0 into the IGRP domain, and the four IGRP routers eventually converge on a single path to that subnet. However, the convergence is unpredictable. This condition can be seen by rebooting routers Lazzeri and Meusel. After the reboot, Ruth’s route table shows that it is using Combs as the next-hop router to reach 192.168.1.0 (Example 11-2).
Example 11-2. The convergence of the network in Figure 11-3 is unpredictable. After a reboot of the routers, Ruth is now routing to 192.168.1.0 through Combs.
Ruth#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, 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.2, 00:00:23, Serial0 I 192.168.2.0/24 [100/12576] via 192.168.5.1, 00:00:22, Serial1 I 192.168.3.0/24 [100/12476] via 192.168.5.1, 00:00:22, Serial1 I 192.168.4.0/24 [100/10476] via 192.168.5.1, 00:00:22, Serial1 C 192.168.5.0/24 is directly connected, Serial1 C 192.168.6.0/24 is directly connected, Serial0 Ruth#
Convergence after the reboot is not only unpredictable but also slow. Example 11-3 shows Gehrig’s route table approximately three minutes after the reboot. It is using Lazzeri as a next-hop router to subnet 192.168.1.0, but pings to a working address on that link fail. Lazzeri’s route table (Example 11-4) shows the problem: Lazzeri is using Gehrig as a next-hop router. A routing loop exists.
Example 11-3. Soon after the reboot, Gehrig is routing packets to 192.168.1.0 via Lazzeri.
Gehrig#show ip 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 I 192.168.1.0/24 [100/16100] via 192.168.3.2, 00:02:38, Serial0 C 192.168.2.0/24 is directly connected, Ethernet0 C 192.168.3.0/24 is directly connected, Serial0 I 192.168.4.0/24 [100/10476] via 192.168.3.2, 00:00:29, Serial0 I 192.168.5.0/24 [100/12476] via 192.168.3.2, 00:00:29, Serial0 I 192.168.6.0/24 [100/14476] via 192.168.3.2, 00:00:39, Serial0 Gehrig#ping 192.168.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) Gehrig#
Example 11-4. Lazzeri is routing packets to 192.168.1.0 via Gehrig, creating a routing loop. Notice the age of the route.
Lazzeri#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, 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 I 192.168.1.0/24 [100/12100] via 192.168.3.1, 00:04:21, Serial0 I 192.168.2.0/24 [100/8576] via 192.168.3.1, 00:00:33, Serial0 C 192.168.3.0/24 is directly connected, Serial0 C 192.168.4.0/24 is directly connected, Serial1 I 192.168.5.0/24 [100/10476] via 192.168.4.2, 00:00:53, Serial1 I 192.168.6.0/24 [100/12100] via 192.168.3.1, 00:02:32, Serial0 Lazzeri#
Here’s the sequence of events leading to the loop:
While Lazzeri and Meusel are rebooting, both Gehrig and Ruth have route table entries showing network 192.168.1.0 as reachable via Combs.
As Lazzeri and Meusel become active, both Gehrig and Ruth send IGRP updates that include subnet 192.168.1.0. Simply by the “luck of the draw,” Ruth sends its update slightly earlier than Gehrig does.
Meusel, receiving Ruth’s update, makes Ruth the next-hop router and sends an update to Lazzeri.
Lazzeri, receiving Meusel’s update, makes Meusel the next-hop router.
Lazzeri and Gehrig send updates to each other at about the same time. Lazzeri makes Gehrig the next-hop router to 192.168.1.0 because its route is metrically closer than Meusel’s route. Gehrig makes Lazzeri the next-hop router to 192.168.1.0 because its IGRP advertisement has a lower administrative distance than Combs RIP advertisement. The loop is now in effect.
Split horizon and the invalid timers will eventually sort things out. Lazzeri is advertising 192.168.1.0 to Meusel, but Meusel continues to use the metrically closer route via Ruth. And since Ruth is the next-hop router, split horizon is in effect for 192.168.1.0 at Meusel’s S1 interface. Meusel is also advertising 192.168.1.0 to Lazzeri, but Lazzeri sees Gehrig as metrically closer.
Lazzeri and Gehrig see each other as the next-hop router to 192.168.1.0, so they will not advertise the route to each other. The route will age in both of their route tables until the invalid timer expires (Example 11-5).
Example 11-5. When the invalid timer for the route to 192.168.1.0 expires, the route is declared unreachable and the holddown timer is started.
Lazzeri#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, 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 I 192.168.1.0/24 is possibly down, routing via 192.168.3.1, Serial0 I 192.168.2.0/24 [100/8576] via 192.168.3.1, 00:00:57, Serial0 C 192.168.3.0/24 is directly connected, Serial0 C 192.168.4.0/24 is directly connected, Serial1 I 192.168.5.0/24 [100/10476] via 192.168.4.2, 00:01:25, Serial1 I 192.168.6.0/24 is possibly down, routing via 192.168.3.1, Serial0 Lazzeri#
When Lazzeri’s invalid timer expires, the route to 192.168.1.0 will be put into holddown. Although Meusel is advertising a route to that network, Lazzeri cannot accept it until the holddown timer expires. Example 11-6 shows that Lazzeri has finally accepted the route from Meusel, and Example 11-7 shows that Gehrig is successfully reaching 192.168.1.0 through Lazzeri. It took more than nine minutes for these two routers to converge, and the route they are using is still not the optimal route.
Example 11-6. After the holddown timer for 192.168.1.0 expires, Lazzeri accepts the route advertised by Meusel.
Lazzeri#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, 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 I 192.168.1.0/24 [100/14100] via 192.168.4.2, 00:00:27, Serial1 I 192.168.2.0/24 [100/8576] via 192.168.3.1, 00:00:02, Serial0 C 192.168.3.0/24 is directly connected, Serial0 C 192.168.4.0/24 is directly connected, Serial1 I 192.168.5.0/24 [100/10476] via 192.168.4.2, 00:00:28, Serial1 I 192.168.6.0/24 [100/12476] via 192.168.4.2, 00:00:28, Serial1 Lazzeri#
Example 11-7. Gehrig can now reach subnet 192.168.1.0 via Lazzeri.
Gehrig#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, 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 I 192.168.1.0/24 [100/16100] via 192.168.3.2, 00:00:32, Serial0 C 192.168.2.0/24 is directly connected, Ethernet0 C 192.168.3.0/24 is directly connected, Serial0 I 192.168.4.0/24 [100/10476] via 192.168.3.2, 00:00:33, Serial0 I 192.168.5.0/24 [100/12476] via 192.168.3.2, 00:00:33, Serial0 I 192.168.6.0/24 [100/14476] via 192.168.3.2, 00:00:33, Serial0 Gehrig#ping 192.168.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 52/72/108 ms Gehrig#
Administrative distances can cause even worse problems than the sub-optimal routes, unpredictable behavior, and slow convergence of the previous example. For example, Figure 11-4 shows essentially the same network as in Figure 11-3, except that the links between the IGRP routers are Frame Relay PVCs. By default, IP split horizon is turned off on Frame Relay interfaces. As a result, permanent routing loops will form between Lazzeri and Gehrig and between Meusel and Ruth. Subnet 192.168.1.0 is unreachable from the IGRP domain.
Figure 11-4. Because IP split horizon is turned off by default on Frame Relay interfaces, permanent routing loops will form in this network.
Several tools and strategies exist to prevent routing loops when redistributing. The administrative distances can be manipulated, and route filters or route maps can be used. Chapter 13 covers route filters, and Chapter 14 covers route maps. These chapters also demonstrate techniques for changing administrative distances.
Careful consideration must be given to the effects of redistributing routes from a classless routing process domain into a classful domain. To understand why, it is necessary to first understand how a classful routing protocol reacts to variable subnetting. Recall from Chapter 5, “Routing Information Protocol (RIP),” that classful routing protocols do not advertise a mask with each route. For every route a classful router receives, one of two situations will apply:
The router will have one or more interfaces attached to the major network.
The router will have no interfaces attached to the major network.
In the first case, the router must use its own configured mask for that major network to correctly determine the subnet of a packet’s destination address. In the second case, only the major network address itself can be included in the advertisement because the router has no way of knowing which subnet mask to use.
Figure 11-5 shows a router with four interfaces connected to subnets of 192.168.100.0. The network is variably subnetted—two interfaces have 27-bit masks, and two interfaces have 30-bit masks. If the router is running a classful protocol such as IGRP, it cannot use the 27-bit mask to derive 30-bit subnets, and it cannot use the 30-bit mask to derive 27-bit subnets. So, how does the protocol cope with the conflicting masks?
In Example 11-8, debugging is used to observe the IGRP advertisements sent by the router in Figure 11-5. Notice that subnet 192.168.100.128/27 is advertised out interface E0, which has a 27-bit mask, but neither 192.168.100.4/30 nor 192.168.100.8/30 is advertised out that interface. Similarly, 192.168.100.8/30 is advertised out interface S1, which has a 30-bit mask, but neither 192.168.100.96/27 nor 192.168.100.128/27 is advertised out that interface. The same situation applies to all four interfaces. Only subnets of 192.168.100.0 whose masks match the interface mask are advertised. As a result, IGRP-speaking neighbors on interfaces E0 and E1 will have no knowledge of the 30-bit subnets, and IGRP-speaking neighbors on interfaces S0 and S1 will have no knowledge of the 27-bit subnets.
Example 11-8. A classful routing protocol will not advertise routes between interfaces whose masks do not match.
O'Neil#debug ip igrp transactions
IGRP protocol debugging is on
O'Neil#
IGRP: sending update to 255.255.255.255 via Ethernet0 (192.168.100.97)
subnet 192.168.100.128, metric=1100
IGRP: sending update to 255.255.255.255 via Ethernet1 (192.168.100.129)
subnet 192.168.100.96, metric=1100
IGRP: sending update to 255.255.255.255 via Serial0 (192.168.100.9)
subnet 192.168.100.4, metric=8476
IGRP: sending update to 255.255.255.255 via Serial1 (192.168.100.5)
subnet 192.168.100.8, metric=8476
O'Neil#This behavior of only advertising routes between interfaces with matching masks also applies when redistributing from a classless routing protocol into a classful routing protocol. In Figure 11-6, the subnets of the OSPF domain are variably subnetted, and Paige is redistributing OSPF-learned routes into IGRP.
As Example 11-9 shows, Paige knows about all of the subnets in both the OSPF and the IGRP domain. And because OSPF is classless, the router knows which masks are associated with each subnet connected to Gibson. Paige’s IGRP process is using a 24-bit mask; therefore, 172.20.113.192/26 and 172.20.114.48/28 are not compatible and are not advertised (Example 11-10). Notice that IGRP does advertise 172.20.112.0/24 and 172.20.115.0/24. The result is that the only subnets within the OSPF domain that Leonard knows of are the ones with a 24-bit mask (Example 11-11).
Example 11-9. Paige knows about all six subnets of Figure 11-6, either from OSPF, IGRP, or a direct connection.
Paige#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, 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.20.0.0/16 is variably subnetted, 6 subnets, 3 masks
O 172.20.113.192/26 [110/74] via 172.20.112.1, 00:01:35, Ethernet1
C 172.20.112.0/24 is directly connected, Ethernet1
O 172.20.115.0/24 [110/80] via 172.20.112.1, 00:01:35, Ethernet1
I 172.20.110.0/24 [100/1600] via 172.20.111.1, 00:00:33, Ethernet0
C 172.20.111.0/24 is directly connected, Ethernet0
O 172.20.114.48/28 [110/74] via 172.20.112.1, 00:01:35, Ethernet1
Paige#Example 11-10. Only the OSPF-learned routes with a 24-bit mask are successfully redistributed into the IGRP domain, which is also using a 24-bit mask.
Paige#debug ip igrp transactions
IGRP protocol debugging is on
Paige#
IGRP: received update from 172.20.111.1 on Ethernet0
subnet 172.20.110.0, metric 1600 (neighbor 501)
IGRP: sending update to 255.255.255.255 via Ethernet0 (172.20.111.2)
subnet 172.20.112.0, metric=1100
subnet 172.20.115.0, metric=1100
Paige#Example 11-11. The only subnets within the OSPF domain known at Leonard are the ones with a 24-bit mask. 172.20.113.192/26 and 172.20.114.48/28 are unreachable from here.
Leonard#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, 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.20.0.0/24 is subnetted, 4 subnets
I 172.20.112.0 [100/1200] via 172.20.111.2, 00:00:48, Ethernet1
I 172.20.115.0 [100/1200] via 172.20.111.2, 00:00:48, Ethernet1
C 172.20.110.0 is directly connected, Ethernet0
C 172.20.111.0 is directly connected, Ethernet1
Leonard#The configuration section includes case studies that demonstrate methods for reliably redistributing from a classless routing protocol to a classful routing protocol.
Redistribution is configured in two steps:
In the routing protocol configuration that is to receive the redistributed routes, use the redistribute command to specify the source of the routes.
Specify the metric to be assigned to the redistributed routes.
For example, the EIGRP configuration of Lajoie in Figure 11-7 is displayed in Example 11-12.
Example 11-12. Lajoie’s EIGRP configuration shows OSPF being redistributed into the EIGRP process.
router eigrp 1 redistribute ospf 1 metric 10000 100 255 1 15003 passive-interface Ethernet1 network 172.20.0.0
This configuration redistributes routes discovered by OSPF process 1 into EIGRP process 1. The metric portion of the command assigns EIGRP metrics to the routes. In order, the numbers specify the following:
Bandwidth, in kilobits per second
Delay, in tens of microseconds
Reliability, as a fraction of 255
Load, as a fraction of 255
MTU, in octets
The OSPF configuration of Lajoie is in Example 11-13
Example 11-13. Lajoie’s OSPF configuration shows the redistribution of EIGRP routes into OSPF.
router ospf 1 redistribute eigrp 1 metric 30 metric-type 1 subnets network 172.20.11.2 0.0.0.0 area 0
This configuration redistributes routes discovered by EIGRP 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 Lajoie 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 in Example 11-14.
Example 11-14. Lajoie’s OSPF configuration uses the default-metric command to assign an OSPF metric to all routes redistributed into OSPF.
router ospf 1 redistribute eigrp 1 metric-type 1 subnets default-metric 30 network 172.20.11.2 0.0.0.0 area 0
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 Lajoie in Figure 11-7 was running not only EIGRP and OSPF but also RIP. The OSPF configuration might be as displayed in Example 11-15.
Example 11-15. Lajoie’s OSPF configuration uses the default-metric command to assign an OSPF metric to routes redistributed from both EIGRP and RIP.
router ospf 1 redistribute eigrp 1 metric-type 1 subnets redistribute rip metric-type 1 subnets default-metric 30 network 172.20.11.2 0.0.0.0 area 0
Here an OSPF cost of 30 will be assigned to all EIGRP- and RIP-learned routes.
The two methods of assigning metrics can also be used with each other. For example, suppose Lajoie were to be configured to redistribute OSPF and RIP into EIGRP, but that RIP routes were to be advertised with a different set of metrics than the OSPF routes. The configuration might be like Example 11-16.
Example 11-16. Lajoie’s EIGRP configuration uses a metric with the redistribution command to assign metrics to addresses redistributed from RIP, and uses the default metric command to assign the EIGRP metric to all other redistributed addresses.
router eigrp 1 redistribute ospf 1 redistribute rip metric 50000 500 255 1 1500 default-metric 10000 100 255 1 1500 passive-interface Ethernet1 network 172.20.0.0
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 EIGRP with the metrics specified on the redistribute rip line, and the OSPF-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 EIGRP multi-metric format. These two 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.
In the network of Figure 11-8, Ford is running IGRP, and Berra is running RIP. Mantle’s routing configuration is shown in Example 11-17.
Example 11-17. Mantle is running both IGRP and RIP and performing redistribution between the two protocols, using both the default metric and the metric assigned with the redistribution command.
router rip redistribute igrp 1 metric 5 passive-interface Ethernet1 network 10.0.0.0 ! router igrp 1 redistribute rip default-metric 1000 100 255 1 1500 passive-interface Ethernet0 network 10.0.0.0
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 as in Example 11-18.
Example 11-18. Mantle redistributes the connected stub network into IGRP.
router rip redistribute igrp 1 metric 5 passive-interface Ethernet1 network 10.0.0.0 ! router igrp 1 redistribute connected redistribute rip default-metric 1000 100 255 1 1500 passive-interface Ethernet0 network 10.0.0.0
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 would be as in Example 11-19.
Example 11-19. Mantle’s configuration shows the connected stub network advertised into both RIP, assigning the metric during redistribution, and IGRP, assigning the metric using the default metric command.
router rip redistribute connected metric 5 redistribute igrp 1 metric 5 passive-interface Ethernet1 network 10.0.0.0 ! router igrp 1 redistribute connected redistribute rip default-metric 1000 100 255 1 1500 passive-interface Ethernet0 network 10.0.0.0
The network of Figure 11-9 has an OSPF domain and two EIGRP domains. Router Hodges is running OSPF process 1. Podres is running EIGRP process 1, and on Snider and Campanella, EIGRP process 2 is running.
Figure 11-9. Hodges is running OSPF, and Podres is running EIGRP 1. Snider and Campanella are running EIGRP 2.
Robinson has the configuration in Example 11-20.
Example 11-20. Robinson is redistributing the EIGRP1, EIGRP2, and OSPF processes.
router eigrp 1 redistribute ospf 1 metric 1000 100 1 255 1500 redistribute eigrp 2 passive-interface FastEthernet0/0 network 192.168.3.0 ! router eigrp 2 redistribute ospf 1 metric 1000 100 1 255 1500 redistribute eigrp 1 network 192.168.4.0 network 172.16.0.0 ! router ospf 1 redistribute eigrp 1 redistribute eigrp 2 metric 100 default-metric 50 network 192.168.3.33 0.0.0.0 area 0
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. Example 11-21 shows Podres’ route table. The redistributed routes are tagged as EIGRP external routes.
Example 11-21. The route table of Podres in Figure 11-9.
Podres#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, ia - IS-IS inter area
* - candidate default, U - per-user static route, o – ODR
P - periodic downloaded static route
Gateway of last resort is not set
172.16.0.0/16 is variably subnetted, 3 subnets, 3 masks
D EX 172.16.2.20/30 [170/2195456] via 192.168.3.129, 00:00:26, Ethernet0
D EX 172.16.0.0/16 [170/2195456] via 192.168.3.129, 00:00:26, Ethernet0
D EX 172.16.1.0/24 [170/2221056] via 192.168.3.129, 00:00:26, Ethernet0
192.168.4.0/24 is variably subnetted, 3 subnets, 3 masks
D EX 192.168.4.72/29 [170/2221056] via 192.168.3.129, 00:00:26, Ethernet0
D EX 192.168.4.4/30 [170/2195456] via 192.168.3.129, 00:00:26, Ethernet0
D EX 192.168.4.0/24 [170/2195456] via 192.168.3.129, 00:00:27, Ethernet0
D EX 192.168.1.0/24 [170/2611200] via 192.168.3.129, 00:00:28, Ethernet0
C 192.168.2.0/24 is directly connected, Ethernet3
192.168.3.0/24 is variably subnetted, 7 subnets, 2 masks
D EX 192.168.3.96/27 [170/2611200] via 192.168.3.129, 00:00:28, Ethernet0
D EX 192.168.3.64/27 [170/2611200] via 192.168.3.129, 00:00:28, Ethernet0
D 192.168.3.32/27 [90/284160] via 192.168.3.129, 00:00:35, Ethernet0
D 192.168.3.0/24 is a summary, 00:07:18, Null0
C 192.168.3.192/27 is directly connected, Ethernet2
C 192.168.3.160/27 is directly connected, Ethernet1
C 192.168.3.128/27 is directly connected, Ethernet0
Podres#Example 11-22 shows Hodges’ route table, which has some problems. Recall from Chapter 8, “OSPFv2,” that routes redistributed into OSPF are either type 1 (E1) or type 2 (E2) external routes. The only routes that seem to have been redistributed, indicated by the E2 tag, are the major network addresses 192.168.2.0/24, 172.16.0.0/16, and 192.168.4.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 within the non-OSPF process will be redistributed.
Example 11-22. The route table of Hodges contains only major network redistributed routes, indicated by the E2 tag.
Hodges#show ip route
Codes: C - connected, S - static, 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
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
O E2 172.16.0.0/16 [110/100] via 192.168.3.33, 00:24:41, FastEthernet0/0
O E2 192.168.4.0/24 [110/100] via 192.168.3.33, 00:24:41, FastEthernet0/0
C 192.168.1.0/24 is directly connected, Serial0/0
O E2 192.168.2.0/24 [110/50] via 192.168.3.33, 00:02:57, FastEthernet0/0
192.168.3.0/27 is subnetted, 3 subnets
C 192.168.3.96 is directly connected, Serial0/0
C 192.168.3.64 is directly connected, Serial0/0
C 192.168.3.32 is directly connected, FastEthernet0/0
Hodges#Robinson’s configuration is changed to include the subnets keyword as displayed in Example 11-23.
Example 11-23. Robinson uses the subnets keyword when redistributing routes into OSPF so that subnets in addition to major network addresses will be redistributed.
router eigrp 1 redistribute ospf 1 metric 1000 100 1 255 1500 redistribute eigrp 2 passive-interface FastEthernet0/0 network 192.168.3.0 ! router eigrp 2 redistribute ospf 1 metric 1000 100 1 255 1500 redistribute eigrp 1 network 192.168.4.0 network 172.16.0.0 ! router ospf 1 redistribute eigrp 1 subnets redistribute eigrp 2 metric 100 subnets default-metric 50 network 192.168.3.33 0.0.0.0 area 0
As a result of this change, the subnets in Figure 11-9 are in Hodges’ route table (Example 11-24).
Example 11-24. After the subnets keyword is added to Robinson’s redistribution configuration, Hodges has knowledge of all subnets.
Hodges#show ip route
Codes: C - connected, S - static, 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
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
172.16.0.0/16 is variably subnetted, 3 subnets, 3 masks
O E2 172.16.2.20/30 [110/100] via 192.168.3.33, 00:00:59, FastEthernet0/0
O E2 172.16.0.0/16 [110/100] via 192.168.3.33, 00:30:20, FastEthernet0/0
O E2 172.16.1.0/24 [110/100] via 192.168.3.33, 00:00:59, FastEthernet0/0
192.168.4.0/24 is variably subnetted, 3 subnets, 3 masks
O E2 192.168.4.72/29 [110/100] via 192.168.3.33, 00:00:59, FastEthernet0/0
O E2 192.168.4.4/30 [110/100] via 192.168.3.33, 00:01:00, FastEthernet0/0
O E2 192.168.4.0/24 [110/100] via 192.168.3.33, 00:30:22, FastEthernet0/0
C 192.168.1.0/24 is directly connected, Serial0/0
O E2 192.168.2.0/24 [110/50] via 192.168.3.33, 00:08:38, FastEthernet0/0
192.168.3.0/27 is subnetted, 6 subnets
C 192.168.3.96 is directly connected, Serial0/0
C 192.168.3.64 is directly connected, Serial0/0
C 192.168.3.32 is directly connected, FastEthernet0/0
O E2 192.168.3.192 [110/50] via 192.168.3.33, 00:01:12, FastEthernet0/0
O E2 192.168.3.160 [110/50] via 192.168.3.33, 00:01:12, FastEthernet0/0
O E2 192.168.3.128 [110/50] via 192.168.3.33, 00:01:12, FastEthernet0/0
Hodges#By default, external routes are redistributed into OSPF as type 2 routes. As discussed in Chapter 8, 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-10. In this network, 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-10. 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-10 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-9, is redistributing EIGRP 1 with a cost of 50 and redistributing EIGRP 2 with a cost of 100. Example 11-24 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 FastEthernet 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 configuration in Example 11-25, Robinson continues to redistribute EIGRP 1 as E2, but EIGRP 2 is redistributed as E1.
Example 11-25. Robinson configures routes redistributed into OSPF from EIGRP2 as external type 1 routes.
router eigrp 1 redistribute ospf 1 metric 1000 100 1 255 1500 redistribute eigrp 2 passive-interface FastEthernet0/0 network 192.168.3.0 ! router eigrp 2 redistribute ospf 1 metric 1000 100 1 255 1500 redistribute eigrp 1 network 192.168.4.0 network 172.16.0.0 ! router ospf 1 redistribute eigrp 1 subnets redistribute eigrp 2 metric 100 metric-type 1 subnets default-metric 50 network 192.168.3.33 0.0.0.0 area 0
Example 11-26 shows Hodges’s route 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 101 (the redistributed cost plus the default cost of 1 for the FastEthernet link between Robinson and Hodges).
Example 11-26. 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.
Hodges#show ip route
Codes: C - connected, S - static, 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
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
172.16.0.0/16 is variably subnetted, 3 subnets, 3 masks
O E1 172.16.2.20/30 [110/101] via 192.168.3.33, 09:01:00, FastEthernet0/0
O E1 172.16.0.0/16 [110/101] via 192.168.3.33, 00:01:02, FastEthernet0/0
O E1 172.16.1.0/24 [110/101] via 192.168.3.33, 09:01:00, FastEthernet0/0
192.168.4.0/24 is variably subnetted, 3 subnets, 3 masks
O E1 192.168.4.72/29 [110/101] via 192.168.3.33, 00:00:57, FastEthernet0/0
O E1 192.168.4.4/30 [110/101] via 192.168.3.33, 00:01:03, FastEthernet0/0
O E1 192.168.4.0/24 [110/101] via 192.168.3.33, 00:01:03, FastEthernet0/0
C 192.168.1.0/24 is directly connected, Serial0/0
O E2 192.168.2.0/24 [110/50] via 192.168.3.33, 09:01:01, FastEthernet0/0
192.168.3.0/27 is subnetted, 6 subnets
C 192.168.3.96 is directly connected, Serial0/0
C 192.168.3.64 is directly connected, Serial0/0
C 192.168.3.32 is directly connected, FastEthernet0/0
O E2 192.168.3.192 [110/50] via 192.168.3.33, 09:01:06, FastEthernet0/0
O E2 192.168.3.160 [110/50] via 192.168.3.33, 09:01:06, FastEthernet0/0
O E2 192.168.3.128 [110/50] via 192.168.3.33, 09:01:06, FastEthernet0/0
Hodges#The Cisco EIGRP, OSPFv2, OSPFv3, and IS-IS implementations have the capability to summarize redistributed routes. This case study examines summarization for EIGRP and OSPF for IPv4; the following two case studies examine OSPFv3 for IPv6 and 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-9 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 8.
At Robinson in Figure 11-9, 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, as displayed in Example 11-27.
Example 11-27. Robinson summarizes external addresses advertised into OSPF.
router eigrp 1 redistribute ospf 1 metric 1000 100 1 255 1500 redistribute eigrp 2 passive-interface FastEthernet0/0 network 192.168.3.0 ! router eigrp 2 redistribute eigrp 1 network 192.168.4.0 network 172.16.0.0 ! router ospf 1 summary-address 192.168.3.128 255.255.255.128 summary-address 172.16.0.0 255.255.0.0 redistribute eigrp 1 subnets redistribute eigrp 2 metric 100 metric-type 1 subnets default-metric 50 network 192.168.3.33 0.0.0.0 area 0
Compare Example 11-28 with Example 11-26. In Example 11-28, Hodges’ route 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 192.168.4.0/24, so the subnets of that major address are still in the route table.
Example 11-28. Robinson is summarizing 192.168.3.128/25 and 172.16.0.0/16, so no more-specific subnets within those ranges appear in the route table of Hodges.
Hodges#show ip route Codes: C - connected, S - static, 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 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route Gateway of last resort is not set O E1 172.16.0.0/16 [110/101] via 192.168.3.33, 00:11:55, FastEthernet0/0 192.168.4.0/24 is variably subnetted, 3 subnets, 3 masks O E1 192.168.4.72/29 [110/101] via 192.168.3.33, 00:03:56, FastEthernet0/0 O E1 192.168.4.4/30 [110/101] via 192.168.3.33, 00:11:55, FastEthernet0/0 O E1 192.168.4.0/24 [110/101] via 192.168.3.33, 00:11:55, FastEthernet0/0 C 192.168.1.0/24 is directly connected, Serial0/0 O E2 192.168.2.0/24 [110/50] via 192.168.3.33, 00:03:57, FastEthernet0/0 192.168.3.0/24 is variably subnetted, 4 subnets, 2 masks C 192.168.3.96/27 is directly connected, Serial0/0 C 192.168.3.64/27 is directly connected, Serial0/0 C 192.168.3.32/27 is directly connected, FastEthernet0/0 O E2 192.168.3.128/25 [110/50] via 192.168.3.33, 00:00:37, FastEthernet0/0
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 configuration in Example 11-29, Robinson will advertise summary addresses 192.168.3.0/25, 172.16.0.0/16, and 192.168.4.0/24 into EIGRP 1.
Example 11-29. Robinson summarizes routes advertised into EIGRP 1.
interface FastEthernet0/0 ip address 192.168.3.33 255.255.255.224 ! interface FastEthernet0/1 ip address 192.168.3.129 255.255.255.224 ip summary-address eigrp 1 192.168.3.0 255.255.255.128 ip summary-address eigrp 1 172.16.0.0 255.255.0.0 ip summary-address eigrp 1 192.168.4.0 255.255.255.0 ! interface Serial0/0.1 ip address 192.168.4.5 255.255.255.252 ip summary-address eigrp 2 192.168.3.0 255.255.255.0 ! interface Serial0/0.2 ip address 172.16.2.21 255.255.255.252 ip summary-address eigrp 2 192.168.0.0 255.255.0.0 ! router eigrp 1 redistribute ospf 1 metric 1000 100 1 255 1500 redistribute eigrp 2 passive-interface FastEthernet0/0 network 192.168.3.0 ! router eigrp 2 redistribute eigrp 1 network 192.168.4.0 network 172.16.0.0 ! router ospf 1 summary-address 192.168.3.128 255.255.255.128 summary-address 172.16.0.0 255.255.0.0 redistribute eigrp 1 subnets redistribute eigrp 2 metric 100 metric-type 1 subnets default-metric 50 network 192.168.3.33 0.0.0.0 area 0
Example 11-30 shows the route table of Podres. As with OSPF summarization, EIGRP summarization suppresses the advertisement of subnets within the summary range. Unlike OSPF, Podres’ route table shows that summary routes advertised into EIGRP are not tagged as external routes.
Example 11-30. The route table of Podres, showing summary routes 192.168.3.0/25, 192.168.4.0/24, and 172.16.0.0/16.
Podres#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, ia - IS-IS inter area * - candidate default, U - per-user static route, o – ODR P - periodic downloaded static route Gateway of last resort is not set D 172.16.0.0/16 [90/2195456] via 192.168.3.129, 00:00:12, Ethernet0 D 192.168.4.0/24 [90/2195456] via 192.168.3.129, 00:00:12, Ethernet0 D EX 192.168.1.0/24 [170/2611200] via 192.168.3.129, 00:00:12, Ethernet0 C 192.168.2.0/24 is directly connected, Ethernet3 192.168.3.0/24 is variably subnetted, 6 subnets, 3 masks D 192.168.3.0/25 [90/284160] via 192.168.3.129, 00:00:12, Ethernet0 D 192.168.3.0/24 is a summary, 00:00:12, Null0 C 192.168.3.192/27 is directly connected, Ethernet2 C 192.168.3.160/27 is directly connected, Ethernet1 D EX 192.168.3.128/25 [170/2611200] via 192.168.3.129, 00:00:13, Ethernet0 C 192.168.3.128/27 is directly connected, Ethernet0 D EX 192.168.0.0/16 [170/284160] via 192.168.3.129, 00:00:13, Ethernet0 Podres#
Robinson is advertising EIGRP summary routes of 192.168.3.0/24 to Campanella and 192.168.0.0/16 to Snider. Example 11-31 shows Campanella’s route table, and Example 11-32 shows Snider’s route table.
Example 11-31. Campanella’s route table after summarization is configured at Robinson.
Campanella#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, ia - IS-IS inter area * - candidate default, U - per-user static route, o – ODR P - periodic downloaded static route Gateway of last resort is not set D EX 172.16.0.0/16 [170/2681856] via 192.168.4.5, 00:35:12, Serial0.1 192.168.4.0/24 is variably subnetted, 3 subnets, 3 masks C 192.168.4.72/29 is directly connected, Ethernet0 C 192.168.4.4/30 is directly connected, Serial0.1 D EX 192.168.4.0/24 [170/2681856] via 192.168.4.5, 00:35:12, Serial0.1 D EX 192.168.1.0/24 [170/3097600] via 192.168.4.5, 00:35:12, Serial0.1 D EX 192.168.2.0/24 [170/2300416] via 192.168.4.5, 00:35:12, Serial0.1 D 192.168.3.0/24 [90/2172416] via 192.168.4.5, 00:35:13, Serial0.1 Campanella#
Example 11-32. Snider’s route table after summarization is configured at Robinson.
Snider#show ip route Codes: C - connected, S - static, 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 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route Gateway of last resort is not set 172.16.0.0/16 is variably subnetted, 3 subnets, 3 masks C 172.16.2.20/30 is directly connected, Serial0/0.1 D EX 172.16.0.0/16 [170/2681856] via 172.16.2.21, 00:07:59, Serial0/0.1 C 172.16.1.0/24 is directly connected, Ethernet0/0 D 192.168.0.0/16 [90/2195456] via 172.16.2.21, 00:07:59, Serial0/0.1 Snider#
Looking again at Example 11-30, notice the entry for the summary route 192.168.3.128/25. This entry might 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. This is the same reason why you see 172.16.0.0/16 and 192.168.4.0/24 as external routes on Campanella. These summary addresses are advertised to Podres, in EIGRP 1, and then redistributed back into EIGRP 2. Snider’s route table shows the route to 172.16.0.0/16, but not 192.168.4.0/24, because Snider has an entry for the summarized address 192.168.0.0/16.
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.
In fact, this situation will not occur.
Robinson’s route table (Example 11-33) 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,[2] 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.
Example 11-33. Robinson’s route 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.
Robinson#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, ia - IS-IS inter area
* - candidate default, U - per-user static route, o – ODR
P - periodic downloaded static route
Gateway of last resort is not set
172.16.0.0/16 is variably subnetted, 3 subnets, 3 masks
C 172.16.2.20/30 is directly connected, Serial0/0.2
D 172.16.0.0/16 is a summary, 00:19:44, Null0
D 172.16.1.0/24 [90/2195456] via 172.16.2.22, 00:17:08, Serial0/0.2
192.168.4.0/24 is variably subnetted, 3 subnets, 3 masks
D 192.168.4.72/29 [90/2172416] via 192.168.4.6, 00:15:17, Serial0/0.1
C 192.168.4.4/30 is directly connected, Serial0/0.1
D 192.168.4.0/24 is a summary, 00:20:53, Null0
O 192.168.1.0/24 [110/74] via 192.168.3.34, 00:21:14, FastEthernet0/0
D 192.168.2.0/24 [90/665600] via 192.168.3.130, 00:19:41, FastEthernet0/1
192.168.3.0/24 is variably subnetted, 8 subnets, 3 masks
O 192.168.3.96/27 [110/74] via 192.168.3.34, 00:21:15, FastEthernet0/0
O 192.168.3.64/27 [110/74] via 192.168.3.34, 00:21:15, FastEthernet0/0
C 192.168.3.32/27 is directly connected, FastEthernet0/0
D 192.168.3.0/24 is a summary, 00:19:01, Null0
D 192.168.3.0/25 is a summary, 00:19:47, Null0
D 192.168.3.192/27 [90/665600] via 192.168.3.130, 00:19:42, FastEthernet0/1
D 192.168.3.160/27 [90/665600] via 192.168.3.130, 00:19:42, FastEthernet0/1
C 192.168.3.128/27 is directly connected, FastEthernet0/1
D 192.168.0.0/16 is a summary, 00:19:00, Null0
Robinson#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, “Route Filtering,” or route maps, as described in Chapter 14, “Route Maps,” is essential.
The previous scenario also demonstrates the trade-off of using summarization. Although the size of the route table is reduced, saving memory and processor cycles, route precision is also reduced. As the network grows more complex, that loss of detail increases the possibility of routing errors.
IPv6 is running on the network in Figure 11-11. Router Griffey is the connection point between three distinct networks. Two networks are running OSPFv3, the other is running RIPng. Routes are redistributed between the routing processes by Griffey.
Figure 11-11. IPv6 is being routed with both OSPFv3 and RIPng, and a single router is redistributing between the routing protocols.
Griffey’s configuration is displayed in Example 11-34.
Example 11-34. Griffey is configured with IPv6, OSPFv3 process 1, OSPFv3 process 2, and RIPng, and is redistributing between the processes.
interface Ethernet 0/0 ipv6 address 2001:db8:0:21::1/64 ipv6 rip Mariners enable ! interface Serial 0/0.1 point-to-point ipv6 address 2001:db8:0:31::1/64 ipv6 ospf 1 area 1 ! interface Serial 0/0.4 point-to-point ipv6 address 2001:db8:0:30::1/64 ipv6 ospf 2 area 20 ! ipv6 router ospf 1 redistribute rip Mariners metric-type 1 tag 4 ! ipv6 router ospf 2 redistribute rip Mariners ! ipv6 router rip Mariners redistribute ospf 1 metric 5 redistribute ospf 2 metric 10
Griffey is redistributing routes known via the RIPng process called Mariners into OSPFv3 process ID 1 with a metric-type of external, type 1. Also, a tag value of 4 is added to these routes. The tag can later be used to identify routes advertised by this RIPng process. Boone’s IPv6 route table (Example 11-35) shows these routes.
Example 11-35. IPv6 route table shows routes redistributed into OSPF from RIP, with a tag of 4 and external type 1 metrics.
Boone#show ipv6 route ospf
IPv6 Routing Table - 26 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
OE1 2001:DB8:0:22::/64 [110/84], tag 4
via FE80::207:85FF:FE6B:EA20, Serial0/0.1
OE1 2001:DB8:0:23::/64 [110/84], tag 4
via FE80::207:85FF:FE6B:EA20, Serial0/0.1
OE1 2001:DB8:0:24::/64 [110/84], tag 4
via FE80::207:85FF:FE6B:EA20, Serial0/0.1
OE1 2001:DB8:0:25::/64 [110/84], tag 4
via FE80::207:85FF:FE6B:EA20, Serial0/0.1
OE1 2001:DB8:0:26::/64 [110/84], tag 4
via FE80::207:85FF:FE6B:EA20, Serial0/0.1
OE1 2001:DB8:0:27::/64 [110/84], tag 4
via FE80::207:85FF:FE6B:EA20, Serial0/0.1
Boone#Griffey advertises the RIPng routes into OSPFv3 process ID 2 with the default metric-type (external type 2) and no tag value. Garcia’s route table (Example 11-36) shows the redistributed routes.
Example 11-36. IPv6 route table shows redistributed routes with the default metric-type of external type 2.
Garcia#show ipv6 route ospf
IPv6 Routing Table - 26 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
OE2 2001:DB8:0:22::/64 [110/20]
via FE80::207:85FF:FE6B:EA20, Serial0/0.1
OE2 2001:DB8:0:23::/64 [110/20]
via FE80::207:85FF:FE6B:EA20, Serial0/0.1
OE2 2001:DB8:0:24::/64 [110/20]
via FE80::207:85FF:FE6B:EA20, Serial0/0.1
OE2 2001:DB8:0:25::/64 [110/20]
via FE80::207:85FF:FE6B:EA20, Serial0/0.1
OE2 2001:DB8:0:26::/64 [110/20]
via FE80::207:85FF:FE6B:EA20, Serial0/0.1
OE2 2001:DB8:0:27::/64 [110/20]
via FE80::207:85FF:FE6B:EA20, Serial0/0.1
Garcia#The subnets keyword is not used with OSPFv3 for IPv6. All IPv6 routing protocols include IPv6 prefixes, which always include the address and the prefix length. Redistribution between protocols includes all prefixes unless filtering is performed to limit the prefixes advertised. Route filtering is discussed in Chapter 13 and Chapter 14.
Griffey also redistributes the routes known via both OSPFv3 processes into RIPng. OSPF 1 routes are advertised with a metric of 5 and OSPF 2 routes are advertised with a metric of 10. Example 11-37 shows Suzuki’s IPv6 route table.
Example 11-37. The RIPng route table shows routes redistributed into RIPng with different metrics.
Suzuki#show ipv6 route rip
IPv6 Routing Table - 19 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 2001:DB8:0:11::/64 [120/11]
via FE80::207:85FF:FE6B:EA20, Ethernet0/0
R 2001:DB8:0:12::/64 [120/11]
via FE80::207:85FF:FE6B:EA20, Ethernet0/0
R 2001:DB8:0:13::/64 [120/11]
via FE80::207:85FF:FE6B:EA20, Ethernet0/0
R 2001:DB8:0:14::/64 [120/11]
via FE80::207:85FF:FE6B:EA20, Ethernet0/0
R 2001:DB8:0:AA01::/64 [120/6]
via FE80::207:85FF:FE6B:EA20, Ethernet0/0
R 2001:DB8:0:AA02::/64 [120/6]
via FE80::207:85FF:FE6B:EA20, Ethernet0/0
R 2001:DB8:0:AA03::/64 [120/6]
via FE80::207:85FF:FE6B:EA20, Ethernet0/0
Suzuki#The routes from Boone have a metric of 6 and the routes from Garcia have a metric of 11.
Route summarization is now going to be configured on Griffey. RIPng does not have a method for summarizing the routes that are advertised into it when redistributing from another protocol, but Griffey’s Ethernet interface connecting to Suzuki can be configured to summarize the RIPng prefixes that are advertised out the interface. OSPFv3 summarizes the RIPng prefixes as they are redistributed into the routing process. Griffey’s configuration is displayed in Example 11-38.
Example 11-38. Griffey summarizes RIPng routes as they are advertised out Ethernet0/0, and also summarizes routes as they are redistributed into OSPFv3.
interface Ethernet 0/0 ipv6 address 2001:db8:0:21::1/64 ipv6 rip Mariners enable ipv6 rip Mariners summary-address 2001:DB8:0:AA00::/62 ipv6 rip Mariners summary-address 2001:DB8:0:10::/61 ! interface Serial 0/0.1 point-to-point ipv6 address 2001:db8:0:31::1/64 ipv6 ospf 1 area 1 ! interface Serial 0/0.4 point-to-point ipv6 address 2001:db8:0:30::1/64 ipv6 ospf 2 area 20 ! ipv6 router ospf 1 redistribute rip Mariners metric-type 1 tag 4 summary-prefix 2001:DB8:0:20::/61 tag 4 ! ipv6 router ospf 2 redistribute rip Mariners summary-prefix 2001:DB8:0:20::/61 ! ipv6 router rip Mariners redistribute ospf 1 metric 5 redistribute ospf 2 metric 10
The new route tables show the summarized routes and show that the more specific routes have been removed (Example 11-39).
Example 11-39. Route tables include summarized routes but no longer include the more specific routes that fall into the summarized range.
Boone#show ipv6 route ospf IPv6 Routing Table - 21 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 OE1 2001:DB8:0:20::/61 [110/84], tag 4 via FE80::207:85FF:FE6B:EA20, Serial0/0.1 Boone# ___________________________________________________________________________ Garcia#show ipv6 route ospf IPv6 Routing Table - 21 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 OE2 2001:DB8:0:20::/61 [110/20] via FE80::207:85FF:FE6B:EA20, Serial0/0.1 Garcia# ___________________________________________________________________________ Suzuki#show ipv6 route rip IPv6 Routing Table - 19 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 2001:DB8:0:10::/61 [120/11] via FE80::207:85FF:FE6B:EA20, Ethernet0/0 R 2001:DB8:0:20::/61 [120/6] via FE80::207:85FF:FE6B:EA20, Ethernet0/0 R 2001:DB8:0:AA00::/62 [120/6] via FE80::207:85FF:FE6B:EA20, Ethernet0/0 Suzuki#
Notice that the summary route 2001:db8:0:20::/61 is being advertised by Griffey to Suzuki. This is the summary route created for the prefixes advertised into OSPFv3. This summary route is being advertised from OSPF back into RIPng. The routers in the RIPng domain will still be able to route to the more specific prefixes correctly. Suzuki’s full IPv6 route table (Example 11-40) shows that the prefixes that are included in the summary 2001:db8:0:20::/61 are directly connected to the router. The router will forward traffic to the more specific prefixes, rather than to the summary. A downside of having this summary re-advertised back into the RIPng domain is that packets destined to an address that falls into the summary range, but does not actually exist in the network, will get forwarded to Griffey before being dropped. The route can be filtered during route redistribution so that only prefixes known to reside in the OSPFv3 domain are advertised into the RIPng domain. Route filtering during redistribution is discussed in Chapter 13 and Chapter 14.
Example 11-40. Suzuki’s RIPng route table shows a summary route and more specific routes that fall within the summary route’s range. The router will forward traffic to the more specific routes when possible.
Suzuki#show ipv6 route
IPv6 Routing Table - 19 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 2001:DB8:0:10::/61 [120/11]
via FE80::207:85FF:FE6B:EA20, Ethernet0/0
R 2001:DB8:0:20::/61 [120/6]
via FE80::207:85FF:FE6B:EA20, Ethernet0/0
C 2001:DB8:0:21::/64 [0/0]
via ::, Ethernet0/0
L 2001:DB8:0:21::2/128 [0/0]
via ::, Ethernet0/0
C 2001:DB8:0:22::/64 [0/0]
via ::, Serial0/0
L 2001:DB8:0:22::1/128 [0/0]
via ::, Serial0/0
C 2001:DB8:0:23::/64 [0/0]
via ::, Serial0/0
L 2001:DB8:0:23::1/128 [0/0]
via ::, Serial0/0
C 2001:DB8:0:24::/64 [0/0]
via ::, Serial0/0
L 2001:DB8:0:24::1/128 [0/0]
via ::, Serial0/0
C 2001:DB8:0:25::/64 [0/0]
via ::, Serial0/0
L 2001:DB8:0:25::1/128 [0/0]
via ::, Serial0/0
C 2001:DB8:0:26::/64 [0/0]
via ::, Serial0/0
L 2001:DB8:0:26::1/128 [0/0]
via ::, Serial0/0
C 2001:DB8:0:27::/64 [0/0]
via ::, Serial0/0
L 2001:DB8:0:27::1/128 [0/0]
via ::, Serial0/0
R 2001:DB8:0:AA00::/62 [120/6]
via FE80::207:85FF:FE6B:EA20, Ethernet0/0
L FE80::/10 [0/0]
via ::, Null0
L FF00::/8 [0/0]
via ::, Null0
Suzuki#In the network of Figure 11-12, Aaron is running IS-IS, Williams is running RIPv1 for IPv4 and RIPng for IPv6, and Mays is redistributing.
Mays’s IS-IS and RIP IPv4 and IPv6 configuration is displayed in Example 11-41.
Example 11-41. Mays is configured for IS-IS, RIP, and RIPng.
interface Ethernet1 description to Williams ip address 10.2.1.1 255.255.255.0 ipv6 address 2001:db8:0:21::1/64 ipv6 rip baseball enable ! interface Ethernet0 description to Aaron ip address 10.1.4.2 255.255.255.0 ip router isis ipv6 address 2001:db8:0:14::2/64 ipv6 router isis router rip passive-interface Ethernet0 network 10.0.0.0 redistribute isis level-1-2 metric 1 ! router isis net 01.0001.0000.0c76.5432.00 redistribute rip metric 0 metric-type internal level-2 address-family ipv6 redistribute rip baseball metric 0 metric-type internal level-2 ! ipv6 router rip baseball redistribute isis level-1-2 metric 1
Routes may be redistributed into IS-IS with either internal or external metrics (internal is the default) and as either level 1 or level 2 routes (level 2 is the default). The metric type determines the base metric value of the redistributed routes. The metric value of an internal metric type will be lower then 64. The metric value of an external metric will be between 64 and 128. If the metric type is internal, the initial metric of the redistributed route will be the number specified by the metric value (0 in this example), or 0 if no metric is specified. The redistributed route in this example gets added to Mays’s IS-IS database entry with a metric of 0. If the metric value of 5 were specified, the entry in Mays’s IS-IS database would be 5. An external type of metric starts with a base value of 64. If the metric value of 5 is specified, the metric value for the entry in Mays’s IS-IS database would be 64 + 5, or 69. In the example shown, the RIP routes are redistributed as internal, level 2 routes with the default metric of 0. Example 11-42 shows the redistributed routes in Aaron’s IPv4 route table, and Example 11-43 shows the redistributed route in the IPv6 route table.
Example 11-42. Aaron’s IPv4 route table shows the redistributed RIP routes.
Aaron#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 10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks C 10.1.3.0/24 is directly connected, Ethernet4 i L2 10.2.1.0/24 [115/10] via 10.1.4.2, Ethernet0 i L2 10.2.2.0/24 [115/10] via 10.1.4.2, Ethernet0 C 10.1.1.0/24 is directly connected, Ethernet1 C 10.1.4.0/24 is directly connected, Ethernet0 C 10.1.2.160/28 is directly connected, Ethernet2 C 10.1.2.224/28 is directly connected, Ethernet3 Aaron#
Example 11-43. Aaron’s IPv6 route table shows the redistributed RIP routes.
Aaron#show ipv6 route isis
IPv6 Routing Table - 13 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
I2 2001:DB8:0:22::/64 [115/10]
via FE80::204:C1FF:FE50:E700, Ethernet0
Aaron#The IPv6 route table on Aaron shows that the address connected to Mays, 2001:db8:0:21::/64, is not advertised into IS-IS. An additional command, redistribute connected, is added to Mays in Example 11-44 to redistribute the connected addresses, and the resulting IPv6 route table is shown in Example 11-45.
Example 11-44. redistribute connected is added to Mays, so the directly connected IPv6 prefix can be advertised into IS-IS.
router isis net 01.0001.0000.0c76.5432.00 redistribute rip metric 0 metric-type internal level-2 address-family ipv6 redistribute rip baseball metric 0 metric-type internal level-2 redistribute connected metric 0 metric-type internal level-2 ! ipv6 router rip baseball redistribute isis level-1-2 metric 1 redistribute connected metric 1
Example 11-45. Aaron’s IPv6 route table shows redistributed RIP and connected addresses.
Aaron#show ipv6 route isis
IPv6 Routing Table - 14 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
I2 2001:DB8:0:21::/64 [115/10]
via FE80::204:C1FF:FE50:E700, Ethernet0
I2 2001:DB8:0:22::/64 [115/10]
via FE80::204:C1FF:FE50:E700, Ethernet0
Aaron#Because 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, as in Example 11-46.
Example 11-46. Mays configures the routes redistributed from RIP to IS-IS to external routes.
router isis redistribute rip metric 0 metric-type external level-2 net 01.0001.0000.0c76.5432.00 address-family ipv6 redistribute rip baseball metric 0 metric-type external level-2 redistribute connected metric 0 metric-type external level-2 ! router rip redistribute isis level-1-2 metric 1 passive-interface Ethernet0 network 10.0.0.0 ! ipv6 router rip baseball redistribute isis level-1-2 metric 1 redistribute connected metric 1
Example 11-47 shows Aaron’s IPv4 route table after the change. The only change from Example 11-42 is that the metrics of the redistributed routes have increased to greater than 64, indicating (in this small network) external routes. Example 11-48 displays the IS-IS database entry for Mays. The entries for the redistributed routes are shown as IP-External and IPv6-Ext.
Example 11-47. 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.
Aaron#show ip route Codes: C - connected, S - static, 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 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route Gateway of last resort is not set 10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks C 10.1.3.0/24 is directly connected, Ethernet4 i L2 10.2.1.0/24 [115/74] via 10.1.4.2, Ethernet0 i L2 10.2.2.0/24 [115/74] via 10.1.4.2, Ethernet0 C 10.1.1.0/24 is directly connected, Ethernet1 C 10.1.4.0/24 is directly connected, Ethernet0 C 10.1.2.160/28 is directly connected, Ethernet2 C 10.1.2.224/28 is directly connected, Ethernet3 Aaron#
Example 11-48. Redistributed routes are displayed as IP-External and IPv6-Ext in Mays’s IS-IS database.
Mays# show isis database detail level-2 Mays.00-00
IS-IS Level-2 LSP Mays.00-00
LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL
Mays.00-00 * 0x0000005F 0xA0E5 1186 0/0/0
Area Address: 01.0001
NLPID: 0xCC 0x8E
Hostname: Mays
IP Address: 10.1.4.2
IPv6 Address: 2001:DB8:0:14::2
Metric:10 IS Aaron.00
Metric:20 IP 10.1.3.0 255.255.255.0
Metric:64 IP-External 10.2.1.0 255.255.255.0
Metric:64 IP-External 10.2.2.0 255.255.255.0
Metric:20 IP 10.1.1.0 255.255.255.0
Metric:10 IP 10.1.4.0 255.255.255.0
Metric:20 IP 10.1.2.160 255.255.255.240
Metric:20 IP 10.1.2.224 255.255.255.240
Metric:20 IPv6 2001:DB8:0:11::/64
Metric:20 IPv6 2001:DB8:0:13::/64
Metric:10 IPv6 2001:DB8:0:14::/64
Metric:0 IPv6-Ext 2001:DB8:0:21::/64
Metric:0 IPv6-Ext 2001:DB8:0:22::/64
Metric:20 IPv6 2001:DB8:0:12A::/64
Metric:20 IPv6 2001:DB8:0:12B::/64
Mays#Another look at Figure 11-12 shows that both subnets of the RIP domain, IPv4 and IPv6, can be summarized with a single address of 10.2.0.0/16 and 2001:db8:0:20::/62. IPv4 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 can also be specified. If the level is not specified, the addresses will be summarized into level 2. As with OSPFv3 for IPv6, IPv6 routes are summarized into IS-IS using the summary-prefix command for the IPv6 address-family. In the configuration in Example 11-49, RIP IPv4 routes are redistributed as level 1 and summarized, and RIPng IPv6 routes are redistributed as level 2 and summarized.
Example 11-49. Mays summarizes the RIP routes after they have been redistributed into IS-IS.
router isis summary-address 10.2.0.0 255.255.0.0 level-1 redistribute rip metric 0 metric-type external level-1 net 01.0001.0000.0c76.5432.00 address-family ipv6 redistribute rip baseball metric 0 metric-type external level-2 redistribute connected metric 0 metric-type external level-2 summary-prefix 2001:db8:0:20::/62 level-2 router rip redistribute isis level-1-2 metric 1 passive-interface Ethernet0 network 10.0.0.0 ! ipv6 router rip baseball redistribute isis level-1-2 metric 1 redistribute connected metric 1
Example 11-50 shows the summary route in Aaron’s IPv4 route table. Example 11-51 shows Aaron’s IPv6 route table. Like OSPF and EIGRP, the summarization causes more-specific routes in the summary range to be suppressed.
Example 11-50. Aaron’s IPv4 route table with a level-1 summary route to the subnets within the RIP domain.
Aaron#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 10.0.0.0/8 is variably subnetted, 6 subnets, 3 masks i L1 10.2.0.0/16 [115/138] via 10.1.4.2, Ethernet0 C 10.1.3.0/24 is directly connected, Ethernet4 C 10.1.1.0/24 is directly connected, Ethernet1 C 10.1.4.0/24 is directly connected, Ethernet0 C 10.1.2.160/28 is directly connected, Ethernet2 C 10.1.2.224/28 is directly connected, Ethernet3 Aaron#
Example 11-51. Aaron’s IPv6 route table with a level-2 summary route to the subnets within the RIP domain.
Aaron#show ipv6 route isis
IPv6 Routing Table - 13 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
I2 2001:DB8:0:20::/62 [115/10]
via FE80::204:C1FF:FE50:E700, Ethernet0
Aaron#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.
Example 11-52 shows the route table of Williams in Figure 11-12. 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’s 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.
Example 11-52. The routes with subnets other than /24 are not redistributed into the RIP domain.
Williams#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
10.0.0.0/8 is subnetted, 5 subnets
R 10.1.3.0 [120/1] via 10.2.1.2, 00:00:01, Ethernet0
C 10.2.1.0 is directly connected, Ethernet0
R 10.1.1.0 [120/1] via 10.2.1.2, 00:00:02, Ethernet0
C 10.2.2.0 is directly connected, Ethernet1
R 10.1.4.0 [120/1] via 10.2.1.2, 00:00:02, Ethernet0
Williams#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, as displayed in Example 11-53.
Example 11-53. Mays is configured with a static route to create a summarized route for IPv4 subnets. The static route is redistributed into RIP.
router isis summary-address 10.2.0.0 255.255.0.0 level-1 redistribute rip metric 0 metric-type external level-1 net 01.0001.0000.0c76.5432.00 ! router rip redistribute static metric 1 redistribute isis level-1-2 metric 1 passive-interface Ethernet0 network 10.0.0.0 ! ip route 10.1.2.0 255.255.255.0 10.1.4.1
Example 11-54 shows Williams’s route table with the summary route included.
Example 11-54. Subnets 10.1.2.160/28 and 10.1.2.224/28 have been summarized with the address 10.1.2.0/24.
Williams#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 10.0.0.0/8 is subnetted, 6 subnets R 10.1.3.0 [120/1] via 10.2.1.2, 00:00:03, Ethernet0 R 10.1.2.0 [120/1] via 10.2.1.2, 00:00:03, Ethernet0 C 10.2.1.0 is directly connected, Ethernet0 R 10.1.1.0 [120/1] via 10.2.1.2, 00:00:03, Ethernet0 C 10.2.2.0 is directly connected, Ethernet1 R 10.1.4.0 [120/1] via 10.2.1.2, 00:00:03, Ethernet0 Williams#
As discussed in Chapter 3, 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 as displayed in Example 11-55.
Example 11-55. Mays is configured with a static route pointing out an interface rather then to a next-hop address.
router isis summary-address 10.2.0.0 255.255.0.0 level-1 redistribute rip metric 0 metric-type external level-1 net 01.0001.0000.0c76.5432.00 ! router rip redistribute isis level-1-2 metric 1 passive-interface Ethernet0 network 10.0.0.0 ! ip route 10.1.2.0 255.255.255.0 Ethernet0
Here the static route now points to Mays’s 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’s route table still looks the same as in Example 11-54.
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 (Example 11-56). 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.
Example 11-56. Mays considers the summary address 10.1.2.0/24 to be directly connected to Ethernet 0.
Mays#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 10.0.0.0/8 is variably subnetted, 8 subnets, 2 masks i L1 10.1.3.0/24 [115/20] via 10.1.4.1, Ethernet0 S 10.1.2.0/24 is directly connected, Ethernet0 C 10.2.1.0/24 is directly connected, Ethernet1 i L1 10.1.1.0/24 [115/20] via 10.1.4.1, Ethernet0 R 10.2.2.0/24 [120/1] via 10.2.1.1, 00:00:21, Ethernet1 C 10.1.4.0/24 is directly connected, Ethernet0 i L1 10.1.2.160/28 [115/20] via 10.1.4.1, Ethernet0 i L1 10.1.2.224/28 [115/20] via 10.1.4.1, Ethernet0 Mays#
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.
Recall that when the summarization commands are used, they create an entry in the route table to Null 0.
The same can and should be done with static summary routes (see Example 11-57).
Example 11-57. Mays’s static summary route now points to the null interface.
router isis summary-address 10.2.0.0 255.255.0.0 level-1 redistribute rip metric 0 metric-type external level-1 net 01.0001.0000.0c76.5432.00 ! router rip redistribute isis level-1-2 metric 1 passive-interface Ethernet0 network 10.0.0.0 ! ip route 10.1.2.0 255.255.255.0 Null0
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.
This chapter touches on several problems that can arise when redistributing routes. Avoiding or correcting trouble in all but the simplest redistribution schemes usually involves the use of route filters, which are discussed in Chapter 13, or route maps, discussed in Chapter 14. Those chapters include examples of more complex redistribution schemes and how to troubleshoot them. First, though, Chapter 12 examines default routes—which may be thought of as the most generic form of summary routes.
Command | Description |
|---|---|
default-metric bandwidth delay reliability load mtu | Specifies a default metric to be associated with routes redistributed into IGRP and EIGRP |
default-metric number | Specifies a default metric to be associated with routes redistributed into RIP and OSPF |
ip summary-address eigrp autonomous-system-number address mask | Configures an EIGRP summary route on an interface |
redistribute connected | Redistributes all directly connected networks |
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 redistribution into a routing protocol and specifies the source of the redistributed routes |
summary-address address mask {level-1| level-1-2| level-2} prefix mask [not-advertise] [tag tag] | Configures route summarization for IS-IS and OSPF |
summary-prefix prefix/length {level-1| level-1-2| level-2} | Configures route summarization for IS-IS for IPv6 |
summary-prefix prefix/length[not-advertise| tag tag-value] | Configures route summarization for OSPFv3 for IPv6 |
Router A in Figure 11-13 is running OSPFv2 and v3, and router C is running RIPv1 and RIPng. Write a configuration for router B that will provide full connectivity for all subnets. | |
Configure IPv6 summarization on router B in Figure 11-13 wherever possible. | |
Router A in Figure 11-13 is running IS-IS for both IPv4 and IPv6 and router C is running EIGRP for IPv4, and RIPng for IPv6. At router B, all the IS-IS routes are level 1. Configure mutual redistribution at router B by using summarization wherever possible. The EIGRP routes should be advertised into the IS-IS domain as external routes. |
In the case study “Redistributing IGRP and RIP,” the following configuration is given for router Mantle of Figure 11-8: router rip redistribute igrp 1 metric 5 passive-interface Ethernet1 network 10.0.0.0 ! router igrp 1 redistribute connected redistribute rip default-metric 1000 100 255 1 1500 passive-interface Ethernet0 network 10.0.0.0 Will the RIP domain know about the stub network 192.168.10.0/24 by virtue of the fact that it is redistributed into IGRP, which is then redistributed into RIP? | |
In Troubleshooting Exercise 1, if the redistribute rip command is eliminated under the IGRP configuration, will the redistribute connected command be sufficient to advertise the RIP domain? | |
In Example 11-21, why isn’t subnet 192.168.3.32/27 tagged as an EIGRP external route? | |
In Example 11-21, there is a summary route to 192.168.3.0. What caused this entry? | |
Given the following configuration, will a level-1 router in area 1 know about the summary route? Router A: router isis net 01.0001.0000.0c76.5432.00 address-family ipv6 redistribute rip baseball metric-type external summary-prefix 2001:db8:0:20::/62 level-1 |