www.howtonetwork.org

CCNA & CCNP Certifcation Training

  • About
  • Contact
  • FAQ
  • Join
  • Home
  • CCNA
    • ICND1
    • ICND2
    • 101 CCNA LABS
  • CCNP
    • ROUTE
    • SWITCH
    • TSHOOT
    • 101 CCNP LABS
  • CompTIA
    • Security+
    • Network+
  • Design
    • CCDA
    • CCDP
You are here: Home / ROUTE / Module 4 / IGP – Route Redistribution Design Considerations (Part 1)

IGP – Route Redistribution Design Considerations (Part 1)

Now that we understand how route redistribution works and how to configure and verify route redistribution, we will conclude this chapter by looking at the ways in which route redistribution can be implemented and general design considerations that should be taken into account when implementing route redistribution in networks.

Route redistribution can be performed one-way or two-way. In addition to this one-way or two-way route redistribution can be implemented on a single router in the network, which is referred to as single point redistribution or on two or more routers, which is referred to as multipoint redistribution. Regardless of the method used, it is important to know that if poorly implemented, routed redistribution can cause suboptimal routing or even routing loops. The following sections describe these types of redistribution and look and some common issues that may result when either of these methods is implemented.

One-Way and Two-Way Route Redistribution

One-way route redistribution occurs when a single routing protocol imports external routing information from another routing protocol, but not vice versa. An example of one-way redistribution would be the redistribution of static routes into EIGRP using the redistribute static metric 1544 2000 255 1 255 router configuration command when configuring EIGRP route redistribution on a router.

One-way redistribution is commonly implemented at the network edge. While the example illustrates the configuration of one-way route redistribution between a static and dynamic routing protocol, it is important to understand that one-way redistribution can also be performed between dynamic routing protocols. Consider the basic network topology that is illustrated in Figure 4-13 for example:

4-13

Fig. 4-13. One-Way Redistribution between Dynamic Route Sources

Referencing Figure 4-13, the router is connected to both an ISP and the interior network. BGP has been enabled between the router and the ISP and the ISP is advertising the full Internet routing table to the router which includes hundreds of thousands of prefixes. The customer owns the 150.254.0.0/22 address space. The specific EIGRP subnets advertised to the router can be redistributed into BGP and a single aggregate route advertised to the Internet.

However, because redistributing the complete Internet routing table into the interior network would very quickly overwhelm an Interior Gateway Protocol, a default route is instead configured and advertised to the interior network, allowing routers within the EIGRP domain to send packets to unknown destinations, e.g. the Internet, to this router.

Two-way route redistribution is also referred to as mutual redistribution. Mutual redistribution allows two routing protocols to exchange dynamic routing information as was illustrated in examples earlier in this chapter. When implementing route redistribution, it is always considered good practice to use some form of filtering mechanism, e.g. route maps to ensure that only the correct subnets are redistributed into the domain.

Single Point Route Redistribution

Single point route redistribution occurs at the single point in the network. This is considered an easy and safe method of redistributing between different route sources because there is a single ingress and egress point between the route sources. However, it should be noted that single point route redistribution can also result in suboptimal routing in some environments. Consider the network topology illustrated in Figure 4-14 for example:

4-14
Fig. 4-14. Implementing Single Point Redistribution
Figure 4-14 shows a basic multi-protocol network. R1, R2 and R3 are running RIP version 2. R2 and R3 are also running OSPF, and reside in the same OSPF domain as R4 and R5.  Based on this topology, the routing table of R2 currently shows the following RIP entries:

R2#show ip route rip
10.0.0.0/24 is subnetted, 5 subnets
R       10.0.1.0 [120/1] via 10.0.0.1, 00:00:03, FastEthernet0/0
R    192.168.254.0/24 [120/1] via 10.0.0.1, 00:00:03, FastEthernet0/0
192.168.253.0/29 is subnetted, 1 subnets
R       192.168.253.0 [120/1] via 10.0.0.1, 00:00:03, FastEthernet0/0

