IGP – Configuring and Verifying Route Redistribution (Part 1)

In Cisco IOS software, route redistribution is configured via the redistribute [protocol] [process ID] [autonomous-system-number] [metric <value>] [metric-type <type>] [match <internal | external 1 | external 2>] [tag <tag>] [route-map <name>] [subnets] [nssa-only] router configuration command. Table 4-3 lists and describes the functions of these included keywords:

Tab. 4-3. Route Redistribution Configuration Keywords

The sections that follow will describe the route redistribution configuration and verification tasks for both OSPF and EIGRP.  These sections describe the following scenarios:

• EIGRP Redistribution Metrics
• Redistributing between two EIGRP Autonomous Systems
• Redistributing OSPF Routes into EIGRP
• Redistributing Connected and Static Routes into EIGRP
• OSPF Redistribution Metrics
• Redistributing Classful and Classless Subnets into OSPF
• Redistributing between two OSPF Processes
• Redistributing EIGRP Routes into OSPF
• Redistributing Connected and Static Routes into OSPF
• OSPF NSSA Type 1 and Type 2 External Routes
• Troubleshooting OSPF Route Redistribution Issues

EIGRP Redistribution Metrics

By default, when external routing information is redistributed into EIGRP, the external routes are assigned a default metric of infinity. The only three exceptions to this rule are:

• When redistributing between two EIGRP autonomous systems
• When redistributing static routes into EIGRP
• When redistributing connected interfaces (subnets) into EIGRP

EIGRP preserves all metrics when redistributing between the two EIGRP autonomous systems. When connected subnets (interfaces) and static routes are redistributed into EIGRP, the redistributed routes are assigned a default external metric value of 0. This default behavior will be illustrated in detail later in the following sections.

When redistributing any other external route source, OSPF, or BGP, for example, a metric must be manually specified for those external routes. In Cisco IOS software, this can be performed using one of three methods:

• By specifying the seed (default) EIGRP metric for redistributed routes
• By indirectly specifying the EIGRP metric during redistribution using a route map
• By directly specifying the EIGRP metric during route redistribution

The seed metric is the metric value that will be assigned to all the redistributed routes. In other words, this is the initial metric that will be assigned to the external routing information when redistribution into EIGRP is configured. The seed metric is configured using the default-metric [bandwidth] [delay] [reliability] [loading] [mtu] router configuration command. The following configuration example illustrates how to configure the seed metric using a bandwidth value of 10000 Kbps, a delay value of 1000 microseconds, a reliability value of 255/255, a loading value of 1/255, and finally, an MTU value of 1500 bytes:

NOTE: As was stated in Chapter 2, the delay value used in EIGRP metric calculation is in tens of microseconds. Therefore, the delay value in microseconds must be divided by 10 to be used to compute the EIGRP metric

This configuration can be verified using the show ip protocols command as follows:

The second method of specifying the initial route metric for redistributed routes is to use a route map during route redistribution. This option provides greater flexibility in that different metrics can be assigned to different route sources. Within a route map, the EIGRP metric is specified using the set metric [bandwidth] [delay] [reliability] [loading] [mtu] route map configuration command. The following configuration example illustrates how to set the EIGRP metric for different external OSPF routes using a route map:

Referencing the configuration above, redistributed OSPF routes are assigned an initial metric based on the metric values specified for each route type in the route map configuration. This configuration can be validated by looking at any specific OSPF route simply by using the show ip route command as shown below:

The EIGRP values used for the metric assigned to the route, which in internal (inter-area) in this example, can then be validated using the show ip eigrp topology command as follows:

The values used to derive the initial metric are those specified for internal OSPF routes in the route map as can be seen in the output of the show route-map command:

Finally, the third method of specifying the initial EIGRP metric to be used for imported routes (redistributed routes) is directly during redistribution configuration using the redistribute [protocol] metric [bandwidth] [delay] [reliability] [loading] [mtu] router configuration command. Different values can be used for different route sources, as is shown in the following configuration example:

Redistributing between two EIGRP Autonomous Systems

When redistributing between two EIGRP autonomous systems, EIGRP simply uses the metric value of the other EIGRP autonomous system and a metric does not have to be configured during the redistribution process. Consider the network topology illustrated in Figure 4-7 which shows a basic EIGRP network. R1 and R2 reside in autonomous system 1, while R2 and R3 reside in autonomous system 2. Because R2 resides in both autonomous systems, it is considered the ASBR. This is the router on which redistribution will be performed. Because one EIGRP process is being redistributed into another, the redistribution configuration will be straightforward as there is no need to manually specify a metric for the redistributed routes.

