Route Redistribution - Route Redistribution and Selection - CCNP Routing and Switching ROUTE 300-101 Official Cert Guide (2015)

CCNP Routing and Switching ROUTE 300-101 Official Cert Guide (2015)

Part III. Route Redistribution and Selection

Chapter 10. Route Redistribution

This chapter covers the following subjects:

Image Route Redistribution Basics: This section discusses the reasons why designers might choose to use route redistribution, and how routing protocols redistribute routes from the IP routing table.

Image Redistribution in EIGRP: This section discusses the mechanics of how Cisco IOS redistributes routes from other sources into EIGRP.

Image Redistribution in OSPF: This section discusses the mechanics of how Cisco IOS redistributes routes from other sources into OSPF.

Image Redistribution with Route Maps and Distribution Lists: This section focuses on the functions available using route maps and distribute lists on the same router that performs redistribution into either EIGRP or OSPF.

Image Issues with Multiple Redistribution Points: This section examines the domain loop problem that can occur when multiple routers redistribute routes between the same two routing domains. This section also examines various solutions, including the setting of large metrics, setting the administrative distance, and using route tags.

This chapter examines how routers can exchange routes between routing protocols through route redistribution. Specifically, this chapter begins by discussing the mechanics of what happens when the routes are redistributed. Then the discussion shifts to filtering and summarizing routes when redistributing, along with typical issues and solutions when multiple routers redistribute the same routes.

This chapter examines how routers can exchange routes between routing protocols through route redistribution. Specifically, this chapter begins by discussing the mechanics of what happens when the routes are redistributed. Then the discussion shifts to filtering and summarizing routes when redistributing, along with typical issues and solutions when multiple routers redistribute the same routes.

This chapter then looks at the methods by which a router can manipulate the routes being redistributed, beyond the settings of the metrics. This manipulation includes the filtering of routes and the setting of other values that can be associated with a route during the redistribution process.

Next, this chapter examines a variety of design issues that occur when multiple redistribution points exist between routing domains. Many designs use multiple redistribution points for redundancy and even for load sharing. This redundancy creates some additional complexity. (This complexity has long been a favorite topic for the CCIE R/S Lab.) This chapter also shows methods of dealing with the design issues, including the manipulation of metrics, administrative distance, and route tags.

“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz allows you to assess whether you should read the entire chapter. If you miss no more than two of these 16 self-assessment questions, you might want to move ahead to the “Exam Preparation Tasks” section. Table 10-1 lists the major headings in this chapter and the “Do I Know This Already?” quiz questions covering the material in those headings so that you can assess your knowledge of these specific areas. The answers to the “Do I Know This Already?” quiz appear in Appendix A.

Image

Table 10-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping

1. Which of the following answers is the least likely reason for an engineer to choose to use route redistribution?

a. To exchange routes between merged companies

b. To give separate control over routing to different parts of one company

c. To support multiple router vendors

d. To knit together an OSPF area if the area becomes discontiguous

2. For a router to successfully redistribute routes between OSPF and EIGRP, which of the following are true? (Choose two.)

a. The router must have one routing protocol configured, but configuration for both routing protocols is not necessary.

b. The router must have at least one working link connected to each routing domain.

c. The redistribute command must be configured under EIGRP to send the routes to OSPF.

d. The redistribute command should be configured under OSPF to take routes from EIGRP into OSPF.

3. Process EIGRP 1 is redistributing routes from process OSPF 2. Which of the following methods can be used to set the metrics of the redistributed routes? (Choose two.)

a. Let the metrics default.

b. Set the metric components using the redistribute command’s metric keyword.

c. Set the metric components using the default-metric subcommand under router configuration mode.

d. Set the integer (composite) metric using the redistribute command’s metric keyword.

4. Examine the following excerpt from the show ip eigrp topology 10.2.2.0/24 command on Router R1. Which answer can be verified as definitely true based on this output?

External data:
Originating router is 10.1.1.1
AS number of route is 1
External protocol is OSPF, external metric is 64
Administrator tag is 0 (0x00000000)

a. R1 is the router that redistributed the route.

b. R1’s metric to reach subnet 10.2.2.0/24 is 64.

c. The route was redistributed on a router that has a router ospf 1 command configured.

d. R1 is redistributing a route to prefix 10.2.2.0/24 into OSPF.

5. Router R1 has a connected route for 10.1.1.0/24 off interface Fa0/0. Interface Fa0/0 has been enabled for OSPF because of a router ospf 1 and network 10.1.1.0 0.0.0.255 area 0 command. R1 also has EIGRP configured, with the redistribute ospf 1 metric 1000 100 10 1 1500command configured under EIGRP. Which of the following is true?

a. R1 will not redistribute 10.1.1.0/24 into EIGRP, because R1 knows it as a connected route and not as an OSPF route.

b. For any OSPF routes redistributed into EIGRP, the metric components include a value equivalent to 1 Mbps of bandwidth.

c. For any OSPF routes redistributed into EIGRP, the metric components include a value equivalent to 100 microseconds of delay.

d. No subnets of network 10.1.1.0 will be redistributed because of the omission of the subnets parameter.

6. Process OSPF 1 is redistributing routes from process OSPF 2. Which of the following methods can be used to set the metrics of the redistributed routes? (Choose two.)

a. Let the metrics default.

b. Use each redistributed route’s OSPF metric using the redistribute command’s metric transparent keywords.

c. Set the metric using the default-metric subcommand under router configuration mode.

d. Redistribution is not allowed between two OSPF processes.

7. Examine the following excerpt from the show ip ospf database asbr-summary command on Router R1 (RID 1.1.1.1). Which answer can be verified as definitely true based on this output?

LS Type: Summary Links (AS Boundary Router)
Link State ID: 9.9.9.9 (AS Boundary Router address)
Advertising Router: 3.3.3.3
LS Seq Number: 8000000D
Checksum: 0xE43A
Length: 28
Network Mask: /0
TOS: 0 Metric: 100

a. The output describes the contents of a Type 5 LSA.

b. 3.3.3.3 identifies a router as being the router performing redistribution.

c. R1’s metric for its best route to reach the router with RID 9.9.9.9 is 100.

d. The router with RID 3.3.3.3’s metric for its best route to reach the router with RID 9.9.9.9 is 100.

8. Router R1 sits inside OSPF area 1. Router R2 redistributes an E1 route into OSPF for prefix 2.2.2.0/24, with external metric 20. Router R22 redistributes an E2 route for the same prefix/length, external metric 10. Under what conditions will R1 choose as its best route the route through R22?

a. R1 will always choose the route through R22.

b. As long as R1’s best internal OSPF cost to reach R22 is less than 10.

c. As long as R1’s best internal OSPF cost to reach R22 is less than 20.

d. R1 will never choose the route through R22 if the E1 route through R2 is available.

9. Router R1 has been configured with the redistribute ospf 1 route-map fred command under router eigrp 1. The route map named fred needs to be configured to match routes to determine which routes are redistributed into EIGRP. Which of the following answers lists an item that cannot be matched by route map fred?

a. Subnet number

b. Next-hop router IP address of the route

c. Whether the route is an E1 or E2 route

d. The route’s tag

e. The number of router hops between the router and the subnet

10. Router R1 refers to route map fred when redistributing from EIGRP into OSPF. The entire route map is listed next. Which of the following answers must be true based on the configuration as shown?

route-map fred deny 10
match ip address one
route-map fred deny 20
match ip address two
route-map fred permit 100

a. The third route map clause will allow any routes not already filtered by the first two clauses.

b. Routes permitted by ACL “two” will be redistributed.

c. Routes denied by ACL “one” will be redistributed.

d. All routes will be filtered.

11. On Router R1, process EIGRP 1 is redistributing routes from process OSPF 2, calling route map fred with the redistribute ospf 2 route-map fred command. R1 has learned intra-area routes for 10.1.1.0/24 and 10.1.2.0/24 in part because of the Type 2 LSAs known for each subnet. The route map filters route 10.1.1.0/24 and allows 10.1.2.0/24 through. Which of the following commands on Router R1 list subnet 10.1.1.0/24? (Choose two.)

a. show ip route

b. show ip eigrp topology

c. show ip ospf database

d. show ip eigrp topology 10.1.1.0/24

12. Router R1 is redistributing between two OSPF processes. Given the configuration shown, which includes all commands in the route map named fred, which of the following answers is true regarding the redistribution into OSPF process 1?

router ospf 1
redistribute ospf 2 match external 2 route-map fred
!
route-map fred permit 10
match ip address 1
set metric-type type-1

a. No routes are redistributed because a route cannot be both E1 and E2.

b. Only OSPF E2 routes in the OSPF 2 domain will be considered for redistribution.

c. Inside the OSPF 2 domain, any formerly E2 routes will become E1 routes.

d. Routes permitted by ACL 1 will be redistributed, regardless of whether the routes are E1 or E2 routes.

13. Which of the following is not true regarding Cisco IOS default settings for administrative distance?

a. EIGRP internal: 90

b. OSPF external: 110

c. EIGRP external: 90

d. RIP: 120

e. OSPF internal: 110

14. A network includes a RIPv2 domain, an EIGRP domain, and an OSPF domain. Each pair of routing domains has multiple routers redistributing routes between the pair of domains. The design requires that the redistribution configuration avoid matching based on prefix/length because of the trouble in maintaining such configurations. Which of the following tools can be used in all three routing domains to attempt to prevent domain loops? (This book uses the term domain loop to refer to the long routes that might be chosen for routes when redistribution exists—for example, a route might forward packets from the EIGRP domain, to the OSPF domain, back to EIGRP, and then to subnet X in the RIP domain.)

a. Setting route tags

b. Setting the default administrative distance differently for internal and external routes

c. Setting administrative distance differently per route

d. Setting metrics much higher for all external routes than for all internal routes

15. A coworker is developing an implementation plan for a design that uses OSPF 2 and RIPv2 routing domains, with two routers redistributing between the two domains. The coworker asks your help in choosing how to prevent domain loops by setting administrative distance. Assuming that all other related settings use defaults, which of the following would solve the domain loop problem?

a. The distance ospf intra-area 80 inter-area 80 OSPF subcommand

b. The distance ospf external 80 OSPF subcommand

c. The distance ospf intra-area 180 inter-area 180 OSPF subcommand

d. The distance ospf external 180 OSPF subcommand

16. Router R1 sets a route tag for subnet 10.1.1.0/24 when redistributing from OSPF into EIGRP. Which of the following units is assigned to the route tag?

a. Kilobits/second

b. Tens-of-microseconds

c. Cost

d. Hop count

e. No units assigned

Foundation Topics

Route Redistribution Basics

Most internetworks use a single interior gateway protocol (IGP) to advertise and learn IP routes. However, in some cases, more than one routing protocol exists inside a single enterprise. Also, in some cases, the routes learned with an IGP must then be advertised with Border Gateway Protocol (BGP), and vice versa. In such cases, engineers often need to take routing information learned by one routing protocol and advertise those routes into the other routing protocol—a function provided by the Cisco IOS route redistribution feature.

This section examines the basics of route redistribution.

The Need for Route Redistribution

The potential need for route redistribution exists when a route learned through one source of routing information, most typically one routing protocol, needs to be distributed into a second routing protocol domain. For example, two companies might merge, with one company using Enhanced Interior Gateway Routing Protocol (EIGRP) and the other using Open Shortest Path First (OSPF). The engineers could choose to immediately migrate away from OSPF to instead use EIGRP exclusively, but that migration would take time and potentially cause outages. Route redistribution allows those engineers to connect a couple of routers to both routing domains, and exchange routes between the two routing domains, with a minimal amount of configuration and with little disruption to the existing networks.

Figure 10-1 shows just such a case, with R1 performing redistribution by using its knowledge of subnet 1 from the EIGRP domain and advertising a route for subnet 1 into the OSPF domain. Note that the opposite should also occur, with the OSPF domain’s subnet 2 being redistributed into the EIGRP domain.

Image

Figure 10-1 Typical Use of Redistribution

The main technical reason for needing redistribution is straightforward: An internetwork uses more than one routing protocol, and the routes need to be exchanged between those routing domains, at least temporarily. The business reasons vary widely but include the following:

Image Mergers when different IGPs are used.

Image Mergers when the same IGP is used.

Image Momentum (The enterprise has been using multiple routing protocols for a long time.)

Image Different company divisions are under separate control for business or political reasons.

Image Connections between partners.

Image Between IGPs and BGP when BGP is used between large segments of a multinational company.

Image Layer 3 WAN (Multiprotocol Label Switching [MPLS]).

The list begins with two entries for mergers just to make the point that even if both merging companies use the same IGP, redistribution can still be useful. Even if both companies use EIGRP, they probably use a different autonomous system number (ASN) in their EIGRP configuration (with the router eigrp asn command). In such a case, to have all routers exchange routing information with EIGRP, all the former company’s routers would need to migrate to use the same ASN as the first company. Such a migration might be simple, but it still requires disruptive configuration changes in a potentially large number of routers. Redistribution could be used until a migration could be completed.

Although useful as an interim solution, many permanent designs use redistribution as well. For example, it could be that a company has used different routing protocols (or different instances of the same routing protocol) in different divisions of a company. The network engineering groups can remain autonomous, and manage their own routing protocol domains, using redistribution to exchange routes at a few key connecting points between the divisions. Similarly, partner companies have separate engineering staffs, and want autonomy for managing routing, but also need to exchange routes for key subnets to allow the partnership’s key applications to function. Figure 10-2 depicts both of these cases.

Image

Figure 10-2 Permanent Uses for Route Redistribution

