Case Study: Redistribution

You will often find yourself wanting to redistribute routes from EIGRP into other protocols and routes from other protocols into EIGRP. The main problem with redistribution between protocols is that it's very easy to create redistribution routing loops. Look at Figure 7-15 to see why.

Given the setup in Figure 7-15, the following events will occur:

With EIGRP's use of an administrative distance of 170 for external sites, the preceding problem shouldn't happen; should it? The example is simplified to make it clear. In reality, when Router D gets the route from Router A, Router D should prefer the route it had already received from RIP because it has an administrative distance of 120. So what is the problem?

The problem occurs if Router E temporarily loses the route to 172.16.20.0/24 and withdraws it from Router D. If this happens, Router D advertises to Router E the route to 172.16.20.0/24 due to the redistribution from EIGRP. This means that the alternative path is working fine. Unfortunately, because the hop count on the redistribution is set to 1 due to the default metric, when Router E gets the "real" route back from Router B, it will not use it because the one it received from Router D is better. This is not what you want to happen!

This is a classic redistribution routing loop. How do you solve it? The easiest thing to do is to filter the destinations redistributed from RIP into EIGRP and from EIGRP into RIP.

Using Distribute Lists to Troubleshoot Redistribution Routing Loops

The first, and simplest, way to handle this is to set up a distribute list specifically blocking the routes that you don't want to redistribute. For example, on Router D, you could build the following distribute list:

access-list 10 deny 172.16.20.0 0.0.0.255
access-list 10 permit any
!
router rip
 redistribute eigrp 100
 distribute-list 10 out serial 0

Assuming that serial 0 is the link between Router D and Router E, this will resolve the problem. RIP will not advertise the 172.16.20.0/24 route from Router D to Router E. If you have more than one connection back into the RIP side of the network, it can be difficult to manage the distribution lists that must be maintained.

Using Route Maps to Troubleshoot Redistribution Routing Loops

Another alternative to distribution lists is to use a route map; in which case, you would configure the following on Router D:

access-list 10 deny 172.16.20.0 0.0.0.255
access-list 10 permit any
!
route-map kill-loops permit 10
 match ip address 10
!
router rip
 redistribute eigrp 100 route-map kill-loops

This configuration allows only those networks permitted by access list 10 to be redistributed into RIP. This has the same effect as the distribute list used in the preceding solution, but it applies the filter in the redistribution rather than in the advertisement to Router D.

Another alternative is to match all external EIGRP routes in the route map, like this:

route-map kill-loops deny 10
 match route-type external
route-map kill-loops permit 20

But this will also "kill off" any external EIGRP routes learned from a protocol other than RIP. In other words, it will prevent external destinations elsewhere in the EIGRP network from being reached by the hosts attached on the RIP side of the network.

Using Prefix Lists to Troubleshoot Redistribution Routing Loops

In addition to using route maps to troubleshoot redistribution routing loops, you can also use prefix lists. For example, you could configure Router D with the following:

ip prefix-list loop-list 10 deny 172.16.20.0/24
ip prefix-list loop-list 10 permit 0.0.0.0/0 le 32
!
route-map kill-loops permit 10
 match prefix-list loop-list
!
router rip
 redistribute eigrp 100 route-map kill-loops

The big advantage of prefix lists is that they allow you to match based on prefix length (the subnet mask) as well as the prefix (destination network) itself. There are a lot of possibilities for filtering when this application is considered, but they won't be covered here.

Setting the Administrative Distance to Troubleshoot Redistribution Routing Loops

Another way to block these routes that is completely different and doesn't rely on the manual configuration of an access list, is to set the administrative distance of all external routes learned by Router D from Router A. You can accomplish this configuration using the distance command. On Router D, you would configure the following:

router eigrp 100
 distance 255 172.16.21.1 0.0.0.0

Assuming that Router A's address is 172.16.21.1, Router D assigns an administrative distance of 255 to any routes it receives from Router A. A route with the administrative distance of 255 will never be inserted in the routing table; therefore, they will not be redistributed into RIP from EIGRP (because redistribution always occurs from the routing table rather than any private databases that the various routing protocols use).

The only problem with this approach is that Router D will refuse all routes learned from Router A, including any legitimate ones. You can remedy this by adding the access list back into the equation:

access-list 10 permit 172.16.20.0 0.0.0.255
!
router eigrp 100
 distance 255 172.16.21.1 0.0.0.0 10

Using External Flags to Troubleshoot Redistribution Routing Loops

All of the previously mentioned troubleshooting methods will work, but they all require either configuring a list of networks or removing the alternative route through the other protocol as a possible backdoor route in the case of failure. Tagging EIGRP externals to block routing loops resolves these two problems and is fairly straightforward to configure.

The two networks in Figure 7-16 have recently been merged by connecting Router A to Router B and Router C to Router D. At some point in the future, the network administrators intend to replace RIP with EIGRP; for now, they are redistributing between RIP and EIGRP on Routers A and C.

This setup produces a classic redistribution routing loop. Router B learns about some destination, for example 10.1.4.0/24, through RIP, and then advertises this route to Router A. Router A redistributes this route into EIGRP and advertises it to Router C. Then, Router C redistributes this route back into RIP and advertises it to Router D, which will then advertise it back to Router B (possibly with a better metric than Router B learned in the original advertisement).

Almost all of the EIGRP network uses addresses from the 10.1.0.0/16 address space, and almost all of the RIP network uses addresses from the 10.2.0.0/16 address space. However, there are some exceptions, such as the 10.1.4.0/24 network.

If it weren't for the exceptions, this redistribution routing loop would be easy to resolve. You would simply prevent Router A and Router C from advertising routes in the 10.2.0.0/16 address range to Router B and Router D and prevent Router B and Router D from advertising routes in the 10.1.0.0/16 address range to Router A and Router C. Distribution lists combined with summarization would make this configuration very easy. (See the previous Case Study, "Redistribution," in this chapter for more information.)

Because there are exceptions, though, preventing this redistribution routing loop becomes more of a problem. You could build distribution lists around the subnets present on each side and apply them on Router A, Router B, Router C, and Router D, but this adds some serious administrative overhead if there are a lot of exceptions. Specific distribution lists would also require modification for each new exception added.

It is easier to use an automatic method to flag the routes learned through RIP on Router A and Router C, and then you can prevent any route that is flagged from being redistributed back into RIP. For example, Router A will still learn about the 10.1.100.0/24 network through EIGRP and advertise this destination to Router B through RIP.

Router B will still advertise 10.1.4.0/24 to Router A, which will then redistribute it into EIGRP and advertise it to Router C. But Router A will flag this route as coming from the RIP domain so that Router C won't advertise it back into RIP. Using some sort of tag like this means that adding a new network in the RIP AS shouldn't require any reconfiguration on the routers doing the redistribution. This type of routing loop is a good use for EIGRP's administrator tags.

Administrator tags are applied and matched using route maps. On Router A and Router C, first you create the route maps and then you apply them to the redistribution between EIGRP and RIP by issuing the following:

route-map setflag permit 10
 set tag 1
route-map denyflag deny 10
 match tag 1
route-map denyflag permit 20

The setflag route map sets the administrator tag on any route to 1, whereas the denyflag route map denies routes with a flag of 1 and permits all others. On both Router A and Router C, you apply these route maps to the redistribution between EIGRP and RIP by issuing the following:

router eigrp 4000
 redistribute rip route-map setflag
router rip
 redistribute eigrp 4000 route-map denyflag

As routes are redistributed from RIP to EIGRP, the route map setflag is applied, setting the EIGRP administrative tag to 1. As the routes are redistributed from EIGRP to RIP, the administrative tag is checked; if it is 1, the route is denied so that it won't be redistributed.