Resolving route redistribution issues

- [Instructor] So far in our discussion of Route redistribution, we've had a single router sitting at the boundary of our autonomous systems. But from a design perspective, we might look at that and think, you know, that could be a single point of failure. If that went down, we're not interconnecting these autonomous systems anymore. So we might decide, for redundancy reasons to have a couple of points of redistribution, like we have here. I've got BB1 and BB2, a couple of backbone routers, each of which can redistribute from one autonomous system into another. However, we might run into a situation where a router becomes a bit confused as to the best way to get to a destination network. Because it's hearing about it from two different sources. We can get into sort of a routing loop and maybe make a sub optimal routing decision. Consider the network of 192.168.1.0/24. It's directly connected to R1. And R1, is going to advertise that network out to its neighbors, BB1 and R2. But BB1, sends it's to R3, who sends it to BB2, who sends it into R2 coming in on a different interface. So now R2 is a bit confused. It doesn't know exactly which way to go to get to this network, should it go via BB2, or should it go via R1. And it may, depending on how things are set up, it may pick a sub optimal route, it may go to BB2 and then loop all the way through that other autonomous system to come back into its original autonomous system. Well, the good news is, this is rarely going to be an issue. But sometimes, we might have some non default administrative distance settings, we might have some creative metrics assigned, as we're redistributing into an autonomous system. And just based on the nature of the routing protocols that we're using, we could run into a situation like this. And in this video, we want to see how to address that issue. The good news is though, under normal conditions, it's probably going to be fine. For example, consider EIGRP. Let's imagine that EIGRP is running an autonomous system too whereas BB1 redistributes that route into autonomous system two, it's going to be redistributed as an EIGRP, external route, which has an administrative distance of 170. As opposed to 90, it's going to be less believable, than whatever the routing protocol is like OSPF running on autonomous system one, so it's probably not going to be used. But again, we could have some non default settings, there are some situations where this could happen. So let's consider how to avoid it, what we can do is, say, if we redistribute a route from one autonomous system into another, we're not going to allow that route to come back into our original autonomous system, it's sort of like, going to a store where they're having a clearance sale, and they have some clearance merchandise. And, if you buy it, you're not allowed to return it. So on the receipt they actually stamp, no returns, it's kind of the same thing here, what we can do is, let's say on BB1, as we're redistributing that route into autonomous system two, we can apply a tag to that route, maybe a tag of 10, we can do that with a route map. And I'll show you how to do that in a few moments on some live gear. But let's say that we apply this tag of 10 to this route, then when BB2 gets it, and it's about to redistribute it back into autonomous system one, we have another rule on BB1 that says, don't redistribute anything that has a tag of 10. That's going to prevent this loop. And of course, we would want the opposite as well, we would want BB2, to apply a tag of 10 as its redistributing into autonomous system two. And we would want BB1 to deny routes with a tag of 10, as its redistributing into autonomous system one. But after we set this up. Now when R1 sends this route out, BB1 is going to apply that tag of 10. So when it hits BB2, it's going to be dropped, it's not going to be advertised into autonomous system one. Okay, let's go out to a live interface and see how we set this up. We're sending here on router BB2. And let's take a look at the routes that we know right now if I do a show IP route, let's consider how BB2, can get to the 192.0.2.0/30 network. That's the network between R1 and BB2. Well, according to this, we're going to get there, going to a next hop of 192.0.2.5. That's our one. And we learned that via OSPF, but hold on. Didn't that route get redistributed, because I've already got redistribution configured here. Didn't that route get redistributed into EIGRP, and haven't I learned it via EIGRP? I have, in fact let's prove that, let's do a show IP, EIGRP, topology command. And we can see that I have learned via EIGRP, how to get to 192.0.2.0/30. But it was learned via redistribution, and a redistributed EIGRP route has an administrative distance value of 170. So when BB2, is taking a look at its two sources of information, it's learned to a route via OSPF with an AD and administrative distance of 110. And it's learned that same route via EIGRP. But it's a reduced distributed route. So it has an administrative distance value of 170, OSPF is more believable. So that's the route that makes it into the IP routing table. This is why I'm saying that under normal conditions that this is probably not going to be a problem. But just as a safeguard, because it can happen, I know of it happening. Let's see how to apply those tags, so that will prevent any route redistributed out of an autonomous system from being redistributed back into that autonomous system. And let's begin over on router BB1. On BB1, let's go into global configuration mode. And let's create a route map that's going to apply a tag of 10, we'll say route-map. And I'll just call this tag 10. Now notice, I did not give any sort of a sequence number, I didn't say permit, or deny or anything like that. And that's because I'm just setting a value of 10. I'm not trying to do one thing with one type of traffic. And another thing with another type of traffic, I've only got one statement in this route map. And here it is, it's set tag 10. That's it. Now in just a moment, we'll go over to BB2 and we'll create a route map that prevents routes that have this tag of 10, from being redistributed into OSPF. However, we also want router a BB2 to be marking routes. And we want BB1 where we are now to prevent those routes from being redistributed back into OSPF. So while we're here on BB1, let's go ahead and set up that route map, to deny anything marked with a tag of 10, from being redistributed into OSPF. Now here I will give a couple of sequence numbers because I'm trying to, deny some traffic while permitting other traffic. Let's create another route map. I'll say route' map. I'll call this deny tag 10. And I'll say I'm going to deny and I'll give a sequence number of 10. So it's going to be applied first. And I'll say we want to match anything that has a tag of 10. That's going to be denied. Let's create a another sequence, sequence number 20. This time, I'm going to say permit. And I'm going to permit everything else, I don't need to say anything, everything is going to be implicitly matched and permitted by that sequence number 20. And now that I've got the route maps created, I need to apply those to my redistribution statements. So I can go into router, EIGRP, autonomous system 100. And I'll say, redistribute I'll just overwrite the redistribution commands I already have. I'll say I want to redistribute OSPF. Process ID1, and I want to apply the route map of tag 10. So as I'm redistributing from OSPF and EIGRP. I'm applying a tag of 10. And by the way, I've already got another statement. In fact, let me show it to you. Let's do, a do show run pipe two section router EIGRP. I just want you to see that I do have a default metric. That's the reason I didn't make it part of that redistribute command. Because remember, EIGRP has a seed metric of infinity. So yes, I do have a default metric set. Now, we've set a tag of 10 on anything being redistributed into EIGRP. Now we need to go into the OSPF routing process and say we want to deny anything that has a tag of 10 from being redistributed into OSPF. Let's do a, do show run, pipe two, section, router OSPF and see how we're configured right now. Here's my existing redistribute command. Let's replace that and just add on to it, the route map of deny tagged 10, so let's say router, OSPF process ID1. And we'll say redistribute. Yeah, GRP autonomous system 100, subnets. And now we want to apply that route map I'll say route-map, deny tag 10. And that's all we need to do on BB1. Let's go give a mirrored configuration on BB2 now. So we're going to do exactly the same thing on BB2, we're going to go in and we're going to create a route map, named tag 10, and its purpose in life is to set a tag of 10. And we're going to create another route map, called deny tag 10. And we'll give this a sequence number of 10, and we're going to say deny, and we're going to deny anything that matches a tag of 10. We're going to create another sequence number of 20, which is going to permit everything else. Let's go into router EIGRP, autonomous system 100. And we'll say, redistribute. OSPF process ID1, applying the route map of tag 10. And then, for the OSPF routing process, we'll say redistribute. EIGRP autonomous system 100 subnets. And we want to apply the route map of deny tag 10. And we're done. And just to make sure the routes are being tagged as expected, even though it wasn't causing an issue in our topology, We do want to confirm that we are marking those routes. So let's check this out. Let's go to router R2. And let's do a show IP, EIGRP, topology command. And we're going to be able to see, that a redistributed route like the one we were considering earlier. It's redistributed, with a tag of 10. So now when BB2 gets it and we're trying to redistribute those routes into OSPF, we're not going to do that because we've applied that route map on BB2 and BB1 to say we're going to deny the redistribution of any routes in OSPF that have that tag. And that's a look at how we can sort of rubber stamp routes and deny them from being redistributed into an autonomous system from which they originated. And as a result, hopefully we can eliminate some sub optimal routing.