Hour 560: Solving redistribution loops

Route redistribution is a very important topic that every CCIE candidate should master before attempting their lab. In some scenarios when dealing with redistribution, one or multiple routing loops can occur. In the CCIE R&S lab, if a routing loop is possible then you can be almost certain that there will be one, so you better know how to deal with them. This post is meant to help people understand, identify and remove these loops from the network.

First, let’s start by breaking down the different kind of loops that you will see and the best tools to identify them.

Data-plane loops

This kind of loop is the easiest one to identify and can be seen when you have data constantly looping in your network until TTL expires. This can be for known or unknown traffic. “Known traffic” will be the traffic that you have a prefix in the RIB for and “Unknown traffic” will be for the traffic that only matches a default route. The best tool to identify these kind of loops is the traceroute or ping command. Sending ICMP packets to these prefixes will always fail and traceroute will clearly show a pattern of where the traffic is looping.

Control-plane loops

Control-plane loops are when you have routing information looping in the network. These are the most devious kind of loops because sending ICMP packets will not always help you to identify them. The reason for this is that the routing prefixes will sometimes be in a constant race to enter and be removed from the RIB between two protocols. The tool to identify these is actually running a “debug ip routing” on the redistribution routers. In a stable and loop-free environment, this debug command will be almost completely silent. However, if you are having control-plane loop problems, you will several debug messages indicating that routes being added and withdrawn from the RIB.

When can a routing loop occur?

To answer this question, it is easier to explain when a routing loop CANNOT be formed.

One way redistribution:

There cannot be a routing loop when you are doing one way redistribution on a single or multiple routers. For example, redistribution from OSPF to EIGRP on one or multiple routers CANNOT form a loop. There is no possible way that an OSPF route will be injected into EIGRP and be redistributed back into OSPF because there is no redistribution from EIGRP to OSPF configured.

Single router, mutual redistribution:

There cannot be a routing loop when you have a single router doing mutual redistribution. There is no possible way that a route from a routing protocol can be redistributed back on the same router that the route was injected into.

For all the other type of redistribution scenarios there can be a loop. Again, this does not mean that there will be a loop but simply that there can be a loop. These scenarios include: one way redistribution on one device and mutual redistribution on another device between two protocols, multiple devices doing mutual redistribution between two protocols or even multiple devices doing mutual redistribution between multiple protocols.

I have identified one or several data-plane/control-plane loops in my network, now what?

Well the good news is that you don’t have to go on a case by case basis to identify each prefixes, figure out where the loop comes from and where you have to filter it out. There is a system that you can use to will filter out all current and future loops out of the network. This system relies on you to identify the protocols and to filter out the routes. The way you identify these protocols can be through any method of matching of your choice: route tags, access-lists, prefix lists, cos/dscp values, communities, etc. The way to filter these routes can also vary: you can use route-maps, distribute-lists, admin distance manipulation or even offset-lists.

Here is the formula to filter out loops for multiple devices doing mutual redistribution between 2 protocols:

  • Filter everything coming from the protocol being redistributed into
  • Identify everything coming from the protocol that we are redistributing routes into

Let me give you an example on how this would be written using route-maps and tags for a mutual redistribution scenario between EIGRP and OSPF on 2 different routers (R1 and R2):

On every redistribution point:

route-map EIGRP->OSPF deny 10

match tag 110

route-map EIGRP->OSPF permit 20

set tag 90

route-map OSPF->EIGRP deny 10

match tag 90

route-map OSPF->EIGRP permit 20

set tag 110

router ospf 1

redistribute eigrp 1 subnets route-map EIGRP->OSPF

router eigrp 1

redistribute ospf 1 route-map OSPF->EIGRP metric 1 1 1 1 1

In the first route-map statement, we are filtering routes that have been tagged with a tag of 110 (OSPF) to be redistributed back into OSPF. In the second route-map statement, we are allowing all the other routes to be redistributed into OSPF and to identify them with tag 90 (EIGRP). The same formula is repeated for OSPF to EIGRP routes.

What about more than 2 protocols?

The problem with more than 2 protocols being redistributed mutually is that we cannot apply the methodology we did above. The reason for this is that by identifying “all the other routes” with a new identifier, we are overwriting routes that are originated from another protocol. What we actually want to do is to preserve the identifier that the route originally came from but only if it came from another protocol than the one being redistributed or redistributed from. Here is the formula:

  • Filter everything coming from the protocol being redistributed into
  • Match everything coming from the other protocol
  • Identify everything coming from the other protocol
  • Identify everything coming from the protocol that we are redistributing routes into

Let me give an example how this would be written using route-maps and tags for a mutual redistribution between EIGRP, RIP and OSPF on 3 different devices. R1 is doing mutual redistribution between OSPF and RIP. R2 is doing mutual redistribution between OSPF and EIGRP. R3 is doing mutual redistribution between RIP and EIGRP

R1:

route-map OSPF->RIP deny 10

match tag 120

route-map OSPF->RIP permit 20

match tag 90

set tag 90

route-map OSPF->RIP permit 30

set tag 110

route-map RIP->OSPF deny 10

match tag 110

route-map RIP->OSPF permit 20

match tag 90

set tag 90

route-map RIP->OSPF permit 30

set tag 120

router ospf 1

redistribute rip subnets route-map RIP->OSPF

router rip

redistribute ospf 1 route-map OSPF->RIP metric 1

R2:

route-map OSPF->EIGRP deny 10

match tag 90

route-map OSPF->EIGRP permit 20

match tag 120

set tag 120

route-map OSPF->EIGRP permit 30

set tag 110

route-map EIGRP->OSPF deny 10

match tag 110

route-map EIGRP->OSPF permit 20

match tag 120

set tag 120

route-map EIGRP->OSPF permit 30

set tag 90

router ospf 1

redistribute eigrp 1 subnets route-map EIGRP->OSPF

router eigrp 1

redistribute ospf 1 route-map OSPF->EIGRP metric 1 1 1 1 1

R3:

route-map EIGRP->RIP deny 10

match tag 120

route-map EIGRP->RIP permit 20

match tag 110

set tag 110

route-map EIGRP->RIP permit 30

set tag 90

route-map RIP->EIGRP deny 10

match tag 90

route-map RIP->EIGRP permit 20

match tag 110

set tag 110

route-map RIP->EIGRP permit 30

set tag 120

router eigrp 1

redistribute rip route-map RIP->EIGRP metric 1 1 1 1 1

router rip

redistribute ospf 1 route-map EIGRP->RIP metric 1

In the first route-map statement, we are filtering routes that have been tagged with a tag of 120 (RIP) to be redistributed back into OSPF. In the second route-map statement, we are identifying all routes with tag 90 (EIGRP) and tagging them once again with 90. This route-map statement might at first look funny but it is necessary in order to preserve the route-tag on the routes from the third protocol (in this case EIGRP). In the third route-map statement, all the other routes are being allowed to be redistributed and identified with route-tag 110 (OSPF). The formula repeats itself for RIP to OSPF redistribution. The system will be the same on every other router but the “other protocol” will be the one changing.

In conclusion, this post helped you understand the different kind of loops that can exist in your network, taught you what tools to use to identify them and how you can remove them using a scalable system.

On a side note, this will be my last blog before my CCIE bootcamp in 2 weeks. Hope this was informative.

Advertisements

One thought on “Hour 560: Solving redistribution loops

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s