Route Redistribution- Part 3
Nov 06, 2018
This post is the third in a series of posts on Route Redistribution. If you didn’t yet read the first two, here are the links:
So far in this series, the route redistribution examples we’ve worked through used a single router to do all of the redistribution between our autonomous systems. However, from a design perspective, we might look at that one router and realize that it's potential single point of failure.
For redundancy, let’s think about adding a second router to redistribute between a couple of autonomous systems. What we probably don’t want is for a route to be advertised from, let’s say, AS1 into AS2, and then have AS2 advertise that same route back into AS1, as shown in the figure.
The good news is, with default settings, that probably won’t be an issue. For example, in the above graphic, router BB2 would learn two ways to get to Network A. One way would be via the OSPF AS to which it’s attached. The other way would be through the EIGRP AS, through router BB1, and back into the OSPF AS. Normally, when a router knows how to get to a network via two routing protocols, it compares the Administrative Distance (AD) values of the routing protocols and trusts the routing protocol with the lower AD. In this example, although EIGRP’s AD is normally 90, which is more believable than OSPF’s AD of 110, the AD of an EIGRP External route (i.e. a route that originated in a different AS) is 170. As a result, BB2’s OSPF-learned route to Network A has a lower AD (i.e. 110) than the AD (i.e. 170) of the EIGRP-learned route to Network A. The result? BB2 sends traffic to Network A by sending that traffic into the OSPF AS, with no need to transit the EIGRP AS.
From time-to-time, though, we might have some non-default AD settings configured, or we might have some creative metrics applied to redistributed routes. In such cases, we run the risk of the scenario depicted in the previous figure.
Let’s discuss how to combat such an issue. Consider the following topology.
In this topology, we have two autonomous systems, one running OSPF and one running EIGRP. Routers BB1 and BB2 are currently configured to do mutual route redistribution between OSPF and EIGRP. Let’s take a look at the IP routing tables of these backbone routers.
Notice, as just one example, that from the perspective of router BB2, the best way to get to the 192.0.2.0 /30 network is to go to a next-hop IP address of 192.0.2.5 (which is router R1). That means, if router BB2 wanted to send traffic to the 192.0.2.0 /30 network, that traffic would stay within the OSPF AS.
Interestingly, the EIGRP routing process running on router BB2 also knows how to get to the 192.0.2.0 /30 network due to router BB1 redistributing that route into the EIGRP AS, but that route is considered to be an EIGRP External route. Since an EIGRP External route’s AD of 170 is greater than OSPF’s AD of 110, the OSPF-learned route is injected into router BB2’s IP routing table.
This is how route redistribution typically works when we have more than one router performing route redistribution between two autonomous systems. However, what can we do if things aren’t behaving as expected (or desired)? How can we prevent a route redistributed into an AS from being redistributed out of that AS and back into the original AS, such as in the example shown in the following figure.
In the above example, router R1 advertises the 192.168.1.0 /24 network to router BB1, which redistributes that route from AS1 into AS2. Router R2 receives the route advertisement from router BB1 and sends an advertisement for that route down to router BB2. Router BB2 then take’s that newly learned route and redistributes it from AS2 into AS1, from whence it came. We probably don’t want that to happen, because it might be creating a suboptimal route.
A common approach correct such an issue is to use a route map in conjunction with a tag. Specifically, when a route is being redistributed from one AS into another, we can set a tag on that route. Then, we can configure all of the routers performing redistribution to block a route with that tag from being redistributed back into its original AS, as depicted in the following figure.
Notice in the above topology, when a route is redistributed from AS1 into AS2, it receives a tag of 10. Also, router BB2 has an instruction (configured in a route map) to not redistribute any routes from AS2 into AS1 that have a tag of 10. As a result, the route originally advertised by router R1 in AS1 never gets redistributed back into AS1, thereby potentially avoiding a suboptimal route.
Next, let’s take a look at how we can configure this tagging approach using the following topology once again. Specifically, on routers BB1 and BB2, let's set a tag of 10 on any route being redistributed from OSPF into EIGRP. Then, on those same routers, we’ll prevent any route with a tag of 10 from being redistributed from EIGRP back into OSPF.
To begin, on router BB1 we create a route map, whose purpose is to assign a tag value of 10.
Notice that we didn’t say permit as part of the route-map statement, and we didn’t specify a sequence number. The reason is, permit is the default action, and the TAG10 route map only had a single entry.
In just a moment, we’ll go to router BB2 and create a route map that prevents any routes with a tag of 10 from being redistributed into OSPF. Also, we’ll want router BB2 to be marking routes it’s redistributing from OSPF into EIGRP with a tag value of 10. That means, we’ll want router BB1 to prevent those routes (with a tag value of 10) from being redistributed back into OSPF. So, while we’re here on router BB1, let’s setup a route map that will accomplish that (i.e. preventing the redistribution of routes with a tag value of 10 into OSPF).
This newly created route map (DENYTAG10) does use the permit and deny keywords, and it does have sequence numbers. Sequence number 10 is used to deny routes with a tag of 10 (it's just coincidental that those numbers match). Then, we have to have a subsequent sequence number (that we’ve numbered 20) to permit the redistribution of all other routes.
Now that we have our two route maps created, let’s apply the TAG10 route map to EIGRP’s redistribute command (to tag routes being redistributed into EIGRP with a value of 10). Also, we’ll want to apply the DENYTAG10 route map to OSPF’s redistribute command (to prevent the redistribution of routes tagged with a value of 10 back into the OSPF AS).
Now, we need to enter a mirrored configuration on router BB2.
Just to make sure our routes are being tagged, let’s check out router R2's EIGRP topology table.
Notice that all routes redistributed into EIGRP from OSPF now have a tag of 10, and we’ve told routers BB1 and BB2 not to redistribute those routes back into OSPF. That’s how we can solve some of the potential problems that arise with route redistribution.
At this point in our route redistribution series, we’ve discussed the need for and the operation of route redistribution. We configured basic route redistribution, and then saw how we could filter specific routes from being redistributed. Then, in this post, we saw how to prevent a route being redistributed from one AS into another from being redistributed back into the original AS. That might be necessary, if we find ourselves in a suboptimal routing situation.
We have one more post coming up in our route redistribution series. It’s all about how we can perform route redistribution for IPv6 networks.
Enjoy your studies,
Kevin Wallace, CCIEx2 (R/S and Collaboration) #7945
