Route Redistribution

Simple routing protocols work well for simple networks. However as a network grows and becomes more complex, and the original routing protocol may not be the best choice anymore and it is necessary to change the routing protocols. Transition between routing protocols must be well-planned and implemented gradually, in which multiple routing protocols may run in the network for some time.

Whatever the reason for changing the routing protocol, network administrators must manage the transition and migration carefully and thoughtfully. Below lists some important points for that:
 An accurate network topology diagram and an inventory of all network devices are critical for success.
 The new routing protocol will definitely have different requirements and capabilities. Network administrators must understand and know what must be changed and create a detailed migration plan prior to implement any changes.
 There will likely be a time when both routing protocols are running in the network during the transition and migration. Route redistribution strategy must be carefully planned to avoid disrupting production traffic or causing suboptimal routing.
 Determine the timing of the migration – change the entire network at once, or done in stages?
 Will the transition and migration require the change of the IP addressing scheme?

Networks may run multiple routing protocols as part of their design, not only as part of a transition and migration. Therefore, route redistribution might be required in such cases as well.

Resources and schedules must be well-considered when migrating multiple remote sites to a new IP address space. The address plan created for the migration must be well-documented and accessible for review and reference by all networking personnel. Those documents helps to settle any questions or conflicts when there is any. Ex: The new address space might have portions already in use and not known by the designer. Having other networking personnel to review and agree upon the address assignments helps prevent problems during the implementation phase.

Plan the implementation steps after the IP addressing scheme has been determined. Carefully consider the following for successful implementation of a new IP addressing scheme:
 Host addressing. If host IP addresses are statically assigned, this is an excellent time to migrate to use DHCP. If DHCP is already in use, configures the new IP address scopes and the changes of IP addressing will be transparent to most end users.
 Access lists and other filters. Firewalls and other types of traffic filters must have been configured for the old IP addresses. It is important to have complete documentation of all the traffic filters so that they can be updated upon using the new IP addresses. Any route filtering based on the old IP addresses must also be updated.
 Network Address Translation (NAT). If NAT is being used in the network, it must also be modified to recognize the process the new IP addresses. The new IP addresses also might need to be translated to different outside local addresses.
 Domain Name System (DNS). If DNS servers are being used in the network, decide the mappings that must be modified to reflect the new IP addresses.
 Timing. Changes are typically done in stages for a large network. Determine to start at the core and work outward or start at the edges and work inward. Be sure to allocate enough time to test and verify the new configuration.
 Transition strategy. Decide whether to use only the new IP addressing during the migration or whether the old and new IP addressing schemes exist during the transition. Secondary IP addresses may be configured on router interfaces for the second approach.

Note: Some routing protocols have issues with secondary addresses – EIGRP and OSPF use the primary IP address of an interface as the source of their packets. They expect the routers reside on the same subnet. They do not form a neighbor relationship with a router on the wrong subnet. Uses the IP addresses from the same subnet for the primary addresses on neighboring router; do not use the IP addresses from the same subnet for the primary address on one router and the secondary address on its neighbor.

Consider the following steps when planning the migration to a new routing protocol:
 Safe-guard the latest configurations of all network devices, as well as network documentation that include information about traffic-flow paths to ensure that the changes will not create suboptimal paths or routing loops. The documentation should also include baseline statistics for data flows.
 Define a clear and comprehensive timeline for all migration steps.
 Determine which routing protocol is the core and which is the edge, and decide whether starting the migration at the core of the network and working out to the edges; or starting at an edge and working in toward the network core. Each approach has its pros and cons.
 Identify the boundary routers between the multiple running routing protocols. Migrating to a new routing protocol often requires route redistribution between the old and new routing protocols.
 Determine how to redistribute information between the core and edge routing protocols.
 Verify that all devices support the new routing protocol. Perform Cisco IOS software updates when deem fit prior to the migration.
 Implement and test the routing design solution in a lab environment. The migration strategy should be tested in an environment that is as realistic as possible to identify and correct any problem ahead.

---

Route Redistribution

Below are some possible reasons to run multiple routing protocols within an organization:
 Migrating from an older IGRP to a new IGP. Multiple redistribution boundaries may exist until the old protocol has been completely replaced by the new protocol.
 Want to use another protocol but need to keep the old protocol due to the limitations of end systems. Ex: Legacy UNIX host-based routers might support only RIP.
 Merging of organizations with different IGPs.
 Some departments do not want to upgrade their routers to support a new routing protocol.
 When there is a mixed-router vendor network environment, the Cisco-specific routing protocol – EIGRP can be deployed in the Cisco portion of the network; and a public standard-based routing protocol – OSPF for non-Cisco devices.

