CCNP ROUTE Certification Guide: Basic IGP Redistribution

This chapter is from the book 

Foundation Topics

Route Redistribution Basics

Most internetworks use a single 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 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 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 EIGRP and the other using 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 9-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.

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:

• Mergers when different IGPs are used.
• Mergers when the same IGP is used.
• Momentum (The Enterprise has been using multiple routing protocols a long time.)
• Different company divisions under separate control for business or political reasons.
• Connections between partners.
• To allow multivendor interoperability (OSPF on non-Cisco, EIGRP on Cisco, for instance).
• Between IGPs and BGP when BGP is used between large segments of a multinational company.
• Layer 3 WAN (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 may still be useful. Even if both companies use EIGRP, they probably use a different AS number 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 may 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 may 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 9-2 depicts both of these cases.

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 their respective routing protocol instance, redistribute into BGP, and then redistribute out of BGP into other divisions. Also, when an Enterprise uses an MPLS VPN service, the MPLS provider's provider edge (PE) router typically redistributes customer routes with BGP inside the MPLS provider's MPLS network. Figure 9-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.

Redistribution Concepts and Processes

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

• Step 1. Use at least one working physical link with each routing domain.
• Step 2. A working routing protocol configuration for each routing domain.
• Step 3. 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 9-4 shows an example router, RD1, that has completed Steps 1 and 2. RD1 uses EIGRP on the left, OSPF on the right, and has learned some routes with each routing protocol (Steps 1 and 2). However, no redistribution has been configured yet.

The goal for redistribution in this case is to have EIGRP advertise about subnets 11, 12, and 13, which exist inside the OSPF domain, and have OSPF advertise about 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 LSAs, 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 for 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 IOS redistribute 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 9-5 spells it out with an example, which focuses on the internal logic of Router RD1 as shown in Figure 9-4.

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 9-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 an NSSA area, 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 may or may 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 9-1 later in this chapter demonstrates this concept.

Example 9-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

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. Before moving into the specifics, however, note that the redistribution as discussed in this chapter does not include any filtering or summarization. In real life, engineers often use both route filtering and route summarization at the redistribution point on a router. For the sake of making the underlying concepts clear, this chapter focuses on the mechanics of redistribution, without filtering, or summarization, or any other changes to the redistributed routes. Chapter 10 then looks at the fun 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, and its parameters. 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 9-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]

Table 9-2. Commonly Used OSPF Terms

Option	Description
protocol	The source of routing information. Includes RIP, OSPF, EIGRP, IS-IS, BGP, connected, and static.
process-id, as-number	If redistributing a routing protocol that uses a process ID or ASN on the router global config command, use this parameter to refer to that process or ASN value.
metric	A keyword after which follows the four metric components (bandwidth, delay, reliability, link load), plus the MTU associated with the route.
match	If redistributing from OSPF, this keyword lets you match internal OSPF routes, external (by type), and NSSA external routes, essentially filtering which routes are redistributed.
tag	Assigns a unitless integer value to the routes redistributed by this command—tags which can be later matched by other routers using a route-map.
route-map	Apply the logic in the referenced route-map to filter routes, set metrics, and set route tags.

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 9-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.

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. (Chapter 10 discusses these issues in some depth.) Example 9-1 shows the configuration on RD1, listing the IP addresses of the four active serial interfaces shown in Figure 9-6, plus the complete but basic EIGRP and OSPF configuration—but without any redistribution configured yet.

Configuring EIGRP Redistribution with Default Metric Components

For the internetwork of Figure 9-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, it may not be obvious of the direction of redistribution. A better command name might have been "take-routes-from," because the first parameter after the command tells IOS from where to get the routes.

For example, consider the configuration in Example 9-2, which was added to RD1's existing configuration in Example 9-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 IOS to redistribute the routes into EIGRP 1, from OSPF 2 in this case.

Example 9-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)#^Z

IOS does accept the configuration; unfortunately, 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 in Example 9-3, which lists show command output from RD1 when configured as shown in the previous example. Note that 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 9-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 9-3.

Table 9-3. Methods of Setting EIGRP Metrics When Redistributing into EIGRP

Function	Command
Setting the default for all redistribute commands	The default-metric bw delay reliability load mtu EIGRP subcommand
Setting the component metrics applied to all routes redistributed by a single redistribute command	The metric bw delay reliability load mtu parameters on the redistribute command
Setting different component metrics to different routes from a single route source	Use the route-map parameter on the redistribute command, matching routes and setting metric components.

If the metrics do not matter to the design, which is likely when only a single redistribution point exists as in Figure 9-6, either of the first two methods listed in Table 9-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 redistribute command 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 9-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), reliability to 255 (a value between 1–255, 255 is best), load to 1 (a value between 1–255, 1 is best), and MTU of 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 9-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)#^Z

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 9-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 9-5 shows the proof that RD1 indeed created entries in its EIGRP topology table for the five subnets in the OSPF domain.

Example 9-5. Verifying 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, including

• On Router RD1, which performed the redistribution, the EIGRP topology table lists the outgoing interface as "via redistributed."
• 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.
• 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.
• The output of the show ip eigrp topology 172.16.48.0/25 command confirms the component metrics match the values configured on the default-metric command.
• 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 9-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:

• All routes in the routing table learned by that routing protocol
• All connected routes of interfaces on which that routing protocol is enabled

Although Example 9-5 shows the evidence that Router RD1 added the topology data to its EIGRP topology database, it did not show any routes. Example 9-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 9-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. Chapter 10 shows cases in which this default helps prevent routing loops when multiple redistribution points exist.

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 9-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]

