Route Redistribution -
It is preferable to employ a single routing protocol in an internetwork environment, for simplicity and ease of management. Unfortunately, this is not always possible, making multi-protocol environments common
Route Redistribution allows routes from one routing protocol to be advertised into another routing protocol. The routing protocol receiving these redistributed routes usually marks the routes as external. External routes are usually less preferred than locally-originated routes
At least one redistribution point needs to exist between the two routing domains. This device will actually run both routing protocols. Thus, to perform redistribution in the following example, RouterB would require at least one interface in both the EIGRP and the OSPF routing domains
It is possible to redistribute from one routing protocol to the same routing protocol, such as between two separate OSPF domains (distinguished by unique process ID’s). Static routes and connected interfaces can be redistributed into a routing protocol as well. Routes will only be redistributed if they exist in the routing table. Routes that are simply in a topology database (for example, an EIGRP Feasible Successor), will never be redistributed. Routing metrics are a key consideration when performing route redistribution. With the exception of IGRP and EIGRP, each routing protocol utilizes a unique (and thus incompatible) metric. Routes redistributed from the injecting protocol must be manually (or globally) stamped with a metric that is understood by the receiving protocol.
Redistributing into RIP
RouterB(config)# router rip
RouterB(config-router)# network 172.16.0.0
RouterB(config-router)# redistribute igrp 10 metric 2
Redistributing into IGRP
RouterB(config)# router igrp 10
RouterB(config-router)# network 10.0.0.0
RouterB(config-router)# redistribute rip metric 10000 1000 255 1 1500
Redistributing EIGRP or OSPF:-
To redistribute all OSPF routes into EIGRP:
RouterB(config)# router eigrp 15
RouterB(config-router)# network 10.1.2.0 0.0.0.255
RouterB(config-router)# redistribute ospf 20 metric 10000 1000 255 1 1500
RouterB(config)# router eigrp 15
RouterB(config-router)# redistribute ospf 20
RouterB(config-router)# default-metric 10000 1000 255 1 1500
RIP and IGRP also support the default-metric command. Though IGRP/EIGRP use only bandwidth and delay by default to compute the metric, it is still necessary to specify all five metrics when redistributing. If the default-metric or a manual metric is not specified, IGRP/EIGRP will assume a metric of 0, and will not advertise the redistributed routes.
EIGRP Redistributing into OSPF
To redistribute all EIGRP routes into OSP
OSPF is a standardized Link-State routing protocol that uses cost (based on bandwidth) as its link-state metric. An OSPF router performing redistribution automatically becomes an ASBR.
RouterB(config)# router ospf 20
RouterB(config-router)# network 172.16.0.0 0.0.255.255 area 0
RouterB(config-router)# redistribute eigrp 15 RouterB(config-router)# default-metric 30
If the default-metric or a manual metric is not specified for the redistributed routes, a default metric of 20 will be applied to routes of all routing protocols except for BGP. Redistributed BGP routes will have a default metric of 1 applied by OSPF. By default, OSPF will only redistribute classful routes into the OSPF domain. To configure OSPF to accept subnetted networks during redistribution, the subnets parameter must be used:
RouterB(config)# router ospf 20
RouterB(config-router)# redistribute eigrp 15 subnets
Routes redistributed into OSPF are marked external. OSPF identifies two types of external routes, Type-1 (which is preferred) and Type-2 (which is default). To change the type of redistributed routes:
RouterB(config)# router ospf 20
RouterB(config-router)# redistribute eigrp 15 subnets metric-type 1
Redistributing Static and Connected Routes
Redistributing static routes into a routing protocol
RouterB(config)# router eigrp 15
RouterB(config-router)# redistribute static
Redistributing networks on connected interfaces into a routing protocol
RouterB(config)# router eigrp 15
RouterB(config-router)# redistribute connected
The above commands redistribute all connected networks into EIGRP. Route-maps can be used to provide more granular control:
RouterB(config)# route-map CONNECTED permit 10
RouterB(config-route-map)# match interface fa0/0, fa0/1, s0/0, s0/1
RouterB(config)# router eigrp 15
RouterB(config-router)# redistribute connected route-map CONNECTED
Route Redistribution – Administrative Distance:-
Route redistribution introduces unique problems when there are multiple points of redistribution. Consider the following diagram:
The first issue is caused by Administrative Distance (AD), which determines which routing protocol is “trusted” the most. By default, OSPF routes have an AD of 110, whereas RIP routes have an AD of 120. Lowest AD is preferred, thus making the OSPF routes the most trusted.
Assume mutual redistribution has been performed on RouterC and RouterD. The following networks will be injected from RIP into OSPF: 10.1.1.0/24, 10.1.2.0/24, 10.1.3.0/24, 10.1.4.0/24, and 10.1.5.0/24. RouterC will eventually receive OSPF routes to the above networks from RouterD, in addition to the RIP routes already in its table. Likewise, RouterD will receive OSPF routes to these networks from RouterC. Because OSPF’s AD is lower than RIP’s, both RouterC and RouterD will prefer the sub-optimal path through OSPF to reach the non-connected networks. Thus, RouterC will choose the OSPF route for all the 10.x.x.x/24 networks except for 10.1.1.0/24, as it is already directly connected. This actually creates a routing loop. RouterC will prefer the OSPF path through RouterA to reach the 10.x.x.x networks (except for 10.1.1.0/24), and RouterA will likely consider RouterC its shortest path to reach those same networks. Traffic will be continuously looped between these two routers. Even if RouterC managed to send the traffic through RouterA and RouterB to RouterD, the preferred path to the 10.x.x.x networks for RouterD is still through OSPF. Thus, the routing loop is inevitable.
There are two methods to correct this particular routing loop. The first method involves filtering incoming routes using a distribution-list, preventing RouterC and RouterD from accepting any routes that originated in RIP from their OSPF neighbors.
RouterC’s configuration would be as follows:
RouterC(config)# access-list 10 deny 10.1.2.0 0.0.0.255
RouterC(config)# access-list 10 deny 10.1.3.0 0.0.0.255
RouterC(config)# access-list 10 deny 10.1.4.0 0.0.0.255
RouterC(config)# access-list 10 deny 10.1.5.0 0.0.0.255
RouterC(config)# access-list 10 permit any RouterC(config)# router ospf 20
RouterC(config-router)# distribute-list 10 in fastethernet0/0
An access-list was created that is denying the RIP networks in question, and permitting all other networks. Under the OSPF process, a distribute-list is created for routes coming inbound off of the fastethernet0/0 interface. The access-list and distribute-list numbers must match. RouterD’s configuration would be similar. This prevents each router from building OSPF routes for the networks that originated in RIP, and thus eliminates the possibility of a loop. However, redundancy is also destroyed – if RouterC’s fa0/1 interface were to fail, it could not choose the alternate path through OSPF.
RouterC(config)# access-list 10 permit 10.1.2.0 0.0.0.255
RouterC(config)# access-list 10 permit 10.1.3.0 0.0.0.255
RouterC(config)# access-list 10 permit 10.1.4.0 0.0.0.255
RouterC(config)# access-list 10 permit 10.1.5.0 0.0.0.255
RouterC(config)# access-list 10 deny any
RouterC(config)# router rip
RouterC(config-router)# distance 70 10.1.1.0 0.0.0.255 10
Route-maps provide a sequential list of commands, each having a permit or deny result:
RouterC(config)# route-map OSPF2RIP deny 5
RouterC(config-route-map)# match tag 33
RouterC(config-route-map)# route-map OSPF2RIP permit 15
RouterC(config-route-map)# set tag 44
RouterC(config)# router rip
RouterC(config)# redistribute ospf 20 route-map OSPF2RIP
RouterC(config)# route-map RIP2OSPF deny 5
RouterC(config-route-map)# match tag 44
RouterC(config-route-map)# route-map RIP2OSPF permit 15
RouterC(config-route-map)# set tag 33
Thus, OSPF routes being redistributed into RIP are set with a tag of 44. When RIP is redistributed back into OSPF, any route with a tag that matches 44 is denied. Similarly, RIP routes being redistributed into OSPF are set with a tag of 33. When OSPF is redistributed back into RIP, any route with a tag that matches 33 is denied. The net result: routes originating from a routing domain will not redistributed back into that domain.
It is preferable to employ a single routing protocol in an internetwork environment, for simplicity and ease of management. Unfortunately, this is not always possible, making multi-protocol environments common
Route Redistribution allows routes from one routing protocol to be advertised into another routing protocol. The routing protocol receiving these redistributed routes usually marks the routes as external. External routes are usually less preferred than locally-originated routes
At least one redistribution point needs to exist between the two routing domains. This device will actually run both routing protocols. Thus, to perform redistribution in the following example, RouterB would require at least one interface in both the EIGRP and the OSPF routing domains
It is possible to redistribute from one routing protocol to the same routing protocol, such as between two separate OSPF domains (distinguished by unique process ID’s). Static routes and connected interfaces can be redistributed into a routing protocol as well. Routes will only be redistributed if they exist in the routing table. Routes that are simply in a topology database (for example, an EIGRP Feasible Successor), will never be redistributed. Routing metrics are a key consideration when performing route redistribution. With the exception of IGRP and EIGRP, each routing protocol utilizes a unique (and thus incompatible) metric. Routes redistributed from the injecting protocol must be manually (or globally) stamped with a metric that is understood by the receiving protocol.
Redistributing into RIP
RouterB(config)# router rip
RouterB(config-router)# network 172.16.0.0
RouterB(config-router)# redistribute igrp 10 metric 2
Redistributing into IGRP
RouterB(config)# router igrp 10
RouterB(config-router)# network 10.0.0.0
RouterB(config-router)# redistribute rip metric 10000 1000 255 1 1500
Redistributing EIGRP or OSPF:-
RouterB(config)# router eigrp 15
RouterB(config-router)# network 10.1.2.0 0.0.0.255
RouterB(config-router)# redistribute ospf 20 metric 10000 1000 255 1 1500
RouterB(config)# router eigrp 15
RouterB(config-router)# redistribute ospf 20
RouterB(config-router)# default-metric 10000 1000 255 1 1500
RIP and IGRP also support the default-metric command. Though IGRP/EIGRP use only bandwidth and delay by default to compute the metric, it is still necessary to specify all five metrics when redistributing. If the default-metric or a manual metric is not specified, IGRP/EIGRP will assume a metric of 0, and will not advertise the redistributed routes.
EIGRP Redistributing into OSPF
To redistribute all EIGRP routes into OSP
OSPF is a standardized Link-State routing protocol that uses cost (based on bandwidth) as its link-state metric. An OSPF router performing redistribution automatically becomes an ASBR.
RouterB(config)# router ospf 20
RouterB(config-router)# network 172.16.0.0 0.0.255.255 area 0
RouterB(config-router)# redistribute eigrp 15 RouterB(config-router)# default-metric 30
If the default-metric or a manual metric is not specified for the redistributed routes, a default metric of 20 will be applied to routes of all routing protocols except for BGP. Redistributed BGP routes will have a default metric of 1 applied by OSPF. By default, OSPF will only redistribute classful routes into the OSPF domain. To configure OSPF to accept subnetted networks during redistribution, the subnets parameter must be used:
RouterB(config)# router ospf 20
RouterB(config-router)# redistribute eigrp 15 subnets
Routes redistributed into OSPF are marked external. OSPF identifies two types of external routes, Type-1 (which is preferred) and Type-2 (which is default). To change the type of redistributed routes:
RouterB(config)# router ospf 20
RouterB(config-router)# redistribute eigrp 15 subnets metric-type 1
Redistributing Static and Connected Routes
Redistributing static routes into a routing protocol
RouterB(config)# router eigrp 15
RouterB(config-router)# redistribute static
Redistributing networks on connected interfaces into a routing protocol
RouterB(config)# router eigrp 15
RouterB(config-router)# redistribute connected
The above commands redistribute all connected networks into EIGRP. Route-maps can be used to provide more granular control:
RouterB(config)# route-map CONNECTED permit 10
RouterB(config-route-map)# match interface fa0/0, fa0/1, s0/0, s0/1
RouterB(config)# router eigrp 15
RouterB(config-router)# redistribute connected route-map CONNECTED
Route Redistribution – Administrative Distance:-
Route redistribution introduces unique problems when there are multiple points of redistribution. Consider the following diagram:
The first issue is caused by Administrative Distance (AD), which determines which routing protocol is “trusted” the most. By default, OSPF routes have an AD of 110, whereas RIP routes have an AD of 120. Lowest AD is preferred, thus making the OSPF routes the most trusted.
Assume mutual redistribution has been performed on RouterC and RouterD. The following networks will be injected from RIP into OSPF: 10.1.1.0/24, 10.1.2.0/24, 10.1.3.0/24, 10.1.4.0/24, and 10.1.5.0/24. RouterC will eventually receive OSPF routes to the above networks from RouterD, in addition to the RIP routes already in its table. Likewise, RouterD will receive OSPF routes to these networks from RouterC. Because OSPF’s AD is lower than RIP’s, both RouterC and RouterD will prefer the sub-optimal path through OSPF to reach the non-connected networks. Thus, RouterC will choose the OSPF route for all the 10.x.x.x/24 networks except for 10.1.1.0/24, as it is already directly connected. This actually creates a routing loop. RouterC will prefer the OSPF path through RouterA to reach the 10.x.x.x networks (except for 10.1.1.0/24), and RouterA will likely consider RouterC its shortest path to reach those same networks. Traffic will be continuously looped between these two routers. Even if RouterC managed to send the traffic through RouterA and RouterB to RouterD, the preferred path to the 10.x.x.x networks for RouterD is still through OSPF. Thus, the routing loop is inevitable.
There are two methods to correct this particular routing loop. The first method involves filtering incoming routes using a distribution-list, preventing RouterC and RouterD from accepting any routes that originated in RIP from their OSPF neighbors.
RouterC’s configuration would be as follows:
RouterC(config)# access-list 10 deny 10.1.2.0 0.0.0.255
RouterC(config)# access-list 10 deny 10.1.3.0 0.0.0.255
RouterC(config)# access-list 10 deny 10.1.4.0 0.0.0.255
RouterC(config)# access-list 10 deny 10.1.5.0 0.0.0.255
RouterC(config)# access-list 10 permit any RouterC(config)# router ospf 20
RouterC(config-router)# distribute-list 10 in fastethernet0/0
An access-list was created that is denying the RIP networks in question, and permitting all other networks. Under the OSPF process, a distribute-list is created for routes coming inbound off of the fastethernet0/0 interface. The access-list and distribute-list numbers must match. RouterD’s configuration would be similar. This prevents each router from building OSPF routes for the networks that originated in RIP, and thus eliminates the possibility of a loop. However, redundancy is also destroyed – if RouterC’s fa0/1 interface were to fail, it could not choose the alternate path through OSPF.
RouterC(config)# access-list 10 permit 10.1.2.0 0.0.0.255
RouterC(config)# access-list 10 permit 10.1.3.0 0.0.0.255
RouterC(config)# access-list 10 permit 10.1.4.0 0.0.0.255
RouterC(config)# access-list 10 permit 10.1.5.0 0.0.0.255
RouterC(config)# access-list 10 deny any
RouterC(config)# router rip
RouterC(config-router)# distance 70 10.1.1.0 0.0.0.255 10
Route-maps provide a sequential list of commands, each having a permit or deny result:
RouterC(config)# route-map OSPF2RIP deny 5
RouterC(config-route-map)# match tag 33
RouterC(config-route-map)# route-map OSPF2RIP permit 15
RouterC(config-route-map)# set tag 44
RouterC(config)# router rip
RouterC(config)# redistribute ospf 20 route-map OSPF2RIP
RouterC(config)# route-map RIP2OSPF deny 5
RouterC(config-route-map)# match tag 44
RouterC(config-route-map)# route-map RIP2OSPF permit 15
RouterC(config-route-map)# set tag 33
Thus, OSPF routes being redistributed into RIP are set with a tag of 44. When RIP is redistributed back into OSPF, any route with a tag that matches 44 is denied. Similarly, RIP routes being redistributed into OSPF are set with a tag of 33. When OSPF is redistributed back into RIP, any route with a tag that matches 33 is denied. The net result: routes originating from a routing domain will not redistributed back into that domain.
thanks
ReplyDelete