Fig. 4-7. Redistributing Between Two EIGRP Autonomous Systems
The redistribution of EIGRP 1 into EIGRP 2 is performed as follows on R2:

The initial metric value assigned to the 172.16.1.0/24 subnet advertised via EIGRP autonomous system 1 on R1 to R2 can be validated using the show ip eigrp topology command:

Because no explicit metric was specified during the redistribution of EIGRP 1 into EIGRP 2, the same metric value is assigned to the external route under EIGRP autonomous system 2:

This routing information is propagated downstream to R3 as illustrated below:

NOTE: Although the Topology Table on R3 shows the original metric of the external EIGRP route, the metric assigned during redistribution will change just as any EIGRP metric would as EIGRP routes are propagated to downstream routers in the autonomous system. R3s metric includes the delay for the link between itself and R2.

Redistributing OSPF Routes into EIGRP

When redistributing OSPF routes into EIGRP, a metric must be manually specified because the two routing protocols use different metrics and EIGRP does not assign a default metric. In addition to this, while Cisco IOS software allows the configuration to be implemented, the routes will not be redistributed by the router. As an example, consider the topology illustrated in Figure 4-8 which shows a basic network running both EIGRP and OSPF:

Fig. 4-8. Redistributing Between Two EIGRP Autonomous Systems

Referencing Figure 4-8, R1 and R2 are both running OSPF, while R2 and R3 both are running EIGRP. Assuming that the network is correctly configured, R2 shows the following routes:

Next, router R2 is configured to redistribute the OSPF routes into EIGRP as follows:

Following this configuration, the output of the show ip route command for the 172.16.1.0/24 subnet shows that the route is being redistributed via EIGRP as was configured:

However, because no metric was specified, the route is actually not being redistributed and is not present in the EIGRP Topology Table; instead, only the connected subnet is present since this does not require a metric to be specified when being redistributed into EIGRP:

In order to redistribute the 172.16.1.0/24 subnet into EIGRP, the metric must be specified using any one of the three methods described earlier in this section. The following illustrates how to set the metric directly using the redistribute router configuration command:

Following this configuration, the route is now included in the EIGRP Topology Table:

And finally, the output of the show ip route command shows the EIGRP is redistributing the subnet; however, this time, the metric used during redistribution is included:

R2 advertises the route downstream to R3 which shows the following in the Topology Table:

Redistributing Connected and Static Routes into EIGRP

As was stated earlier in this section, by default EIGRP redistributes connected and static routes with a metric value of 0. Therefore a metric does not have to be explicitly configured when redistributing connected routes into EIGRP.

Figure 4-9 shows a basic EIGRP network comprised of two routers. R2 and R3 reside in EIGRP autonomous system 2. R2 has two additional Loopback interfaces, Loopback 253, with the IP address 192.168.253.2/24 and Loopback 254, with the IP address 192.168.254.2/24. These subnets will be redistributed into EIGRP on R2. In addition to this, two static routes are also configured on R2. The two static routes for the 172.16.253.0/24 and 172.16.254.0/24 subnets both point to the Null0 interface. These static routes will also be redistributed into EIGRP.

Fig. 4-9. Redistributing Connected and Static Routes into EIGRP

Assuming that EIGRP has been configured correctly between R2 and R3, the redistribution of the connected subnets is performed as follows:

Following this configuration, the show ip eigrp topology command can be used to view the EIGRP metric values assigned to each of these routes which are derived from the interfaces:

The same command, when used for any one of the static routes, shows the following:

When redistributing connected and static routes it is always considered good practice to use a route map to ensure that only the routes that should be imported are redistributed into EIGRP. For example, let us assume that only the 192.168.254.0/24 and the 172.16.254.0/24 prefixes should be redistributed into EIGRP.  Based on the configuration implemented on R2 in the previous example, a distribute list could be used to filter these prefixes so that they would not be advertised to R3. However, this requires additional unnecessary configuration. The recommended solution, therefore, is to use a route map with route redistribution as follows:

Following this configuration, the EIGRP Topology Table on R2 shows the following:

NOTE: An alternative approach when redistributing static routes is to assign each static route a route tag. This can then be matched during redistribution. This negates the need to manually add to the ACL used to match static subnets when redistributing routes. The use of route tags is illustrated in the following configuration example:

In the configuration above, six static routes have been configured on R2. The static routes with an even third octet have been assigned a route tag of 888, while those with an odd third octet have been assigned a route tag of 999. EIGRP has been configured to redistribute static routes based on the specified route map. The route map, in turn, has only been configured to match routes with a route tag of 888. Following this configuration, the EIGRP Topology Table on R2 shows the following route entries: