Overview
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.
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.
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. Rarely is one-way redistribution implemented with the source being a routing protocol.
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 connversion. 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 of redistributed routes can be configured in the following ways:
- Using the
metrickeyword of theredistributioncommand. - 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. - Using a route-map with the
metriccommand.
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 MED path attribute of the prefix.
Routes with the default redistribution metric of infinity are installed into the Link-state database (OSPF), 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),
Configuration of Redistribution
When redistributing routes into a routing protocol from another routing domain, there are many controls that can be implemented that 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 source."
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.
In EIGRP 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-af-topology)#redistribute ospf 1
In EIGRP classic mode, redistribution is configured under EIGRP router configuration mode as shown below:
R2(config)#router eigrp 1
R2(config-router)#redistribute ospf 1
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.
EIGRP requires the configuration of a seed metric during redistribution. If the seed metric is not included in the redistribution, EIGRP will give the route a metric of infinity.
In IPv4, by default, connected routes that are associated with EIGRP will have their configured network addresses included in a 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.
Redistribution of routers into EIGRP can be implemented using the following
EIGRP routing device command: redistribute <source> metric
<bandwidth delay reliability load mtu>
| Command | Description |
| BGP |
|
OSPF
In OSPF, the routing device that redistributes external routes into OSPF is referred to as an autonomous system boundary router (ASBR).
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.
When configuring redistribution into OSPF, the OSPF router mode command
redistribute 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 command is excluded, only classful routes are advertised. 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.
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.
When redistributing into OSPF, the optional subnets keyword results in subnets being included in the redistribution. In newer IOS versions the subnets keyword is automatically included by default if the keyword was not configured.
OSPF External Route Types
OSPF classifies redistributed routes as external type 1 and external type 2 routes. By default, OSPF classifies 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 maintain this same metric throughout the OSPF autonomous system. 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.
| Command | Description |
| BGP |
When redistributing BGP into OSPF, the |
| EIGRP |
|
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.
| Protocol | Command |
| OSPF |
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
|
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 routingcommand. 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 thedebug ip routingoutput for a while. -
Data-plane: occur when data packets are looping. The best way to detect
data-plane loops is to use the
pingandtraceroutecommands. 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
- 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
Prefixe filtering can be implemented during the redistribution with some prefixes filtered (preventing 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.
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
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
| Source | Destination | Tag Maintained |
| RIP | OSPF | Yes |
| RIP | OSPF | YES |
| EIGRP | RIP | NO |
| OSPF | RIP | NO |
| EIGRP | OSPF | YES |
| OSPF | EIGRP | YES |
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.
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.
No comments:
Post a Comment