The routing table on R3 currently shows the following RIP route entries:

R3#show ip route rip
10.0.0.0/24 is subnetted, 5 subnets
R       10.0.0.0 [120/1] via 10.0.1.1, 00:00:27, FastEthernet0/0
R    192.168.254.0/24 [120/1] via 10.0.1.1, 00:00:27, FastEthernet0/0
192.168.253.0/29 is subnetted, 1 subnets
R       192.168.253.0 [120/1] via 10.0.1.1, 00:00:27, FastEthernet0/0

Next, mutual redistribution between RIP and OSPF is configured on R2 as follows:

R2(config)#router rip
R2(config-router)#redistribute ospf 2 metric 1
R2(config-router)#exit
R2(config)#router ospf 2
R2(config-router)#redistribute rip subnets
R2(config-router)#exit

Following this configuration change, the routing table on R2 shows the following entries:

R2#show ip route rip
10.0.0.0/24 is subnetted, 5 subnets
R       10.0.1.0 [120/1] via 10.0.0.1, 00:00:22, FastEthernet0/0
R    192.168.254.0/24 [120/1] via 10.0.0.1, 00:00:22, FastEthernet0/0
192.168.253.0/29 is subnetted, 1 subnets
R       192.168.253.0 [120/1] via 10.0.0.1, 00:00:22, FastEthernet0/0

Although everything on R2 is in order, the issue actually resides on R3. Following the mutual route redistribution between RIP and OSPF on R2, the routing table on R3 shows as follows:

R3#show ip route | begin Gateway
Gateway of last resort is not set10.0.0.0/24 is subnetted, 5 subnets
O       10.0.9.0 [110/128] via 10.0.3.5, 00:04:31, Serial0/0
O       10.0.2.0 [110/192] via 10.0.3.5, 00:04:31, Serial0/0
C       10.0.3.0 is directly connected, Serial0/0
O E2    10.0.0.0 [110/111] via 10.0.3.5, 00:04:31, Serial0/0
C       10.0.1.0 is directly connected, FastEthernet0/0
O E2 192.168.254.0/24 [110/111] via 10.0.3.5, 00:04:31, Serial0/0
192.168.253.0/29 is subnetted, 1 subnets
O E2    192.168.253.0 [110/111] via 10.0.3.5, 00:04:31, Serial0/0

Because of the redistribution performed on R2, R3 now prefers the external OSPF routes to all the RIP subnets because the administrative distance of 110 is lower than the default administrative distance of 120 used by RIP. This is a suboptimal path because the direct path from R3 to R1 is clearly the better path.

If you are thinking that implementing mutual redistribution on R3 will resolve the issue, you are incorrect. This goes back to the fundamentals of building the routing table which are described in Chapter 1, as well as the fundamentals of route redistribution which are described earlier in this chapter. To reinforce this statement, mutual redistribution is configured on R3:

R3(config)#router ospf 3
R3(config-router)#redistribute rip subnets
R3(config-router)#exit
R3(config)#router rip
R3(config-router)#redistribute ospf 3 metric 1
R3(config-router)#exit

However, the routing table on R3 still shows the following route entries:

R3#show ip route | begin Gateway
Gateway of last resort is not set10.0.0.0/24 is subnetted, 5 subnets
O       10.0.9.0 [110/128] via 10.0.3.5, 00:15:41, Serial0/0
O       10.0.2.0 [110/192] via 10.0.3.5, 00:15:41, Serial0/0
C       10.0.3.0 is directly connected, Serial0/0
O E2    10.0.0.0 [110/111] via 10.0.3.5, 00:15:41, Serial0/0
C       10.0.1.0 is directly connected, FastEthernet0/0
O E2 192.168.254.0/24 [110/111] via 10.0.3.5, 00:15:41, Serial0/0
     192.168.253.0/29 is subnetted, 1 subnets
O E2    192.168.253.0 [110/111] via 10.0.3.5, 00:15:41, Serial0/0