The last two cases in the previous list each relate to BGP in some way. First, some large corporations actually use BGP internal to the company’s internetwork, redistributing routes from IGPs. Each large autonomous division of the company can design and configure its respective routing protocol instance, redistribute into BGP, and then redistribute out of BGP into other divisions. Also, when an enterprise uses an MPLS Virtual Private Network (VPN) service, the MPLS provider’s provider edge (PE) router typically redistributes customer routes with BGP inside the MPLS provider’s MPLS network. Figure 10-3 shows samples of both these cases. In each of these cases, a given prefix/length (subnet/mask) is typically distributed into BGP at one location, advertised over a BGP domain, and redistributed back into some IGP.

Image

Figure 10-3 Using Redistribution to Pass Routes Using BGP

Redistribution Concepts and Processes

Route redistribution requires at least one router to do the following:

Image

Image Use at least one working physical link with each routing domain.

Image A working routing protocol configuration for each routing domain.

Image Additional redistribution configuration for each routing protocol, specifically the redistribute command, which tells the routing protocol to take the routes learned by another source of routing information and to then advertise those routes.

The first two steps do not require any new knowledge or commands, but the third step represents the core of the redistribution logic and requires some additional background information. To appreciate the third step, Figure 10-4 shows an example router, RD1, which has met the first two requirements. RD1 uses EIGRP on the left and OSPF on the right, and has learned some routes with each routing protocol (Steps 1 and 2). However, no redistribution has yet been configured.

Image

Figure 10-4 Routing Protocol Tables on a Router Doing Redistribution

The goal for redistribution in this case is to have EIGRP advertise subnets 11, 12, and 13, which exist inside the OSPF domain, and have OSPF advertise subnets 1, 2, and 3, which exist inside the EIGRP domain. To do that, EIGRP must put topology information about subnets 11, 12, and 13 into its EIGRP topology table, and OSPF must put topology information about subnets 1, 2, and 3 into its topology table. However, OSPF’s topology table has a lot of different information in it compared to EIGRP’s topology table. OSPF has link-state advertisements (LSA) and EIGRP does not. EIGRP lists the components of the composite metric and the neighbor’s reported distance (RD)—but OSPF does not. In short, EIGRP and OSPF differ significantly in the contents of their topology tables.

Because the details of various routing protocols’ topology tables differ, the redistribution process does not use the topology tables when redistributing routes. Instead, redistribution uses the one table that both routing protocols understand: the IP routing table. Specifically, the Cisco IOSredistribute command takes routes from the IP routing table and passes those routes to a routing protocol for redistribution. The redistribute command, configured inside a routing protocol configuration mode, redistributes routes into that routing protocol from some other source. Figure 10-5 spells it out with an example, which focuses on the internal logic of Router RD1 as shown in Figure 10-4.

Image

Figure 10-5 Mutual Redistribution Between OSPF and EIGRP on Router RD1

Starting on the left of the figure, RD1’s EIGRP 1 process configuration lists the redistribute ospf 2 command. This command tells RD1 to look in the IP routing table, take all OSPF routes added to the IP routing table by the OSPF 2 process on RD1, and put those routes into EIGRP’s topology table. Conversely, the redistribute eigrp 1 command configured on the OSPF process tells RD1 to take IP routes from the IP routing table, if learned by EIGRP process 1, and add those routes to OSPF 2’s topology table.

The process works as shown in Figure 10-5, but the figure leaves out some important details regarding the type of routes and the metrics used. For EIGRP, the EIGRP topology table needs more than the integer metric value held by the IP routing table—it needs values for the components of the EIGRP composite metric. EIGRP can use default settings that define the metric components for all routes redistributed into EIGRP, or the engineer can set the metric components in a variety of ways, as covered in several locations later in this chapter.

Like EIGRP, OSPF treats the redistributed routes as external routes. OSPF creates an LSA to represent each redistributed subnet—normally a Type 5 LSA, but when redistributed into a not-so-stubby area (NSSA), the router instead creates a Type 7 LSA. In both cases, OSPF needs an integer metric to assign to the external route’s LSA. The redistribution configuration should include the OSPF cost setting, which might or might not match the metric listed for the route in the redistributing router’s IP routing table.

The last concept, before moving on to the configuration options, is that the redistribute command tells the router to take not only routes learned by the source routing protocol but also connected routes on interfaces enabled with that routing protocol—including passive interfaces. Example 10-1, later in this chapter, demonstrates this concept.

Redistribution into EIGRP

This section looks at the specifics of how EIGRP performs redistribution—that is, how EIGRP takes routes from other routing sources, such as OSPF, and advertises them into EIGRP. In real life, engineers often use both route filtering and route summarization at the redistribution point on a router. However, for the sake of making the underlying concepts clear, this portion of the chapter focuses on the mechanics of redistribution, without filtering, or summarization, or any other changes to the redistributed routes. This chapter later looks at the interesting options for manipulating routes at the redistribution point.

This section begins with a couple of short discussions of reference information. The first topic summarizes the parameters of the main configuration command, the EIGRP redistribute command. Next, the baseline configuration used in the upcoming samples is listed, including all EIGRP and OSPF configuration, but no redistribution configuration. With those details listed for reference, the rest of this section examines the configuration of redistribution into EIGRP.

EIGRP redistribute Command Reference

First, for reference, the following lines show the generic syntax of the redistribute command when used as a router eigrp subcommand. Note that the syntax differs slightly depending on the routing protocol into which routes will be redistributed. Following that, Table 10-2 lists the options on the command with a brief description.

redistribute protocol [process-id | as-number] [metric bw delay reliability load
mtu
] [match {internal | nssa-external | external 1 | external 2}] [tag tag-value]
[route-map name]

Image

Image

Table 10-2 Parameters of the EIGRP redistribute Command

Baseline Configuration for EIGRP Redistribution Examples

The best method to see the results of redistribution is to use examples, so this section explains the sample internetwork used in the upcoming EIGRP redistribution examples. Figure 10-6 shows the sample internetwork. In this case, the EIGRP domain on the left uses subnets of Class B network 172.30.0.0, and the OSPF domain on the right uses subnets of Class B network 172.16.0.0. Note that all OSPF subnets reside in area 0 in this example internetwork, although that is not a requirement.

Image

Figure 10-6 Sample Internetwork Used for Redistribution Examples

The internetwork uses a single router (RD1) to perform redistribution, just to avoid some interesting issues that occur when multiple routers redistribute the same routes (issues that are discussed later in this chapter). Example 10-1 shows the configuration on RD1, listing the IP addresses of the four active serial interfaces shown in Figure 10-6, plus the complete but basic EIGRP and OSPF configuration—but without any redistribution configured yet.

Example 10-1 Configuration on Router RD1 Before Adding Redistribution Configuration


interface Serial0/0/0
ip address 172.30.12.1 255.255.255.252
clock rate 1536000
!
interface Serial0/0/1
ip address 172.16.18.1 255.255.255.252
clock rate 1536000
!
interface Serial0/1/0
ip address 172.16.14.1 255.255.255.252
clock rate 1536000
!
interface Serial0/1/1
ip address 172.30.17.1 255.255.255.252
clock rate 1536000
!
router eigrp 1
network 172.30.0.0
no auto-summary
!
router ospf 2
router-id 1.1.1.1
network 172.16.0.0 0.0.255.255 area 0


Configuring EIGRP Redistribution with Default Metric Components

For the internetwork of Figure 10-6, a reasonable design goal would be to redistribute EIGRP routes into OSPF, and OSPF routes into EIGRP. This section examines the case of redistributing the routes into EIGRP from OSPF.

First, consider the EIGRP redistribute command. For those unfamiliar with the command, the direction of redistribution might not be obvious. A better command name might have been “take-routes-from,” because the first parameter after the command tells Cisco IOS from where to get the routes.

For example, consider the configuration in Example 10-2, which was added to RD1’s existing configuration in Example 10-1. The configuration uses only required parameters; namely, a reference to the source from which routes should be redistributed. Because the configuration places this command in EIGRP configuration mode, the command tells Cisco IOS to redistribute the routes into EIGRP 1, from OSPF 2 in this case.

Example 10-2 Minimal Configuration for Redistribution from OSPF into EIGRP


RD1# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
RD1(config)# router eigrp 1
RD1(config-router)# redistribute ospf 2
RD1(config-router)# end


Cisco IOS does accept the configuration. Unfortunately, Cisco IOS does not actually redistribute routes from OSPF into EIGRP in this case. EIGRP does not have a default setting for the metric components to use when redistributing into EIGRP from OSPF. To confirm these results, examine the output shown in Example 10-3, which lists show command output from RD1 when configured as shown in the previous example. Note that RD1’s EIGRP topology table lists only routes for Class B network 172.30.0.0, which all sit inside the EIGRP domain. None of the routes from Class B network 172.16.0.0, which exist inside the OSPF domain, have been added to RD1’s EIGRP topology table.

Example 10-3 Redistribution Did Not Work on RD1


