Implementing Route Redistribution
As shown in Example 4-1, redistribution supports all routing protocols. Static and connected routes can also be redistributed to allow the routing protocol to advertise these routes.
Example 4-1: Redistribution Supports All Protocols
RtrA(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
| Note |
|
It is important to note that routes are redistributed into a routing protocol, so the redistribute command is configured under the routing process that is to receive the redistributed routes.
Configuring Route Redistribution
Before implementing redistribution, consider the following points:
- You can only redistribute routes from routing protocols that support the same protocol stack. For example, you can redistribute between IP Version 4 (IPv4) RIP and OSPF because they both support the TCP/IP stack. You cannot redistribute between IP Version 6 (IPv6) RIP new generation (RIPng) and IPv4 RIP because IPv6 RIPng supports only the IPv6 stack and IPv4 RIP supports only the IPv4 stack. Although there are different protocol-dependent modules of EIGRP for IPv4, IPv6, IPX, and AppleTalk, routes cannot be redistributed between them, because each protocol-dependent module supports a different protocol stack.
- The method you use to configure redistribution varies among combinations of routing protocols. For example, redistribution would occur automatically between IGRP and EIGRP processes with the same autonomous system number, but redistribution must be configured between all other routing protocols. Some routing protocols require a metric to be configured during redistribution, but others do not.
The following steps for configuring redistribution are generic enough to apply to all routing protocol combinations. However, the commands used to implement the steps vary, as identified in the following sections. It is important that you review the Cisco IOS documentation for the configuration commands that apply to the specific routing protocols you want to redistribute.
| Note |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The following sections examine the specific commands for redistributing routes into the various IP routing protocols.
Redistributing into RIP
Use the redistribute protocol [process-id] [match route-type] [metric metric-value] [route-map map-tag] router configuration command to redistribute routes into RIP. The parameters for this command are explained in Table 4-3.
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
|
|
|
Open table as spreadsheet Example 4-2 shows how to configure redistribution from OSPF process 1 into RIP. This example uses the router rip command to access the routing process into which routes need to be redistributed—the RIP routing process. The redistribute command is then used to specify the routing protocol to be redistributed into RIP. In this case, it is OSPF routing process number 1.
Example 4-2: Configuring Redistribution into RIP
RtrA(config-router)#redistribute ospf ?
<1-65535> Process ID
RtrA(config-router)#redistribute ospf 1 ?
match Redistribution of OSPF routes
metric Metric for redistributed routes
route-map Route map reference
...
Figure 4-12 provides an example of redistributing routes into RIP. On Router A, routes from OSPF process 1 are redistributed into RIP and are given a seed metric of 3. Because no route type is specified, both internal and external OSPF routes are redistributed into RIP. Notice that Router B learns about the 172.16.0.0 network from Router A via RIP; Router B’s routing table has 172.16.0.0 installed as a RIP route.
| Note |
|
Redistributing into OSPF
Use the redistribute protocol [process-id] [metric metric-value] [metric-type type-value] [route-map map-tag] [subnets] [tag tag-value] router configuration command to redistribute routes into OSPF. The parameters for this command are explained in Table 4-4.
|
| |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Example 4-3 shows how to configure redistribution from EIGRP autonomous system 100 into OSPF. This example uses the router ospf 1 command to access the OSPF routing process 1 into which routes need to be redistributed. The redistribute command is then used to specify the routing protocol to be redistributed into OSPF—in this case, the EIGRP routing process for autonomous system 100.
Example 4-3: Configuring Redistribution into OSPF
RtrA(config-router)#redistribute eigrp ?
<1-65535> Autonomous system number
RtrA(config-router)#redistribute eigrp 100 ?
metric Metric for redistributed routes
metric-type OSPF/IS-IS exterior metric type for redistributed routes
route-map Route map reference
subnets Consider subnets for redistribution into OSPF
tag Set tag for routes redistributed into OSPF
...
It is important to remember that when redistributing into OSPF, the default metric is usually 20, the default metric type is 2, and subnets are not redistributed by default.
Redistribution into OSPF can also be limited to a defined number of prefixes with the redistribute maximum-prefix maximum [threshold] [warning-only] router configuration command. The threshold parameter will default to logging a warning at 75 percent of the defined maximum value configured. After reaching the defined maximum number, no further routes are redistributed. If the warning-only parameter is configured, no limitation is placed on redistribution, and the maximum value number simply becomes a second point where another warning messaged is logged. This command was introduced in Cisco IOS Release 12.0(25)S and was integrated into Cisco IOS Releases 12.2(18)S and 12.3(4)T and later.
Figure 4-13 illustrates an example of redistributing EIGRP routes into OSPF. In this example, the default metric of 20 for OSPF is being used. The metric type is set to 1 (type 1 external [E1] routes), meaning that the metric increments whenever updates are passed through the network. Assuming the cost of the Ethernet link is 10, Router B’s cost for the 172.16.1.0 route is 20 + 10 = 30.
In Figure 4-13, note that the subnets keyword is used so subnets are redistributed. If this keyword were omitted, no subnets would be redistributed into the OSPF domain (including the 172.16.1.0 subnet). Omitting this keyword is a common configuration error.
Redistributing into EIGRP
Use the redistribute protocol [process-id] [match route-type] [metric metric-value] [route-map map-tag] router configuration command to redistribute routes into EIGRP. The parameters for this command are explained in Table 4-5.
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
|
|
|
Example 4-4 shows how to configure redistribution from OSPF into EIGRP autonomous system 100. This example uses the router eigrp 100 command to access the routing process into which routes need to be redistributed—in this case, the EIGRP routing process for autonomous system 100. The redistribute command is then used to specify the routing protocol to be redistributed into EIGRP autonomous system 100—in this case, OSPF routing process 1.
Example 4-4: Configuring Redistribution into EIGRP
RtrA(config-router)#redistribute ospf ?
<1-65535> Process ID
RtrA(config-router)#redistribute ospf 1 ?
match Redistribution of OSPF routes
metric Metric for redistributed routes
route-map Route map reference
...
Table 4-6 shows the five parameters that comprise metric-value when redistributing into EIGRP. Alternatively, these same five parameters can be configured using the default-metric router configuration command for EIGRP.
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Note |
|
Figure 4-14 illustrates an example of redistributing OSPF routes into EIGRP autonomous system 100. A metric is specified to ensure that routes are redistributed. The redistributed routes appear in Router B’s table as external EIGRP (D EX) routes.
External EIGRP routes have a higher administrative distance than internal EIGRP (D) routes, so internal EIGRP routes are preferred over external EIGRP routes. Having different administrative distances for internal and external routes helps prevent routing loops in a network with multiple redistribution points because the routes learned within one part of the network will by default be preferred over those redistributed from another part of the network.
The metric configured in this example is interpreted as follows:
- Bandwidth in kbps = 10,000
- Delay in tens of microseconds = 100
- Reliability = 255 (maximum)
- Load = 1 (minimum)
- MTU = 1500 bytes
The default-metric Command
You can affect how routes are redistributed by changing the default metric associated with a protocol. You either specify the default metric with the default-metric router configuration command or use the metric metric-value parameter in the redistribute command.
If you use the default-metric command, the default metric you specify applies to all protocols being redistributed into this protocol.
If you use the metric parameter in the redistribute command, you can set a different default metric for each protocol being redistributed. A metric configured in a redistribute command overrides the value in the default-metric command for that one protocol.
When redistributing into EIGRP, use the default-metric bandwidth delay reliability loading mtu router configuration command to set the seed metric for all protocols. The parameters of this command are the same as those described earlier in Table 4-6.
When redistributing into OSPF, RIP, and BGP, use the default-metric number router configuration command for setting the seed metric. The number is the value of the metric, such as the number of hops for RIP.
The passive-interface Command
There are times when you must include a subnet in a routing protocols’ network command, although you do not want the interface on which the subnet is connected to participate in the routing protocol. For example, you may want to advertise the subnet on the interface to other neighbors, but not run the routing protocol on that interface. The passive-interface type number [default] router configuration command prevents a routing protocol’s routing updates from being sent through the specified router interface. This command is used to set either a particular interface or all router interfaces to passive; use the default option to set all router interfaces to passive. Table 4-7 describes the parameters of this command.
|
|
|
|---|---|
|
|
|
|
|
|
When you use the passive-interface command with RIP (and IGRP), routing updates are not sent out of the specified interface. However, the router still receives routing updates on that interface.
As described in Chapter 2, when you use the passive-interface command with EIGRP, hello messages are not sent out of the specified interface. Neighboring router relationships do not form with other routers that can be reached through that interface (because the hello protocol is used to verify bidirectional communication between routers). Because no neighbors are found on an interface, no other EIGRP traffic is sent.
As described in Chapter 3, using the passive-interface command on a router running a link-state routing protocol also prevents the router from establishing neighboring router adjacencies with other routers connected to the interface specified in the command. The router does not send hello packets on the interface and therefore cannot establish neighbor adjacencies. Also with OSPF, the specified interface appears as a stub network in the OSPF domain, and OSPF routing information is neither sent nor received through the specified router interface.
In ISPs and large enterprise networks, many distribution routers have more than 100 interfaces. Before the introduction of the passive-interface default command in Cisco IOS Software Release 12.0, network administrators would have to configure the routing protocol on all interfaces and then manually set the passive-interface command on the interfaces where they did not require adjacencies. However, this solution meant entering many passive-interface commands. A single passive-interface default command can now be used to set all interfaces to passive by default. To enable routing on individual interfaces where you require adjacencies, use the no passive-interface command.
For example, in Figure 4-15, Routers A and B run RIP and have a network command that encompasses all their interfaces. However, the network administrator wants to run RIP only on the link between Router A and Router B. Router A has several interfaces, so the passive-interface default command is configured, and then the no passive-interface command is used for the one interface from where RIP updates are advertised. Router B has only two interfaces, so the passive-interface command is used for the one interface that does not participate in RIP routing.
It is important to understand how this configuration affects the information exchanged between Routers A, B, and C. Unless you configure another routing protocol between Routers A and B and Router C, and redistribute between it and RIP, Router A does not tell Router C about the networks it learned from Router B via RIP (or about any of Router A’s directly connected networks). Likewise, Router B does not tell Router C that it has a way to reach the networks advertised by Router A via RIP (or about any of Router B’s directly connected networks). Physical redundancy is built in to this network; however, the three routers might not be able to use the redundancy effectively if they are not configured properly. For example, if the link between Routers C and A fails, Router C does not know that it has an alternative route through Router B to reach Router A.
Route Redistribution Example
This section shows an example of route redistribution in a network using multiple routing protocols.
Figure 4-16 shows the network of a hypothetical company. The network begins with two routing domains (autonomous systems)—one using OSPF and one using RIPv2. Router B is the boundary router; it connects directly to one router within each routing domain and runs both protocols. Router A is in the RIPv2 domain and advertises subnets 10.1.0.0, 10.2.0.0, and 10.3.0.0 to Router B. Router C is in the OSPF domain and advertises subnets 10.8.0.0, 10.9.0.0, 10.10.0.0, and 10.11.0.0 to Router B.
Figure 4-16 also shows the configuration of Router B, before redistribution is configured. RIPv2 is required to run on the serial 0/0/1 interface only, so the passive-interface command is configured for interface serial 0/0/2 to prevent RIPv2 from sending route advertisements out that interface. OSPF is configured on interface serial 0/0/2.
Figure 4-17 shows the routing tables for Routers A, B, and C. Each routing domain is separate, and routers within them only recognize routes communicated from their own routing protocols. The only router with information on all the routes is Router B, the boundary router that runs both routing protocols and connects to both routing domains.
The goal of redistribution in this network is for all routers to recognize all routes within the company. To accomplish this goal, RIPv2 routes are redistributed into OSPF, and OSPF routes are redistributed into RIPv2. Router B is the boundary router, so the redistribution is configured on it, as shown in Figure 4-18.
RIPv2 is redistributed into the OSPF process, and the metric is set using the redistribute command. A metric value of 300 is selected because it is a worse metric than any belonging to a native OSPF route. (Although a smaller metric would only be a problem if there were multiple redistribution points between the two domains, it is considered a best practice to configure a larger metric than the native metric of the receiving domain.)
Routes from OSPF process 1 are redistributed into the RIPv2 process with a metric of 5. Again, a value of 5 is chosen because it is higher than any metric in the RIP network.
Figure 4-19 shows the routing tables of all three routers after redistribution is complete; Routers A and C now have routes to all the subnets that Router B learned from the other routing protocol. There is complete reachability, but Routers A and C now have many more routes to keep track of than before. They also will be affected by any topology changes in the other routing domain.
Depending on the network requirements, you can increase efficiency by summarizing the routes before redistributing them. Remember that route summarization hides information, so if routers in the other autonomous systems are required to track topology changes within the entire network, route summarization should not be performed. A more typical case is that the routers need to recognize topology changes only within their own routing domains, so performing route summarization is appropriate.
If routes are summarized before redistribution on Routers A and C, each router’s routing tables are significantly smaller. Figure 4-20 shows the summarization configuration on both Routers A and C, and the routing tables on all three routers after summarization has been configured. Router B benefits the most; it now has only four routes to keep track of instead of nine. Router A has six routes instead of nine, and Router C has seven routes to keep track of instead of nine. The configurations on Routers A and C are also shown in Figure 4-20.
For RIPv2 on Router A, the summarization command is configured on the interface connecting to Router B, interface S0/0/0. Interface S0/0/0 advertises the summary address instead of the individual subnets. (Note that when RIPv2 is configured, the subnet mask of the summary address must be greater than or equal to the default mask for the major classful network.) 10.0.0.0 255.252.0.0 summarizes the four subnets on Router A (including the 10.0.0.0/30 subnet).
For OSPF, summarization must be configured on an Area Border Router (ABR) or an ASBR. Therefore, OSPF area 1 is created to include the four subnets to be summarized. Router C becomes an ABR, and the summarization command is configured under the OSPF process on Router C. 10.8.0.0 255.252.0.0 summarizes the four subnets on Router C.
Using Administrative Distance to Influence the Route-Selection Process
Multiple sources of routing information may be active at the same time, including static routes and routing protocols that use various methods of operation and metrics. In this situation, several sources of information may supply ambiguous next-hop addresses for a particular network, so routers must identify which routing information source is the most trustworthy and reliable. When routes are redistributed between two different methods of resolving the best path, important information may be lost—namely, the relative metrics of the routes—so route selection is sometimes confusing. One approach for correcting wayward choices is to control the administrative distance to indicate route selection preference and ensure that route selection is unambiguous. This approach does not always guarantee the best route is selected, only that route selection will be consistent.
You should change the default administrative distance carefully and by considering the network’s specific requirements.
Selecting Routes with Administrative Distance
Recall that administrative distance is a way of ranking the believability or trustworthiness of the sources of routing information. Administrative distance is expressed as an integer from 0 to 255, as shown earlier in Table 4-1; lower values indicate greater believability.
Each routing protocol is prioritized in the order of most believable to least believable. Some examples of default prioritization are as follows:
- Prefer manually configured routes (static routes) to dynamically learned routes
- Prefer protocols with sophisticated metrics to protocols with more deterministic metrics
For example, in Figure 4-21, R1 may choose a different path to get to the 10.0.0.0/8 network on R6, depending on the routing protocol configured. If RIP, OSPF, and EIGRP are all configured on all routers in this network, the protocols make the following path decisions:
- RIP, with an administrative distance of 120, chooses the R1 to R4 to R6 path based on hop count (two hops versus four hops the other way).
- OSPF, with an administrative distance of 110, by default calculates the default metric as 100 megabits per second (Mbps) divided by the interface bandwidth, where the interface bandwidth is the speed of each link in Mbps. The path R1 to R4 to R6 default metric is as follows:(100 Mbps / 64 kbps) + (100 Mbps / 1.544 Mbps)= (100 Mbps / .064 Mbps) + (100 Mbps / 1.544 Mbps)= (1562 + 64)= 1626The R1 to R2 to R3 to R5 to R6 path default metric is this:(100 Mbps / 1.544 Mbps) + (100 Mbps / 1.544 Mbps) + (100 Mbps / 1.544 Mbps) + (100 Mbps / 1.544 Mbps)= 64 + 64 + 64 + 64= 256Therefore, OSPF chooses the R1 to R2 to R3 to R5 to R6 path. (Although OSPF and IS-IS are both link-state routing protocols that converge quickly, OSPF is considered more trustworthy than IS-IS because OSPF bases its default metric on bandwidth and therefore is more likely to pick a faster path.)
- EIGRP, with an administrative distance of 90, calculates the default metric as BW + delay, where BW is [(107 / least bandwidth in the path in kbps) * 256], and delay is cumulative across the path, in tens of microseconds, multiplied by 256. Assuming a uniform link delay of 100 tens of microseconds, the R1 to R4 to R6 path default metric is as follows:((107 / 64) * 256) + (200 * 256) = 40,051,200.The R1 to R2 to R3 to R5 to R6 path default metric is this:((107 / 1544) * 256) + (400 * 256) = 1,760,431.
- Therefore, EIGRP chooses the R1 to R2 to R3 to R5 to R6 path. Although EIGRP and OSPF routing protocols both converge quickly and consider bandwidth, EIGRP is considered more trustworthy than OSPF because EIGRP takes more information into account in its calculation.
Because EIGRP has the lowest administrative distance of the three protocols, only the EIGRP path to 10.0.0.0/8 is put into the routing table.
| Note |
|
Modifying Administrative Distance
In some cases, you will find that a router selects a suboptimal path as a result of believing a routing protocol that actually has a poorer route, because that protocol has a better administrative distance. One way to make sure that routes from the desired routing protocol are selected is to assign a higher administrative distance to the routes from the undesired routing protocol.
| Note |
|
For all protocols use the distance administrative-distance [address wildcard-mask [ip-standard- list] [ip-extended-list]] router configuration command, as explained in Table 4-8, to change the default administrative distances.
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
| Note |
|
Alternatively, for EIGRP, the distance eigrp internal-distance external-distance router configuration command can be used, as explained in Table 4-9. By default, natively learned routes have an administrative distance of 90, but external routes have an administrative distance of 170.
|
|
|
|---|---|
|
|
|
|
|
|
In Example 4-5, the distance eigrp 80 130 command sets the administrative distance for internal EIGRP routes to 80 and for external EIGRP routes to 130. The distance 90 192.168.7.0 0.0.0.255 command sets the administrative distance to 90 for all routes learned from routers on the Class C network 192.168.7.0. The distance 120 172.16.1.3 0.0.0.0 command sets the administrative distance to 120 for all routes from the router with the address 172.16.1.3.
Example 4-5: Modifying Administrative Distance for EIGRP Example
router eigrp 100
network 192.168.7.0
network 172.16.0.0
distance eigrp 80 130
distance 90 192.168.7.0 0.0.0.255
distance 120 172.16.1.3 0.0.0.0
Alternatively for OSPF, the distance ospf {[intra-area dist1] [inter-area dist2] [external dist3]} router configuration command can be used to define the OSPF administrative distances based on route type, as explained in Table 4-10.
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
In Example 4-6, the distance ospf external 100 inter-area 100 intra-area 100 command sets the administrative distance for external, interarea, and intra-area OSPF routes to 100 (default values are 110). The distance 90 10.0.0.0 0.0.0.255, distance 110 10.11.0.0 0.0.0.255, and distance 130 10.11.12.0 0.0.0.255 commands set the administrative distance to 90, 110, and 130, respectively, for all routes learned from routers with specific addresses; notice that the router’s addresses are specified from least to the most specific. For example, routes from a router with address 10.10.0.1 will have an administrative distance of 90, and routes from a router with address 10.11.12.1 will have an administrative distance of 130.
Example 4-6: Modifying Administrative Distance for OSPF Example
router ospf 10
network 192.168.7.0 0.0.0.255 area 0
network 172.16.0.0 0.0.255.255 area 0
distance ospf external 100 inter-area 100 intra-area 100
distance 90 10.0.0.0 0.0.0.255
distance 110 10.11.0.0 0.0.0.255
distance 130 10.11.12.0 0.0.0.255
Alternatively, for BGP, the distance bgp external-distance internal-distance local-distance router configuration command can be used to change the administrative distances, as explained in Table 4-11. (Using the distance command for BGP sets the administrative distance of EBGP routes only.)
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
Redistribution Using Administrative Distance Example
Figure 4-22 illustrates a network using multiple routing protocols, RIPv2 and OSPF. The purpose of this example is to show how a path-selection problem can occur, where the problem appears, and one possible way to resolve it, using administrative distance.
Recall that OSPF is by default considered more believable than RIPv2; OSPF has an administrative distance of 110 and RIPv2 has an administrative distance of 120. For example, if a boundary router (R1 or R2) learns about network 10.3.3.0 via RIPv2 and also via OSPF, the OSPF route is inserted into the routing table. This route is used because OSPF has a lower administrative distance than RIPv2, even though the path via OSPF might be the longer (worse) path.
Example 4-7 and Example 4-8 illustrate the configurations for the R1 and R2 routers; RIPv2 is redistributed into OSPF and OSPF is redistributed into RIPv2 on both routers.
Example 4-7: Configuration of Redistribution on Router R1 in Figure 4-22
hostname R1
!
router ospf 1
redistribute rip metric 10000 metric-type 1 subnets
network 172.31.0.0 0.0.255.255 area 0
!
router rip
version 2
redistribute ospf 1 metric 5
network 10.0.0.0
no auto-summary
Example 4-8: Configuration of Redistribution on Router R2 in Figure 4-22
hostname R2
!
router ospf 1
redistribute rip metric 10000 metric-type 1 subnets
network 172.31.0.0 0.0.255.255 area 0
!
router rip
version 2
redistribute ospf 1 metric 5
network 10.0.0.0
no auto-summary
The RIPv2 routes redistributed into OSPF have an OSPF seed metric of 10,000 to make these routes less preferred than native OSPF routes and to protect against route feedback. The redistribute command also sets the metric type to 1 (external type 1) so that the route metrics continue to accrue. The routers also redistribute subnet information.
The OSPF routes redistributed into RIPv2 have a RIP seed metric of five hops to also protect against route feedback.
The first edge router on which redistribution is configured, R1 in this case, has a routing table that contains both OSPF and RIPv2 routes, as you would expect. The routers in the OSPF domain learn about the routes from the RIPv2 domain via redistribution; they then advertise these RIPv2 routes via OSPF routes to their neighboring routers. Thus, the second edge router, R2, receives information about the RIPv2 domain routes (also called the native RIPv2 routes) from both OSPF and RIPv2. R2 prefers the OSPF routes because OSPF has a lower administrative distance.
Example 4-9 displays the routing table on the R2 router after redistribution has occurred. This output confirms that even though the R2 router learns RIPv2 and OSPF routes, it lists only OSPF routes in the routing table, because they have a lower administrative distance.
Example 4-9: Routing Table on Router R2 in Figure 4-22 with Redistribution Configured
See Figure 4-22 to trace some of the routes. The redistribution has resulted in suboptimal paths to many of the networks. For instance, 10.200.200.34 is a loopback interface on Router R4. R4 is directly attached to R2. However, from R2 the OSPF path to that loopback interface goes through R1, and then R3, and then R4 before it reaches its destination. The OSPF path taken is actually a longer (worse) path than the more direct RIPv2 path.
You can change the administrative distance of the redistributed RIPv2 routes to ensure that the boundary routers select the native RIPv2 routes. Example 4-10 and Example 4-11 show the configurations on the R1 and R2 routers. The distance command changes the administrative distance of the OSPF routes to the networks that match access list 64 to 125 (from 110). Table 4-12 describes some of the command parameters used in the example configurations.
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
Example 4-10: Configuration to Change the Administrative Distance on Router R1 in Figure 4-22
hostname R1
!
router ospf 1
redistribute rip metric 10000 metric-type 1 subnets
network 172.31.0.0 0.0.255.255 area 0
distance 125 0.0.0.0 255.255.255.255 64
!
router rip
version 2
redistribute ospf 1 metric 5
network 10.0.0.0
no auto-summary
!
access-list 64 permit 10.3.1.0
access-list 64 permit 10.3.3.0
access-list 64 permit 10.3.2.0
access-list 64 permit 10.200.200.31
access-list 64 permit 10.200.200.32
access-list 64 permit 10.200.200.33
access-list 64 permit 10.200.200.34
Example 4-11: Configuration to Change the Administrative Distance on Router R2 in Figure 4-22
hostname R2
!
router ospf 1
redistribute rip metric 10000 metric-type 1 subnets
network 172.31.0.0 0.0.255.255 area 0
distance 125 0.0.0.0 255.255.255.255 64
!
router rip
version 2
redistribute ospf 1 metric 5
network 10.0.0.0
no auto-summary
!
access-list 64 permit 10.3.1.0
access-list 64 permit 10.3.3.0
access-list 64 permit 10.3.2.0
access-list 64 permit 10.200.200.31
access-list 64 permit 10.200.200.32
access-list 64 permit 10.200.200.33
access-list 64 permit 10.200.200.34
Access list 64 is used to match all the native RIPv2 routes. The access-list 64 permit 10.3.1.0 command configures a standard access list to permit the 10.3.1.0 network; similar access list statements permit the other internal native RIPv2 networks. Table 4-13 describes some of the command parameters used in the examples.
|
| |
|---|---|
|
|
|
|
|
|
|
|
|
Both R1 and R2 are configured to assign an administrative distance of 125 to routes that they learn from OSPF and that match access list 64. Access list 64 has permit statements for the internal native RIPv2 networks 10.3.1.0, 10.3.2.0, and 10.3.3.0 and the loopback networks 10.200.200.31, 10.200.200.32, 10.200.200.33, and 10.200.200.34. Therefore, when either of these routers learns about these networks from both RIPv2 and OSPF, it selects the routes learned from RIPv2—with a lower administrative distance of 120—over the same routes learned from OSPF (via redistribution from the other boundary router)—with an administrative distance of 125—and puts only the RIPv2 routes in the routing tables.
Notice in this example that the distance command is part of the OSPF routing process configuration because the administrative distance should be changed for these routes when they are learned by OSPF, not by RIPv2.
You need to configure the distance command on both redistributing routers because either one can have suboptimal routes, depending on which redistributing router sends the OSPF updates about the RIPv2 networks to the other redistributing router first.
Example 4-12 shows that Router R2 now retains the more direct paths to the internal networks by learning them from RIPv2.
Example 4-12: Routing Table on Router R2 in Figure 4-22 with the Administrative Distance Changed
However, some routing information is lost with this configuration. For example, depending on the actual bandwidths, R2’s OSPF path for the 10.3.1.0 network might have been better than its RIP path, so it might have made sense not to include 10.3.1.0 in the access list for R2.
This example illustrates the importance of knowing your network before implementing redistribution, and closely examining which routes the routers select after redistribution is enabled. You should pay particular attention to routers that can select from several possible redundant paths to a network, because they may select suboptimal paths. The most important feature of using administrative distance to control route preference is that no path information is lost. In this example, the OSPF information is still in the OSPF database, so if the primary path (via the RIPv2 routes) is lost, the OSPF path reasserts itself, and the router maintains connectivity with those networks.
Verifying Redistribution Operation
The best way to verify redistribution operation is as follows:
- Know your network topology, particularly where redundant routes exist.
- Study the routing tables on a variety of routers in the internetwork using the show ip route [ip-address] EXEC command. For example, check the routing table on the boundary router and on some of the internal routers in each autonomous system.
- Examine the topology table of each configured routing protocol to ensure that all appropriate prefixes are being learned.
- Perform a trace using the traceroute [ip-address] EXEC command on some of the routes that go across the autonomous systems to verify that the shortest path is being used for routing. Be sure to run traces to networks for which redundant routes exist.
- If you encounter routing problems, use the traceroute and debug commands to observe the routing update traffic on the boundary routers and on the internal routers.
| Caution |
|
0 comments
Post a Comment