As shown in the output above, even though mutual route redistribution has been configured between OSPF and RIP on R3, R3 still prefers the OSPF routes to the RIP routes. Why? Well, referencing the first point made, in Chapter 1 when we learned about how the routing table is built, the third step states the following:

  • If the route entry is the same as an existing one, but is received from a more preferred route source, replace the old entry with the new entry

So, originally, R3 preferred the RIP routes for the RIP networks because these routes were not known via OSPF. However, once the routes were redistributed into OSPF, because the same entries were received from a more preferred route source, i.e. because the administrative distance of OSPF is better than that of RIP, even though the routes are external OSPF routes, the RIP entries were replaced with the OSPF entries.
The second point ties into the first point. When redistribution is configured on the routers, the routing protocols communicate with the routing table. Since all the RIP subnets have been installed into the routing table as OSPF external routes, when the redistribute rip subnets command is configured on R3, OSPF queries the routing table for RIP routes.

However, there are none, since they are all known via OSPF following the redistribution on R2. R3 therefore does not import any RIP routes as the routing table shows no entries.
There are three possible solutions that may be used to ensure that R3 prefers the RIP routes for the RIP subnets. These three possible solutions are as follows:

  • Change the OSPF administrative distance for all RIP routes on R3
  • Change the administrative distance for external OSPF routes only on R3
  • Use EIGRP in place of OSPF as the routing protocol

The OSPF administrative distance for all RIP routes can be modified using the distance router configuration command. This command can be used in conjunction with an ACL to increment the administrative distance of the OSPF external routes for the RIP subnets so that R3 prefers the routes received via RIP from R1. This configuration is performed on R3 as illustrated below:

R3(config)#ip access-list standard RIP-ROUTES-ONLY
R3(config-std-nacl)#remark ‘Change AD For RIP Routes Only’
R3(config-std-nacl)#permit 10.0.0.0
R3(config-std-nacl)#permit 192.168.253.0
R3(config-std-nacl)#permit 192.168.254.0
R3(config-std-nacl)#exit
R3(config)#router ospf 3
R3(config-router)#distance 130 2.2.2.2 0.0.0.0 RIP-ROUTES-ONLY
R3(config-router)#exit

By incrementing the OSPF administrative distance for the RIP subnets, the RIP routes are now preferred over the OSPF routes and the routing table on R3 shows the following:

R3#show ip route | begin Gateway
Gateway of last resort is not set10.0.0.0/24 is subnetted, 5 subnets
O       10.0.9.0 [110/128] via 10.0.3.5, 00:01:51, Serial0/0
O       10.0.2.0 [110/192] via 10.0.3.5, 00:01:51, Serial0/0
C       10.0.3.0 is directly connected, Serial0/0
R       10.0.0.0 [120/1] via 10.0.1.1, 00:00:20, FastEthernet0/0
C       10.0.1.0 is directly connected, FastEthernet0/0
R    192.168.254.0/24 [120/1] via 10.0.1.1, 00:00:20, FastEthernet0/0
     192.168.253.0/29 is subnetted, 1 subnets
R       192.168.253.0 [120/1] via 10.0.1.1, 00:00:20, FastEthernet0/0

The second solution would be to change the default administrative distance for all the external OSPF routes. This negates the need to constantly modify the Access Control List that was used in conjunction with the distancecommand in the previous section. For example, if R1 was advertising 50 additional RIP subnets, it would become cumbersome and unnecessarily labor intensive to include every one of those subnets in the ACL.

Cisco IOS software allows administrators to change the default administrative distance for both internal and external OSPF routes using the distance ospf [external | inter-area | intra-area] router configuration command. Any administrative distance values between 1 and 255 can be specified for any of these different route types.

Referencing the topology in Figure 4-14, the following configuration illustrates how to modify the default administrative distance value of all OSPF external routes on R3 to 150, which ensures that whenever additional RIP subnets advertised by R1 are redistributed into OSPF on R3, the router will always prefer the same subnets received from R1 as they will have a lower administrative distance value and will therefore be installed into the routing table:

R3(config)#router ospf 3
R3(config-router)#distance ospf external 150
R3(config-router)#exit

Following this change, the routing table on R3 shows the following entries:

R3#show ip route | begin Gateway
Gateway of last resort is not set10.0.0.0/24 is subnetted, 5 subnets
O       10.0.9.0 [110/128] via 10.0.3.5, 00:00:22, Serial0/0
O       10.0.2.0 [110/192] via 10.0.3.5, 00:00:22, Serial0/0
C       10.0.3.0 is directly connected, Serial0/0
R       10.0.0.0 [120/1] via 10.0.1.1, 00:00:16, FastEthernet0/0
C       10.0.1.0 is directly connected, FastEthernet0/0
R    192.168.254.0/24 [120/1] via 10.0.1.1, 00:00:16, FastEthernet0/0
     192.168.253.0/29 is subnetted, 1 subnets
R       192.168.253.0 [120/1] via 10.0.1.1, 00:00:16, FastEthernet0/0

The third possible solution would be to use EIGRP. This solution would require no additional configuration other than enabling EIGRP on R3. This is because EIGRP uses a default administrative distance of 170 for all external routes. Therefore, when the RIP subnets that are advertised by R1 are redistributed into EIGRP on R2, they would be propagated as external EIGRP routes with an administrative distance of 170. Because R3 is receiving the same routes from RIP with a default administrative distance value of 120, the RIP routes would be used.

NOTE: You are not required to perform any RIP redistribution in the ROUTE exam. RIP has been used in this example for simplicity. The same issue could be replicated using EIGRP instead on R1 and redistributing the 192.168.253.0/29 and 192.168.254.0/24 subnets into EIGRP and advertising them to R2 and R3. Assuming this, the routing table on R2 would show the following initial route entries:

R2#show ip route eigrp
10.0.0.0/24 is subnetted, 5 subnets
D       10.0.1.0 [90/30720] via 10.0.0.1, 00:00:36, FastEthernet0/0
D EX 192.168.254.0/24 [170/156160] via 10.0.0.1, 00:00:36, FastEthernet0/0
     192.168.253.0/29 is subnetted, 1 subnets
D EX    192.168.253.0 [170/156160] via 10.0.0.1, 00:00:36, FastEthernet0/0

Likewise, the routing table on R3 would show the following initial route entries:

R3#show ip route | begin Gateway
Gateway of last resort is not set10.0.0.0/24 is subnetted, 5 subnets
O       10.0.9.0 [110/128] via 10.0.3.5, 00:00:17, Serial0/0
O       10.0.2.0 [110/192] via 10.0.3.5, 00:00:17, Serial0/0
C       10.0.3.0 is directly connected, Serial0/0
D       10.0.0.0 [90/30720] via 10.0.1.1, 00:05:39, FastEthernet0/0
C       10.0.1.0 is directly connected, FastEthernet0/0
D EX 192.168.254.0/24 [170/156160] via 10.0.1.1, 00:00:17, FastEthernet0/0
     192.168.253.0/29 is subnetted, 1 subnets
D EX    192.168.253.0 [170/156160] via 10.0.1.1, 00:00:23, FastEthernet0/0

However, after mutual route redistribution is configured between OSPF and EIGRP on R2, the routing table on R3 would show the following route entries:

R3#show ip route | begin Gateway
Gateway of last resort is not set10.0.0.0/24 is subnetted, 5 subnets
O       10.0.9.0 [110/128] via 10.0.3.5, 00:00:09, Serial0/0
O       10.0.2.0 [110/192] via 10.0.3.5, 00:00:09, Serial0/0
C       10.0.3.0 is directly connected, Serial0/0
D       10.0.0.0 [90/30720] via 10.0.1.1, 00:03:14, FastEthernet0/0
C       10.0.1.0 is directly connected, FastEthernet0/0
O E2 192.168.254.0/24 [110/20] via 10.0.3.5, 00:00:09, Serial0/0
     192.168.253.0/29 is subnetted, 1 subnets