RD1# show ip eigrp topology
IP-EIGRP Topology Table for AS(1)/ID(172.30.17.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status

P 172.30.17.0/30, 1 successors, FD is 2169856
via Connected, Serial0/1/1
P 172.30.26.0/23, 2 successors, FD is 2172416
via 172.30.12.2 (2172416/28160), Serial0/0/0
via 172.30.17.2 (2172416/28160), Serial0/1/1
P 172.30.2.0/23, 1 successors, FD is 2172416
via 172.30.12.2 (2172416/28160), Serial0/0/0
via 172.30.17.2 (2174976/30720), Serial0/1/1
P 172.30.6.0/23, 1 successors, FD is 2172416
via 172.30.17.2 (2172416/28160), Serial0/1/1
via 172.30.12.2 (2174976/30720), Serial0/0/0
P 172.30.12.0/30, 1 successors, FD is 2169856
via Connected, Serial0/0/0


To complete the configuration of redistribution into EIGRP, Router RD1 needs to set the metric values. EIGRP can set the metrics for redistributed routes in three ways, as summarized in Table 10-3.

Image

Image

Table 10-3 Methods of Setting EIGRP Metrics When Redistributing into EIGRP


Note

EIGRP does have a default metric when redistributing from another EIGRP process, in which case it takes the metric from the source of the routing information. In all other cases, the metric must be set using one of the methods in Table 10-3.


If the metrics do not matter to the design, which is likely when only a single redistribution point exists as in Figure 10-6, either of the first two methods listed in Table 10-3 is reasonable. The first method, using the default-metric command in EIGRP configuration mode, sets the metric for all routes redistributed into EIGRP, unless set by one of the other methods. Alternatively, the second method, which uses additional parameters on the redistribute command, sets the metric for all routes redistributed because of that one redistribute command. Finally, if the redistributecommand also refers to a route map, the route map can use the set metric command to set the metric components for routes matched by the route map clause, overriding the metric settings in the default-metric command or with the metric keyword on the redistribute command.

Example 10-4 shows the addition of the default-metric 1000 33 255 1 1500 command to RD1’s configuration. This command sets the bandwidth to 1000 (kbps), the delay to 33 (tens-of-microseconds, or 330 microseconds), the reliability to 255 (a value in the range 1–255, where 255 is best), the load to 1 (a value in the range 1–255, where 1 is best), and the maximum transmission unit (MTU) to 1500. Note that even though EIGRP ignores the last three parameters by default when calculating integer metrics, you still must configure these settings for the commands to be accepted.

Example 10-4 Redistributed Routes in RD1


RD1# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
RD1(config)# router eigrp 1
RD1(config-router)# default-metric 1000 33 255 1 1500
RD1(config-router)# end


Because this example uses a single redistribute command for the EIGRP 1 process, you could have used the redistribute ospf 2 metric 1000 33 255 1 1500 command and ignored the default-metric command to achieve the same goal.

Verifying EIGRP Redistribution

As shown earlier in Figure 10-5, redistribution takes routes from the routing table and places the correct information for those subnets into the redistributing router’s topology table. The redistributing router then advertises the routes from its topology table as it would for other routes. To verify that redistribution works, Example 10-5 shows the proof that RD1 indeed created entries in its EIGRP topology table for the five subnets in the OSPF domain.

Example 10-5 Verifying That RD1 Added EIGRP Topology Data for Five OSPF Subnets


RD1# show ip eigrp topology
IP-EIGRP Topology Table for AS(1)/ID(172.30.17.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status

! Note – all lines for class B network 172.30.0.0 have been omitted for brevity
P 172.16.48.0/25, 1 successors, FD is 2568448
via Redistributed (2568448/0)
P 172.16.18.0/30, 1 successors, FD is 2568448
via Redistributed (2568448/0)
P 172.16.14.0/30, 1 successors, FD is 2568448
via Redistributed (2568448/0)
P 172.16.8.0/25, 1 successors, FD is 2568448
via Redistributed (2568448/0)
P 172.16.4.0/25, 1 successors, FD is 2568448
via Redistributed (2568448/0)
RD1# show ip eigrp topology 172.16.48.0/25
IP-EIGRP (AS 1): Topology entry for 172.16.48.0/25
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2568448
Routing Descriptor Blocks:
172.16.18.2, from Redistributed, Send flag is 0x0
Composite metric is (2568448/0), Route is External
Vector metric:
Minimum bandwidth is 1000 Kbit
Total delay is 330 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 0
External data:
Originating router is 172.30.17.1 (this system)
AS number of route is 2
External protocol is OSPF, external metric is 65
Administrator tag is 0 (0x00000000)


The show command output lists several interesting facts:

Image On Router RD1, which performed the redistribution, the EIGRP topology table lists the outgoing interface as “via redistributed.”

Image All the redistributed routes have the same feasible distance (FD) calculation (2568448), because all use the same component metrics per the configured default-metric command.

Image RD1’s two connected subnets in the OSPF 2 domain—subnets 172.16.14.0/30 and 172.16.18.0/30—were also redistributed, even though these routes are connected routes in RD1’s routing table.

Image The output of the show ip eigrp topology 172.16.48.0/25 command confirms that the component metrics match the values configured on the default-metric command.

Image The bottom of the output of the show ip eigrp topology 172.16.48.0/25 command lists information about the external source of the route, including the routing source (OSPF) and that source’s metric for the route (65). It also lists the phrase “(this system),” meaning that the router on which the command was issued (RD1 in this case) redistributed the route.

The third item in the list—the fact that RD1 redistributed some connected routes—bears further consideration. The redistribute ospf 2 command tells EIGRP to redistribute routes learned by the OSPF 2 process. However, it also tells the router to redistribute connected routes for interfaces on which process OSPF 2 has been enabled. Back in Example 10-1, the configuration on RD1 lists a network 172.16.0.0 0.0.255.255 area 0 command, enabling OSPF 2 on RD1’s S0/0/1 and S0/1/0 interfaces. As such, the redistribution process also redistributed those routes.

Stated more generally, when the redistribute command refers to another IGP as the routing source, it tells the router to redistribute the following:

Image

Image All routes in the routing table learned by that routing protocol

Image All connected routes of interfaces on which that routing protocol is enabled

Although Example 10-5 shows the evidence that Router RD1 added the topology data to its EIGRP topology database, it did not show any routes. Example 10-6 shows the IP routing tables on both RD1 and Router R2, a router internal to the EIGRP domain. R2’s routes forward the packets toward the redistributing router, which in turn has routes from the OSPF domain with which to forward the packet to the destination subnet.

Example 10-6 Verification of IP Routes on RD1 and R2


! First, on RD1
RD1# show ip route 172.16.0.0
Routing entry for 172.16.0.0/16, 5 known subnets
Attached (2 connections)
Variably subnetted with 2 masks
Redistributing via eigrp 1

O 172.16.48.0/25 [110/65] via 172.16.18.2, 00:36:25, Serial0/0/1
[110/65] via 172.16.14.2, 00:36:25, Serial0/1/0
C 172.16.18.0/30 is directly connected, Serial0/0/1
C 172.16.14.0/30 is directly connected, Serial0/1/0
O 172.16.8.0/25 [110/65] via 172.16.18.2, 00:36:25, Serial0/0/1
O 172.16.4.0/25 [110/65] via 172.16.14.2, 00:36:25, Serial0/1/0


! Next, on Router R2
R2# 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, 5 subnets, 2 masks
D EX 172.16.48.0/25 [170/3080448] via 172.30.12.1, 00:25:15, Serial0/0/1
D EX 172.16.18.0/30 [170/3080448] via 172.30.12.1, 00:25:15, Serial0/0/1
D EX 172.16.14.0/30 [170/3080448] via 172.30.12.1, 00:25:15, Serial0/0/1
D EX 172.16.8.0/25 [170/3080448] via 172.30.12.1, 00:25:15, Serial0/0/1
D EX 172.16.4.0/25 [170/3080448] via 172.30.12.1, 00:25:15, Serial0/0/1
172.30.0.0/16 is variably subnetted, 5 subnets, 2 masks
D 172.30.17.0/30 [90/2172416] via 172.30.27.7, 00:25:15, FastEthernet0/0
C 172.30.26.0/23 is directly connected, FastEthernet0/0
C 172.30.2.0/23 is directly connected, FastEthernet0/1
D 172.30.6.0/23 [90/30720] via 172.30.27.7, 00:25:15, FastEthernet0/0
C 172.30.12.0/30 is directly connected, Serial0/0/1


Beginning with the output for R2, in the second half of the example, R2 knows routes for all five subnets in Class B network 172.16.0.0, listing all as external EIGRP routes. The routes all use R2’s link connected to RD1. Also, note that the administrative distance (AD) is set to 170, rather than the usual 90 for EIGRP routes. EIGRP defaults to use AD 90 for internal routes and AD 170 for external routes.

RD1 has routes for all routes in the OSPF domain as well, but as either connected or OSPF-learned routes.

Redistribution into OSPF

As you might expect, OSPF redistribution has several similarities and differences as compared to redistribution into EIGRP. Unlike EIGRP, OSPF does have useful default metrics for redistributed routes, but OSPF does use the same general methods to configure metrics for redistributed routes. Like EIGRP, OSPF flags redistributed routes as being external. Unlike EIGRP, OSPF creates LSAs to represent each external route, and OSPF must then apply some much different logic than EIGRP to calculate the best route to each external subnet.

This section examines the OSPF redistribution process and configuration. It also discusses background on three OSPF LSA Types—Types 4, 5, and 7—all created to help OSPF distribute information so that routers can calculate the best route to each external subnet.

OSPF redistribute Command Reference

First, for reference, the following lines show the generic syntax of the redistribute command when used as a router ospf subcommand. Note that the syntax differs slightly depending on the routing protocol into which routes will be redistributed. Following that, Table 10-4 lists the options on the command with a brief description.

redistribute protocol [process-id | as-number] [metric metric-value] [metric-type
type-value] [match {internal | external 1 | external 2 | nssa-external}] [tag tag-
value
] [route-map map-tag] [subnets]

Image

Image

Table 10-4 Parameters on the OSPF redistribute Command

Configuring OSPF Redistribution with Minimal Parameters

The redistribute subcommand under router ospf has many optional settings. To better appreciate some of these settings, this section first examines the results when using all defaults, using as few parameters as possible. Following the discussion of the behavior with defaults, the next examples add the parameters that complete the redistribution configuration.

Redistribution into OSPF uses the following defaults:

Image

Image When taking from BGP, use a default metric of 1.

Image When taking from another OSPF process, take the source route’s metric.

Image When taking from all other sources, use a default metric of 20.

Image Create a Type 5 LSA for each redistributed route (external) if not inside an NSSA; create a Type 7 LSA if inside an NSSA.

Image Use external metric type 2.

Image Redistribute only routes of classful (Class A, B, and C) networks, and not routes for subnets.

To demonstrate OSPF redistribution, this section uses an example that uses the same internetwork shown in Figure 10-6, including the baseline configuration shown in Example 10-1, and the EIGRP redistribution configuration shown in Examples 10-2 and 10-4. Essentially, the upcoming OSPF examples begin with Router RD1 including all the configurations seen in all the earlier examples in this chapter. According to those examples, OSPF has been correctly configured on the routers on the right side of Figure 10-6, EIGRP has been configured on the left, and the configuration of redistribution of OSPF routes into EIGRP has been completed. However, no redistribution into OSPF has yet been configured.

For perspective, before showing the redistribution into OSPF, Example 10-7 reviews the OSPF configuration, along with show commands listing RD1’s IP routing table entries and its OSPF LSDB.

Example 10-7 Router RD1 Routing Protocol Configuration, Before Redistribution into OSPF


RD1# show run
! lines omitted for brevity
router eigrp 1
redistribute ospf 2
network 172.30.0.0
default-metric 1000 33 255 1 1500
no auto-summary
!
router ospf 2
router-id 1.1.1.1
log-adjacency-changes
network 172.16.0.0 0.0.255.255 area 0

RD1# show ip route 172.30.0.0
Routing entry for 172.30.0.0/16, 5 known subnets
Attached (2 connections)
Variably subnetted with 2 masks
Redistributing via eigrp 1

C 172.30.17.0/30 is directly connected, Serial0/1/1
D 172.30.26.0/23 [90/2172416] via 172.30.17.2, 01:08:50, Serial0/1/1
[90/2172416] via 172.30.12.2, 01:08:50, Serial0/0/0
D 172.30.2.0/23 [90/2172416] via 172.30.12.2, 01:08:50, Serial0/0/0
D 172.30.6.0/23 [90/2172416] via 172.30.17.2, 01:08:50, Serial0/1/1
C 172.30.12.0/30 is directly connected, Serial0/0/0
RD1# show ip ospf database

OSPF Router with ID (1.1.1.1) (Process ID 2)

Router Link States (Area 0)

Link ID ADV Router Age Seq# Checksum Link count
1.1.1.1 1.1.1.1 1425 0x80000007 0x007622 4
4.4.4.4 4.4.4.4 1442 0x8000000D 0x00B1E9 4
8.8.8.8 8.8.8.8 1466 0x80000006 0x00640E 4

Net Link States (Area 0)

Link ID ADV Router Age Seq# Checksum
172.16.48.4 4.4.4.4 1442 0x80000004 0x007E07


! The following occurs on OSPF internal router R4
R4# show ip route 172.30.0.0
% Network not in table


The output in Example 10-7 shows several important points relative to the upcoming redistribution configuration. First, by design, the EIGRP domain contains subnets of network 172.30.0.0. Router RD1 knows routes for five subnets in this range. RD1 has four LSAs: three Type 1 Router LSAs (one each for Routers RD1, R4, and R8) plus one Type 2 network LSA (because only one subnet, 172.16.48.0/25, has elected a DR). Because the design for this internetwork puts all OSPF routers in area 0, no Type 3 summary LSAs exist in RD1’s LSDB. Also, because no routers have redistributed external routes into OSPF yet, no Type 5 external nor Type 7 NSSA external routes are listed.

By adding the redistribute eigrp 1 command in OSPF configuration mode, OSPF tries to redistribute routes from EIGRP—but with no success. The reason is that by omitting the subnets parameter, OSPF will only redistribute routes for entire classful subnets, and only if such a route is listed in the IP routing table. Example 10-8 shows the results.

Example 10-8 Redistributing into OSPF from EIGRP 1, All Default Settings


RD1# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
RD1(config)# router ospf 2
RD1(config-router)# redistribute eigrp 1
% Only classful networks will be redistributed
RD1(config-router)# end
RD1#
RD1# show ip ospf database

OSPF Router with ID (1.1.1.1) (Process ID 2)

Router Link States (Area 0)

Link ID ADV Router Age Seq# Checksum Link count
1.1.1.1 1.1.1.1 6 0x80000008 0x007A1B 4
4.4.4.4 4.4.4.4 1782 0x8000000D 0x00B1E9 4
8.8.8.8 8.8.8.8 1806 0x80000006 0x00640E 4

Net Link States (Area 0)

Link ID ADV Router Age Seq# Checksum
172.16.48.4 4.4.4.4 1782 0x80000004 0x007E07


Cisco IOS even mentions that only classful routes will be redistributed. As seen in Example 10-7, no route exists for the exact Class B network prefix of 172.30.0.0/16, and by default, OSPF does not redistribute any subnets inside that range, as noted in the informational message in Example 10-8. So, the OSPF database on Router RD1 remains unchanged.

By changing the configuration to use the redistribute eigrp 1 subnets command, OSPF indeed redistributes the routes, as shown in Example 10-9.

Example 10-9 Redistributing from EIGRP into OSPF, with Subnets


RD1# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
RD1(config)# router ospf 2
RD1(config-router)# redistribute eigrp 1 subnets
RD1(config-router)# end
RD1#
May 12 12:49:48.735: %SYS-5-CONFIG_I: Configured from console by console
RD1# show ip ospf database
! omitting the Type 1 and 2 LSA output for brevity

Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag
172.30.2.0 1.1.1.1 3 0x80000001 0x008050 0
172.30.6.0 1.1.1.1 3 0x80000001 0x005478 0
172.30.12.0 1.1.1.1 3 0x80000001 0x0005C3 0
172.30.17.0 1.1.1.1 3 0x80000001 0x00CDF5 0
172.30.26.0 1.1.1.1 3 0x80000001 0x007741 0


! The following occurs on router R4
R4# show ip route 172.30.0.0
Routing entry for 172.30.0.0/16, 5 known subnets
Variably subnetted with 2 masks

O E2 172.30.17.0/30 [110/20] via 172.16.14.1, 00:01:10, Serial0/0/0
O E2 172.30.26.0/23 [110/20] via 172.16.14.1, 00:01:11, Serial0/0/0
O E2 172.30.2.0/23 [110/20] via 172.16.14.1, 00:01:11, Serial0/0/0
O E2 172.30.6.0/23 [110/20] via 172.16.14.1, 00:01:11, Serial0/0/0
O E2 172.30.12.0/30 [110/20] via 172.16.14.1, 00:01:11, Serial0/0/0


After adding the subnets option, Router RD1 redistributes the five routes from the EIGRP domain. Of particular interest:

Image If you look back to Example 10-7’s show ip route command output from Router RD1, you see three EIGRP-learned routes, plus two connected routes, inside the EIGRP domain. Example 10-9’s two show commands confirm that OSPF redistributes the three EIGRP-learned routes, plus the two connected subnets on which EIGRP is enabled (172.30.12.0/30 and 172.30.17.0/30).

Image The show ip ospf database command in Example 10-9 lists R1 (RID 1.1.1.1) as the advertising router of the five new Type 5 LSAs, because RD1 (with RID 1.1.1.1) created each Type 5 LSA.

Image Per OSPF internal Router R4’s show ip route 172.30.0.0 command at the end of Example 10-9, the external metric type is indeed E2, meaning external Type 2.

Image Per that same command on Router R4, the metric for each route is 20. The reasoning is that the default metric is 20 when redistributing from EIGRP into OSPF, and with an E2 route, internal OSPF costs are not added to the cost of the route.

That last point regarding the external route type requires a little more discussion. OSPF defines external routes as either an external Type 1 (E1) or external Type 2 (E2) route. By default, the OSPF redistribute command creates Type 2 routes, noting this external route type in the Type 5 LSA. The difference between the two lies in how OSPF calculates the metrics for E1 and E2 routes.

The next section completes the discussion of how OSPF can set the metrics when redistributing routes—or more specifically, the metric as listed in the Type 5 LSA created for that subnet. Following that, the text takes a detailed look at how OSPF calculates the best route for E2 routes. Later, the section “Redistributing into OSPF as E1 Routes” discusses the same subject, but for E1 routes.

Setting OSPF Metrics on Redistributed Routes

As mentioned earlier, no matter the source of the redistributed route, OSPF has a default metric to use. However, OSPF can set the metrics for redistributed routes using the same options used for EIGRP. Table 10-5 summarizes the defaults and metric setting options for redistribution into OSPF.

Image

Image

Table 10-5 Summary of Metric Values When Redistributing into OSPF

LSAs and Metrics for External Type 2 Routes

To appreciate how OSPF calculates the possible routes for each E2 route, you need to take a moment to think about the Type 5 LSA in more detail. First, by definition, the router that performs the redistribution into OSPF becomes an autonomous system border router (ASBR), because it injects external routes into OSPF. For each such route, that ASBR creates a Type 5 LSA for that subnet. The Type 5 LSA includes the following fields:

Image LSID (Link-state ID): The subnet number

Image Mask: The subnet mask

Image Advertising Router: The RID of the ASBR injecting the route

Image Metric: The metric as set by the ASBR

Image External Metric Type: The external metric type, either 1 or 2

When created, the ASBR floods the Type 5 LSA throughout the area. Then, if any area border routers (ABR) exist, the ABRs flood the Type 5 LSAs into any normal (nonstubby) areas (note that ABRs cannot forward Type 5 LSAs into any type of stubby area, instead relying on default routes). Figure 10-7 shows a sample flooding of the Type 5 LSA for EIGRP subnet 172.30.27.0/23 as an E2 route.

Image

Figure 10-7 Flooding of Type 5 LSAs

When flooded, OSPF has little work to do to calculate the metric for an E2 route, because by definition, the E2 route’s metric is simply the metric listed in the Type 5 LSA. In other words, the OSPF routers do not add any internal OSPF cost to the metric for an E2 route.

Because routers ignore internal cost when calculating E2 external route metrics, whenever an alternative route can be calculated, the metrics tie. For example, in Figure 10-7, Router R4 has two possible physical routes to ASBR RD1—one directly to RD1 and one through R8. The cost for both routes to external subnet 172.30.26.0/23 will be 20, because that is the cost that RD1 assigned to the route (actually, the Type 5 LSA) when redistributing the route.

To avoid loops, OSPF routers use a tiebreaker system to allow a router to choose a best external route. The logic differs slightly depending on whether the router in question resides in the same area as the ASBR (intra-area) or in a different area (interarea), as discussed in the next two sections.

Determining the Next Hop for Type 2 External Routes—Intra-area

When a router finds multiple routes for the same E2 destination subnet, it chooses the best route based on the lowest cost to reach any ASBR(s) that advertised the lowest E2 metric. For example, if five ASBRs all advertised the same subnet as an E2 route, and two ASBRs advertised a metric of 10, and the other three advertised a metric of 20, either of the first two ASBRs could be used. Then, the router calculates its lowest-cost route to reach the ASBR and uses the next-hop IP address and outgoing interface listed in that route.

The following list spells out the mechanics of the calculation used to break the tie when multiple equal-cost E2 routes exist for a particular subnet:

Image

Step 1. Find the advertising ASBR(s) as listed in the Type 5 LSA(s) for Type 5 LSAs.

Step 2. Calculate the lowest-cost route to reach any of the ASBR(s) based on the intra-area LSDB topology.

Step 3. Use the outgoing interface and next hop based on the best route to reach the ASBR (as chosen at Step 2).

Step 4. The route’s metric is unchanged—it is still simply the value listed in the Type 5 LSA.

For example, use Router R4 in Figure 10-7 as an example and the E2 route for 172.30.26.0/23. Before using these four steps, R4 calculated two possible routes for 172.16.26.0/23: an E2 route directly to RD1 and another route through R8. Both routes use metric 20 in this case so the routes tie. Because of the tie, R4 proceeds with the following steps:

Step 1. R4 looks in the Type 5 LSA and sees RID 1.1.1.1 (RD1) is the advertising ASBR.

Step 2. R4 then looks at its area 0 LSDB entries, including the Type 1 LSA for RID 1.1.1.1, and calculates all possible area 0 routes to reach 1.1.1.1.

Step 3. R4’s best route to reach RID 1.1.1.1 happens to be through its S0/0/0 interface, to next-hop RD1 (172.16.14.1), so R4’s route to 172.16.26.0/23 uses these details.

Step 4. The route lists metric 20, as listed in the Type 5 LSA.

Figure 10-8 shows the interface costs that Router R4 will use, based on its LSDB, to calculate the cost for two possible routes to reach ASBR RD1. Again using subnet 172.30.26.0/23 as an example, RD1 first looks at the Type 5 external LSA and sees RID 1.1.1.1 as the advertising ASBR. R4 then calculates the costs based on its intra-area LSDB—but we can perform the equivalent by adding the interface costs seen in Figure 10-8. Example 10-10 lists the external Type 5 LSAs, highlighting subnet 172.30.26.0/23 and the interface costs on both R4 and R8, as seen in the figure.

Image

Figure 10-8 R4’s Cost to Reach ASBR RD1

Example 10-10 Verifying OSPF External Routes—Intra-area


R4# show ip ospf database | begin Ext
Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag
172.30.2.0 1.1.1.1 189 0x80000002 0x007E51 0
172.30.6.0 1.1.1.1 189 0x80000002 0x005279 0
172.30.12.0 1.1.1.1 189 0x80000002 0x0003C4 0
172.30.17.0 1.1.1.1 189 0x80000002 0x00CBF6 0
172.30.26.0 1.1.1.1 189 0x80000002 0x007542 0

R4# show ip ospf database external 172.30.26.0

OSPF Router with ID (4.4.4.4) (Process ID 4)

Type-5 AS External Link States

Routing Bit Set on this LSA
LS age: 175
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 172.30.26.0 (External Network Number )
Advertising Router: 1.1.1.1
LS Seq Number: 80000001
Checksum: 0x7741
Length: 36
Network Mask: /23
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 0

R4# show ip ospf interface brief
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Se0/0/0 4 0 172.16.14.2/30 64 P2P 1/1
Fa0/1 4 0 172.16.4.4/25 1 DR 0/0
Fa0/0 4 0 172.16.48.4/25 1 DR 1/1
Se0/0/1 4 1 172.16.45.4/25 64 P2P 1/1

! Next output occurs on R8
R8# show ip ospf interface brief
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Fa0/1 8 0 172.16.8.8/25 1 DR 0/0
Se0/0 8 0 172.16.18.2/30 64 P2P 1/1
Fa0/0 8 0 172.16.48.8/25 1 BDR 1/1


Determining the Next Hop for Type 2 External Routes—Interarea

When a router exists in a different area than the ASBR, the issues remain the same, but the tiebreaker calculation of choosing the least-cost route to reach the ASBR changes. If a router finds multiple routes to reach a single E2 subnet, some or all might tie based on metric, because the metric is based solely on the external cost as defined by the ASBR. (If multiple ASBRs redistribute routes for the same prefix, each ASBR can assign a different metric.) A router then chooses the best route based on the least-cost route to reach an ASBR that has advertised the lowest E2 cost for the subnet.

When the ASBR is in a different area, the calculation of the cost to reach the ASBR requires more information, and even an additional LSA type, as compared with the intra-area calculation. To calculate its best route to reach the ASBR, a router in another area adds the cost to reach an ABR between the areas, plus that ABR’s cost to reach the ASBR. To make more sense of that concept, Figure 10-9 shows a portion of Figure 10-7, with costs highlighted, assuming that the OSPF reference bandwidth is also using default settings.

Image

Figure 10-9 R5’s Cost to Reach ASBR RD1

R5 has two possible routes shown in Figure 10-9 to reach ASBR RD1. On the left, the path through R3 has a total cost of 65. To the right, the router through ABR R4 has a total cost of 128. R5 then chooses the route through R3 as the best route based on the least cost to reach the ASBR.

For humans, when you have a figure and know all costs, the calculation of the costs of the two routes is simple. However, for routers, the calculation occurs in two parts:

Step 1. Calculate the cost to reach the ABR, based on the local area’s topology database.

Step 2. Add the cost from the ABR to the ASBR, as listed in a Type 4 LSA.

ABRs create this new type of LSA—the Type 4 Summary ASBR LSA—to support the logic mentioned at Step 2. The Type 4 ASBR LSA lists the RID of the ASBR, and the RID of the ABR that created and flooded the Type 4 LSA. Most importantly, the Type 4 LSA lists that ABR’s cost to reach the ASBR. In effect, the LSA makes an announcement like this: “I am ABR X. I can reach ASBR Y, and my cost to reach that ASBR is Z.” In short, it allows the second part of the computation.

ABRs create Type 4 LSAs in reaction to receiving an external LSA from some ASBR. When an ABR forwards a Type 5 LSA into an area, the ABR looks at the RID of the ASBR that created the Type 5 LSA. The ABR then creates a Type 4 LSA listing that ASBR, and the cost to reach that ASBR, flooding that Type 4 LSA into the neighboring areas.

For example, using Figure 10-9 again, R3 would create and flood a Type 4 Summary ASBR LSA into area 1. R3’s Type 4 LSA lists ASBR 1.1.1.1 (RD1), ABR 3.3.3.3 (itself), and cost 1 (R3’s cost to reach 1.1.1.1). Similarly, in that same example, ABR R4 would create another Type 4 ASBR Summary LSA. This LSA also lists ASBR 1.1.1.1 (RD1), but with advertising ABR 4.4.4.4 (R4), and lists cost 64 (R4’s cost to reach 1.1.1.1).

R5, internal to area 1, then calculates the cost for each competing route by adding R5’s intra-area cost to reach the respective ABRs (Step 1 in the previous list) to the cost listed in the corresponding Type 4 LSAs (Step 2 in the previous list). When R5 calculates two possible routes to reach external subnet 172.30.26.0/23, R5 finds routes both have a metric of 20, so R5 tries to break the tie by looking at the cost to reach the ASBR over each route. To do so, R5 examines each route, adding its intra-area cost to reach the ABR to the ABR’s cost to reach the ASBR (as listed in the Type 4 LSA). In this case, R5 finds that the route through R3 has the lower cost (65), so R5 uses outgoing interface S0/0 for its route to 172.30.26.0/23.

Example 10-11 lists the show command output that demonstrates the same example. Again focusing on R5’s route for 172.30.26.0/23, the example first shows R5’s LSDB, beginning with the Summary ASBR LSAs. More discussion follows the example.

Example 10-11 Redistributing from EIGRP into OSPF, with Subnets


R5# show ip ospf database | begin ASB
Summary ASB Link States (Area 1)

Link ID ADV Router Age Seq# Checksum
1.1.1.1 3.3.3.3 956 0x8000000D 0x00E43A
1.1.1.1 4.4.4.4 1044 0x8000000B 0x00439A

Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag
172.30.2.0 1.1.1.1 1185 0x8000000B 0x006C5A 0
172.30.6.0 1.1.1.1 1185 0x8000000B 0x004082 0
172.30.12.0 1.1.1.1 1185 0x8000000B 0x00F0CD 0
172.30.17.0 1.1.1.1 1185 0x8000000B 0x00B9FF 0
172.30.26.0 1.1.1.1 1185 0x8000000B 0x00634B 0

R5# show ip ospf database asbr-summary

OSPF Router with ID (5.5.5.5) (Process ID 5)

Summary ASB Link States (Area 1)

Routing Bit Set on this LSA
LS age: 984
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(AS Boundary Router)
Link State ID: 1.1.1.1 (AS Boundary Router address)
Advertising Router: 3.3.3.3
LS Seq Number: 8000000D
Checksum: 0xE43A
Length: 28
Network Mask: /0
TOS: 0 Metric: 1

LS age: 1072
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(AS Boundary Router)
Link State ID: 1.1.1.1 (AS Boundary Router address)
Advertising Router: 4.4.4.4
LS Seq Number: 8000000B
Checksum: 0x439A
Length: 28
Network Mask: /0
TOS: 0 Metric: 64

R5# show ip ospf border-routers
OSPF Process 5 internal Routing Table
Codes: i - Intra-area route, I - Inter-area route

i 4.4.4.4 [64] via 172.16.45.4, Serial0/1, ABR, Area 1, SPF 6
I 1.1.1.1 [65] via 172.16.35.3, Serial0/0, ASBR, Area 1, SPF 6
i 3.3.3.3 [64] via 172.16.35.3, Serial0/0, ABR, Area 1, SPF 6

R5# show ip route 172.30.0.0
Routing entry for 172.30.0.0/16, 5 known subnets
Variably subnetted with 2 masks

O E2 172.30.17.0/30 [110/20] via 172.16.35.3, 05:48:42, Serial0/0
O E2 172.30.26.0/23 [110/20] via 172.16.35.3, 05:48:42, Serial0/0
O E2 172.30.2.0/23 [110/20] via 172.16.35.3, 05:48:42, Serial0/0
O E2 172.30.6.0/23 [110/20] via 172.16.35.3, 05:48:42, Serial0/0
O E2 172.30.12.0/30 [110/20] via 172.16.35.3, 05:48:42, Serial0/0


The show ip ospf database | begin ASB command’s output lists two Type 4 LSAs. (The command itself lists the summary of R5’s OSPF LSDB, beginning with the section that lists Type 4 LSAs.) Both Type 4 LSAs list ASBR RD1’s RID of 1.1.1.1 as the LSID, but they each list different advertising routers: 3.3.3.3 (R3) and 4.4.4.4 (R4). In that same command, the output lists five Type 5 LSAs for the five subnets in the EIGRP domain, each with advertising Router 1.1.1.1 (RD1).

The next command, show ip ospf database asbr-summary, lists the same two Type 4 LSAs seen in the previous command, but in detail. The first lists ASBR 1.1.1.1 (RD1), with ABR 3.3.3.3 (R3) and a cost of 1. The second lists ASBR 1.1.1.1, but with ABR 4.4.4.4 (R4) and a cost of 64. The costs list the respective ABR’s cost to reach ASBR 1.1.1.1.

The third command, show ip ospf border-routers, lists a line for every ABR and ASBR known to the local router. It lists whether the router is inside the same area or in another area, the RID of the ABR or ASBR, and this router’s best route to reach each ABR and ASBR. This command essentially shows the answer to the question “Which route to ASBR 1.1.1.1 is best?” Finally, the last command lists R5’s IP route for 172.30.26.0, with the same next-hop and outgoing interface information as seen in the entry for RID 1.1.1.1 in the output of the show ip ospf border-routerscommand.

Redistributing into OSPF as E1 Routes

OSPF’s external metric type feature gives engineers a design tool for influencing the choice of best route. E2 routes work well when the design needs to choose the best route based on the external metric—in other words, the metric as perceived outside the OSPF domain. E2 routes ignore the internal OSPF cost (except when breaking ties for best route). Therefore, when OSPF compares two E2 routes for the same subnet, that first choice to pick the lowest-metric route is based on the external metric only.

OSPF routers calculate the metrics of E1 routes by adding the internal cost to reach the ASBR to the external cost defined on the redistributing ASBR. As a result, an engineer can influence the choice of routes based on the combination of the external and internal OSPF cost simply by redistributing a route as an E1 route instead of as an E2 route. To take advantage of this feature, the redistribute command simply needs to set the metric type.

Example 10-12 shows the simple change to the redistribution configuration on RD1 (as shown earlier in Example 10-9) to make all routes redistributed from EIGRP into OSPF be E1 routes. The example also lists output from R4 demonstrating the metric, which is based on the (default) external metric (20) plus R4’s best internal metric to reach ASBR 1.1.1.1 (64).

Example 10-12 Redistributing from EIGRP into OSPF, with Subnets


RD1# conf t
Enter configuration commands, one per line. End with CNTL/Z.
RD1(config)# router ospf 2
RD1(config-router)# redistribute eigrp 1 subnets metric-type 1
RD1(config-router)# end
RD1#


! Moving to router R4
R4# show ip route 172.30.0.0
Routing entry for 172.30.0.0/16, 5 known subnets
Variably subnetted with 2 masks

O E1 172.30.17.0/30 [110/84] via 172.16.14.1, 00:00:06, Serial0/0/0
O E1 172.30.26.0/23 [110/84] via 172.16.14.1, 00:00:06, Serial0/0/0
O E1 172.30.2.0/23 [110/84] via 172.16.14.1, 00:00:06, Serial0/0/0
O E1 172.30.6.0/23 [110/84] via 172.16.14.1, 00:00:06, Serial0/0/0
O E1 172.30.12.0/30 [110/84] via 172.16.14.1, 00:00:06, Serial0/0/0

R4# show ip ospf border-routers

OSPF Process 4 internal Routing Table
Codes: i - Intra-area route, I - Inter-area route

i 1.1.1.1 [64] via 172.16.14.1, Serial0/0/0, ASBR, Area 0, SPF 16
i 3.3.3.3 [65] via 172.16.14.1, Serial0/0/0, ABR, Area 0, SPF 16
i 3.3.3.3 [128] via 172.16.45.5, Serial0/0/1, ABR, Area 1, SPF 8


Note that for routers in a different area than the ASBR, the calculation of metric follows the same general logic used when breaking ties for E2 routes. Generally, the computation adds three items:

Image

Image The best intra-area cost to reach the ABR (per that area’s LSDB)

Image The cost from that ABR to the ASBR (per Type 4 LSA)

Image The external cost for the route (per Type 5 LSA)

For example, Figure 10-9 shows that R5’s best cost to reach ASBR RD1 was out S0/0, to R3 next, with a cost of 65. Adding the external cost of 20, R5’s best route will have a metric of 85. R5 calculates that cost by adding the following:

Image The intra-area cost to ABR R3 (64), by analyzing the area 1 LSDB entries

Image R3’s cost to reach ASBR 1.1.1.1, as listed in its Type 4 LSA (1)

Image The external cost as listed in the Type 5 LSA (20)

A Brief Comparison of E1 and E2 Routes

OSPF defines two types of external routes to give network designers two slightly different tools with which to calculate the best route to reach a destination external to OSPF. For E1 routes, both the external cost and internal OSPF cost matter to the choice of best route. For E2 routes, only the external cost matters to the choice of best route (unless a tie needs to be broken).

The benefits of the different external route types apply mostly to when multiple ASBRs advertise the same subnet. For example, imagine two ASBRs, ASBR1 and ASBR2, between OSPF and another routing domain. If the goal is to always send traffic through ASBR1, you could use E2 routes and set the metric for ASBR1’s redistributed routes to a lower metric than ASBR2. Because routers ignore the internal metrics when calculating the E2 metrics, every router chooses ASBR1 as the better ASBR. Conversely, if the goal were to load-balance the traffic, and make each router pick the closest ASBR, both ASBRs could set the same metric on their redistributed routes, but make the routes Type E1. As a result, routers closer to each ASBR choose best routes based on the lower OSPF internal costs.

Also, note that for a given prefix/length, OSPF always prefers an E1 route over an E2 route.

External Routes in NSSAs

Routes can be redistributed into OSPF on any OSPF router, with a few exceptions. The router can be internal to area 0, like Router RD1 in the many examples earlier in this chapter. It can also be an ABR connected to several areas. It can be a router internal to a nonbackbone area as well.

Of the four types of stubby areas, two do not allow redistribution into the area, and two do allow redistribution—even though none of the stubby area types allow Type 5 LSAs. OSPF does not allow routers in stubby and totally stubby areas to inject external routes. However, routers in not-so-stubby areas—NSSAs—can redistribute routes, while still holding to the restriction of having no Type 5 LSAs.

OSPF supports the injection of external routes into NSSAs by defining the Type 7 AS External LSA. This LSA type essentially replaces the Type 5 LSA’s role, but only inside the NSSA. Figure 10-10 shows a conceptual view.

Image

Figure 10-10 Process of Adding and Converting Type 7 LSAs

Following the steps in the figure:

Step 1. The ASBR attached to NSSA area 1 redistributes a route for subnet 1, creating a Type 7 LSA.

Step 2. The ASBR floods the Type 7 LSA throughout NSSA area 1.

Step 3. ABR1 converts the Type 7 LSA to a Type 5 LSA when forwarding into other areas (area 0 in this case).

Step 4. ABR2, connected to another normal area, forwards the Type 5 LSA for subnet 1 into normal area 2.

Example 10-13 demonstrates the concept using area 1 from Figures 10-7 and 10-9. Area 1 has been converted to be an NSSA. R5 has been configured to redistribute connected routes. This feature allows a router to inject connected routes into a routing domain without having to enable the routing protocol on the corresponding interfaces. In this case, R5 will redistribute subnet 10.1.1.0/24, a connected route added by R5 using interface Loopback0.

Example 10-13 Redistributing from EIGRP into OSPF, with Subnets


! R5's new configuration here:
interface loopback0
ip address 10.1.1.1 255.255.255.0
router ospf 5
area 1 nssa
redistribute connected subnets

R5# show ip ospf database | begin Type-7
Type-7 AS External Link States (Area 1)

Link ID ADV Router Age Seq# Checksum Tag
10.1.1.0 5.5.5.5 26 0x80000001 0x00E0A6 0

R5# show ip ospf database nssa-external

OSPF Router with ID (5.5.5.5) (Process ID 5)

Type-7 AS External Link States (Area 1)

LS age: 69
Options: (No TOS-capability, Type 7/5 translation, DC)
LS Type: AS External Link
Link State ID: 10.1.1.0 (External Network Number )
Advertising Router: 5.5.5.5
LS Seq Number: 80000001
Checksum: 0xE0A6
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 172.16.45.5
External Route Tag: 0


! Moving to router R8
R8# show ip ospf database | begin Type-7

R8# show ip ospf database | begin External
Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag
10.1.1.0 4.4.4.4 263 0x80000001 0x009302 0
172.30.2.0 1.1.1.1 1655 0x8000000E 0x00665D 0
172.30.6.0 1.1.1.1 1655 0x8000000E 0x003A85 0
172.30.12.0 1.1.1.1 1655 0x8000000E 0x00EAD0 0
172.30.17.0 1.1.1.1 1655 0x8000000E 0x00B303 0
172.30.26.0 1.1.1.1 1655 0x8000000E 0x005D4E 0


The example begins with configuration on R5, followed by show commands on both Router R5 and R8. In particular, the show ip ospf database | begin Type-7 command on R5 skips output until the heading for Type 7 LSAs, listing one such LSA. The LSA lists the subnet number (10.1.1.0) as the LSID and the ASBR’s RID (5.5.5.5, or R5). The next command provides output from the show ip ospf database nssa-external command on R5, which shows the details in the Type 7 LSA, including the LSA cost of 20—the same default used when injecting routes as Type 5 LSAs.

The second half of the output, on Router R8, starts with another show ip ospf database | begin Type-7 command—the same command seen earlier in the example on R5. The null output in this command confirms that R8 has no Type 7 LSAs. However, the final command in the example confirms that R8 does have a Type 5 external LSA for subnet 10.1.1.0, with a listing of R4 (4.4.4.4) as the advertising router. This LSA does not list R5’s RID of 5.5.5.5 as the advertising router, because R5 did not create this Type 5 LSA. Instead, R4 created this Type 5 LSA when R4 reacted to learning the Type 7 LSA inside area 1.

Finally, Example 10-14 shows a few interesting items about the IP routing table with NSSAs. Routers inside the NSSA use a different code in the output of show ip route to denote NSSA external routes as compared with normal external routes. The example shows R4’s IP routing table, which lists an N2 route. This means that it is external Type 2, but inside an NSSA, and using a Type 7 AS external LSA. The second part of the example shows R8’s route for the same subnet. Because R8 is inside a non-NSSA, R8 knows of subnet 10.1.1.0/24 because of a Type 5 LSA, so R8 lists the route as an E2 route.

Example 10-14 Redistributing from EIGRP into OSPF, with Subnets


! R4's output here:
R4# 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

! lines omitted for brevity

10.0.0.0/24 is subnetted, 1 subnets
O N2 10.1.1.0 [110/20] via 172.16.45.5, 00:10:54, Serial0/0/1


! R8, in area 0, next
R8# show ip route | begin 10.0.0.0
10.0.0.0/24 is subnetted, 1 subnets
O E2 10.1.1.0 [110/20] via 172.16.48.4, 00:10:24, FastEthernet0/0


Redistribution with Route Maps and Distribute Lists

In some cases, a redistribution design calls for all routes to be redistributed, all with the same metric and all with the same external route type (if applicable). However, in other cases, the metrics might need to be set differently for different routes. Additionally, some designs require that only a subset of the routes should be redistributed, for example, when only a few key subnets need to be exposed for connections from a partner. And with routing protocols that have different types of external routes, such as OSPF and IS-IS, the design might or might not allow all redistributed routes to be of the same external route type.

All these features require a tool by which Cisco IOS can identify the routes that need to be treated differently, whether given different metrics, filtered, or assigned a different external route type. Cisco IOS provides such a feature by allowing a reference to a route map from the redistributecommand. Specifically, the route map can perform the following:

Image

Image Identify the subset of the routes to filter or change based on the route’s prefix/length, plus many other factors.

Image Make filtering choices about which routes are redistributed and which are not.

Image Set the metric to different values based on information matchable by the route map.

Image Set the type of external route for different redistributed routes, for example, OSPF Type 1 for some routes and Type 2 for others.

Image Set a route tag, a unitless integer value that can later be matched with a route map at another redistribution point.

This section examines the mechanics of using the route-map option of the redistribute command to filter routes and set the metrics, along with a few other small features.

Overview of Using Route Maps with Redistribution

The redistribute command has two mechanisms that allow filtering of routes:

Image The match {internal | external 1 | external 2 | nssa-external} parameters

Image The route-map map-name option

Of these two options, the first applies only when redistributing from OSPF, and matches routes solely based on the types of routes listed here. However, the route map referenced by the redistribute command has many options for identifying routes by matching various facts about the route.

To identify the routes, route maps use the match subcommand. The match command can refer to ACLs and prefix lists to match anything matchable by those tools, plus match other facts more directly. Table 10-6 lists the match command options that matter when using route maps for IGP redistribution.

Image

Image

Table 10-6 match Command Options for Redistribution

A route map referenced by the redistribute command always attempts to filter routes. If the route map matches a particular route with a particular route-map clause, and the action in that clause is permit, the route is redistributed. However, if the first route-map clause matched by a route has a deny action, the route is filtered—in other words, not redistributed.

Additionally, for routes not filtered by the route map, the route map can set other values (like the route’s metric) using the aptly named set command. Table 10-7 lists the various route map set subcommands that can be used to set the values used for routes redistributed into IGPs.

Image

Image

Table 10-7 set Command Options for Redistribution into IGPs

Filtering Redistributed Routes with Route Maps

As usual, the best way to understand the configuration, and the methods to verify the results, is to use an example. In this case, the same internetwork seen earlier in this chapter is used, but with some more routes added. Figure 10-11 shows some of the details of the internetwork.

Image

Figure 10-11 Sample Internetwork Used for Redistribution Route Map Examples

The internetwork has been preconfigured with mainly defaults, as follows:

Image EIGRP works on the left side of Figure 10-11.

Image OSPF works on the right side.

Image Mutual redistribution has been configured on Router RD1, with no filtering.

Image All routes use these metric settings: EIGRP (1500 10 255 1 1500), OSPF (20).

Example 10-15 shows the routing protocol configuration on Router RD1 at the beginning of the example.

Example 10-15 Initial Configuration—Mutual Redistribution, No Filtering


RD1# show run
! lines omitted for brevity
router eigrp 1
redistribute ospf 2
network 172.30.0.0
default-metric 1500 10 255 1 1500
auto-summary
!
router ospf 2
router-id 1.1.1.1
log-adjacency-changes
redistribute eigrp 1 subnets
network 172.16.0.0 0.0.255.255 area 0


Configuring Route Filtering with Redistribution

The configuration shown in Example 10-15 shows mutual redistribution with no filtering. The next example extends that same configuration to now use a route map that should filter routes being redistributed from OSPF process 2 into EIGRP AS 1. Any routes not mentioned in Table 10-8, but shown in Figure 10-11, should be redistributed.

Image

Table 10-8 Parameters Used in Route-Filtering Example

The route map simply needs to match the routes to be filtered with a route-map clause that has a deny action and match the routes to not be filtered with a clause that has a permit action. Example 10-16 shows two such potential solutions, with route map names option1 and option2. The general style of the two options, both of which work, is as follows:

Image option1: Begin with a match of the routes to be filtered, using extended IP ACLs, with a deny action so that the routes are filtered. Then use a permit clause with no match command, matching and allowing through all remaining routes.

Image option2: Begin with a match of the routes to be allowed, matching with prefix lists, with a permit action. Then use the implicit deny all at the end of the route map to filter unwanted routes.

Example 10-16 Redistribution Filtering Configuration Example


! This ACL matches subnet 172.16.101.0, with mask 255.255.255.0
ip access-list extended match-101
permit ip host 172.16.101.0 host 255.255.255.0

! This ACL matches subnets 172.16.104.0 and 172.16.105.0, with masks
! 255.255.255.224 and 255.255.255.240, respectively.
ip access-list extended match-104-105
permit ip host 172.16.104.0 host 255.255.255.224
permit ip host 172.16.105.0 host 255.255.255.240
!
! This prefix list matches the five subnets in area 0
ip prefix-list match-area0-permit seq 5 permit 172.16.14.0/30
ip prefix-list match-area0-permit seq 10 permit 172.16.18.0/30
ip prefix-list match-area0-permit seq 15 permit 172.16.8.0/25
ip prefix-list match-area0-permit seq 20 permit 172.16.4.0/25
ip prefix-list match-area0-permit seq 25 permit 172.16.48.0/25
!
! This prefix list matches the two sets of two area 3 subnets that will
! be permitted to be redistributed
ip prefix-list match-area3-permit seq 5 permit 172.16.102.0/23 ge 25 le 26
ip prefix-list match-area3-permit seq 10 permit 172.16.106.0/23 ge 29 le 30


! The first alternative route-map:
route-map option1 deny 10
match ip address match-101
!
route-map option1 deny 20
match ip address match-104-105
!
route-map option1 permit 100


! The second alternative route-map:
route-map option2 permit 10
match ip address prefix-list match-area3-permit
!
route-map option2 permit 20
match ip address prefix-list match-area0-permit


! Finally, the configuration shows the enablement of option 1.
router eigrp 1
redistribute ospf 2 route-map option1


Route map option1 takes the approach of denying the redistribution of some routes and then allowing the rest through. The last clause in this route map, with sequence number 100, does not have a match command, meaning that it will match any and all routes. The permit action on this last clause overrides the implied deny all at the end of the route map.

The ACLs referenced by route map option1 show some particularly interesting features for matching routes. With an extended ACL, Cisco IOS compares the source IP address parameter to the subnet address of the route and the destination IP address to the subnet mask of the route. For example, the permit ip host 172.16.101.0 host 255.255.255.0 command matches the specific route for subnet 172.16.101.0, specifically with mask 255.255.255.0.

Route map option2 takes the opposite approach compared to option1, for no other reason than to just show an alternative. It uses two different prefix lists to match the routes—one for subnets in area 0, all of which are redistributed, and another for subnets in area 3 that should be allowed through the redistribution process. Alternatively, all routes could have been matched with a single prefix list, with a single permit clause in the option2 route map.

Finally, the very end of the example shows the syntax of the redistribute command, with route map option1 enabled.

Verifying Redistribution Filtering Operations

The redistribution process takes routes from the IP routing table of a router and adds the appropriate entries to the destination routing protocol’s topology table. The filtering process prevents some of the routes from being added to the topology table, so an examination of the destination routing protocol’s topology table shows whether the filtering worked correctly. Additionally, the routing tables of other routers in the destination routing domain can be checked.

A good redistribution verification plan should check that the correct routes are filtered and confirm that no extra routes are filtered. In a production environment, that work might be laborious. With the example shown in Figure 10-11 and Example 10-16, verification takes a little less time because of the relatively small number of routes and the fact that the subnets in the OSPF domain all begin with 172.16.

Example 10-17 shows an abbreviated version of the EIGRP topology table on Router RD1. The show ip route 172.16.0.0 command lists the 12 OSPF subnets that currently exist in the OSPF domain (as shown in Figure 10-11). The show ip eigrp topology | include 172[.]16 command lists only routes that include text “172.16,” listing only nine subnets—and omitting the three subnets that should have been filtered, which confirms that the filtering worked.


Note

The brackets in the show ip eigrp topology | include 172[.]16 command tell Cisco IOS to treat the period as a literal, searching for the text “172.16” in the command output, instead of treating the period as a wildcard in a Cisco IOS regular expression.


Example 10-17 Verifying Redistribution Filtering


RD1# show ip route 172.16.0.0
Routing entry for 172.16.0.0/16, 12 known subnets
Attached (2 connections)
Variably subnetted with 7 masks
Redistributing via eigrp 1

O 172.16.48.0/25 [110/65] via 172.16.18.2, 03:25:56, Serial0/0/1
[110/65] via 172.16.14.2, 03:24:09, Serial0/1/0
C 172.16.18.0/30 is directly connected, Serial0/0/1
C 172.16.14.0/30 is directly connected, Serial0/1/0
O 172.16.8.0/25 [110/65] via 172.16.18.2, 03:25:56, Serial0/0/1
O 172.16.4.0/25 [110/65] via 172.16.14.2, 03:24:49, Serial0/1/0
O IA 172.16.104.0/27 [110/65] via 172.16.14.2, 03:24:44, Serial0/1/0
O IA 172.16.105.0/28 [110/65] via 172.16.14.2, 03:24:44, Serial0/1/0
O IA 172.16.106.0/29 [110/65] via 172.16.14.2, 03:24:44, Serial0/1/0
O IA 172.16.107.0/30 [110/65] via 172.16.14.2, 03:24:44, Serial0/1/0
O IA 172.16.101.0/24 [110/65] via 172.16.14.2, 03:24:44, Serial0/1/0
O IA 172.16.102.0/25 [110/65] via 172.16.14.2, 03:24:44, Serial0/1/0
O IA 172.16.103.0/26 [110/65] via 172.16.14.2, 03:24:44, Serial0/1/0

RD1# show ip eigrp topology | include 172[.]16
P 172.16.48.0/25, 1 successors, FD is 1709056
P 172.16.18.0/30, 1 successors, FD is 1709056
P 172.16.14.0/30, 1 successors, FD is 1709056
P 172.16.8.0/25, 1 successors, FD is 1709056
P 172.16.4.0/25, 1 successors, FD is 1709056
P 172.16.106.0/29, 1 successors, FD is 1709056
P 172.16.107.0/30, 1 successors, FD is 1709056
P 172.16.102.0/25, 1 successors, FD is 1709056
P 172.16.103.0/26, 1 successors, FD is 1709056


Besides examining the topology tables on the router doing the redistribution, a show ip route command on other routers inside the EIGRP domain, like R2, could be used to confirm the presence and absence of the routes according to the plan. However, the routing table on the redistributing router will list the routes as learned from the original routing domain.

Any ACLs or prefix lists used to match packets can also be used as a gauge to tell whether the correct statements matched routes. The show ip access-list [number | name] and show ip prefix-list detail [name] commands list counters that increment each time Cisco IOS matches a route for redistribution. Particularly when first using the ACL or prefix list, these commands can confirm which statements have been matched. The counters do increment each time the router considers whether to redistribute a route. Specifically, when a route fails, and the redistributing router removes the route from the routing table and then later adds the route to the routing table again, the counters for matching the ACL or prefix list will increment. Example 10-18 shows an example of each command and the appropriate counters.

Example 10-18 Verifying Redistribution Filtering


RD1# show access-list
Extended IP access list match-101
10 permit ip host 172.16.101.0 host 255.255.255.0 (1 match)
Extended IP access list match-104-105
10 permit ip host 172.16.104.0 host 255.255.255.224 (1 match)
20 permit ip host 172.16.105.0 host 255.255.255.240 (1 match)
RD1# show ip prefix-list detail match-area0-permit
ip prefix-list match-area0-permit:
count: 5, range entries: 0, sequences: 5 - 25, refcount: 3
seq 5 permit 172.16.14.0/30 (hit count: 6, refcount: 1)
seq 10 permit 172.16.18.0/30 (hit count: 5, refcount: 1)
seq 15 permit 172.16.8.0/25 (hit count: 4, refcount: 2)
seq 20 permit 172.16.4.0/25 (hit count: 3, refcount: 3)
seq 25 permit 172.16.48.0/25 (hit count: 2, refcount: 2)


Setting Metrics When Redistributing

Setting a different metric for different redistributed routes requires only a minor amount of additional configuration. The redistributing router still needs a route map and still needs to match the routes. Additionally, to set the metric for routes matched by a particular clause, the route map needs the set metric route map subcommand. When redistributing into EIGRP, this command has five parameters (bandwidth, delay, reliability, load, and MTU). When redistributing into OSPF or Routing Information Protocol (RIP), a single integer metric is used.

Configuring the Metric Settings

Continuing with the same internetwork shown in Figure 10-11, and with the same filtering goals summarized earlier in Table 10-8, Table 10-9 further defines the goals from redistribution from OSPF into EIGRP in this internetwork. The same routes will be filtered, but now the metrics of the allowed routes will be set differently as listed in the table.

Image

Table 10-9 Parameters Used in Metric and Tag Setting Example

The requirements in Table 10-9 list three different sets of metrics for the redistributed routes. To implement this design, the route map needs at least three clauses: one for each set of routes for which the metric should differ. The example route maps listed earlier in Example 10-16 do not happen to separate the three groups of allowed routes into different route-map clauses, so a new route map will be used. Example 10-19 shows the new configuration. Note that it does make use of one of the old IP prefix lists; namely, match-area0-permit.

Example 10-19 Route Map to Set Metrics According to Table 10-9


! First, two new prefix lists are added – one to match subnets 102 and 103,
! and another to match subnets 106 and 107.

ip prefix-list match-102-103 seq 5 permit 172.16.102.0/23 ge 25 le 26
!
ip prefix-list match-106-107 seq 5 permit 172.16.106.0/23 ge 29 le 30

! The following is a repeat of the prefix list that matches the five routes
! in area 0
ip prefix-list match-area0-permit seq 5 permit 172.16.14.0/30
ip prefix-list match-area0-permit seq 10 permit 172.16.18.0/30
ip prefix-list match-area0-permit seq 15 permit 172.16.8.0/25
ip prefix-list match-area0-permit seq 20 permit 172.16.4.0/25
ip prefix-list match-area0-permit seq 25 permit 172.16.48.0/25

! A new route map to filter and set metrics, with three clauses

route-map set-metric permit 10
match ip address prefix-list match-area0-permit
!
route-map set-metric permit 20
match ip address prefix-list match-102-103
set metric 1000 44 255 1 1500
!
route-map set-metric permit 30
match ip address prefix-list match-106-107
set metric 100 4444 255 1 1500

!
router eigrp 1
default-metric 1500 10 255 1 1500
redistribute ospf 2 route-map set-metric


The new route map has three explicitly configured clauses, two of which explicitly set the metric values using the set metric command. However, the first clause (sequence number 10), which matches routes for the five subnets inside area 0, does not use a set metric command to set the metric. Instead, because this route map clause omits the set metric command, routes that match this clause use the metric keyword on the redistribute command, or if not listed, the metrics as defined by the default-metric EIGRP subcommand. In this case, because the redistributecommand does not list a metric keyword, routes matched by this clause (sequence number 10) use the metric values listed in the default-metric command.

Verifying the Metric Settings

Verifying the metrics again requires an examination of the EIGRP topology table. In this case, Example 10-20 displays a couple of views of RD1’s EIGRP topology table, focusing on routes to 172.16.102.0/25 and 172.16.106.0/29. The configuration in the previous Example 10-19 set the metrics to different values, and next the output in Example 10-20 shows the differences.

Example 10-20 Verifying Metrics as Set During Redistribution


RD1# show ip eigrp topology 172.16.102.0/25
IP-EIGRP (AS 1): Topology entry for 172.16.102.0/25
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 1709056
Routing Descriptor Blocks:
172.16.14.2, from Redistributed, Send flag is 0x0
Composite metric is (2571264/0), Route is External
Vector metric:
Minimum bandwidth is 1000 Kbit
Total delay is 440 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 0
External data:
Originating router is 172.30.17.1 (this system)
AS number of route is 2
External protocol is OSPF, external metric is 65
Administrator tag is 0 (0x00000000)

RD1# show ip eigrp topology 172.16.104.0/25
% IP-EIGRP (AS 1): Route not in topology table

RD1# show ip eigrp topo 172.16.106.0/29
IP-EIGRP (AS 1): Topology entry for 172.16.106.0/29
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 1709056
Routing Descriptor Blocks:
172.16.14.2, from Redistributed, Send flag is 0x0
Composite metric is (26737664/0), Route is External
Vector metric:
Minimum bandwidth is 100 Kbit
Total delay is 44440 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 0
External data:
Originating router is 172.30.17.1 (this system)
AS number of route is 2
External protocol is OSPF, external metric is 65
Administrator tag is 0 (0x00000000)
!
RD1# show ip prefix-list detail match-102-103
ip prefix-list match-102-103:
count: 1, range entries: 1, sequences: 5 - 5, refcount: 2
seq 5 permit 172.16.102.0/23 ge 25 le 26 (hit count: 14, refcount: 1)


Although you could use variations of the show ip route command to verify the new metrics, because the redistribution process sets the EIGRP component metrics, the show ip eigrp topology command displays much more useful verification information.

Setting the External Route Type

When redistributing into OSPF, Cisco IOS automatically sets the external route type to external Type 2 (E2). However, the type can be configured as E1 or E2 by using the set metric-type {type-1 | type-2} route map subcommand. When a redistribute OSPF subcommand references such a route map, the routes matched by the route map clause with the set metric-type command will be designated as that external type in the Type 5 LSA created for that subnet.

Note that the redistribute command also allows the match {internal | external 1 | external 2 | nssa-external} parameters, but these parameters do not set the type or route. Instead, these parameters match existing routes as part of the process of deciding which routes to redistribute.

Redistribution Filtering with the distribute-list Command

Using a route map as referenced on the redistribute command provides many features. You can filter routes, assign different metrics for different routes, and assign external route types. You can even assign route tags as discussed later in the section “Preventing Domain Loops by Filtering on Route Tag Using Distribute Lists.” However, if the plan calls for route filtering only when redistributing, but none of the other functions supplied by a route map are needed, and you can match all the routes with a single ACL or prefix list, Cisco IOS supports a second style of route filtering configuration using the distribute-list command.

The distribute-list command can be configured to refer to the routing process from which routes are redistributed and cause the router to filter routes taken from that process. To do so, the command must use the out direction, and it must refer to the routing process from which routes are redistributed. For example, distribute-list 1 out ospf 2, configured under an EIGRP process, tells EIGRP to apply ACL 1 to routes redistributed from the OSPF 2 process. For another example, under an OSPF process, the distribute-list prefix fred out eigrp 1 command tells OSPF to apply IP prefix list fred to routes redistributed from the EIGRP 1 process.

Finally, one note about internals of how this command works. The filtering takes place as the routes are redistributed. As a result, routes filtered by the distribute-list command prevent the routes from being added to the topology table of the destination routing protocol. So, the same verification commands seen in earlier examples, with a focus on the topology tables, can be used to show whether the filtering worked. Also, the counters in the show ip access-list and show ip prefix-list detail command output also increment to show whether the filtering worked.

Issues with Multiple Redistribution Points

The use of a single router to redistribute routes means that a single failure could cause hosts in different routing domains to fail. The redistributing router could simply fail, or interfaces or links on that router could fail. To avoid that single point of failure, many redistribution designs call for a minimum of two routers performing redistribution, particularly in cases where the redistribution function will be somewhat permanent.

The existence of two or more redistribution points between the same two routing domains introduces some complexity and caveats. The issues revolve around the concept that a route in one domain can be advertised into another domain, and then back into the original routing domain.

Figure 10-12 shows one of the issues when using multiple redistribution points. In this case, the arrowed lines show the best route from a router in domain 2 to reach a subnet also in domain 2. However, the route actually passes through domain 1.

Image

Figure 10-12 Domain Loop

Figure 10-12 shows the long route that goes from R2, through RD1, to R1, and back into routing domain 2 through RD2. This long route occurs because of the routing advertisements that flow in the opposite direction: advertised by RD2 into routing domain 1 and then by RD1 back into routing domain 2. The problem occurs when the twice-redistributed route for subnet X is redistributed back into the original domain with a relatively low metric. The twice-redistributed route then has a better metric than the route that was advertised only internal to that routing domain.

This section examines how to prevent this “domain loop” problem when using multiple redistribution points. Interestingly, this problem does not occur, at least with default settings, when EIGRP is one of the two routing protocols. So this section begins with examples of RIP and OSPF redistribution, showing how to prevent this domain-looping problem and then showing why EIGRP accomplishes this same feat with default settings.


Note

I know of no industry-standard name for the problem shown in Figure 10-12. For the duration of this chapter, I refer to it simply as the domain loop problem.


Preventing Routing Domain Loops with Higher Metrics

One easy method of preventing the domain loop problem is to assign purposefully high metric values when redistributing routes. For example, consider the case shown in Figure 10-13, with a RIP domain on the left and OSPF on the right. In this case, the two routers doing the redistribution (RD1 and RD2) assign an OSPF metric of 500 when redistributing routes into OSPF and a metric value of 5 when redistributing routes into RIP.

Image

Figure 10-13 Defeating Domain Loops by Using Very Large Metrics

First, focus on routes inside the RIP domain. This design prevents the domain loop problem—routes that send packets from the RIP domain, into OSPF, and back again—if the normal intra-domain RIP routes never exceed a hop count of 4. Then, all routes redistributed from RIP into OSPF, and then back into RIP, will at least have a metric of 5. As a result, the route advertisements that looped back into the RIP domain will always have less desirable metrics than the RIP advertisements from within the RIP domain.

The same concept applies to OSPF. For routes completely internal to the OSPF domain, if the highest cost is 499, the redistribution of external routes with a metric of 500 prevents the domain loop. For example, a subnet that exists in the OSPF domain could be advertised into RIP by RD1 and then re-advertised by RD2 back into the OSPF domain—but with a metric value that begins at 500. Again, assuming that all the normal OSPF routes that were not reintroduced as external routes have a cost of less than 500, the domain loop problem is defeated.

Note that OSPF actually defeats the domain loop problem without using the higher metrics. OSPF always prefers internal routes over E1 routes, and E1 routes over E2 routes, before even considering the metrics.

Preventing Routing Domain Loops with Administrative Distance

Each router associates an administrative distance (AD) with every route it considers to be added to the routing table. When a router must consider multiple routes from different sources for the exact same prefix/length, the first item considered by the router is not the metric, but rather the AD. The lower the AD, the better the route.

Note that the AD is a local setting on a router and cannot be advertised to neighboring routers.

Each routing source has a default AD according to Cisco IOS. In some cases, a given routing source has different defaults for different types of routes inside that routing source. For example, EIGRP has different AD values for EIGRP internal routes (AD 90) and EIGRP external routes (AD 170). Table 10-10 lists the default settings.

Image

Image

Table 10-10 Default Administrative Distances

EIGRP Default AD Defeats Loop from EIGRP to OSPF to EIGRP

The default AD settings for EIGRP take care of the domain loop problem when redistributing between EIGRP and OSPF. First, consider an EIGRP and OSPF domain with two redistribution points (Routers RD1 and RD2), as shown in Figure 10-14. The figure shows a general idea of route advertisements for subnet X, which exists in the EIGRP domain. (Note: To reduce clutter, the figure shows only route advertisements that affect Router RD2’s logic; the same issue exists on both redistributing routers.)

Image

Image

Figure 10-14 Subnet X: Internal EIGRP, External OSPF, on Router RD2

Router RD2 hears about a route for subnet X as an internal EIGRP route (default AD 90) on the left. RD2 also hears about the subnet as an external OSPF route on the right (default AD 110). As a result, RD2 will do a couple of things that are important to this discussion:

Image RD2 considers the internal EIGRP route as the best route, because of the lower AD, and places that route in its own IP routing table.

Image RD2 does not redistribute a route for subnet X from OSPF back to EIGRP, because RD2 does not have an OSPF route for subnet X.

The second point is particularly important but easily missed. Remember that routers use the IP routing table as the basis for route redistribution. Both RD1 and RD2 redistribute routes in both directions between both domains. However, a route must be in the routing table before it can be redistributed. Because RD2’s route for subnet X will list its EIGRP route, RD2’s redistribution from OSPF into EIGRP will not redistribute a route for subnet X. Because RD2 will not advertise a route for subnet X from OSPF back into EIGRP, the domain loop has been prevented.

EIGRP Default AD Defeats Loop from OSPF to EIGRP to OSPF

The reverse case—routes taken from OSPF, advertised into EIGRP, and then advertised back into OSPF—is the more interesting possible domain loop case. However, the default EIGRP AD settings still defeat the domain loop issue. Figure 10-15 shows an example similar to Figure 10-14, but this time with subnet Y in the OSPF domain. As before, the focus of the figure is on the routing advertisements that reach Router RD2, with other details omitted to reduce clutter.

Image

Figure 10-15 IDS and IPS Operational Differences

In this case, Router RD2 hears about a route for subnet Y as an external EIGRP route (default AD 170) and as an internal OSPF route (default AD 110). As a result, RD2 chooses the OSPF internal route as the best route and adds that to RD2’s routing table. Because RD2 does not have an EIGRP route for subnet Y, RD2 will not redistribute a route for subnet Y from EIGRP into OSPF, again defeating the domain loop problem.

Setting AD per Route Source for Internal and External Routes

The reason that the default EIGRP AD settings work well can be summarized generically as follows:

For each of the two routing protocols, the AD used for internal routes for one routing protocol is better than the AD used for external routes by the other routing protocol.

When comparing EIGRP’s and OSPF’s defaults, both of the generic criteria are met:

Image EIGRP internal AD 90 < OSPF external AD 110

Image OSPF internal AD 110 < EIGRP external AD 170

Likewise, when redistributing between EIGRP and RIP:

Image EIGRP internal AD 90 < RIP external AD 120

Image RIP internal AD 120 < EIGRP external AD 170


Note

RIP does not have a concept of internal and external routes. The preceding references refer to internal routes as routes that exist inside the RIP domain and external as routes that exist outside the RIP domain.


When redistributing between OSPF and RIP, the default AD settings do not defeat the domain loop problem. However, Cisco IOS supports the definition of different AD settings for all routing protocols. With EIGRP, the internal and external AD settings can be overridden, although the defaults work well for the prevention of domain loops. OSPF can be configured to use a different AD for external routes, intra-area routes, and interarea routes. RIP, which does not have a concept of internal and external routes, can only be set with a single AD value. Table 10-11 shows the router subcommands to set the AD values, per route category.

Image

Table 10-11 Setting AD Values with the distance Command

To defeat the OSPF-RIP domain loop problem by setting AD, just configure the AD for OSPF external routes using the distance ospf external ad-value command in OSPF configuration mode. The actual AD value does not matter much, but it should be higher than RIP’s AD on that same router. For example, the distance ospf external 130 command in OSPF configuration mode results in the following, assuming that all other AD values are set to their defaults:

Image RIP internal AD 120 < OSPF external AD 130

Image OSPF internal AD 110 < RIP external AD 120

Domain Loop Problems with More Than Two Routing Domains

With only two routing domains, the solutions seen so far—setting higher metrics and AD values—can deal with domain loop problems. However, with three or more routing domains, setting metrics and AD values does not always solve the domain loop problem. Specifically, problems can occur when three or more routing domains connect in sequence, as shown in Figure 10-16. Such a situation might exist in the real world where a large company has multiple mergers and acquisitions with smaller companies (running a variety of routing protocols).

Image

Figure 10-16 Inefficient Routing with Looped Routing Advertisements

The steps noted in the figure are as follows:

Step 1. Router R9 advertises a route for network 172.20.0.0/16 from the RIP domain into the EIGRP domain, where the route is treated with (default) AD 170 as an external route.

Step 2. Router RD1 redistributes this EIGRP external route into OSPF, where it is treated as an E2 route, AD 110, by default.

Step 3. Router RD2 uses the AD 110 E2 route, rather than the AD 170 EIGRP external route, as its best route for 172.20.0.0/16. As a result, RD2 can then redistribute that OSPF route back into EIGRP as an external route.

Step 4. Router R4 learns of two external routes for 172.20.0.0/16, and the routes tie based on AD (170). R4 might have a better EIGRP metric through RD2, depending on the metrics used at redistribution, preferring this long route through the OSPF domain as shown.

This is just one example case for such problems, but the problem exists, because the obviously better route and the longer domain loop route are both external routes. The two competing routes tie on AD as a result. In the earlier cases, with only two routing domains, this problem does not occur.

Several solutions exist for such problems. None of the solutions require a lot of extra configuration, other than that some of the solutions require ACLs or prefix lists that match the prefixes from the various routing domains. The next three sections address each option, namely, using per-route AD settings, filtering routes based on prefix/length, and using route tags.

Using Per-Route Administrative Distance Settings

As seen in Table 10-11, you can use the distance router subcommand to set the AD value per routing protocol, per type (internal and external). The distance command also supports another syntax in which the router sets the AD for individual routes based on the following criteria:

Image The router that advertised the routing information

Image Optionally, for the prefixes/lengths of the routes as matched by a referenced ACL

The syntax of the command in this case is

distance distance ip-adv-router wc-mask [acl-number-or-name]

In this command, the required parameters match the neighboring router that advertises a route. The router with the distance command configured compares the advertising router’s IP address to the range of addresses implied by the ip-adv-router and wc-mask parameters of the command, as if these were parameters in an ACL. For routes advertised by a matching neighbor, that router then applies the AD listed in the command.

Optionally, the distance command can also refer to an ACL. If included, that router compares the ACL to the prefix/length of each route learned from any matched neighbors and uses the listed AD only for routes permitted by the ACL.

For example, consider the problem shown in Figure 10-16. Assuming that the design calls for all hosts to have reachability to 172.20.0.0/16, the route must be redistributed by R9 into the EIGRP domain. For the best availability, this route should be redistributed from EIGRP into OSPF at both redistribution points (RD1 and RD2). The unfortunate long-route choice by Router R4 in the figure occurs at what is listed as Step 3 in that figure, with Router RD2 using AD to determine that its external OSPF route for 172.20.0.0/16 (AD 110) is better than its EIGRP external route (AD 170) for that same prefix.

One solution would be to cause RD2 to use a higher AD—specifically higher than the 170 AD used for EIGRP external routes—for prefix 172.20.0.0/16 as learned with OSPF. A distance command on RD2 could solve the problem.

Upcoming Examples 10-21 and 10-22, plus Figure 10-17, demonstrate both the domain loop problem in this same case, along with the solution. First, Figure 10-17 shows a more detailed topology for reference. Then, Example 10-21 shows the relevant configuration and a few related showcommands on Router RD2 before using the distance command to prevent the problem. This example shows Router R4 using the longer path through the OSPF domain on the left. Finally, Example 10-22 shows the configuration of the distance command and resulting solution.

Image

Figure 10-17 Detailed View of Internetwork

Example 10-21 Long Route from RD2, into OSPF, for 172.20.0.0/16


! The following is the routing protocol configuration on RD2
router eigrp 1
redistribute ospf 2 metric 1000 200 255 1 1500
network 172.16.0.0
no auto-summary
!
router ospf 2
router-id 3.3.3.3
log-adjacency-changes
redistribute eigrp 1 subnets
network 172.30.0.0 0.0.255.255 area 0

! Next, the long route for 172.20.0.0/16 is listed. This route goes from
! RD2 back into the OSPF domain; interface S0/0/1 connects to router R2.
RD2# show ip route | include 172.20.0.0
O E2 172.20.0.0/16 [110/20] via 172.30.23.2, 00:06:57, Serial0/0/1


! Next, the source of this routing information is listed under the
! text "Known via". RD2's current route is learned by OSPF.
RD2# show ip route 172.20.0.0
Routing entry for 172.20.0.0/16
Known via "ospf 2", distance 110, metric 20, type extern 2, forward metric 128
Redistributing via eigrp 1
Advertised by eigrp 1 metric 1000 200 255 1 1500
Last update from 172.30.23.2 on Serial0/0/1, 00:07:04 ago
Routing Descriptor Blocks:
* 172.30.23.2, from 1.1.1.1, 00:07:04 ago, via Serial0/0/1
Route metric is 20, traffic share count is 1

! RD2 does know a working (successor) route for the same prefix,
! but prefers the lower-AD route (110) through OSPF.
RD2#show ip eigrp topology | section 172.20.0.0
P 172.20.0.0/16, 1 successors, FD is 2611200
via Redistributed (2611200/0)


The comments inside Example 10-21 detail the current state, with the longer route, as shown in Figure 10-16. Most importantly, note the “Known via...” text in the output of the show ip route 172.20.0.0 command. This output specifically states the source of the route that is currently in the routing table.

Next, Example 10-22 shows the configuration on RD2 to solve this problem by setting RD2’s AD for that specific route and additional show commands.

Example 10-22 Configuring Per-Route AD on Router RD2


RD2# conf t
Enter configuration commands, one per line. End with CNTL/Z.
RD2(config)# router ospf 2
RD2(config-router)# distance 171 1.1.1.1 0.0.0.0 match-172-20
RD2(config-router)# ip access-list standard match-172-20
RD2(config-std-nacl)# permit host 172.20.0.0
RD2(config-std-nacl)# end
RD2#

! Now the best route for 172.20.0.0 is known from EIGRP 1.
RD2# show ip route 172.20.0.0
Routing entry for 172.20.0.0/16
Known via "eigrp 1", distance 170, metric 3635200, type external
Redistributing via ospf 2, eigrp 1
Advertised by ospf 2 subnets
Last update from 172.16.34.2 on Serial0/0/0, 00:08:01 ago
! lines omitted for brevity

! The next command lists the matching logic of the distance command.
RD2# show ip protocols | section ospf
Routing Protocol is "ospf 2"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Router ID 172.30.23.1
It is an autonomous system boundary router
Redistributing External Routes from,
eigrp 1, includes subnets in redistribution
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
Maximum path: 4
Routing for Networks:
172.30.0.0 0.0.255.255 area 0
Reference bandwidth unit is 100 mbps
Routing Information Sources:
Gateway Distance Last Update
1.1.1.1 171 00:00:35
2.2.2.2 110 00:00:35
7.7.7.7 110 00:00:35
Distance: (default is 110)
Address Wild mask Distance List
1.1.1.1 0.0.0.0 171 match-172-20
Redistributing: ospf 2, eigrp 1


The configuration, although short, has one possibly counterintuitive twist. The IP address of the neighboring router, referenced in the distance command in OSPF configuration mode, will be compared to the OSPF RID of the OSPF router that owns the LSA. In this case, Router RD1 creates the Type 5 LSA for 172.20.0.0, and RD1’s RID happens to be 1.1.1.1. RD2’s distance 171 1.1.1.1 0.0.0.0 match-172-20 command tells OSPF to look for LSAs owned by exactly RID 1.1.1.1, and if the prefix is permitted by the match-172-20 ACL, apply AD 171 to this route.

The show ip route 172.20.0.0 command verifies that Router RD1 now prefers its AD 170 EIGRP route for 172.20.0.0/16. The highlighted portions of this command now refer to routing source EIGRP 1, with the outgoing interface of S0/0/0, which connects RD2 into the EIGRP domain. Because RD2 no longer has an OSPF route for 172.20.0.0/16, RD2 will not redistribute such an OSPF route back into EIGRP, defeating the domain loop problem.


Note

A complete solution requires all redistributing routers to perform this kind of configuration, for all such routes from the third routing domain.


Although this example shows the OSPF version of the distance command, one notable difference exists between the OSPF version and the RIP and EIGRP distance commands. When used as a RIP or EIGRP subcommand, the distance command matches the interface IP address of the neighboring router that advertises the route.

Preventing Domain Loops by Filtering on Subnet While Redistributing

The next tool prevents domain loops by filtering the routes based on prefix. Figure 10-18 shows the idea from a redistribution design perspective.

Image

Figure 10-18 Preventing Domain Loops with Route Filtering

Following are the steps as listed in the figure:

Step 1. Router R9 advertises a route for network 172.20.0.0/16 from the RIP domain into the EIGRP domain.

Step 2. Routers RD1 and RD2 both redistribute this EIGRP external route into OSPF.

Step 3. Both RD1 and RD2 flood the route advertisement for the OSPF external route throughout the OSPF domain.

Step 4. Both RD1 and RD2 apply a route map to their redistribution from OSPF into EIGRP, filtering routes with prefix 172.20.0.0.

The configuration itself uses the same methods and commands as included earlier in the section “Filtering Redistributed Routes with Route Maps.”

Interestingly, this design does prevent the long routes, as shown earlier in Figure 10-16, but it does leave the possibility of a long route on a redistributing router. For example, if using all default AD settings, RD2 still learns an OSPF (default AD 110) route for 172.20.0.0 from RD1, so it might choose as best route the OSPF route through RD1. Setting the AD for OSPF external routes to something larger than EIGRP’s external AD of 170 would prevent this particular problem as well.

Preventing Domain Loops by Filtering on Route Tag Using Distribute Lists

Route tags, the last tool shown in this chapter for preventing the domain loop problem, have a much broader use than just preventing redistribution problems.

A route tag is a unitless 32-bit integer that most routing protocols can assign to any given route. The assignment of a tag occurs when some Cisco IOS function adds the tag—for example, it can be assigned by a route map referenced by a routing protocol distribute-list or redistributecommand. That tag follows the route advertisement, even through the redistribution process. At some later point in the flooding of routing information, other Cisco IOS tools, typically other route maps, can match routes with a given route tag to make a decision.

In some cases, the idea of a route tag creates a mental block, because it has no one specific purpose. The network engineer chooses the purpose of a route tag; the purpose has not been predetermined by a particular protocol. The folks that created the routing protocol provided us all with a nice, convenient place to add the equivalent of a sticky note to each route. It’s up to us to decide what the note means.

Figure 10-19 shows one common use of route tags other than for solving the domain loop problem. In the figure, one large company that uses EIGRP (the middle of the figure) bought two smaller companies, both of whom use OSPF. The larger company wants to connect both small companies into the larger network, but it wants to prevent hosts in the two smaller companies from knowing routes to the other smaller company. The figure shows only left-to-right advertisements of routes to reduce the clutter.

Image

Figure 10-19 Using Route Tags to Determine Routing Domain Origin

The two routers on the left each redistribute routes from the smaller companies into the EIGRP. The routers apply a route tag of 1 to each route from OSPF domain 1 and a tag of 2 to routes redistributed from OSPF domain 2. The actual numbers do not matter, as long as they are unique. On the right, the routers know that the routes from OSPF domain 1 have route tag 1, and only these routes should be redistributed into the other part of OSPF domain 1. So, when redistributing into OSPF domain 1, the route map makes a comparison of the route tag (command match tag 1) and allows only those routes. Similarly, when redistributing into OSPF domain 2, the match tag 2 command would be used, redistributing only routes with tag 2.

To use route tags to prevent domain loop problems, you can use the following strategy:

Image

Image Choose and set a tag value that identifies routes taken from domain X and advertised into domain Y.

Image When redistributing in the opposite direction (from domain Y into domain X), match the tag value and filter routes with that tag.

For example, consider the case shown in Figure 10-20. The figure shows the usual RD1 and RD2 between two routing domains, with EIGRP on the right in this case and OSPF on the left. The engineer planned to use route tag 11 to mean “routes taken from EIGRP and redistributed into OSPF.” The figure shows one direction of potential loops: from EIGRP through RD1, through OSPF, and back to EIGRP through RD2. However, the same concept would also apply to the other direction.

Image

Image

Figure 10-20 Using Route Tags to Prevent Domain Loop Problems

The first step (noted with a circled 1 in the figure) is the usual redistribution, but with a route map that tags all routes redistributed from EIGRP into OSPF with tag 11. RD2 learns these routes with OSPF. At Step 2, RD2 tries to redistribute the routes but chooses to filter all routes that have a tag value of 11. As a result, none of the routes learned from EIGRP are re-advertised back into EIGRP. Example 10-23 shows the configuration that matches Figure 10-20.

Example 10-23 RD1 and RD2 Configuration with Route Tags to Prevent Domain Loops


! The following is the routing protocol configuration on RD1
router ospf 2
router-id 3.3.3.3
log-adjacency-changes
redistribute eigrp 1 subnets route-map set-tag-11
network 172.30.0.0 0.0.255.255 area 0
!
route-map set-tag-11 permit 10
set tag 11


! The following is the routing protocol configuration on RD2
router eigrp 1
redistribute ospf 2 metric 1000 200 255 1 1500 route-map stop-tag-11
network 172.16.0.0
no auto-summary
!
route-map stop-tag-11 deny 10
match tag 11
!
route-map stop-tag-11 permit 20


First, note that the configuration does rely on a couple of default route map actions that bear some review. In the set-tag-11 route map on RD1, only one route map clause exists, and that clause has no match commands. A route map clause with no match commands matches all routes, so all routes are assigned tag 11. In the stop-tag-11 route map on RD2, the first clause lists a deny action, meaning that all routes matched by that clause (all with tag 11) are filtered. All other routes, for example those routes for subnets native to the OSPF domain, match the second, because that second clause does not have a match command.

Example 10-23 shows the configuration that tags routes coming from EIGRP into OSPF and then filters routes with that same tag as they go from OSPF into EIGRP. For a complete solution, the reverse case would also need to be configured, using a different route tag value.

Exam Preparation Tasks

Planning Practice

The CCNP ROUTE exam expects test takers to review design documents, create implementation plans, and create verification plans. This section provides some exercises that can help you to take a step back from the minute details of the topics in this chapter so that you can think about the same technical topics from the planning perspective.

For each planning practice table, simply complete the table. Note that any numbers in parentheses represent the number of options listed for each item in the solutions in Appendix F, “Completed Planning Practice Tables.”

Design Review Table

Table 10-12 lists several design goals related to this chapter. If these design goals were listed in a design document, and you had to take that document and develop an implementation plan, what implementation options come to mind? For any configuration items, a general description can be used, without concern about the specific parameters.

Image

Image

Table 10-12 Design Review

Implementation Plan Peer Review Table

Table 10-13 shows a list of questions that others might ask, or that you might think about, during a peer review of another network engineer’s implementation plan. Complete the table by answering the questions.

Image

Image

Image

Table 10-13 Notable Questions from This Chapter to Consider During an Implementation Plan Peer Review

Create an Implementation Plan Table

To practice skills useful when creating your own implementation plan, list in Table 10-14 configuration commands related to the configuration of the following features. You might want to record your answers outside the book and set a goal to complete this table (and others like it) from memory during your final reviews before taking the exam.

Image

Table 10-14 Implementation Plan Configuration Memory Drill

Choose Commands for a Verification Plan Table

To practice skills useful when creating your own verification plan, list in Table 10-15 all commands that supply the requested information. You might want to record your answers outside the book and set a goal to complete this table (and others like it) from memory during your final reviews before taking the exam.

Image

Image

Table 10-15 Verification Plan Memory Drill


Note

Some of the entries in this table might not have been specifically mentioned in this chapter but are listed in this table for review and reference.


Review All the Key Topics

Review the most important topics from inside the chapter, noted with the Key Topic icon in the outer margin of the page. Table 10-16 lists a reference of these key topics and the page numbers on which each is found.

Image

Image

Table 10-16 Key Topics for Chapter 10

Complete the Tables and Lists from Memory

Print a copy of Appendix D, “Memory Tables,” (found on the CD) or at least the section for this chapter, and complete the tables and lists from memory. Appendix E, “Memory Tables Answer Key,” also on the CD, includes completed tables and lists to check your work.

Define Key Terms

Define the following key terms from this chapter, and check your answers in the glossary.

redistribution

external route

Type 4 Summary ASBR LSA

Type 5 External LSA

Type 7 AS External LSA

External Type 1

External Type 2

domain loop

administrative distance

route tag