Cisco IOS allows internetworks using different routing protocols to exchange routing information through a feature called route redistribution. Redistribution is the capability of boundary routers that interconnecting different routing domains to exchange and advertise routing information between routing domains. The boundary router must be running all the routing protocols that intend to exchange routes. Routers can redistribute static routes and directly-connected networks as well as routes from other routing protocols into a routing domain.

Redistribution is always performed outbound. The router that performing redistribution does not change its routing table. Ex: After configured redistribution between EIGRP and OSPF, the EIGRP process on the boundary router advertises the OSPF routes in its routing table as EIGRP routes to its EIGRP neighbors, and vice versa. The neighbors of the boundary router interpret the redistributed routes as external routes.

Routes must be in the routing table for them to be redistributed; this rule often confused us. :-) For instance, a router learns about a network via EIGRP and OSPF; only the EIGRP route will be inserted into the routing table, as it has a lower administrative distance. Suppose RIP is also running on this boundary router and redistributing OSPF routes into RIP. The mentioned network will not be redistributed into RIP, as it is considered as an EIGRP route instead of an OSPF route in the routing table.

Route redistribution is powerful, yet adds complexity and increase confusions upon a network; therefore it should be used only when necessary. Below lists some main issues of redistribution:
 Routing feedback or domain loop. When multiple boundary routers are performing redistribution, routing information received from an AS can be sent back to the same AS.
 Incompatible routing information. Since each routing protocol uses different metrics to determine the best path and the metric information cannot be translated exactly between routing protocols, path selection using the redistributed information may not be optimal. The relative metrics of redistributed routes are lost upon route redistribution. Redistributed routes should be assigned a seed metric that is higher than the largest native metric for all routes in the receiving AS in order to prevent suboptimal routing.
 Inconsistent convergence times. Different routing protocols converge at different rates.
Proper planning ensures that these issues do not cause problems in the network.

Routing protocols employ different metric structures and algorithms that are incompatible with each other. In a network in which multiple routing protocols are present, the exchange of route information and the capability to select the best path across the multiple protocols is critical. Cisco IOS considers the following 2 parameters (in sequence) to select the best path when it learns multiple routes to the same destination from different routing protocols.
 Administrative distance that is used to rate the believability of a routing protocol. Each routing protocol is prioritized in order from most to least believable or reliable using the AD value. A router uses this criterion to determine which routing protocol to believe when multiple routing protocols provide routing information to the same destination. Lower administrative distance values indicate greater believability.
 Routing metric – A value that represents the cost from the router and the destination.

When implementing route redistribution, it is occasionally need to modify the administrative distance of a routing protocol so that its routes are being preferred.

Redistributed routes are not directly connected to a router; they are learned from other routing protocols. A boundary router is able to translate the metric from the source routing protocol into the destination routing protocol. This metric is referred to as the seed / initial / default metric. It is defined upon redistribution configuration. After the seed metric for a redistributed route is defined, the metric increments normally within the routing domain; except for OSPF E2 routes, which hold their seed metric throughout an OSPF routing domain.

The default-metric router subcommand defines the seed metric for all redistributed routes. Cisco IOS defines the seed metric as part of the redistribute router subcommand either with the metric option or using a route map.

A redistributing router must assign a metric upon the redistributed routes. For directly connected networks, the seed metric is derived from the characteristics of the router interface. For RIP, the seed metric starts with a hop count of 0. For IGRP and EIGRP, the seed metric is based on the interface bandwidth and delay. For OSPF, the seed metric is based on the bandwidth of the interface. For IS-IS, the seed metric is 0. The seed metric increments as usual as the routing information being propagated from router to router in the routing domain.

Below shows the default seed metric value for routes that are redistributed into each IP routing protocol. RIP, IGRP, and EIGRP interpret the seed metric of 0 as infinity by default. Infinity metric indicates that the route is unreachable and therefore should not be advertised. Hence, a seed metric must be specified when redistributing routes from other routing protocols into RIP, IGRP, and EIGRP; or the redistributed routes will not be advertised.

Protocol that Route is Redistributed Into	Default Seed Metric
RIP	Infinity (no routes are inserted into the routing table)
IGRP / EIGRP	Infinity (no routes are inserted into the routing table)
OSPF	20 for all except BGP, which is 1
IS-IS	0 (routes are inserted into the routing table)
BGP	The BGP MED metric is set to the IGP metric value (maintain)

For OSPF, the redistributed routes have a default External Type 2 (E2) metric of 20; except for redistributed BGP routes, which have a default External Type 2 (E2) metric of 1.
For IS-IS, the redistributed routes have a default metric of 0. However, IS-IS does not treat a seed metric of 0 as unreachable as with RIP, IGRP, and EIGRP.
For BGP, the redistributed routes maintain the IGP metrics.
Note: Redistributing between EIGRP processes is not required to define the metric using the metric parameter in the redistribute router subcommand or the default-metric command; EIGRP conserves the metric upon redistributing between EIGRP processes.