O E2    192.168.253.0 [110/20] via 10.0.3.5, 00:00:09, Serial0/0

The same three solutions used to address the suboptimal routing issue caused when mutual redistribution between RIP and OSPF was performed on R2 can also be used to resolve the suboptimal routing issue caused by the redistribution of EIGRP into OSPF on R2.

Multipoint Route Redistribution

When redistributing at multiple points in the network, the chances that either routing loops or suboptimal routing will occur, are greatly increased. When implementing multipoint redistribution, a general rule of thumb is to always filter routes so that the same routes are not re-advertised back into the source protocol at another point of redistribution in the network as illustrated in Figure 4-15:

4-15
Fig. 4-15. Multipoint Redistribution Considerations
Referencing Figure 4-5, R1 is receiving the 10.1.1.0/24 prefix from a downstream RIP router. This prefix is then advertised to routers R2 and R3. RIP is redistributed into OSPF on R2 and the prefix is propagated as an external route to R4, which sends it to R5, which in turn sends it to R3. At this point, R3 removes the 10.1.1.0/24 prefix learned via RIP and replaces it with the 10.1.1.0/24 prefix learned via OSPF because OSPF is a more reliable route source.

Following the redistribution of RIP into OSPF on R2, R3 prefers the 10.1.1.0/24 prefix received via OSPF over the 10.1.1.0/24 prefix received via RIP. When mutual route redistribution is performed on R3, the 10.1.1.0/24 prefix, which has been installed into the routing table as an OSPF route, is imported into RIP and is then re-advertised back into the RIP domain. Depending on the route metrics used during redistribution, this may result in suboptimal routing or cause a routing loop for packets destined to the 10.1.1.0/24 from routers within the OSPF network. Cisco IOS software supports several methods and techniques that can be used in conjunction with route redistribution to avoid such pitfalls. These methods include:

  • Using distribute lists to filter routes
  • Using route maps to filter routes
  • Modifying administrative distance values

Distribute lists were described earlier in this chapter. Referencing the basic scenario illustrated in Figure 4-15, distribute lists could be configured for RIP on R2 and R3 denying the 10.1.1.0/24 subnet from these two gateways. This would prevent the re-advertising of this prefix into the RIP domain during route redistribution.

The second method would be to use route maps during redistribution. This is the recommended method. The route map can be used to filter routes by referencing an ACL, prefix list or route tags. The use of route maps will be illustrated in detail in the following configuration example.

The third method would be to manipulate the administrative distance of the 10.1.1.0/24 prefix or all OSPF external routes on R2 and R3. This would prevent the prefix from being redistributed back into the RIP domain at either one of these routers as the RIP-learned route would always be preferred based on the administrative distance.

Because mutual redistribution is a core requirement of the ROUTE exam and an often confusing topic, we will us the topology illustrated in Figure 4-16 to reinforce the considerations described in the previous section and see how a poorly implemented mutual redistribution implementation can result in suboptimal routing and routing loops within the routed network.

4-16
Fig. 4-16. Implementing Mutual Route Redistribution

Figure 4-16 shows a basic routed network using EIGRP and OSPF. R1, R2, and R3 are running EIGRP and reside in autonomous system 1. R1 is receiving the 192.168.253.0/29 and 192.168.254.0/24 external EIGRP routes from a downstream neighbor and is advertising them to R2 and R3. R2 and R3 are also running OSPF, and these routers reside in the backbone are with R1. Assuming that both the OSPF and EIGRP routing protocols have been correctly implemented on all routers, the routing tables on all routers in the network show the following:

Prev

Next

About Us

This is a free bonus site for members of www.howtonetwork.com

Copyright

The content on this copyright Reality Press Ltd.
Copyright Reality Press Ltd.