Table 9-4. Parameters on the OSPF redistribute Command

Option	Description
protocol	The source of routing information. Includes RIP, OSPF, EIGRP, IS-IS, BGP, connected, and static.
process-id, as-number	If redistributing a routing protocol that uses a process-id or ASN on the router global config command, use this parameter to refer to that process or ASN value.
metric	Defines the cost metric assigned to routes redistributed by this command, unless overridden by a referenced route map.
metric-type {1 | 2}	Defines the external metric type for the routes redistributed by this command: 1 (E1 routes) or 2 (E2 routes).
match	If redistributing from another OSPF process, this keyword lets you match internal OSPF routes, external (by type), and NSSA external routes, essentially filtering which routes are redistributed.
tag	Assigns a unitless integer value to the routes redistributed by this command—a tag that can be later matched by other routers using a route-map.
route-map	Apply the logic in the referenced route-map to filter routes, set metrics, and set route tags.
subnets	Redistribute subnets of classful networks. Without this parameter, only routes for classful networks are redistributed. (This behavior is unique to 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:

• When taking from BGP, use a default metric of 1.
• When taking from another OSPF process, take the source route's metric.
• When taking from all other sources, use a default metric of 20.
• Create a Type 5 LSA for each redistributed route (external) if not inside an NSSA area; create a Type 7 LSA if inside an NSSA area.
• Use external metric type 2.
• 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 9-6, including the baseline configuration shown in Example 9-1, and the EIGRP redistribution configuration shown in Examples 9-2 and 9-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 9-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 been configured yet.

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

Example 9-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 9-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 LSAs (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, either.

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 9-8 shows the results.

Example 9-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)#^Z
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

IOS even mentions that only classful routes will be redistributed. As seen in Example 9-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 9-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 9-9.

Example 9-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)#^Z
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:

• If you look back to Example 9-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 9-9's two show commands in Example 9-9 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).
• The show ip ospf database command in Example 9-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.
• Per OSPF internal router R4's show ip route 172.30.0.0 command at the end of Example 9-9, the external metric type is indeed E2, meaning external type 2.
• 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, a different section titled "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 9-5 summarizes the defaults and metric setting options for redistribution into OSPF.

Table 9-5. Summary of Metric Values When Redistributing into OSPF

Function	Command or Metric Values
Default if no metric configuration exists	Cost 1 for routes learned from BGP. If redistributed from another OSPF process, use the source route's OSPF cost. Cost 20 for all other route sources.
Setting the default for all redistribute commands	The default-metric cost OSPF subcommand.
Setting the metric for one route source	The metric cost parameters on the redistribute command.
Setting different metrics for routes learned from a single source	Use the route-map parameter on the redistribute command.

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:

• LSID: The subnet number
• Mask: The subnet mask
• Advertising router: The RID of the ASBR injecting the route
• Metric: The metric as set by the ASBR
• 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 ABRs exist, the ABRs flood the Type 5 LSAs into any normal (nonstubby) areas. (Note that ABRs must not forward Type 5 LSAs into any type of stubby area, instead relying on default routes.) Figure 9-7 shows a sample flooding of the Type 5 LSA for EIGRP subnet 172.30.27.0/23 as an E2 route.

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 9-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 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 under the next two headings.

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:

• 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 9-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 these steps as follows:

• 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 9-8 shows the interface costs 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 9-8. Example 9-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.

Example 9-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 tie-breaker 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 may 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 their 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 9-9 shows a portion of Figure 9-7, with costs highlighted, assuming the OSPF reference bandwidth is also using default settings.

R5 has two possible routes shown in Figure 9-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 9-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 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 9-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 9-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 difference 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-routers command.

Redistributing into OSPF as E1 Routes

OSPF's external metric type feature allows 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), so 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, 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 9-12 shows the simple change to the redistribution configuration on RD1 (as shown earlier in Example 9-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 9-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)#^Z
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:

• The best intra-area cost to reach the ABR (per that area's LSDB)
• The cost from that ABR to the ASBR (per Type 4 LSA)
• The external cost for the route (per Type 5 LSA)

For example, Figure 9-9 shows that R5's best cost to reach ASBR RD1 was out S0/0, to R3 next, with cost 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:

• The intra-area cost to ABR R3 (64), by analyzing the area 1 LSDB entries
• R3's cost to reach ASBR 1.1.1.1, as listed in its Type 4 LSA (1)
• 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 destination external to OSPF. For E1 routes, both the external cost and internal OSPF cost matters 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, then every router will choose ASBR1 as the better ASBR. Conversely, if the goal were to balance the traffic, and make each router pick the closest ASBR, both ASBRs could set the same metric to their redistributed routes, but make the routers 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 NSSA Areas

Routes may be redistributed into OSPF on any OSPF router, with a few exceptions. The router may 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 non-backbone 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–NSSA areas–can redistribute routes, while still holding to the restriction of having no Type 5 LSAs.

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

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 9-13 demonstrates the concept using area 1 from Figures 9-7 and 9-9. Area 1 has been converted to be an NSSA area. R5 has been configured to redistribute connected routes. This feature allows a router to inject connect 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 9-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
 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 R4. 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, show detailed output from the show ip ospf database nssa-external command on R5 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 exact 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 9-14 shows a few interesting items about the IP routing table with NSSA areas. Routers inside the NSSA area 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 area, 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 area, 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 9-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