Below are 2 methods of performing route redistribution:
 One-way redistribution – Passes a default route into a routing protocol and redistributes only the networks learned from the routing protocol into other routing protocols. This is the safest way to perform redistribution, which redistributes routes in only one direction, on only one boundary router within the network. However, note that having only a single boundary router introduces a single point of failure in the network.
Tips: Implement default routes to facilitate the use of one-way redistribution, if necessary.
Ex: When redistributing between an OSPF routing domain and a RIPv2 protocol domain, use the default-information originate [always] OSPF router subcommand to generate a default route into OSPF domain, and redistribute the OSPF routes into the RIPv2 domain.
 Two-way redistribution – Redistributes all routes between the 2 routing protocols.

Network engineers must determine the core and edge routing protocols. The core routing protocol is the main routing protocol running in the network. During the transition period between routing protocols, the core and edge routing protocols are the new and old routing protocol respectively. For networks that run multiple routing protocols all the time, the core is usually the more advanced routing protocol.

If redistribution must be performed in both directions, and/or on multiple boundary routers, the redistribution configuration should be tuned to avoid suboptimal routing and domain loops.

Route Redistribution Techniques

Below are some redistribution techniques that can be applied depends upon the network design:
 Redistribute a default route from the core routing protocol into the edge routing protocol, and redistributes routes from the edge routing protocol into the core routing protocol. This technique helps prevent suboptimal routing, route feedback, and domain loop.
 Redistribute multiple static routes about the core routing protocol into the edge routing protocol, and vice versa. This method works if there is only a redistribution point (boundary router); multiple redistribution points may cause route feedback / domain loop.
 Redistribute routes from the core routing protocol into the edge routing protocol with filtering to block out inappropriate routes. For instance, when there are multiple boundary routers, routes redistributed from the edge routing protocol at a boundary router should not be redistributed from the core routing protocol back into the edge routing protocol on another boundary router (or redistribution point).
 Redistribute all routes from the core routing protocol into the edge routing protocol, and from the edge routing protocol into the core routing protocol; and then modify the administrative distance associated with the redistributed routes so that they are not the selected routes when multiple routes exist for the same destination. For instance, the administrative distance might need to be modified if the route learned by the core routing protocol is better but has a higher (less believable) administrative distance.

Redistribution supports all routing protocols. Static and directly connected routes can also be redistributed to allow the routing protocol to advertise these routes. Routes are redistributed into a routing protocol; therefore the redistribute router subcommand is configured under the routing protocol that is going to receive the redistributed routes.

Router(config-router)#redistribute ?
  bgp        Border Gateway Protocol (BGP)
  connected  Connected
  eigrp      Enhanced Interior Gateway Routing Protocol (EIGRP)
  isis       ISO IS-IS
  iso-igrp   IGRP for OSI networks
  metric     Metric for redistributed routes
  mobile     Mobile routes
  odr        On Demand stub Routes
  ospf       Open Shortest Path First (OSPF)
  rip        Routing Information Protocol (RIP)
  route-map  Route map reference
  static     Static routes
  <cr>

Router(config-router)#

Consider the following points before implementing redistribution:
 Cisco IOS allows only redistribution between routing protocols that support the same protocol stack. Ex: Redistribution between IP RIP and OSPF is possible because they both support the TCP/IP stack. Redistribution between IPX RIP and OSPF because IPX RIP supports the IPX/SPX (Internetwork Packet Exchange / Sequenced Packet Exchange) stack which OSPF does not support. Although EIGRP has different protocol-independent modules for IP, IPX, and AppleTalk, routes cannot be redistributed between them, because each PDM supports a different protocol stack.
 Redistribution configuration varies upon the different routing protocols. Some routing protocols require a metric to be specified upon redistribution configuration.

The redistribute {src-protocol} [proc-id | isis-area-tag] {level-1 | level-1-2 | level-2} [match {internal | external [1 | 2] | nssa-external [1 | 2] }] [metric {metric-value | transparent}] [metric-type metric-type] [tag tag-value] [route-map map-tag] [subnets] router subcommand redistributes routes from a routing domain into another routing domain.

