Route redistribution basics

Reason to choose route redistribution:

Technical : An internetwork uses more than one routing protocol, and the routers need to be exchanged between those routing domains, at least temporarily. E.g. two companies merge, with one using EIGRP and the other using OSPF.

Business reasons:

  • Mergers when different IGPs are used.
  • Mergers when the same IGP is used
  • Momentum ( the enterprise has been using multiple routing protocols for a long time.)
  • Different company divisions are under separate control for business or political reasons.
  • Connections between partners
  • Between IGPs and BGP when BGP is used between large segments of a multinational company.
  • Layer 3 WAN ( MPLS, also called layer 2.5)

Benefit: minimal amount of configuration, and with little disruption to the existing networks.

 If both companies use EIGRP, they probably use different Autonomous system number (ASN) in their EIGRP configuration (with the router eigrp asn command). In this situation, we would need to migrate to use the same ASN as the first company.

Prerequesite

At least one router to do the following:

  • Use at least one working physical link with each routing domain
  • A working routing protocol configuration for each routing domain
  • Additional redistribution configuration for each routing protocol, specifically the redistribute command.
How it works

The difficulties in routing redistribution:

OSPF’s topology table has a lot of different information in ti compared to EIGRP’s topology table.

  • OSPF has a Link-state advertisements and EIGRP does not.
  • EIGRP list the components of the composite metric and neighbor’s reported distance (RD)- but OSPF does not.

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.

Example:

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.

redistribute
Figure1

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.

redistribute_2
Figure2

The redistribute command, configured inside a routing protocol configuration mode, redistributes routes into that routing protocol from some other source. Figure 2 spells it out with an example, which focuses on the internal logic of Router RD1 as shown in Figure 1 .

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.

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.

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.

Redistribution into EIGRP

Syntax:

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]

Option Description
protocol The source of routing information. Includes bgp, connected, eigrp,isis, mobile, ospf, static and rip.
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.

Note, if you don’t set it here, you must set it another way, or else, IOS does not redistribute other routes into eigrp.

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 that can be later matched by other routers using a route map.
route-map Applies the logic in the referenced route map to filter routes, set metrics, and set route tags


Understand the command:

eg:

RD1(config)# router eigrp 1
RD1(config-router)# redistribute ospf 2
RD1(config-router)# end
  • 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”, in this example, take routes from ospf 2 in local router.
  • Because the configuration places this command in EIGRP configuration mode, the command tells Cisco IOS to redistribute the routes into EIGRP 1.
     

By this stage, 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 or other routing protocols.

Three ways to set metric

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:

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.

 

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

Verify EIGRP redistribution

 

show ip eigrp topology : EIGRP topology table lists the outgoing interface as “from redistributed“.

show ip eigrp topology network/mask_length   :   confirms that the component metrics match the values configured on the default-metric command.

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

Redistribution into OSPF

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.

Syntax:

 

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

Option Description
protocol The source of routing information. Includes bgp, connected, eigrp,isis, mobile, ospf, static, and rip
process-id, as-number   If redistributing a routing protocol that uses a process ID or AS number on the router global config command, use this parameter to refer to that process ID 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 OSPF routes (either E1 or E2),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 Applies 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.)

To better appreciate some of these settings, this section first examines the results when using all defaults, using as few parameters as possible.

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; create a Type 7 LSA if inside an NSSA.
Use external metric type 2.
Redistribute only routes of classful (Class A, B, and C) networks, and not routes for subnets.

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.

RD1(config)# router ospf 2
RD1(config-router)# redistribute eigrp 1
% Only classful networks will be redistributed

If you have a network prefix  172.30.0.0/16 in eigrp topology ,  it will not be redistributed into ospf database. By changing the configuration to use the redistribute eigrp 1 subnets command, OSPF indeed redistributes the routes .

In the show ip 172.30.0.0 command:

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.

Metrics

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.

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.
Redistributing into OSPF as E2 Routes

Type 5 LSA includes the following fields:
LSID (Link-state ID): 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 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).

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.

The router resides in the same area as the ASBR (intra-area) or in a different area (interarea)

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.

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.

Interarea

When the ASBR is in a different area, 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.

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. ABRs create Type 4 LSAs in reaction to receiving an external LSA from some ASBR. 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.

Verify
  • show ip ospf database | begin ASB : lists two Type 4 LSAs. The command itself lists the summary of OSPF LSDB, beginning with the section that lists Type 4 LSAs.)
  • show ip ospf database asbr-summary , lists the same two Type 4 LSAs,  but in detail. The first lists ASBR, with ABR and cost.
  • 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.
Redistributing into OSPF as E1 Routes

OSPF routers calculate the metrics of E1 routes by adding the internal cost to the ASBR to the external cost . 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.

Router(config-router)#  redistribute eigrp 1 subnets   metric-type 1

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)

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

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

NSSAs—can redistribute routes.

OSPF supports the injection of external routes into NSSAs by defining the Type 7 LSA.

Verify:

show ip ospf database | begin Type-7   // keep in mind the case of the keyword “Type-7”

show ip ospf database nssa-external

Redistribution with Router maps

 

Specifically, the route map can perform the following:
■    Identify the subset of the routes to filter or change based on the route’s prefix/length, plus many other factors.
■    Make filtering choices about which routes are redistributed and which are not.
■    Set the metric to different values based on information matchable by the route map.
■    Set the type of external route for different redistributed routes, for example, OSPF Type 1 for some routes and Type 2 for others.
■    Set a route tag, a unitless integer value that can later be matched with a route map at another redistribution point.

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

By route type:

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

this applies only when redistributing from OSPF, and matches routes solely based on the types of routes.

By route map

The   route-map    map-name  option

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.

Match command Description
match interface    interface-type interface-number  […   interface-type interface-number]   Looks at outgoing interface of routes
 match ip address  {[  access-list-number  |   access-list-name ] |   prefix-list    prefix-list-name } Examines route destination prefix and prefix length
match ip next-hop  {  access-list-number  |   access-list-name }   Examines route’s next-hop address
match ip route-source  {  access-list-number  |   access-list-name }  Matches advertising router’s IP address
match metric    metric-value  [  + – deviation ]   Matches route’s metric, or a range (plus/   minus the configured deviation)
match route-type  {  internal  |   external  [  type–1  |  type–2 ]   | level–1  |   level–2 }  Matches route type
   match tag    tag-value  [  …tag-value ]   Matches the route tag, which requires that another router has earlier set the tag

A route map referenced by the   redistribute  command always attempts to filter routes.

  • Not redistributed: However, if the first  route-map  clause matched by a route has a  deny action, the route is filtered.
  • Redistributed: If the route map matches a particular route with a particular   route-map  clause, and the action in that clause is permit.

For routes not filtered by the route map, the route map can set other values (like the route’s metric) using the set  command:

Set command Description
Set metric metric-value Sets the route’s metric for OSPF, RIP, and IS-IS
set metric bandwidth delay reliability
loading mtu
Sets an EIGRP route’s metric values
set metric-type  {  type–1  |   type–2 }   Sets type of route for OSPF
 set tag    tag-value   Sets the unitless tag value in a route

 

 

Verify:
  • show ip route prefix
  • Show ip eigrp topology | include prefix
  • show ip eigrp topology prefix : show the metrics.
  • show ip access-list [nubmer | name]: show the counters , which increment each time IOS matches a route for redistribution.
  • show ip prefix-list detail [name]: show the counters.
example:
RDC_APP_connect

1.  On R3, verify the routing table entry for the routes learned externally identified with the 0 E2 source entry.

 

R3# show ip route ospf | include O E2

O E2     172.16.1.0/24 [110/20] via 172.16.23.2, 00:13:55, Serial0/0/1

O E2     172.16.2.0/24 [110/20] via 172.16.23.2, 00:13:55, Serial0/0/1

O E2     172.16.12.0/24 [110/20] via 172.16.23.2, 00:13:55, Serial0/0/1

 

2. Configure a prefix list identifying the route to be filtered.

R2(config)# ip prefix-list R1-PL permit 172.16.12.0/24

 

3. Configure a route map matching the identified route in the prefix list and assign the metric cost of 25 and change the metric type to External Type 1. Then add a permit statement without a match statement acting as an explicit “permit all”.

 

R2(config)# route-map R1-FILTER permit 10

R2(config-route-map)# description RM filters 172.16.12.0/24

R2(config-route-map)# match ip address prefix-list R1-PL

R2(config-route-map)# set metric 25

R2(config-route-map)# set metric-type type-1

R2(config-route-map)# exit

R2(config)# route-map R1-FILTER permit 20

R2(config-route-map)# description RM permits all other R1 OSPF routes

R2(config-route-map)# exit

 

4. Apply this route map to OSPF by reentering the redistribute command using the route-map

 

R2(config)# router ospf 1

R2(config-router)# redistribute eigrp 1 subnets route-map R1-FILTER

R2(config-router)# exit

R2(config)#

 

5. Verify that the two R3 networks are filtered out in the R1 routing table.

 

R3# show ip route ospf | begin Gateway

Gateway of last resort is not set

172.16.0.0/16 is variably subnetted, 8 subnets, 2 masks

O E2     172.16.1.0/24 [110/20] via 172.16.23.2, 00:02:57, Serial0/0/1

O E2     172.16.2.0/24 [110/20] via 172.16.23.2, 00:02:57, Serial0/0/1

O E1     172.16.12.0/24 [110/1587] via 172.16.23.2, 00:02:57, Serial0/0/1

O IA     172.16.100.0/24 [110/1563] via 172.16.23.2, 00:02:57, Serial0/0/1

O     192.168.8.0/22 is a summary, 00:02:57, Null0

 

Notice that the172.16.12.0/24 route is now a type 1 route and calculates the actual metric.

redistribute by distribute lists

 

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.

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.