Redistribution
Redistribution is the process of taking routes from the routing table and injecting
them into a routing protocol. The source of the injected routes could be any
of: connected routes, static routes or routes from another routing protocol that
are in the routing table (RIB). Sourcing routes from the RIB implies that:
- the best routes are redistributed.
- Loop-free routes are redistributed.
Redistribution enables multi-protocol routing environments. The routing device performing the redistribution
participates in the routing domain of
the source and destination of the redistributed routes. For instance, if redistributing
routes from OSPF into BGP, the redistributing device participates in the OSPF
routing domain as well as the BGP routing domain.
Redistribution requires careful planning to avoid the formation of routing loops and traffic black holes.
Reasons for Redistribution
An enterprise may implement redistribution for one or more of the following reasons:
- A company merger where the networks of both companies run different
routing protocols.
- Different organizational department networks are under different network
administrative control perhaps based on geography.
- An organization inter-connecting with partner networks
- Hardware constraints such routing devices with low memory, CPU.
- During conversion or migration from one routing protocol to another.
- Mixed vendor environment.
- Support for legacy equipment in the network.
- Application-specific protocols support.
- IGP routes may need to be advertised into BGP.
- Some BGP routes may need to be advertised into an IGP.
- Political boundaries.
Types of Redistribution
Redistribution can be implemented in two ways:
Unidirectional Redistribution (one-way redistribution):
routes are redistributed from the source to the destination protocol on a
single routing device in one direction. Conceptually, this type of
redistribution is similar to multipoint one-way redistribution where redistribution
is implemented on more than one routing device but in the same direction i.e.
from source X to destination Y.
Creation of routing loops in one-way redistribution is not possible.
Usually one-way redistribution occurs when redistributing from a source that
is not a routing protocol such as default routes or static routes.
Mutual Redistribution (two-way redistribution): Mutual redistribution
occurs when routes from routing protocol X are injected into routing protocol Y
and routes sourced from routing protocol Y are injected into routing protocol X
on the same routing device.
Mutual redistribution can be thought of as a form of route conversion.
Mutual redistribution can be implemented on a single routing device in the
network (single-point two-way redistribution) or on two or more routing devices
(multipoint two-way redistribution).
Multipoint mutual redistribution has a high-potential for introducing
routing loops. These routing loops can be prevented from occuring using:
access-lists or prefix-lists referenced by route-maps.
One of the most scalable solutions for preventing routing loops introduced by
route redistribution is through the use of route-tags.
Mutual multipoint redistribution provides the benefit of fault-tolerence where
the failure of a redistributing device at one point does not affect traffic across
both routing domains.
Sources of Routes
| Route Source |
Description |
|
Connected
|
Any interface in an "Up" state that is not associated with the destination
protocol. Secondary IP addresses are also redistributed.
|
| Static |
Any static route that is present in
the RIB. Static routes can only be a source i.e. mutual redistribution can
not be implemented with static routes. |
| OSPF |
Any routes in the RIB sourced from OSPF. If redistributing from OSPF to
BGP, by default, OSPF external routes are not redistributed into BGP
unless the match external option is used.
|
| EIGRP |
Any routes in the RIB sourced from EIGRP including connected interfaces.
Any route that is in the topology table will be redistributed.
|
| BGP |
Any routes in the RIB sourced from BGP. By default, routes learned from
iBGP peers are not redistributed into IGP protocols unless the command
redistribute internal is configured.
|
| IS-IS |
Any routes in the RIB sourced from IS-IS. Only routes from the L2
link-state database are selected. Directly connected networks are not
included during redistribution.
|
Redistribution Rules
- Redistribution is not transitive: Routes that have been redistributed
into a routing protocol can not be further redistributed into a third routing
protocol on the same routing device.
To resolve this, mutual redistribution should be configured between
routing protocol A and B, B and C and A with C.
- Sequential redistribution is allowed when it is spread across multiple
routers: Redistributed routes from protocol A into Protocol B on Router R1.
These routes can be redistributed into protocol C on router R2.
- Routes to be redistributed must be in the routing table.
Seed Metric
During redistribution, metric information of the redistributed routes is lost
because the different routing protocols calculate route metrics using different
methods. Route metrics are only maintained when redistribution occurs from one
routing process or autonomous system to another with the same routing protocol.
Seed metric is assigned, by default, to redistributed routes, when no metric
is manually configured.
The redistribution metric can be configured in the following ways:
- Using the
metric keyword of the redistribution
command.
- Configuration of a default metric where all redistributed routes into
the destination routing protocol receive the configured default seed metric.
This can be implemented using the command
default-metric
configured in the destination routing process.
- Using a route-map with the
set metric command.
The recommended best practice from Cisco is to set a default metric when
redistributing routes.
The following table shows the seed metric of routes when redistributing from one
routing protocol to another.
|
DESTINATION |
| SOURCE |
RIP |
EIGRP |
OSPF |
IS-IS |
BGP |
| RIP |
Metric maintained |
Infinity |
20 |
0 |
RIP Metric* |
| EIGRP |
Infinity |
Metric maintained |
20 |
0 |
EIGRP Metric* |
| OSPF |
Infinity |
Infinity |
Metric maintained |
0 |
OSPF Metric* |
| BGP |
Infinity |
Infinity |
1 |
0 |
Path attributes maintained |
* The IGP metric becomes the value of the MED path attribute of the prefix.
Routes with the default redistribution metric of infinity are installed into the
BGP table (BGP) or similar data structures of the
destination routing protocol. These routes are not inserted into the routing
table because they are considered unreachable due to their metric of infinity.
EIGRP does not add routes with infinity metric to its topology table.
When redistributing between two same routing protocols but different processes or
autonomous systems, the metric remains unchanged because the destination protocol
understands the metric of the source protocol. For example OSPF process 1 to
OSPF process 2, the metric of the redistributed routes remains the same.
When redistributing connected networks (on local interfaces):
- Routing Information Protocol (RIP): RIP uses hop count as its metric.
When redistributing connected routes into RIP, the default metric is typically 1 hop. You can usually configure this metric manually. If no metric is specified, some implementations might default to 0, which could prevent the routes from being advertised.
- Open Shortest Path First (OSPF): OSPF uses a cost metric based on bandwidth.
When redistributing connected routes into OSPF, the default metric is usually 20. However, this can vary depending on the vendor and configuration.
It's common practice to set a specific metric using the
metric keyword under the redistribute connected command in the OSPF configuration. You might also need to specify a metric-type (Type 1 or Type 2 external route).
- Enhanced Interior Gateway Routing Protocol (EIGRP):
EIGRP uses a composite metric based on bandwidth, delay, reliability, load, and MTU.
When redistributing connected routes into EIGRP, you must specify the metric using the
metric keyword followed by the five metric components (bandwidth in kbps, delay in microseconds, reliability from 0-255, load from 1-255, and MTU).
If you don't specify a metric, EIGRP will not redistribute the connected routes.
- Border Gateway Protocol (BGP): BGP uses a path-vector routing protocol with a variety of path attributes to determine the best path. The metric in BGP is the MED (Multi-Exit Discriminator).
When redistributing connected routes into BGP, you can set the MED value using the
metric keyword under the redistribute connected command in the BGP configuration. If no metric is specified, the MED will be 0 by default.
Configuration of Redistribution
When redistributing routes into a routing protocol from another routing domain,
there are many controls that can be implemented at the redistribution point
such as tagging, metric configuration, filtering of redistributed routes.
When configuring redistribution, redistribution commmands are entered into the
router configuration mode of the destination routing protocol.
In a way, the redistribution configuration command says:
"Redistribute routes from the specified routing source into this routing protocol."
EIGRP
Any route that is in the EIGRP topology table is a candidate
for redistribution. Routes redistributed into EIGRP are given a default seed
metric of infinity. This prevents the routes from being installed into the EIGRP
topology table. The exception to this is when redistributing routes from one
EIGRP autonomous system to another. In such a scenario, the path metric is maintained.
In IOS, routes redistributed into EIGRP have an administrative distance of 170.
This administrative distance is the same regardless of the source routing
protocol i.e. even if the source of the prefixes was another EIGRP autonomous
system.
Redistribution is configured under the EIGRP router command:
redistribute <source> metric <bandwidth> <delay> <reliability> <load> <mtu> route-map <route-map_name>
where <source> is the source of the redistributed routes. The following illustrations configure
redistribution with the following metrics: Bandwidth (10000 Kbps), Delay (100 μs), Reliability (255/255), Load (1/255), MTU (1500).
- Named mode: redistribution is configured under topology base
configuration mode as shown below:
R2(config)#router eigrp EIGRP_NAMED
R2(config-router)#address-family ipv4 unicast autonomous-system 1
R2(config-router)#topology base
R2(config-router-af-topology)#redistribute ospf 1 metric 10000 10 255 1 1500
- Classic mode: redistribution is configured under EIGRP router configuration
mode as shown below:
R2(config)#router eigrp 1
R2(config-router)#redistribute ospf 1 metric 10000 10 255 1 1500
When configuring the EIGRP redistribution seed metric, delay value is in tens of
microseconds.
When redistributing BGP routes into EIGRP, the administrative tag is set to the
autonomous system number of the BGP device that sent the prefixes.
In IPv4, by default, connected routes that are associated with EIGRP will have
their configured network addresses included during redistribution. However, with
IPv6, by default, they are not included redistributed.
Some connected interfaces may not necessarily be destination networks for network
traffic such as transit networks. However, during redistribution, it may be a
good idea to redistribute these networks as well as it may sometimes result
in traffic blackholing. This is especially likely when utilising some tunneling
techniques such as MPLS tunneling.
| Source |
Command |
Metric Requirements |
Notes |
| BGP |
redistribute bgp <ASN> where <ASN> is
the BGP autonomous system number.
|
Metric required; BGP routes may have higher AD (use distance to adjust if needed). |
Use bgp redistribute-internal to redistribute BGP routes not in the routing table. |
| Connected Routes |
redistribute connected [metric] |
Requires explicit metric or default-metric |
Use redistribute connected under EIGRP process. |
| Static Routes |
redistribute static [metric] |
Must define metric or use default-metric |
Redistributes all static routes |
| OSPF |
redistribute ospf [process-id] [metric] |
Specify metric; optionally filter with match [internal | external | nssa] |
Example: redistribute ospf 100 match external type-5 |
| RIP |
redistribute rip [metric] |
Metric required to ensure consistency across domains |
Use redistribute rip under EIGRP; add
subnets for classless support. |
| IS-IS |
redistribute isis [metric] |
Define metric; ensure IS-IS routes are in the IP routing table. |
Use redistribute isis under EIGRP proces |
| EIGRP |
redistribute eigrp [AS-number] [metric] |
Metric required; avoid loops by using route-maps or tags. |
Redistribute between EIGRP ASes (e.g., redistribute eigrp 100. |
Configuration example:
router eigrp 100
default-metric 10000 100 255 1 1500 // Sets default metric for all redistributed routes
redistribute connected
redistribute static
redistribute rip 1
redistribute ospf 100 match external type-5
!
OSPF
When redistributing routes into OSPF, redistributed routes are given an
administrative distance of 110 and are flagged as OSPF external routes. The AD
is similar to the administrative distance
of intra-area and inter-area routes.
When making forwarding decisions for routes from multiple sources, OSPF's
prefix selection process gives preference in the following order:
- intra-area routes
- inter-area routes
- external routes
- external type 1 routes
- external type 2 routes
The metric for OSPF external type 1 routes equals the redistribution metric plus
the total path metric to the autonomous system boundary router. The metric for
OSPF external type 2 metric equals only the redistribution metric. If two type 2 routes have
the same metric, then the one with the lower forwarding cost is preferred.
This is the default external metric type used by OSPF.
In OSPF, the routing device that redistributes external routes into OSPF is
referred to as an autonomous system boundary router (ASBR).
When configuring redistribution into OSPF, the following command is used:
redistribute <source> subnets metric <metric> metric-type (<1 | 2>)
tag <0 - 4294967295> route-map <route-map-name>
Where:
- source: the source of routes
- metric: seed metric of the redistributed routes
- route-map: filtering can be applied using the route-map or route path
information
In older IOS versions, if the optional subnets keyword is excluded, only classful
routes are advertised and the following notification message is displayed:
R2(config-router)#redistribute eigrp 1
% Only classful networks will be redistributed
In newer IOS versions, the subnets keyword is automatically
added by the IOS into the running configuration.
Redistributing routes between OSPF processes will preserve the path metric during
redistribution regardless of the metric type.
To inject EIGRP sourced routes into OSPF:
R2(config)#router ospf 1
R2(config-router)#redistribute eigrp 1 subnets
OSPF Forwarding Address
By default, packets destined for external destinations are routed through the
advertising autonomous system boundary router (ASBR). Scenarios like
this are not optimal in certain circumstances. By default, OSPF sets the
forwarding address value to 0.0.0.0. The forward address can be viewed using the
command show ip ospf database external.
OSPF will change the forwarding address from 0.0.0.0 to the next-hop IP address
in the source routing protocol when:
- OSPF is enabled on the ASBR's interface that points to the next-hop IP
address of the redistributed routes.
- The interface is not set to passive.
- The OSPF interface type is set to a broadcast or non-broadcast type.
Enabling OSPF on R2's interface facing towards R1 (10.123.1.1) changes the
forwarding address from 0.0.0.0 to the interface pointed towards R1. The
forwarding-address changes on R3 irrespective of whether redistribution is
configured on R3.
When redistributing OSPF prefixes into another routing protocol, IOS provides
the option to match internal, external or NSSA-external routes. This can be
useful in preventing the redistribution of external OSPF routes into another
routing protocol.
OSPF External Route Types
OSPF categorizes redistributed routes as external type 1 and external type 2 routes.
By default, OSPF classifies redistributed routes as external type 2 routes.
OSPF issues redistributed routes with a default metric of 20.
OSPF external type 1 routes are redistributed with the default metric of 20 and
the metric increases downstream from the ASBR. OSPF external
type 2 routes have a default metric of 20 or configured redistribution metric.
However, as the routes are distributed within the OSPF domain, the metric does
not increase.
| Source |
Command |
Metric Requirements |
Comments |
| Connected Routes |
redistribute connected [subnets] |
Use metric (cost) or default-metric. Add subnets for non-classful routes. |
Connected routes require subnets keyword to include subnetted routes |
| Static Routes |
redistribute static [subnets] |
Define metric (cost) or use default-metric. Add subnets for non-classful routes. |
Static routes must exist in the IP routing table. |
| RIP |
redistribute rip [subnets] |
Specify metric (cost) and metric-type (E1/E2). Add subnets for classless support. |
Example: iredistribute rip metric 100 metric-type 1 |
| EIGRP |
redistribute eigrp [AS-number] |
Define metric(cost) and metric-type . Optionally use route-map for filtering. |
Example: redistribute eigrp 100 metric 150 |
| IS-IS |
redistribute isis [level-1/level-2] |
Specify metric (cost) and metric-type. Ensure IS-IS routes are in the IP routing table. |
Example: redistribute isis level-1 metric 200 |
| BGP |
redistribute bgp [AS-number] |
Define metric (cost) and metric-type. Use bgp redistribute-internal for iBGP routes. |
Example: redistribute bgp 65001 metric 100 metric-type 2 |
| Another OSPF Process |
redistribute ospf [process-id] |
Specify metric (cost) and metric-type . Avoid loops with route-map or tags. |
Rarely used; mutual redistribution requires careful planning. |
Key Considerations for OSPF Redistribution
- Metric (Cost):
- Use metric to define the cost for redistributed routes.
- Use default-metric under the OSPF process to set a global default cost.
Example:
router ospf 100
default-metric 100
- Metric-Type :
- Type-1 (E1) : Cost is cumulative across the OSPF domain.
- Type-2 (E2) : Cost remains static (default).
- Specify with metric-type 1 or metric-type 2.
- Route-Maps: Use route-map [map-name] to filter or modify attributes during redistribution.
Example:
router ospf 100
redistribute eigrp 100 route-map EIGRP-TO-OSPF
- Administrative Distance (AD) : Adjust AD with distance ospf [external 150] to prioritize redistributed routes if needed.
- Loop Prevention :
- Use route-tag or distribute-lists to avoid routing loops during mutual redistribution.
- In NSSA areas, use type-7 LSAs for redistribution (converted to type-5 by ABR).
- Subnets: Always add subnets to redistribute non-classful routes (e.g., redistribute static subnets).
Example Configuration Snippet
router ospf 100
default-metric 100 ! Sets default cost for redistributed routes
redistribute connected subnets ! Redistributes connected routes
redistribute static subnets metric 150 metric-type 1
redistribute rip subnets route-map RIP-TO-OSPF
redistribute eigrp 100 metric 200 metric-type 2
redistribute bgp 65001 metric 50
!
route-map RIP-TO-OSPF permit 10
match ip address 1
set metric 100
set metric-type type-1
Summary
- Metric : Always define metric or use default-metric.
- Type : Choose between E1 (dynamic cost) and E2 (static cost).
- Filters : Use route-map or distribute-list for granular control.
- NSSA Areas : Use type-7 LSAs for redistribution in stub/NSSA areas.
BGP
Redistributing routes into BGP does not require a seed metric because it is a
path vector protocol. Redistributed routes have the following BGP attributes set:
- Origin is set to incomplete
- Next-hop address is set to the next-hop IP address identified in the source protocol.
- The weight is set to 32,768.
- The MED is set to the path metric of the source protocol.
Redistributing routes from OSPF to BGP does not include OSPF external routes by
default. The optional match external (1 | 2) keyword is
required to redistribute OSPF external routes. The type of OSPF external routes
can be configured using 1 or 2 to redistribute type-1 or
type-2 routes only.
Redistribution into BGP Configuration Table
| Source |
Syntax |
Parameters |
Notes |
| Connected Routes |
redistribute connected [route-map] |
Use route-map to set origin, med, weight, or community. |
Connected routes must exist in the routing table. Use ip route 0.0.0.0 0.0.0.0 Null0 for summary routes. |
| Static Routes |
redistribute static [route-map] |
Define attributes via route-map (e.g., set origin, set med). |
Static routes must be present in the routing table. Avoid redistributing default routes unless necessary |
| RIP |
redistribute rip [route-map] |
Use route-map to set origin, med, and filter unwanted routes. |
Ensure RIP routes are in the IP routing table. Use match ip address in route-maps for filtering. |
| EIGRP |
redistribute eigrp [AS-number] [route-map] |
Set origin, med, and as-path via route-map. Adjust AD if needed. |
EIGRP routes must be in the routing table. Use match metric-type to filter internal/external routes. |
| OSPF |
redistribute ospf [process-id] [route-map] |
Set origin, med, and filter with match internal/external/nssa. |
Example: redistribute ospf 100 match external type-5. Use subnets for non-summarized routes.
When redistributing OSPF routes into BGP, by default, only internal OSPF
routes are redistributed into BGP. To redistribute external and nssa-external
OSPF routes into BGP, list route type after the redistribute
match keyword. With the match keyword
external type 1 and/or type 2 routes can be matched. Additionally, the route
match can be configured in a route-map.
|
| IS-IS |
redistribute isis [process-id] [route-map]. |
Set origin, med, and filter via route-map. |
IS-IS routes must be in the IP routing table. Use match isis-level-1/level-2 for granular control. |
| Another BGP Process |
Not typical; use import/export policies |
Use neighbor route-map or vrf import/export for inter-process communication. |
Avoid mutual redistribution loops. Use as-path prepending or community tags for control. |
Key Considerations for BGP Redistribution
- Route-Maps: Always use route-map to control redistribution and set attributes.
Example:
route-map STATIC-TO-BGP permit 10
match ip address 1
set origin igp
set med 100
- Origin Codes: Redistributed routes default to incomplete (?). Use
set origin igp or set origin egp in route-maps to override.
Example:
set origin igp ! Marks routes as originating from an IGP
- MED (Multi-Exit Discriminator): Influences inbound traffic from external neighbors. Set via set metric in route-maps.
Example:
set metric 50 ! Sets MED value for route selection
- Administrative Distance (AD): BGP routes inherit the AD of their source (e.g., static = 1, OSPF = 110). Adjust with distance bgp .
Example:
distance bgp 20 200 255 ! External BGP routes have AD 20, internal 200
- Loop Prevention: Use as-path access lists or community attributes to prevent loops during mutual redistribution.
Example:
ip as-path access-list 1 deny _65001$ ! Blocks routes originated in AS 65001
- Maximum Prefixes: Limit redistributed routes with maximum-prefix to avoid instability.
neighbor 192.168.1.2 maximum-prefix 1000 ! Limits prefixes to 1000
Example Configuration Snippet
router bgp 65001
bgp router-id 1.1.1.1
redistribute static route-map STATIC-TO-BGP
redistribute ospf 100 route-map OSPF-TO-BGP
neighbor 192.168.1.2 remote-as 65002
neighbor 192.168.1.2 activate
neighbor 192.168.1.2 soft-reconfiguration inbound
!
route-map STATIC-TO-BGP permit 10
match ip address 1
set origin igp
set metric 100
!
route-map OSPF-TO-BGP permit 10
match ip address 2
set origin incomplete
set metric 200
Summary
- Route-Maps: Mandatory for filtering and attribute manipulation.
- Origin Codes: Control path selection with
origin igp, egp, or incomplete.
- MED: Influences inbound traffic; set via
set metric>
- AD: Adjust with distance bgp if needed.
- Loop Prevention: Use as-path filters or communities.
Formation of Loops
If redistribution happens at one point (one routing device) or two points in one direction, the possibility
of a routing loop does not exist. If mutual redistribution at more than one point occurs,
then the possibility of loop formation exists.
Route feedback occurs when a redistributed route is advertised back into
the original source routing protocol. Route feedback is likely to occur in
networks where mutual redistribution is implemented in more than one device i.e.
multipoint mutual redistribution. Route feedback causes:
- Sub-optimal routing
- Routing loops
- Invalid routing tables
Types of Loops
Loops exist in two categories:
- Control-plane: exist when routing information is looping.
Control-plane loops are detected using the
debug ip routing
command. This command is largely silent. However, it will display when a route
is added or removed from the routing table. If this happens repeatedly, then we
can be certain that we are dealing with a loop. Redistribution should be done
after observing the debug ip routing output for a while.
-
Data-plane: occur when data packets are looping. The best way to detect
data-plane loops is to use the
ping and
traceroute commands. If traffic is being dropped, then
a black hole exists. Looped packets may include packets for known networks (in RIB)
or unknown networks (default route). With mutual multipoint redistribution, it
is also likely that the default route may be looped.
Troubleshooting Loops
Mutual multipoint route redistribution usually forms routing loops. The following
techniques can be used to prevent the formation of routing loops during
redistribution:
- Filtering of network prefixes during redistribution.
- Filtering by route tag during redistribution
- Increasing the seed metric
- Modifying the administrative distance.
- Route summarization
When troubleshooting routing loops:
- Multiple techniques can be combined.
- Document the physical and logical topology to include the routing
protocols and desired traffic flows.
- Focus on keeping the source routing domain loop-free.
The underlying principle in preventing the formation of loops in a multipoint
mutual redistribution network, at each redistribution point, routes from a
source protocol need to be allowed into the destination protocol and these
routes prevented from returning from the destination routing protocol back to the
source protocol.
Prefix Filtering
Prefix filtering can be implemented during the redistribution with some prefixes
filtered (prevented from being redistributed) on one redistribution device and
permitted to be redistributed on another device. This can be used for controlled
path manipulation.
Route filtering can be implemented during redistribution through the configuration
of a route-map. The prefixes to be filtered are identified through the use of a
prefix-list or access control list (ACL).
Filtering Connected Networks
Explicit configuration always overrides implicit configuration. When redistributing
the networks assigned to connected interfaces, the use of the network command
advertises the networks of the connected interfaces. However, when filtering, if
a filter excludes these networks, the networks configured on these interfaces
will not be advertised. This affects all IGP protocols that use interfaces to form neighborships such as
OSPF, EIGRP. BGP behaves a little different as it is enabled on a per neighbor-
basis and not per interface basis. If a route-map references an access list or prefix-list to
identify interfaces to be filtered (not redistributed), these
interfaces should be identified using the permit ACL keyword.
Route Tagging
A route tag is associated with routes during redistribution. A route-tag is a
numeric value associated with a route. Use of the AD of the source protocol for
the route-tag is a good technique.
The use of route-tags is a more scalable solution. In the case of prefix-lists and ACLs,
everytime a new prefix is added, the prefix-list or ACL needs to be updated to reflect
this new addition. When creating route-tags, a recommended best practice is to tag
routes using the administrative distance of the routing protocol. This way, it is
easier to tell the origin of the route.
Increase Seed Metric
Increase the seed metric to a value higher and less preferred to locally originated
routes.This can be done through any of the seed metric configuration methods.
Configuring different seed metric values for different prefixes helps with preventing
sub-optimal routing through traffic shaping. The redistribution metric on one
redistributing device can be made lower so that to reach these prefixes, traffic
transits through a specific path.
The seed metric can be modified through a route-map using the
set metric command.
R1#traceroute 10.0.35.1
Type escape sequence to abort.
Tracing the route to 10.0.35.1
VRF info: (vrf in name/id, vrf out name/id)
1 10.0.12.2 12 msec 16 msec 20 msec
2 10.0.24.2 28 msec 64 msec 44 msec
3 10.0.49.2 52 msec 16 msec 72 msec
4 10.0.59.1 48 msec 68 msec 60 msec
5 10.0.35.1 88 msec 28 msec 36 msec
R3(config)#ip access-list standard ACL_10.3
R3(config-std-nacl)#permit 10.0.35.0 0.0.0.3
R3(config-std-nacl)#20 permit 10.3.0.0 0.0.255.255
R3(config-std-nacl)#30 permit 10.0.59.0 0.0.0.3
R3(config-std-nacl)#40 permit 10.5.0.0 0.0.255.255
R3(config-std-nacl)#exit
R3(config)#route-map O2E permit 10
R3(config-route-map)#match ip address ACL_10.3
R3(config-route-map)#set metric 1000000 1 255 1 1500
R3(config-route-map)#set tag 110
R3(config)#router eigrp 1
R3(config-router)#redistribute ospf 1 route-map O2E
R1#show ip eigrp topology 10.0.35.0/30
EIGRP-IPv4 VR(EIGRP_NAMED) Topology Entry for AS(1)/ID(10.1.13.1) for 10.0.35.0/30
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 1966080, RIB is 15360
Descriptor Blocks:
10.0.13.2 (GigabitEthernet1/0), from 10.0.13.2, Send flag is 0x0
Composite metric is (1966080/1310720), route is External
Vector metric:
Minimum bandwidth is 1000000 Kbit
Total delay is 20000000 picoseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
Originating router is 3.3.3.3
External data:
AS number of route is 1
External protocol is OSPF, external metric is 0
Administrator tag is 110 (0x0000006E)
10.0.12.2 (GigabitEthernet0/0), from 10.0.12.2, Send flag is 0x0
Composite metric is (7864320/7208960), route is External
Vector metric:
Minimum bandwidth is 1000000 Kbit
Total delay is 110000000 picoseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
Originating router is 10.2.13.1
External data:
AS number of route is 1
External protocol is OSPF, external metric is 4
Administrator tag is 0 (0x00000000)
R1#
R1#traceroute 10.0.35.1
Type escape sequence to abort.
Tracing the route to 10.0.35.1
VRF info: (vrf in name/id, vrf out name/id)
1 10.0.13.2 8 msec 44 msec 16 msec
R1#
Administrative Distance
Increase the administrative distance for external routes on routing protocols
that support it. Alternatively, the AD can be modified for preferred routes.
External Route Summarization
Summarizing routes as they are redistributed into the second domain if they are
re-inserted back to primary routing domain. They are less specific and not taken.
Route-Maps
Route-maps can be used to prevent the formation of routing loops. Tools to
match the traffic include: access-lists, prefix-lists, route-tags, communities (BGP),
administrative distance, distribute-lists(ACLs, prefix-lists), offset-lists(ACLs, prefix-lists).
In redistribution of EIGRP to OSPF, using route-tags, the tag for EIGRP is permitted
on one mutually redistributing routing device and denied on another redistributing routing device.
For two protocols mutual redistribution at two points:
R1 BLUE:
route-map o2E deny 10
match tag 90
route-map O2E permit 20
set tag 110
R1 RED
riyte-map E2O deny 10
match tag 110
route-map E2O permit 20
set tag 90
R2 RED
route-map O2E deny 10
match tag 90
route-map O2E permit 20
set tag 110
R2 BLUE
route-map E2O deny 10
match tag 110
route-map E2O permit 20
set tag 90
Redistribution Scenarios
Two-point Mutual Redistribution
Two-Way Multipoint Redistribution
Two-way multipoint redistribution occurs when routes are
exchanged bidirectionally between two routing protocols at multiple
redistribution points (e.g., two routers redistributing
between OSPF and EIGRP). While this provides redundancy and
flexibility, it introduces risks of routing loops ,
suboptimal paths , and route feedback .
Proper configuration and loop prevention techniques are critical.
Configuration Example
Topology
Basic Configuration
! R1 Configuration
router eigrp 1
redistribute ospf 100 metric 1000 100
255 1 1500
default-metric 1000 100 255 1 1500
!
router ospf 100
redistribute eigrp 1 subnets
default-metric 100
! R2 Configuration
router eigrp 1
redistribute ospf 100 metric 1500 150
255 1 1500
default-metric 1500 150 255 1 1500
!
router ospf 100
redistribute eigrp 1 subnets
default-metric 100>
Loop Prevention Techniques
Without safeguards, routes redistributed at R1
could be re-advertised back into OSPF/EIGRP at R2,
creating loops. Below are techniques to mitigate this:
- Route Tags: Use route tags to mark redistributed routes and filter them during redistribution.
Assign a unique tag (e.g.,
TAG_EIGRP=100, TAG_OSPF=200)
to routes when redistributing. Filter routes with the same tag when redistributing back to
avoid feedback.
! R1: Mark EIGRP routes redistributed into OSPF with tag 100
router eigrp 1
redistribute ospf 100 metric 1000 100
255 1 1500 route-map TO_EIGRP
!
route-map TO_EIGRP permit 10
set tag 100
router ospf 100
redistribute eigrp 1 subnets route-map
TO_OSPF
!
route-map TO_OSPF permit 10
match tag 100 ! Drop routes already
tagged as redistributed from EIGRP
deny
!
route-map TO_OSPF permit 20 ! Allow
all other routes
set tag 200 ! Tag OSPF routes
redistributed into EIGRP
! R2: Similar configuration with
inverse tags
router eigrp 1
redistribute ospf 100 metric 1500 150
255 1 1500 route-map TO_EIGRP_R2
!
route-map TO_EIGRP_R2 permit 10
set tag 100
router ospf 100
redistribute eigrp 1 subnets route-map
TO_OSPF_R2
!
route-map TO_OSPF_R2 permit 10
match tag 100
deny
!
route-map TO_OSPF_R2 permit 20
set tag 200
- Distribute-Lists: Filter specific routes using access control lists (ACLs)
or prefix lists during redistribution. Define a list of networks to exclude from redistribution
(e.g., subnets already present in the target protocol).
! R1: Block redistribution of 192.168.1.0/24 from EIGRP to OSPF
ip access-list standard
BLOCK_EIGRP_SUBNETS
deny 192.168.1.0 0.0.0.255
permit any
router ospf 100
redistribute eigrp 1 subnets
distribute-list BLOCK_EIGRP_SUBNETS in
- Administrative Distance (AD): Adjust AD to prioritize internal routes
over redistributed ones. Redistributed routes typically have higher AD. For
example, EIGRP external routes default to AD Use
distance commands to tweak AD values.
! R1: Set higher AD for redistributed OSPF routes in EIGRP
router eigrp 1
distance 180 10.0.0.0 0.255.255.255
OSPF_SOURCE ! Redistributed OSPF routes have AD 180
ip community-list 10 permit 65001:123
! Match specific communities
! R2: Set higher AD for redistributed
EIGRP routes in OSPF
router ospf 100
distance 150 192.168.0.0 0.0.255.255
EIGRP_SOURCE ! Redistributed EIGRP routes have AD 150
- Metric Manipulation Set higher metrics for redistributed routes to avoid suboptimal paths
Configure higher costs in one direction to make routes less preferred.
! R1: Lower metric for EIGRP-to-OSPF redistribution
router eigrp 1
redistribute ospf 100 metric 1000 100 255 1 1500 ! Lower metric
! R2: Higher metric for EIGRP-to-OSPF
redistribution
router eigrp 1
redistribute ospf 100 metric 1500 150 255 1 1500 ! Higher metric
- Route-Maps with Communities (Advanced): Use BGP-style communities to
tag and filter routes. Set communities during redistribution, thereafter, filter routes with
matching communities when redistributing back.
! R1: Set community for EIGRP-to-OSPF routes
route-map TO_OSPF permit 10
set community 65001:123
router ospf 100
redistribute eigrp 1 subnets route-map
TO_OSPF
! R2: Block routes with community
65001:123
route-map FROM_EIGRP deny 10
match community 65001:123
route-map FROM_EIGRP permit 20 ! Allow
other routes
Verification & Best Practices
- Check Routes:
- Verify OSPF routes:
show ip route ospf
- Verify EIGRP routes:
show ip route eigrp
- Debug Redistribution: Monitor route updates
debug ip routing
Best Practices
Summary
Two-way multipoint redistribution introduces complexity but can be
safely implemented with:
By combining these techniques, you can ensure a stable and
loop-free network.
Three-point Mutual Redistribution
If three protocols are involved in mutual redistribution at three points. The
generic method to prevent the formation of routing loops when redistributing
mutually between three or more protocols inside a route map:
- deny destination protocol
- match protocol 2
- match protocol 3
- match protocol 4
- match protocol n
The challenge with this redistribution is if the tag will be maintained when
redistributing from protocol 1 to protocol 2 and then to protocol 3. For example
when redistributing from OSPF into EIGRP and subsequently into RIP. The tag is
maintained when copying the routes from:
This may be IOS specific
| Source |
Destination |
Tag Maintained |
| RIP |
OSPF |
Yes |
| RIP |
OSPF |
YES |
| EIGRP |
RIP |
NO |
| OSPF |
RIP |
NO |
| EIGRP |
OSPF |
YES |
| OSPF |
EIGRP |
YES |
A solution would be for the following:
route-map O2E deny 10
match tag 90
route-map O2E permit 20
match tag 120
set tag 120
route-map O2E permit 30
set tag 110
The above route-maps will only operate if configured as a system on all the
mutually redistributing routers. The route-maps will operate as a system and
potentially prevent loops in 99.999% of the cases.
However, some situations exist where the above route-map will not succeed in preventing
a routing loop.
When configuring redistribution, the configuration commands should be entered
inside the destination routing protocol.
Three-Way Multipoint Redistribution
Three-way multipoint redistribution involves exchanging
routes among three routing protocols (e.g., OSPF, EIGRP, and BGP) at
multiple redistribution points (e.g., routers). This setup
increases redundancy and flexibility but introduces significant risks
of routing loops , suboptimal paths ,
and route feedback . Proper configuration and loop
prevention are critical.
Topology Overview
- Protocols :
- OSPF (Process ID 100) for core/internal routing.
- EIGRP (AS 1) for edge networks.
- BGP (AS 65001) for external connectivity.
- Routers:
- R1: Redistributes OSPF ↔ EIGRP.
- R2: Redistributes EIGRP ↔ BGP.
- R3: Redistributes BGP ↔ OSPF.
- edistribution Points : Routes flow
bidirectionally between all three protocols across R1, R2, and R3.
Configuration Example
Basic Redistribution Setup
! R1: OSPF ↔ EIGRP Redistribution
router eigrp 1
redistribute ospf 100 metric 1000 100
255 1 1500 route-map TO_EIGRP
default-metric 1000 100 255 1 1500
!
router ospf 100
redistribute eigrp 1 subnets route-map
TO_OSPF
default-metric 100
! R2: EIGRP ↔ BGP Redistribution
router bgp 65001
redistribute eigrp 1 route-map
bgp router-id 2.2.2.2
neighbor 192.168.2.2 remote-as 65002
!
route-map EIGRP-TO-BGP permit 10
set origin igp
set metric 100
! R3: BGP ↔ OSPF Redistribution
router ospf 100
redistribute bgp 65001 subnets
route-map BGP-TO-OSPF
default-metric 100
!
router bgp 65001
redistribute ospf 100 route-map
OSPF-TO-BGP
Loop Prevention Techniques
Without safeguards, routes redistributed at one point (e.g., R1)
could re-enter the network via another (e.g., R3), creating loops.
Below are techniques to mitigate this:
- Route Tags: Use unique route tags to identify the source of
redistributed routes and block feedback loops. Assign distinct tags for each
protocol (e.g.,
TAG_OSPF=100, TAG_EIGRP=200, TAG_BGP=300).
Filter routes with matching tags when redistributing back.
! R1: Tag OSPF routes redistributed into EIGRP with TAG_OSPF=100
route-map TO_EIGRP permit 10
set tag 100
! R1: Block EIGRP routes tagged with TAG_EIGRP=200 when redistributing into OSPF
route-map TO_OSPF permit 10
match tag 200
deny
!
route-map TO_OSPF permit 20
set tag 100
! R2: Tag EIGRP routes redistributed into BGP with TAG_EIGRP=200
route-map EIGRP-TO-BGP permit 10
set community 65001:200
set tag 200
! R3: Block BGP routes tagged with TAG_BGP=300 when redistributing into OSPF
route-map BGP-TO-OSPF permit 10
match tag 300
deny
!
route-map BGP-TO-OSPF permit 20
set tag 300
- Distribute-Lists: Filter specific routes using prefix lists or ACLs
during redistribution. >Define prefixes to exclude from redistribution (e.g.,
subnets already present in the target protocol).
! R1: Block redistribution of 192.168.1.0/24 from EIGRP to OSPF
ip prefix-list BLOCK_EIGRP_SUBNETS seq
10 deny 192.168.1.0/24
ip prefix-list BLOCK_EIGRP_SUBNETS seq
20 permit 0.0.0.0/0 le 32
router ospf 100
redistribute eigrp 1 subnets
distribute-list prefix
BLOCK_EIGRP_SUBNETS in
- Administrative Distance (AD): Prioritize internal routes over redistributed ones by
tweaking AD values. Redistributed routes typically have higher AD (e.g., BGP
external = 20, EIGRP external = 170).
! R2: Increase AD for BGP routes redistributed into EIGRP
router eigrp 1
distance 180 10.0.0.0 0.255.255.255
BGP_SOURCE ! BGP routes have AD 180
! R3: Increase AD for OSPF routes
redistributed into BGP
router bgp 65001
distance 200 192.168.0.0 0.0.255.255
OSPF_SOURCE ! OSPF routes have AD 200
- Metric Manipulation: Set higher metrics for redistributed routes to avoid
suboptimal paths. Configure higher costs in one direction to make routes less
preferred.
! R1: Lower metric for OSPF-to-EIGRP redistribution
router eigrp 1
redistribute ospf 100 metric 1000 100 255 1 1500
! R3: Higher metric for BGP-to-OSPF redistribution
router ospf 100
redistribute bgp 65001 subnets
default-metric 200 ! Higher cost for BGP routes
- Communities (Advanced): Use BGP communities to tag and filter routes across
redistribution points. Set communities during redistribution. Filter routes with matching
communities when redistributing back.
! R2: Tag EIGRP routes redistributed into BGP with community 65001:200
route-map EIGRP-TO-BGP permit 10
set community 65001:200
! R3: Block routes with community 65001:200 when redistributing into OSPF
ip community-list 10 deny 65001:200
ip community-list 10 permit all
route-map BGP-TO-OSPF permit 10
match community 10
deny
Verification
- Check Routes:
show ip route ospf Verify OSPF routesshow ip route eigrp ! Verify EIGRP routesshow ip bgp ! Verify BGP routes
- Debug Redistribution:
debug ip routing ! Monitor route updates
Best Practices
Summary
Three-way multipoint redistribution is inherently complex but
manageable with:
By combining these techniques, you can ensure a stable, loop-free
network across multiple routing protocols. 🛡️
IPv6
By default, IPv6 does not include connected networks when doing redistribution.
IPv6 does not include the subnets keyword in OSPFv3. This is because IPv6 does
not necessarily use the concept of classful networks. To redistribute connected networks,
use the keyaword include-connected.
IOS XE no longer redistributes the connected subnets on the interfaces over which
the protocol is enabled. IOS XE routers will only redistribute route entries
that exactly match the source protocol in the route table.
The keyword included-connected can be used with the
redistribution command to include the locally connected prefixes in the
dynamic routing protocol redistribution. The include-connected keyword only
injects prefixes for interfaces that have a dynamic routing protocol enabled. To
inkect networks for interfaces without a dynamic protocol the
redistribute connected command is still required.
TODO :
Redistribute some local interfaces and not others. This results in the
IP address of the excluded connected interfaces being removed from the
routing table. The solution is to include a match statement for that
interface in the route map.
Redistribution lABS
-----------------------------------
-Configure RIP, redistribute OSPF
-Configure EIGRP. redistribute to/from RIP, redistribute to/from OSPF
-Configure OSPF: redistribute where possible for full connectivity.