src-protocol	Source protocol from which routes are being redistributed. It can be one of the bgp, connected, eigrp, isis, ospf, rip, or static [ip] keywords. The static keyword is used to redistribute IP static routes. The ip keyword is used when redistributing IP static routes into the Integrated IS-IS routing protocol.
proc-id, isis-area-tag	For the bgp or eigrp keyword, it is an autonomous system number. For the ospf keyword, it is an OSPF routing process ID. For the isis keyword, it is an area tag value of a routing process. It is not applicable for the rip keyword.
level-1, level-1-2, level-2	Specifies the routes of the corresponding IS-IS routing levels that are being redistributed into other IP routing protocols.
internal, external, nssa-external	Used to specify the type of OSPF routes that are to be redistributed.
metric-value	Defines the seed metric for redistributed routes.
transparent	For RIP to use the routing table metric as the RIP metric for redistributed routes.
type-value	For OSPF, specifies the external route type – E1 or E2 (default) associated with the redistributed routes. For IS-IS, is can be one of the following 2 keywords:  internal – Assign an IS-IS metric that is < 63 (default).  external – Assign an IS-IS metric that is > 64 < 128.
tag-value	An optional 32-bit unsigned decimal value attached to an OSPF external route. This is not being used by OSPF itself. It may be used to communicate information between ASBRs. If none is specified, then the source autonomous system number is used for routes redistributed from BGP and EGP. Not applicable to other protocols.
map-tag	Specifies a route map that filters the routes redistributed from the source routing protocol. If not specified, all routes are redistributed. If the specified route map does not exist, no routes are redistributed.
subnets	Indicates the scope of redistribution for the specified protocol when redistributing routes into OSPF. If this keyword was omitted, only classful networks (no subnets) will be redistributed into the OSPF domain. Omitting this keyword is a common OSPF configuration error.

Redistribution into OSPF and IS-IS can also be limited to a number of prefixes using the redistribute maximum-prefix {max-value} [threshold] [warning-only | withdraw] router subcommand. The threshold value defaults to log a warning message at 75 percent of the defined max-value. No further routes will be redistributed after reaching the defined max-value. If the warning-only keyword is configured, redistribution is not limited to the max-value; it simply logs another warning message when the redistributed prefixes reached the max-value. The optional withdraw keyword that only available for IS-IS will cause IS-IS to rebuild LSPs without the external (redistributed) IP prefixes. This command was introduced in Cisco IOS 12.0(25)S Release and was integrated into Cisco IOS 12.2(18)S and 12.3(4)T Releases and later.

When redistributing into RIP, the default metric is infinity; except when redistributing a static (including a static default route defined using the ip route 0.0.0.0 0.0.0.0 global command) or directly-connected network, in which the default metric is 1.

When redistributing routes into EIGRP, the default metric is infinity; except when redistributing a static or directly-connected route into EIGRP, the default metric is equal to the metric of the associated static route or directly-connected interface. A metric must specified to ensure that the routes are redistributed. The redistributed routes appeared as external EIGRP (D EX) routes in the routing table. External EIGRP routes have a higher administrative distance (170) than internal EIGRP routes (90); therefore internal EIGRP routes are preferred over external EIGRP routes.

When redistributing into OSPF, the default metric is 20 (except for BGP routes, which is 1), the default external metric type is E2, and subnets are not redistributed by default. It the subnets keyword is used. If this keyword were omitted, no subnets would be redistributed into the OSPF routing domain. Omitting this keyword is a common OSPF configuration error.

External routes are introduced into IS-IS as Level 2 with a metric of 0 by default.
When redistributing IS-IS routes into other routing protocols, options are available to include L1, L2, or both L1 and L2 routes. If no level is specified, all routes are being redistributed.

Router(config)#router ospf 100
Router(config-router)#redistribute isis ?
  WORD         ISO routing area tag
  level-1      IS-IS level-1 routes only
  level-1-2    IS-IS level-1 and level-2 routes
  level-2      IS-IS level-2 routes only
--- output omitted ---

The default-metric {metric-value | {bandwidth delay reliability loading mtu}} router subcommand specifies the default metric that applied upon all the redistributed routes. Using this command eliminates the need to define metrics separately for each redistribution.

The metric parameter in the redistribute router subcommand can set a different default metric for each routing protocol that is being redistributed. The metric value configured in such way overrides the value specified in the default-metric command for a particular routing protocol.

The passive-interface {type num | default} router subcommand prevents routing updates for a routing protocol from being sent out a router interface, but still receives routing updates on that interface (RIP and IGRP); and prevents Hello packets from being sent out a router interface, therefore do not establish unwanted neighbor relationship with other routers (EIGRP and OSPF).

The default keyword set all router interfaces for as passive interfaces a routing protocol. The passive-interface default router subcommand is often implemented in distribution routers in Internet service providers and large enterprise networks, which have more than 100 interfaces. Prior to the introduction of the Default Passive Interface feature in Cisco IOS Release 12.0, network administrators would enable the routing protocol on all interfaces and then manually define the interfaces that did not require adjacency using many passive-interface commands. The passive-interface default command is now available to set all interfaces to passive, followed by enable interfaces that require adjacencies using the no passive-interface {intf-type intf-num} command.