Tools for Route Manipulation and Control

0:04It's a wonderful thing when we have a routing domain or a group of routers, we've implemented a routing protocol, and it just works great. The best paths are being used. There's no problems. However, there are times that are going to come up in your career working in networks when the optimal path is not being taken or if you have to redistribute two different routing protocols into each other with mutual redistribution where we need some additional tools and options for controlling routing. So that's what this set of videos is all about. I want to introduce you and talk with you about some of the tools we're going to use for route manipulation, give you some examples, some hands on labs, so you can practice it, so you can be aware of the tools so that when you need them, you can both be aware of what they are, how they work, and how to verify them.

0:44And this discussion continues in the very next video. So I'll see you there in just a moment.

0:05Oh my gosh. So much fun stuff to cover. I'd like to chat with you in this video-- using this topolgy that we're going to look at here in just a moment-- about some of the reasons that we would use these control methods for manipulating the attitude, the brain, of a single router to make it behave in a unique way, rather than just following the defaults. So let's take a look at the topology. I'll share with you some scenarios and also a high level overview of some of the tools we could use to change the attitude of a Cisco router. So let's start with this. Let's imagine that we just threw on routing protocol A on this entire network.

0:37And let's imagine maybe it's EIGRP or OSPF. And what we're going to notice is that the goal of being able to manipulate and control the attitude of a outer is important when it doesn't behave the way we want. See, our goal is to have connectivity through the network. And we don't want any loops. For example, we wouldn't want-- if we had a default route, or wanted a default route that pointed to R2. And R2 had a default route that pointed to R1. And then if either one of them got a packet and they didn't know where to send it, it would just go, "brrrrrrrrrrr"-- I think that's sound it makes-- until the TTL expires.

1:09Then the packet would be killed. That's not ideal to have a routing loop like that based on static routes. So with all those static routes present, if we just had a OSPF, we might think, well, it's going be great. Well, OSPF, by default, has an auto-cost reference bandwith of 100, which means it sees a fast Ethernet interface as a cost of 1. And it sees a gigabit interface as a cost of 1. So, just right out of the gate, we'd want to do some tuning for the OSPF processes, that's what we're using, and specify that we want the auto-cost reference bandwidth certainly higher than 100, maybe 1,000. Or if we have, you know, faster links than gig, we'd also want to make it even bigger and do that across the board.

1:44But once we have the basic elements in place, it should be great. It should be able to identify the best paths to the network. So as part of the EnCore and this NRC training, we've taken a look at the individual routing protocols and how they operate and their metrics. And that's important, I would say, extremely important. Before we start manipulating routes and controlling routes, we'd want to understand how the routing protocols work first before we try to change their behavior. So with EIGRP, it's bandwidth and delay, baby. That's all they-- it's the lowest bandwidth in the path, which is passed on by the neighbor, and the sum of the delays.

2:18And that's what they're basing their metric on. With OSPF, it's cost and using the linked state database. And it's important to send the defaults of how those protocols work and their AD's before we start manipulating them. Because check this out. As we go back to this drawing, let's imagine we put EIGRP on this network. And then we said, wow, if we look at the loopback here on R1. So if we look at the path from R8 to R1, the worst link in the path is going to be these serials. So R8 from all three interfaces is going to have the lowest bandwidth.

2:50And the path being those serial links because that's what's passed on with the EIGRP. That's how it works. And then the sum of the delays would depend on what the delays were advertised. So if we went to R8-- in fact, let's do this as an exercise. If we went to R8 and looked at the routing to get to R1, which path should it use? Did it use this guy over here, serial 3/1, 3/2, or 4/1? And the best way to ask it, or the best way to find out, is just ask it. Let's do that. And I just realized I don't have a routing protocol running. Real quick, let's just do a router EIGRP 2, that's fine.

3:23And we'll do a network 0.0.0.0. And we are off to the races. I'll copy that and just plug that into each of these routers. One of things I love about EIGRP is-- oh my gosh, how fast is it? It is so fast. So by the time I can even paste these in on R8, if we do a show IP route for 1.1.1.1. Yeah, it's got equal cost paths routing to 1.1.1.1 that fast. So if we were to look at this and say, wow, your next hop is dot 7 and dot 6. Your traffic share count is 1.

3:54Let's do a show IP route. Yeah, we have two routes to the 1.1.1.1 network. And we might look at the topology and say, well, you know, what's up with that? Why isn't it-- if the lowest cost in the path is the serial links, how come it's not using this right here? And so it'd be important to first, before we start manipulating routes, to understand why it's doing what it's doing. So in EIGRP and the OSPF content in EnCORE and here in NRC, we've taken a look at the routing metrics and how decisions are made and so forth.

4:25And we'd want to first of all understand what it's doing before we start to manipulate it. So here are some tools that we could use to manipulate it. We could go ahead and say, I want to modify the AD, the administrative distance. We can specify using the tools of manipulation on a router, hey, if you learn about this route off this interface from this neighbor, go ahead and specify the route for just this set of networks to a lower AD. And if you do it, those will be put in the routing table. AD wins always. So that's one way to get those specific routes in the routing table to change its mind from the defaults.

4:59We could also modify the metric. Now, depending on what routing protocol we're using, it might be cost. So if it's BGP it would be the attributes, including the AS path attribute and the weights and so forth that are involved with the metric for BGP. But it's important to understand what the basics are for individual routing protocols like OSPF and EIGRP and BGP. So that if we want to, we can modify those. Now, what are some tools that we can use to modify those? And one of the main tools is called a route map.

5:31And with a route map, we can specify, OK, based on this happening, if this matches this network, that network, the other network, I want to go ahead and change, for example, the administrative distance, or the metric. And route maps can be applied for incoming routes that we're learning or routes that we're sending. It's basically a Swiss Army knife of setting the parameters. We could also set a tag. And you might say, well, Keith, why would we ever set a tag associated with a route? Check this out. Let's imagine that right here.

6:03Let's imagine that this is routing protocol A. And I'll use a different color. And we have another network, another group of networks, that are in routing protocol B. Now, this is not a design goal. Sometimes we have multiple routing protocols because we have to. We're using legacy gear or maybe we're running OSPF and we have some stuff that's still running EIGRP that we want to work. The secret is here that this network right here, network 12, which is the link 10.0.12 between R1 and R2, if we want that network to be seen by routers down here and be able to reach it, either these guys need default routes-- that works-- or they need to have that information.

6:43So what we could do is we could redistribute. And that brings a whole world of challenges because the metrics-- let's imagine this is routing protocol B. The metrics for routing protocol A, whether it's OSPF or EIGRP or ISIS, they are different than the metrics used by routing protocol B. And so when we do redistribution, we do it on a router that is connected to both routing domains. And we simply give the instructions, please redistribute this routing protocol B into A. And then we are also going to have the opportunity at that moment to specify the metrics and the details for those routes as they come in.

7:17Because check this out, we want fault tolerance-- usually, companies do. And so if we have R3 doing mutual redistribution. And we have R4 doing mutual redistribution from B to A and from A to B. That's fine, you might think. But what if this network, the 12 network, gets-- I'll put this in a different color so we can see it. Let's imagine the 12 network gets redistributed into routing protocol B. And then R4 takes that route, the 12 network, which is in routing protocol B, and redistributes it into routing protocol A. What's going to happen then?

7:50We're going to have flaps. If that route is advertised here, then there, then here, then there, then here, then there, it shows up, it disappears, that route could be flapping, which is terrible. And that's when we'd want to use a lot of our controls to make sure that doesn't happen. One of those options is tagging it. Now, there are several options we could use to solve this problem. But one is tagging it, where we take that 12 network when it comes in, we tag it with a number, like, 777, Vegas. So we tag it. And then that route, as it lives here at the 12 network, we can train R4, hey, listen, when you're doing your redistribution, we could combine that with a route map that's looking for that tag.

8:27And we could tell R4, hey, if it has a tag of 777, don't bother bringing it in. So in combination with route maps, and also some other tools we have, we have a large assortment of lists. You might say, Keith, what do you mean lists? We've got ACL's, access controls lists, which we're not using for, like, filtering traffic at an interface. But we could use it as part of a route map to identify networks. And we can also, with some protocols, identify a network prefix and who sent it to us. And use that as part of our identification process.

8:57We also have distribute lists as part of our tool belt. And we have prefix lists, which are another amazing tool to help identify specific routes that we want to either permit or tag or filter or process differently. Another option is an offset list. And some of these do apply based on the routing protocol you're using. But an offset list, if we had, like, EIGRP or RIP, we could go ahead and apply an offset list. And we could tell R8, listen, when you're learning about the route from R7, about the 1.1.1.1 network and it comes in here, go ahead and bump that up with a higher metric, an offset of, like, 50 higher than what it normally should be.

9:33And that way we're influencing the mind of R8 regarding that route by using manipulation on R8. So there are a lot of options for manipulating routes. Some of them depend on which routing protocol we're using. And there are three basic things that I want you to take away from this video. Number one, it's important to first learn the defaults and behaviors of the individual routing protocols. That's why we have so much content regarding that, regarding EIGRP and OSPF and BGP, so you can make sure you understand those defaults first. And then based on the routing protocol or protocols we're working with, we can then, if we need to, manipulate inbound and outbound route updates-- modify the distance or the metrics of the cost and so forth on those routes that will effectively manipulate the behavior of a router regarding those routes it receives to prefer or not prefer one route or one path over another.

10:21So here's what we're going to do. In the upcoming videos and labs, I will walk you through a few scenarios to give you hands-on practice. So you'll have a first-hand opportunity to practice with route maps and prefix lists and distribute lists and offset lists and manipulating AD and using route maps. So you can have a taste of what it feels like and then get that hands-on practice to help reinforce it. So all that's coming up as we continue these videos together. So stay tuned. And I'll see you in the very next video. Meanwhile, I hope this has been informative for you. And I'd like to thank you for viewing.

0:05One of the best ways of learning about a tool or a method for manipulating routing is to actually do it. So in this video and hands-on lab, I encourage you to click on the link for the Virtual Lab and join me as we take a look at using distribute lists and prefix lists to change the attitude and behavior of a Cisco router. And here's our game plan. Let's implement EIGRP on all these devices. And what we'll discover is that for the 10.0.1 network and some other 10.0 networks up here, and also the 1.1.1.1, R8 is going to have two equal cost paths, one going this way, one going that way.

0:38We can verify that in the lab. And what I'd like to do to manipulate R8's behavior is change the way R7 is advertising over to R8. What we can do is, we can use what's called a distribute list. And a distribute list, as used as part of EIGRP is something to say, oh, don't bother sending him this information or advertising this information. So we can say, hey, regarding the networks of 10.0, anything, if they're 24-bits long, go ahead and don't bother advertising them. So if R7 doesn't advertise that and doesn't advertise 1.1.1.1, which we can also control, if it doesn't advertise those to R8, R8 is no longer going to have that route.

1:14And it will stop using it. So in conjunction with the distribute list, we can use an ACL to identify the networks that we don't want to advertise via EIGRP. We could also use something called a prefix list, which can also be used. And it's a little more granular. So lists in our example and our walk-through, let's use a distribute list that calls upon a prefix list that is matching on 10.0.1.anything and also matching on that specific route, and restricting those routes from being advertised to any neighbors. And then I'll walk you through it step by step.

1:45So here's our lab environment. And I'm just going to bring up Notepad for a moment because part of our exercise here is to make sure EIGRP is running. And it is not at the moment. So we do a show IP protocols. It's got no dynamic routing protocols. So let's bring up a fresh Notepad document. And we'll do a config T and a router EIGRP We use autonomous system number one. If you want to use named EIGRP feel free as well. And then we'll do a network of everything. Great. So we'll do a Control A and a Control C to copy all that. And then I'll just do a right click on each of these devices and paste it in.

2:17EIGRP is so stinking fast. Oh my gosh. We do a show IP route for EIGRP learned routes. Boom. It's done. It's very, very fast. So the two routes I want to just pay attention to here would be these guys right here. So first of all, 1.1.1.1 it has a next hop of dot 7 and dot 6, which we look at our topology, that would be R7 and R6. And if we go back to the CLI. And we look at the network 10.0.1.1, it's got a next hop of 6 and 7 as well. And what we're going to do is I want to make those routes coming from R7 not look as good.

2:50And one way of doing that is by simply telling R7, don't advertise those routes. And that will give us an example of practicing with both distribute lists in EIGRP and also with prefix lists. So let's do this. Let's go ahead into R7, get on the right router. And we'll do a show IP prefix lists just to make sure I don't have any in place. And let's create some. We'll get to configuration mode IP prefix list, and a question mark. So let's call this OURLIST. And then you can give him a sequence number.

3:21Now, if you don't give it a sequence number, it'll automatically sequence them for you. But if you want it nice and tight, and you want to know what the numbers are, you can just put them in manually. I'm going to call this sequence-- you know what? What the heck. I'll live on the edge. I think it's going to start with sequence number 5. And that's going to be fine with me. So let's specify deny. And you might say, Keith, what is this prefix it's going to deny? We don't-- we're going to use this prefix list as part of the EIGRP with a distribute list option. So let's go ahead and deny 1.1.1.1, which is a 32-bit route. I need to check on that real quick.

3:52But back to R8, it is indeed a 32-bit route right there. So if we just pressed Enter right here, boom. This prefix list, if called upon, is going to deny the exact 32-bit route of 1.1.1.1. Boom. All right. Next, let's go ahead and deny something else. Do an IP prefix list. And we'll call this OURLIST. And, again, in the background, this is automatically sequencing them for us. So we'll do a deny. And let's do a 10-- you know, let's do this. Let's come up with a plan together.

4:24Let's imagine that we want to have R7 not advertise 10.0.anything if it's a 24-bit mask, a 24-bit route. Now, to do that, prefix lists rock because we can specify not only that these two octets here can be wildcards, it doesn't matter what's there, but we also have the ability with a prefix list to say exactly the length of the network or prefix that we're looking for.

4:57Let me show you how to do that. This is really cool. Let's go back to our CLI. And at the CLI we'll do a deny 10.0.0.0. And then we can say slash 16, like that. And then if we add on, if we add on a GE or an LE, which is greater than or equal to, or less than or equal to, it then says OK. There's more conditions that apply. So it has to be 10.0 and, we could say, needs be less than or equal to a 24-bit route. And press Enter.

5:28And so what that would do, that would say, OK, only 24-bit routes that have the first two octets of 10.0. But any time we see the LE or GE after it, think of the slash 16 or the slash 24, whatever is there, just think of that as everything after that part of the mask is a wild card. And that we're looking for the links. We could also, if we wanted to add on to that, we could also do something like this. We could say, let's say that 10.2, let's say that anything that starts with 10.2. But it has to be greater than or equal to-- let's imagine, how about 19 bits-- and then less than or equal to 31 bits.

6:04Press Enter. So we can be very granular if we have a certain quantity. So this means 10.2.anything, if the mask or the length of the network is between 19 and 31 inclusively. That's what this says. So if we do a do show IP prefix list. Let's see what we have so far. We've got three deny statements. Well, just like an access control list, if we don't have some permits in here, there's not going to be a whole bunch being allowed. So let's add one more sequence. And we'll do it IP prefix OURLIST.

6:35And we'll say permit. And here's how we do the wild card that means let everything. It is 0.0.0.0/0. But we're not going to press Enter there. And then we're going to add-- this is important for the everything-- is that we're going to do a less than or equal to 32, which basically means any IP address that wasn't matched earlier is going to match here. And in this case it's a permit. So what we could do now is we could go to R7 and tell R7 in its routing protocol to go ahead and apply this as an outbound distribute list.

7:06And it will not advertise, if you take a look at this, it won't advertise 1.1.1.1. It won't advertise 10.0.anything if it has a mask exactly equal to 24. And it won't advertise 10.2.anything if it has a mask between 19 and 31. So those are the three categories of routes it will no longer advertise. And then the last line here says permit everything else, which means advertise everything else. So let's go ahead and apply this by going into router configuration mode. So do show IP protocols. Just remember what routing protocols I have.

7:38OK. It's EIGRP 1. So we go to router EIGRP 1. And then we'll do a distribute list. And there's a whole bunch of things to start with dist. So D-I-S-T-R. Great. Distribute list. And then we'll go ahead and-- this is where we could call on an access list to match on what we want to permit or deny out. Or we could use the word "prefix". There's also the keyword for route map if you wanted to call on a route map. So this time we created the prefix list. Now let's call on the prefix list by using the keyword "prefix". And then we'll call OURLIST.

8:09And then a question mark, and then we'll specify "out". Now before we press Enter, let's go to R8. So a moment ago, if we do a show IP route for EIGRP learned routes or the-- let me press Enter again. So for the 10.0.1 we are going to 7 and 6. And also for the 1.1.1.1 we are going to 7 and 6. And basically R7 is going to stop advertising that. And as a result, we're no longer going to use R7 as the next hop. Let's go back to R7 We'll press Enter.

8:43We'll do a show run section router just to verify what we did. And survey says, all right. Pretty straightforward, distribute list, prefix, the name of our prefix list, out. And let's go take a look at R8. And here on R8, we'll do an Up arrow key show IP route EIGRP. And check it out. We no longer have two routes to 1.1.1.1. And that's because R7 is no longer advertising that based on the prefix list. Also, if we had the route for 10.0.1, which we also had R7 as the next hop for.

9:14And we no longer have it there, either. But what we do have, I'm just looking for dot 7 as the next hop, he is advertising to us the 10.1.5 and the 10.1.35 and the 10.1.7. So we're still learning routes, except he is not advertising the routes that we told it not to based on the distribute list, which was associated with the prefix list. So thanks for joining me in this lab on implementing some filtering of routes for outbound advertising with EIGRP using distribute lists in combination with prefix lists. And I'll see you in the next video.

9:45Meanwhile, I hope this has been informative for you. And I'd like to thank you for viewing.

0:05If we had a pet, we'll use a dog because it's more applicable to a dog than the cat. If we had a dog, when would be the best time to train that dog on how to behave? And the answer is as soon as possible-- when it's young, when it is fresh, when it's new. Well, we have the same opportunity with routing and with route control when we do redistribution from one routing protocol to another. That's the perfect time where we can implement some controls and tweaking to make those routes behave the way we want. So let me share with you the topology. And then some ideas regarding redistribution and some controls we can put in place at the point of redistribution.

0:40So with this topology, let's imagine that we have this part of our network using all one common routing protocol. We'll call it, let's call it OSPF. That way we can put some teeth on it, as opposed to routing protocol A. And then down below, down here, let's go ahead and have all these guys run, let's pick, EIGRP. All right. So first of all, this is not a great design. However, if we had OSPF domain and the EIGRP domain that we want to share the routes, one of the key tricks I use is make sure we're focusing on one route at a time, or one network.

1:14So let's say, for example, this 12 network up here between R1 and R2, if we want reachability on here and this is EIGRP domain, they're going to need either a default route or they're going to need to learn that route, and vice versa. If we want the 78 network to be learned by router 1 or router 2, but you're not running EIGRP, we've got to somehow either give them default routes or give them that information by redistributing EIGRP into OSPF. So as far as manipulation and control, check this out. When we do the redistribution of OSPF, the way we do it is we go into router configuration mode for EIGRP.

1:48And then we'd say redistribute OSPF into EIGRP. Now, the problem, the problem is that the metrics are all wacky doodle different. OSPF uses costs and EIGRP uses the composite metric with bandwidth and delay being the two major factors. So how do we deal with that? Well, when we bring in a route when we do the redistribution on this guy, R3, we're going to specify what we want that seed metric to be. We can set a default or we can do it at the point of redistribution with a command. We can say, OK, any new routes that are coming in as far as manipulation and control, we want them to have a bandwidth of XYZ.

2:24And we want the delay to be XYZ. So we can make the route look as good or as bad as we want based on that redistribution into EIGRP. Then once they're there, they're going to show up as external. So that's what an external EIGRP route is. It is redistributed in from another source of static routes or another routing protocol. And so external routes in EIGRP have an administrative distance of 170. So they're not going to be preferred compared to the non-external routes with EIGRP which have an AD of 90.

2:59So just right there, if these routers have to choose a route, they're going to go ahead and choose the route with an AD of 90 if there's duplicates in place. So by default some of the defaults are going to help us. Now, the other element is, if we wanted to redistribute EIGRP into OSPF, we could do it also right here-- which is not a bad idea-- on the same router. That's going to help prevent loops. And then as we bring EIGRP routes in, we have some choices. They are going to be external routes in OSPF once we redistribute them in, including the 78 network. But we can specify, do we want it to be a type 1, external type 1 where the metric can grow and grow and grow as that route gets propagated in OSPF, or do we want it to be an external type 2?

3:37Type 2, I'm fixed. My metric is fixed. That's all I do. So inside of OSPF, we can control that. And also what we can do is when we bring routes back and forth, we can also tag them. And you might say, Keith, what's the benefit of a tag? Tags are helpful in the condition where we, if we're doing redistribution over here-- this is just an example-- on R4 of EIGRP into OSPF and OSPF into EIGRP for fault tolerance-- we have two routers that are behaving that way-- we could, on the redistribution, we could tell the routers, hey, listen.

4:09Any external EIGRP routes, don't bother bringing in. I mean, they're already external. So that's a very elegant way of controlling the device and saying, you know what? These are external routes, like, the 12 network as an external in EIGRP. Don't bother bringing it in. That's great. We might have other scenarios, though, where if we tag them, if we, on R3, if we tagged all the routes as they came in and we added a tag of, let's say, 999. Just a number. So R3 tags 999 as he brings him in, R4 tags 999 as he brings him in.

4:40Then we could tell the routers, hey, listen. If it has a tag of 999, that route, don't bother bringing it in. We can control that with route maps. So we can tag using route maps. Some routing protocols allow us to tag directly. We'll do that in the next lab. And we also, when we redistribute, we can refer to a route map that's looking for a tag of 999 and saying, not going to bring it in. Now, the great news is this. The great news is this. We have a lot of tools and options when we're doing redistribution. And here's one of the key elements that I learned a long, long time ago in a network far away, is that we want to avoid, which is another way of saying don't, don't redistribute a route that was sourced from one routing domain, like, OSPF at the 12 network.

5:25Don't redistribute that same route back into OSPF. So in some, like, a CCIE environment where they have, this domain and that domain, the key is just make sure that a route that was sourced in OSPF, or we'll call this routing protocol 1, routing protocol 1. And we'll call EIGRP routing protocol number 2. Make sure that any routes that were sourced originally from routing protocol 1 and then they're redistributed into a different routing protocol 2, make sure we're never going to redistribute those back in to the original routing domain because that is what's going to lead to loops.

6:02So EIGRP and OSPF have so many defense mechanisms in place. For example, OSPF, if it has the same route that it's learned via an intra-area route versus an inter-area route, it's going to choose the intra. So that's going to be chosen regardless of metric. And if it has an external type 1 and an external type 2, it's going to choose the external type 1 every day over the external type 2 because that's how it's built. So in these two scenarios, it's actually pretty tough to have a routing loop because of the defaults with the AD's and the preference for these routing protocols that they use by default.

6:39So the crux of this video is if we're taking routes from one routing domain and putting them into another, we have lots of controls at that point of redistribution regarding tagging, manipulating, which rails to bring in, which routes to not bring in. We can include tags as part of that mix as we manipulate and control the routes that are brought in. Now, some of you might be thinking, well, Keith, this would be a lot easier if we just ran OSPF in this whole domain. I know. I know. But the goal of this video, these sets of videos, is to share with you some of the techniques and tools that we can use to control the routes in these kind of corner situations.

7:13So here's what we get to do. In the next video and lab, I'm going to walk you through setting up a mixed domain environment with EIGRP and OSPF based on what we just looked at, and give you a chance to practice, first of all, the redistribution between the two different routing protocols, and have some fun with it as we can manipulate the metrics any way we want to when we do that redistribution. So I'll see you in that next hands-on lab in just a few moments. Meanwhile, I hope this has been informative for you. And I'd like to thank you for viewing.

0:05One of the best ways to learn and troubleshoot redistribution is to actually implement it. And that's what we're going to do in this video and lab right now. So click on the link for the virtual lab, and let's go ahead and do this together. Let's start by taking a look at the topology and setting up a plan. So here's our proposed plan. I propose that we take these networks right here, and we put them in OSPF area 0. Now, one thing I did, which was very convenient for this lab, is that all these networks that I've just outlined here, they start with 10.0.

0:37So we can do a 10.0 with a wildcard mask for area 0 on all these routers, and they are good to go. And then, what we can do is, let's make this action down here, let's go ahead and do EIGRP. And this will give you some practice in implementing those protocols as well. This will be EIGRP, and let's use Autonomous System 1. So OSPF process id 1 we'll use up here, and EIGRP1 down here. And down here, we have these networks on the left-hand side are all 10.1-something. Over here on the right-hand side, they're 10.2.

1:08It is playground, which is really what it is. Let me go ahead and walk you through implementing this. You can follow step-by-step. And then once we have the OSPF and EIGRP implemented, we'll do a redistribution plan between those two routing domains on either R3, R4, or both. So let's implement the basic routing protocols first. All right, so I'm going to bring up a fresh notepad document. And let's do a config t, router ospf 1, and network everything, and area 0. And we'll put this on R1 and R2. Let's include all their interfaces.

1:39And that'll be for R1 and R2, all right? Boom, Ctrl-C, and R1, R2, and not R3, because R3 and R4 are going to be on the edge. So we only got some of their interfaces. So for R3, let's do this. We'll go back to our notepad document, and we'll do a network 10.0. And then, with the wildcard mask, saying that we care about the first two octets. So 0.0-- all right, that looks good. And that will be on routers 3 and routers 4.

2:11So we'll do a copy, and on router 3, we'll paste that. On 4, we'll paste that. And let's also verify we got that right. So let's take a look at our topology. So R4, it should have gig 2/0 and fa 4/1, but it should not have Serial3/1, because these are the 10.1 network down here off to the bottom right. Let's go verify that. I'll do a show ip ospf interface brief. Survey says-- great, those are the interfaces we expected. And it's going to form some neighborships here with both R3 and R2 here in a moment.

2:42Great, let's go on to our config for the EIGRP portion. So config t, router eigrp, and we're using-- telling the system 1, and we'll do a network-- let's make it 10.1.0.0. And that's going to be the left-hand side of our network. And we'll do a wildcard mask of the first two octets, and then, also, network 10.2.0.0. And that will be the right-hand side of our network. And that will be appropriate for R3 and R4. So let's do that, just on those two routers.

3:16So here's R3, and here's R4. If we look at our topology, what that just did, that's going to pick up the fa 4/1 on R3 and also these Serial3/1 on R4. and we can verify that by going back to the CLI and doing a show ip eigrp interface. And over on R3, if we use that same command. Now, let's go ahead and do routers 5 through 8. And for that, we can just do router eigrp and network everything.

3:47And that would be good for them. They can include everything. So I will copy that, and we'll put that on routers 5, 6, 7, 8. So copy, and routers 5, 6, 7, and 8. All righty. Oh, and you know what? We need one more interface. I just realized that this interface right here, R3, that is the 10.38 network, which is not part of EIGRP yet. Let's go in and add that. So we'll go back to the CLI, and let's go to R3. And let's do a show ip eigrp interface.

4:20Yep, didn't get it. So we'll config t, and we'll do a router eigrp 1, and we'll do network 10.38. And that should pick it up. If we get a neighborship, which we just did, that's fantastic. That implies we enabled all the correct interface that goes down to R8. So what we have now is we have OSPF on the top and EIGRP on the bottom, and R3 and R4 are running both routing protocols. So to do redistribution, we need to pick a router that's running both routing protocols.

4:53And let's go to R3, and let's take the OSPF routes and put them in EIGRP. So to do that, we're going to go into router config for EIGRP, and then do a redistribute OSPF, and we'll specify what we want the metrics to be once those routes in OSPF come into EIGRP. Let's do that right now. So on R3, we'll do a show IP protocols, just to make sure we're on the right device. It's got OSPF running, great. It's got EIGRP running. We'll go into router configuration mode, or router eigrp 1. And we'll say, redistribute. I want to bring in.

5:24I'm pulling in the routes from OSPF. And it's going to ask me for some questions, like which process ID? Process ID 1. It's going to ask me, what do you want to use for the metric? Now, if you press Enter here, unless you specified a seed metric, what the default metric should be, we're going to have some problems. As far as troubleshooting, you'd better make sure that we've either set the defaults that way we wanted to, or we specify them here for when those routes are brought in. So let's go ahead and use some context-sensitive help. And let's say the metric we want to use is-- first all, there's really two that really matter with the default K values.

5:57And the two that matter are the bandwidth, and also the delay. We just used OSPF1. I want to use a metric for these newly-imported routes. I'm going to put in 100. Well, if I put in 100, that looks like a really bad bandwidth. But I don't care. We want the route to show up. It's not going to show up as, really, a great metric, but that's OK. It's going to be unique. So OSPF1 metric, let's do 100 kilobits per second, and then we'll specify a delay. Let's go ahead and use 200-microsecond delay. And then, for the rest, reliability, nobody cares-- I shouldn't say nobody cares about that.

6:31But we're not looking at that for our metric calculations. So I'm going to put a 1 there. And then, for the effective bandwidth metric, I'm going to put a 1 there, because we don't pay attention that, either. And a question mark. The EIGRP MTU, nobody cares about that either. [LAUGHS] And then, here is where we could actually use a route map to manipulate and control the routes that are going to be coming in from OSPF and stuck into EIGRP. So if we wanted to specify a route map here and then call upon a route map, we could. We can also do a match, and then do a question mark.

7:03And then it's saying, OK, regarding pulling OSPF routes in, do you want to pull in external or internal? So this would be a great option here control-wise, to say, you know what? Any external routes that came into OSPF, I don't want to bring them in. Now, if you do, you could just go ahead and include it. So these are some of the controls we have when we do redistribution. So I'm going to leave that off, not going to use those controls, and boom, we've got redistribution. Like, whoa, that was quick. So if we take a look at our routers-- let's go pick on a router somewhere down here, like R5, R7, R6, R8.

7:35They're all going to know about these 10.0 networks up here because R3 is redistributing them into EIGRP. So let's go take a look. So back to-- let's go to arr-- let's get R7. Arr, I'm a pirate-- Arr-7. And let's do a show IP route. And we'll just do EIGRP learned routes. And check it out, we've got some externals, and externals with a really super high metric. That's because we didn't give it great bandwidth as far as when we imported them. So they're showing up as external EIGRP routes.

8:06The administrator distance for an external EIGRP route is 170. And we have reachability. So should we be able to ping 1.1.1.1? Yeah, the answer to that question is, yeah, we should be able to ping them. And I believe that's working. But the problem is, R1 has no clue how to get back because R1 doesn't have a route to R7. R7's are just slow. So let's do a ping, a 1.1.1.1. This will loopback on R1, and we'll source it from loopback 0, which is 7.7.7.

8:38And just to confirm, R1 doesn't have a route back. So if we go back to R1, we say, hey, Mr. R1, show ip route everything, show me everything, it says, I don't have a route to 7.7.7.7. It's just not in my routing table because no one is sharing with us. So let's go back and finish our redistribution. Now, in a production environment, it would make a lot of sense, short of using when we're in routing domain, but it would also make a lot of sense, if we're doing redistribution on R3 of OSPF in EIGRP, it would be a great idea to do redistribution of EIGRP back into OSPF on that same device.

9:18Because then you're going to avoid loops, and problems, and issues. But the other challenge is that if you do it just on one device, and that router goes down or has a problem you'll lose connectivity between the two routing domains. So even though we could do it here, we could do it bi-directional, mutual redistribution here on R3, we could also do mutual redistribution on R4. For fun-- and it will be fun-- let's do redistribution of EIGRP into OSPF, but we'll do it on R4.

9:49And we're going to have very similar controls as we bring those routes in. Based on the routing protocols, the metric for EIGRP is way different than OSPF. So we're going to have to specify what we want the seed metric or the basic metric to be when those routes come in. So let's go ahead and do redistribution on R4 and take a look at a few of the controls we can use there as well. So on R4-- we'll get on the right device-- we'll do a quick show IP protocols to verify that we are running OSPF and EIGRP. And we want to pull-- redistribute, like pull the routes from EIGRP into OSPF.

10:23So to do that, we'll go to OSPF-- router ospf 1. Now, if you're using address families, the syntax is to be slightly different, again, based on EIGRP named with address families or OSPF version 3 with address families. So the syntax may vary a little bit based on the version and the method you're using, but the concept is very similar. That is, we can control the details for the newly-injected routes based on the device doing the redistribution. So router ospf, we want to redistribute. And look at this. There is lots of options here where we can pull in routes from.

10:55But we're going to pull in routes, in this example, from eigrp, we're telling the system 1, and let's use context-sensitive help. Now it's saying, OK, do you want to use a route map in association with this, with a route map that can further define what we're going to pull in and, as we pull routes in, if we want to manipulate them further via the set statements in the route map? So there's lots of options here. There's also an option for tagging. If we want to tag those routes as-- let's do 999. That way, we could filter on those on R3 if we needed to, or we could look for those routes in the routing table with the tag of 999.

11:28So let's tag it here. We could also tag with a route map. So a route map could be applied, and a route map could match and then tag also. So there's more than just one way of doing it. And let's set the metric. Let's set the metric. This is going to be the OSPF metric for routes that are redistributed in. Let's set the metric to-- let's do 44, because this is R4 bringing them in. So we have a metric of 44. So the routes will show up with a metric of 44. And what type of metric do you want to use? With the OSPF, externals have two types-- type 1, an extra external type 1, which the metric grows as that route is being propagated through the OSPF domain, or a type 2, which is fixed.

12:05[GRUNTS] This is the route. Let's use let's use the metric type of 2 as an example here. And then we could, again, apply a route map, which would further manipulate or look at the routes that we're considering for redistribution and then manipulate them with whatever we set in the route map. And then, let's also includes subnets. That's a little thing with OSPF. By default, when you bring in routes, unless you include the keyword "subnets," it's not going to include any subnets. It's just classful boundaries, which isn't going to serve our purpose here.

12:38All right, so I included the word "subnets." And not going to use a route map. I don't need NSSA only. So I'm ging to press Enter. And now we are redistributing EIGRP routes into OSPF. So if we go to one of these routers-- so this is our four we just did the redistribution on. If we go to R1 or R2 and ask them their opinion about these networks down here, like the 10.78, or the 10.1 networks on the left, or the 10.2 networks on the right, let's go take a look and see what their opinion is. So we'll go to R1.

13:08And on R1, we'll do a show IP route. And look at this. OK, so let me go ahead and actually clean this up a little bit. Let's show ip route for ospf run routes. There we go-- a little less output there. So here are some examples of routes, so external type 2. Why? Because that's what we told R4 to do. We told R4 to go ahead and use an external type 2. And there is our metric that we specified the cost-- 44, hard coded it.

13:40So if we had multiple devices doing redistribution, and we wanted one path to be preferred, how could we do that? Well, if they're all E2s, and one router, when it does redistribution, says, hey, the metric is 33, and one says, the metric is 44, if both routes are available, it's going to choose the one with the lower cost. And that's how we can influence which path the traffic is going to take. Now, a couple of things that I think are very interesting. Why is R1 thinking that to reach 5.5.5.5, which is a loopback, it has two paths, through 13.3 and 13.2?

14:17That's R3 and R2. Let's take a look at our topology. That's wack-a-doodle. So the fun begins. So R1 says, to get to this loopback, so R4 is doing the redistribution, and R1 says, I can go here and here. It's equal cost. But this is fast ethernet, and this is all gig, so those are not really equal costs. And I just realized what we did-- what I did. By default, the auto cost reference bandwidth is 100, meaning that the Fast Ethernet and the gig look like a cost of 1.

14:49So if we change the cost reference bandwidth on all our OSPF devices to 1,000, that would make the gig look like a cost of 1 and the Fast Ethernet look like a cost of 10. And then it would choose a better path. Again, that's just OSPF on its own without the redistribution. So we might want to modify that on a production network to make sure we're choosing optimal paths. But that's why that's happening. Oh, you know what? In a separate video, as part of this all these sets of videos and the encore at NRC, we talked about preference, OSPF preference, where, if it's running the same route, it's going to use the intra-area route first.

15:25And if there's an inter-area route, it would, if there's no intra- and there's an inter-area route, it would use that. And then, if there is no inter-area route, it would then start using the E's in the N's. And we have a whole separate video on that. But I think what would be interesting to do is, we did redistribution here. It's currently R1 is seeing 5.5.5 as an E2. What if we also did redistribution here on R3 and we used a worse metric?

15:56Like right now, we have a metric of 44. If we used a worst metric, but we brought it in as an E1, OSPF preference-wise, it's going to choose the E1 over the E2. And we can actually see that. That's why labbing this up is very helpful and useful in gaining the skills in both implementing and troubleshooting routing by looking at the behaviors, seeing the results, and verifying them with your own hands. So let's look to redistribution from EIGRP into OSPF also on R3, but we'll set them up as type 1s for the external routes.

16:29And we'll see that R1 will change its attitude, because it prefers external type 1's with the same exact network over external type 2's. So back we go. And let's go to R3. And let's go to router ospf 1. And we'll do a redistribute. And we're going to redistribute eigrp into-- and the autonomous system number is 1. And the metric, let's go ahead and set a really bad metric. So for the metric, let's use-- so for the metric, for these EIGRP routes that are going to be pumped into OSPF, let's use a metric of-- let's see here.

17:06How about 88888? That's a really bad metric. [LAUGHS] Because everything else in our routing table on R1-- in fact, let's go take a peek. We have OSPF routes with metric 44, and 2 for the cost. So 8888 is going to be really high. OK, then we're going to specify the metric type. And we're going to bring it in as a metric type of type 1, which is preferred over a metric type of type 2 in OSPF, even though the cost is higher. That's the preference method.

17:37So here, we could go ahead and tag it, if we want tag the routes that we're bringing in. Let's tag it with an 8888. It's just going to be associated with the routes, so that later, if we need to on another router, we can say, hey, anything with a tag of 8888 read as special. Or, don't redistribute it back into EIGRP, or something to that effect. And then, include the word "subnet." That's good, too, because otherwise, the subnets won't come in. It will only do classful boundaries. All right, and we are done. So now we have redistribution here, if we do a show IP protocols, we are now doing mutual redistribution here on R3.

18:12If we do a show IP protocols, so for OSPF1 on R3, it says, OK, I'm bringing in the routes from EIGRP, which makes this device an ASPR for OSPF, bringing in something external, redistributing into OSPF. And it has the metric. It says, including subnets. There's the EIGRP process number. And if we go download it further and look at EIGRP1, it also-- let me go ahead and scroll up just a little bit-- it also says, hey, I'm redistributing ospf 1 into eigrp.

18:43And so now, if we go to R1, it was just a moment ago the 5.5.5 network was reachable with the cost of 44. We had two paths, R2 and R3, because of our autocost reference bandwidth settings. But now that R3 is also advertising that same route for 5.5.5.5, and it's an external type 1-- check this out. We'll do a show ip route ospf. And look at this. There's our external type 1. There's our crazy high metric. An external type 1 grows as it propagates through the network.

19:14And so even though the cost is higher, OSPF prefers intra-area routes than inter-area routes. Then it goes on to the external on the NSSAs, and it prefers the E1 over the E2, even though the metric is higher. So that's just good to be aware of as far as how OSPF behaves and operates. So now, if we want to test connectivity, we could do a test, we could do a ping to 7.7.7.7, which is R7 on the bottom left-hand side, and source it from loopback 0.

19:46And we have full connectivity because we're doing mutual redistribution. Oh, and also, before we go, let's do a real quick show IP route, and let's pick on 7.7.7.7. And look at that. This tag, we added that during the redistribution. So the key is, during redistribution, we have a lot of control as far as what the metrics are going to be for those redistricted routes, what rules we're going to bring in or not bring in, including using a route map to control that, what gets in and what doesn't get in. We can control tagging, the type of metric we're using based on the routing protocol.

20:16So if you were watching this on a mobile device, I would encourage you to schedule a little bit of time to go on a computer to the CBT Nuggets website, click on the link for the virtual lab, and practice these yourself. Because the more you practice hands-on with the redistribution, the more opportunities you'll have to both be able to configure it and troubleshoot it in a production environment should the need arise. So I'll see you in the next video. Meanwhile, I hope this has been informative for you, and I'd like to thank you for viewing.

0:04Imagine if we had two different paths that we could take to go to a theater, or to dinner, or whatever it is. And on these two paths, we'd get notified that, oh, this path is going to take 10 minutes, and this path is going to take an hour. We are going to avoid the path that takes an hour. Now, we can influence a router to think a path is really bad by increasing the metric using a method called an offset list, which is what we're going to both implement and verify in this hands-on lab. So here's our game plan. Let's toss in eigrp on this topology.

0:36And then we'll take a look at some routes from R8. And we'll see-- we'll pick a route. Pick a route, any route. And we'll identify which path that R8 is using to get to that network-- whether it's choosing door number one, door number two, or door number three. And then we can take that preferred path, and what we can do is create an offset list. And here's how an offset list works. We can say, Dear Mr. Router 8, when you receive-- and we can actually identify a single route or a list of routes by using an access control list to point to the exact routes that we want to manipulate the offset for, the metric for, or we can use 0.

1:11So if you 0 instead of an actual access control list, it'll say, OK, that means all routes. And then, we can also associate with an interface. So if-- let's just say for a moment that 3 slash 2 is the preferred path to get to a network. We can specify in eigrp that we're going to use an offset list. We can increase the metric by, say, 100 million. Well, we could also look at the topology table and see what we would have to be worse than for another route to be used and simply increase it. So the offset list increases the metric by whatever value we specify, and that can thereby influence the router to no longer take that path that takes like an hour.

1:50It's going to use a faster path or a quicker path. But that's yet another tool. So let's do this. In the lab environment, click on the link for the virtual lab. We'll implement eigrp on this topology. That will take just a few moments. And then we'll identify the best path R8's taking. And then we'll manipulate that with an offset list locally on R8. And for eigrp everywhere, it's just config t. Router eigrp. We'll use autonomous system one. And also, we have other videos on name mode and numbered mode for eigrp, so enjoy those videos as well.

2:21And we'll just dump everything in. So we'll do a Control-A to select all that, right-click, Copy, and then we'll just go ahead and plug it in on each of these routers-- just clicking on the tab, right-clicking to paste, and it is done. One thing about eigrp, man, is it's so darn fast. All right, so we have full connectivity right now. So iproute eigrp. It looks like we're using Serial3/2 a lot. Let's go ahead and pick 5.5.5.5. That'll be a nice one we can pick out and identify. So to get to 5.5.5.5, it's using Serial3/2.

2:53So if we look at our topology, that's right here. So for 5.5.5.5, it's going to use Serial3/2 as its egress interface. And let's go ahead, and we could do an access control list to specifically call out 5.5.5.5, or we could just say, hey, any routes that we [INAUDIBLE] in on Serial3/2, we want to increase the cost, set the offset to a greater number. Or we could say on Serial3/2, any updates we receive there, just go ahead and let's offset that metric by some number that'll make that path no longer desirable.

3:26And we can also verify that before we do it by looking at the eigrp topology table, which will be a good exercise, too, in this lab. So let's go to R8, and let's take a look at it. So here on R8, we'll do a show ip eigrp topology. [LAUGHS] All right, and let's go ahead and put in 5.5.5.5/32. So as we decode this for this specific route, there is our current metric, which is-- I'm going to put commas in here so I can read it-- it is 2,298,112, and that is this bad boy.

4:01So this is our successful route. There's the reported distance from our neighbor. And here is our feasible successor right here. Well, at the moment it's a feasible successor because the advertised distance is lower than the current feasible distance. So currently, it's a feasible successor. Great, and wow, look at this. [LAUGHS] Its current metric, its current distance to get to 555, is-- it's going to put the commas in here-- is 40,672,000. 40 million versus 2 million-- holy schneikers.

4:35The reason I point that out is because when we do the offset, we need to grow it by about 2 million versus 40. So if we grow it by 38 million, will that be enough? Actually, let's just grow it by 39 million. All right, so what we'll do is we'll set offset. We'll create an offset list, and we'll increase the metric by 39 million. So it's going to make this route, this path, look worse than this guy.

5:08And this guy will take over as the successor route. All right, I wouldn't have guessed it was going to be that high, but I'm glad that we looked. Also, it's a great way to help troubleshoot by looking at the details of the metrics involved. All right, let's go ahead and do it. So here on R8, let's config t. Instead of using an access control list to say which specific network, I'm going to go ahead and say all networks coming in on interface Serial3/2 right there. All right, so we'll go and do a router, eigrp, autonomous-system 1, and press Enter.

5:42And then we'll do an offset list. And this is where we can specify an ACL to identify which routes are going to have this offset. I'm going to use a 0, which is a shortcut for Select All Networks and it says right here. And then we'll go ahead and put it in our offset. So this is going to be for traffic or updates that are coming in, and we're going to specify the offset of, what did we say 39 million, 39? 1, 2, 3, 1, 2, 3. All right, and that should do. [LAUGHS] We have an update here.

6:13We have our eigrp neighbors, which is fine. And let's scroll up to find the original route. So we're looking at 5.5.5.5. This is before. It was using Serial3/2. But now that metric of 2,298,000 is no longer going to be that, because we bumped it up by like 39 million. And so if we do, if we hit the Up Arrow key a couple of times and do a Show IP Route for eigrp, and we look at the 5.5.5 network again, and-- oh, my gosh.

6:46[LAUGHS] It's still using Serial3/2. That's because I did not-- I said, hey! That's why we had the neighborship messages with all of our neighbors. So basically, I increased by 39 million every single update coming in. I need to go correct that, because this is not the results that we wanted. So we'll do a config t router eigrp, autonomous-system 1. Hit the Up arrow key a few times. We'll do a Control-A and say no, offset list 0. Then we'll go ahead and do that command again. But this time, we will include the interface, which is going to be serial 3-- and then let me get the right interface here.

7:21Let me go back here for a moment, our drawing. It's going to be 3/2. So only the updates coming in on 3/2 will have that offset applied. And let's go ahead, and 3/2-- all right. So Serial3/2 is not going to be too preferred anymore. Let's show IP route, and let's go ahead and do for-- this [INAUDIBLE] show IP route eigrp. And let's look for the five network. And there we go. There's the five network. It's now using egress interface of FastEthernet 4/1 with an [INAUDIBLE] of 0.6 because the other route looks terrible.

7:56So we can verify that with a show IP eigrp topology. And there it is right there. It shows us that we have a successor, and there's this metric, and that's out 4/1. [LAUGHS] And here is 3/1, which is a feasible successor because the advertised distance is less than the actual current successor cost. And [LAUGHS] our route through 3/2 is not even showing up anymore. Let's do this. Let's do a show eigrp topology, and let's do an All Links option and press Enter.

8:29Now let's look for 5.5.5.5 again. So there it is. Even though it's not a feasible successor anymore, now, with the All Links option, it's going to show up right there. So there's our winner, there is our feasible successor, and there is the route that we just toasted based on setting the offset so stinking high for that interface. Another command, while we're here, is a show eigrp topology. This is a cool one, too. And that is 0-- 0 successors. Show me the eigrp topology database where there's no winning eigrp route.

9:03And here we go. These two networks, 10.38.0.1, and also 10.78.0.8. And it says the FD is infinity. Well, the metric right here, it doesn't look like infinite to me. It looks like a really large number, like 41 million or whatever. But what happens here is that if we have a route with a better AD, like a directly connected network with an AD of 0, they're going to beat out these routes. And that's what's happening. So this is on R8. It is directly connected to the 10.38.0 network. It's also directly connected to the 10.78.0 network.

9:35And that's why these routes, with the FD as infinity, they are not successor routes. There's no successor route from the eigrp because their AD isn't good enough to compete with the directly connected network, which has an AD of 0. So in this video, we've had some fun with playing with another tool that we can use to manipulate routing, and that is the concept of an offset list. We can apply it to an interface. We can include whether or not it's inbound or outbound when we modify the offset. We can also specify with an access control list which routes it would apply to, specifically regarding that offset.

10:07Thank you for joining me in this video regarding offset lists in a Cisco environment, and I'll see you in the next video. Meanwhile, I hope this has been informative for you, and I'd like to thank you for viewing.

0:04If we're doing redistribution, and we want to do like four or five different things to a specific route, like maybe set the metric type or the metric itself or tag it, instead of doing all those individually, we can also use the method of route map. So in this video and hands on lab, I'd like to walk you through a scenario of what we'd like to do. We'd include all those details inside of a route map and then attach that route map to the redistribution to see it all happen. Let's take a look at our topology. And for the demonstration for the lab, let's just do redistribution from EIGRP, including the 78 network and the 38 network and so forth into OSPF.

0:39But instead of specifying all the details for the metric and the metric type, what we could do during the redistribution is call upon a route map. In that route map, we could match on one or more of our routes with a match statement, and then based on it matching, we could go ahead and do set. We could set things like a tag. We could set things like the metric type. We can set things like the actual metric that those rules will get as they're brought into OSPF, and for routers one and two, we'll just bring all the routes in for OSPF.

1:13So router OSPF 1, and then we'll do a network in area 0. So that last set of four zeros right there, that'll be flipped to 255s as a wildcard mask. This is a quicker way of implementing it, and we'll do that on R1 and R2. So we'll copy all that, right-click copy, and then we'll go ahead and go to R1, paste it in, R2, paste it in. And let's take a look at R3 and 4. Now, R3 and 4, we don't want everything brought in. But R3 and R4, we want 10.0 dot anything.

1:44So we'll go ahead and implement that with a 0.0.255.255. And that'll be great for R3 and R4. Also, on R3 and R4, we'll need EIGRP, so let's also add that right here, the router EIGRP, autonomous system one, and we'll do network 10.1 and also network 10.2, and that'll be appropriate for R3 and R4. That's great.

2:15We'll do a control A. Oh, also, you know what? For R3's benefit, we'll need network 10.38 as well. That's the link from R3 that goes down to R8. All right. And we'll do a control A, grab all that, right-click, copy, and we'll get R3, paste it in, R4, paste it in. And then let's do the rest of the routers, 5, 6, 7, 8 with all EIGRP on everything. So we'll go to config t, and we'll do router EIGRP, autonomous system one, net zero, zero, zero, zero, and we're done.

2:54That'll be on routers 5, 6, 7, and 8. So copy that and then router 5, router 6, router 7, and router 8. Then we could spot check the interfaces, as well. So if we go to R3, and let's take a look at our topology together. So on R3, you should have gig 10 and FA 4/0 in OSPF. Those are 10.0 networks. And FA 4/1 should be in EIGRP. Let's verify that real quick, as well. So here on router 3, we'll just show IP OSPF interface brief.

3:25And sure enough, we have 0. 0, which was in our topology, but 10 and FA 4/0 all running OSPF, show IP EIGRP interface. And that should be FA 4/1 and 3/2. And that is FA 4/1 and 3/2. Let's take a look at my topology again. Oh, yeah. 3/2 goes down to R8, and that is in EIGRP, as well. Fantastic. All right. So let's see if we have any route maps to begin. We'll do show route map. Great. No route map, so we'll go ahead and create one, and I'm going to use all caps here.

3:57So let's go ahead and call it EIGRP number 2 OSPF. So that's the name or route map. Now, in the route map, if we just pressed enter, this route map sequence would be given a sequence number automatically, and it'd also be a permit. But if you want to be explicit, we could go ahead and explicitly put both the permit, as well as the sequence number right here, which is what I'm going to do. I'm going to say permit, and then I'll go ahead and say sequence number 10 and a question mark, and we'll press enter. So we're now in sequence number 10, and now we have to do our if-then.

4:29And let's start-- Oh, you know what? Let's go out just for a moment. Let's create an access control list that points to the 7777 32-bit route, so access-- because we're going to need to point to that. So access list one, and we'll say permit, and we'll say 7.7.7.7 with a 32-bit mask. Awesome. Now that exists, I'm going to go back into that exact sequence number of this route map. So route map, the name, and then permit, sequence 10. We're right back in that sequence number.

5:01So now I'm going to do a match. And we'll do a match. There's lots of things that we can match on, including a lot of attributes based on the protocol that we're using. In this case, we're going to match on IP and address, and we are going to match on axis list number one. That's the one we just created that's looking for the exact 32-bit route 7.7.7.7. We'll put one here, space, and a question mark. Now this is where, if we had four or five access lists, we can specify access list one, access list nine, access list 20.

5:33And if they're all in the same line, It's an or. So any one of those access list being matched as a yes, this matches, that line would be considered true. So in this case, we're going to match for just one access list, access list one, and let's also-- let's match and a question mark, and let's do route type, and let's specify internal. And we'll press enter. So now we do a do show route map.

6:04Let's see we have so far. We've got a route map called EIGRP to OSPF. We have one sequence number so far, 10. In that sequence, we're matching an IP address, matching access list one,s and also matching on route type internal. Now because those match statements are in two different lines, they both have to be true in order for this set, which we're about to put in, to go ahead and take place. So on multiple lines, all those conditions in the matches on multiple lines have to have one true element on each of the lines or the whole result of that sequence to be considered true.

6:37So let's continue. Let's go ahead and, based on those two conditions being true, let's do a set and a question mark. [LAUGHS] And there's lots of options that we can set here. Let's go ahead and set the metric, and we'll set the initial seed metric to 30 based on this route map being activated and matching, and let's also do a set metric type of type one, which is the external type one once it gets into OSPF. That is the metric type that will continue to grow as that route is propagated and advertised further and further away, as opposed to a type two for OSPF, which just stays fixed.

7:11OK. So let's do show command again, do show route map, and let's see what we have. So if the route matches access list one, which is the 7.7.7.7 network, and if it's an internal route, we're going to go ahead, and we are going to set the metric to 30. We are going to set the metric type to type one, and, hey, while we're at it, let's also set a tag. Let's set the tag to 90, which is the AD for EIGRP for internal routes. But if we want to look for that tag, it'll show up in OSPF with any routes that have been brought in, and we'll press enter.

7:44Now, one other thing here is with a route map, is that this route map has one sequence number that's a permit. So what's going to happen if we apply this route map as part of our redistribution from EIGRP going into OSPF, it's going to go down to sequence 10. It's going to say, OK. Match. It's going to look for the route of 7.7.7.7, and that it's an internal route, and then it's going to set those parameters, the metric, the metric type, and also the tag. And any route that isn't 7.7.7.7 and isn't internal, both those things, it will go ahead and deny.

8:18So it's sort of like an access control list used for filtering on an interface in the sense that it's going to process the sequence numbers from top to bottom, like lines top to bottom, and if it doesn't find the match, it just says, sorry, it's not happening. So with this by itself, the only route that is going to be redistributed into OSPF is going to bee the 7.7.7.7 network because everything else is denied. So let's verify that that happens, and then we'll go back, and we'll tweak the route map to have it be a little bit more lenient with the sequence number 20. So now we have the route map, let's apply it. So we'll go into router OSPF 1, and then we're going to redistribute EIGRP routes into OSPF and tag on that route map, so the syntax would be redistribute, and we're pulling in EIGRP from autonomous system one, and we'll use a question mark.

9:05And we're going to include subnets, yes, and here's where we can also specify the route map. So we'll do a route map, and then the name of our route map-- I'm going to scroll up a little bit so I don't do a typo. It's right here. So let's highlight that and paste it in, space, and so the metric and the metric type and the tag are all going to be done in the route map. It's like pre-baked, ready to go, and we'll press enter. Now, how do we verify that? How do we troubleshoot this? If we're having trouble with the redistribution not happening the way we think it should, I would first check the route map.

9:39Show route map, and take a look at what we're looking for based on the matches and the sets. Also we'll do a show IP OSPF, and that's going to show us details, including redistributing external routes from the EIGRP one. Fantastic. So we're doing the redistribution. So if we go up to R1, whose up in OSPF land, so here's the topology. Now, we did the redistribution here on R3. Let's go to R1 and take a look at the routes. If we did it correctly, all we should have is, as far as an external OSPF route perspective, is one route.

10:16And that is 7.7.7.7 that was redistributed in and including the attributes the route map set for it. So let's go ahead and go to R1 right here. Let's do a show IP route and press enter. And there it is, but, whaoa, we have more route. Hmm. Did I not call on the ACL? Let's go take a look at that. So there's these 7.7.7.7 network. There's the route itself, and if we did a show IP route for 7.7.7.7.

10:50We should have details, including the tag, so it's there, but so are other routes. So let's go back and check our route map, do show route map. And this says access list one. Let's go take a look at it and type, internal, and let's take a look at the access list. Oh, permit any. [LAUGHS] A little too lenient. I don't remember doing that, but I'm sure I did, so troubleshooting route maps, which is part of our objective here, is to make sure the individual components are correct.

11:27So let's fix that. I'm not sure how I did that. We'll do a no access list one and then access list one, and we'll permit, and we'll do 7.7.7.7. We can also put a host in front of there, but by default, it's going to think that's a 32-bit match. Do show access list. OK. And let's do this, too. Let's do a clear IP route, asterisk, nice fresh start for everything. And let's go back up to R1, who a moment ago was getting all these external routes, all these EIGRP routes because the access control list said, everything's good.

12:07But now we do a show IP route, and I'll do a show IP route for everything. Now it's much better. We have one route. That's the 7.7.7.7, and it is an external type one, and it has all those attributes that we set on that route in the actual route map. But one other thing we can do is this. If we went back to the route map, show-- on the right router. Let's go back to R3 and do a show route map. So there it is. If we wanted to add another sequence number, we could-- anything that didn't match sequence 10, which is the internal type and the specific IP address specified by the access control list, we could go ahead, for all the other routes that didn't match sequence 10, we could put another entry in and have a whole other set of matching requirements and then set requirements.

12:57So let's modify that a little bit. We'll do config t and route map, and we'll put in the same name here. Now, by default, if I don't do anything else, it'll be a permit. It'll also auto sequence it for me. It'll give me a sequence line, probably of 20, so we'll do a do show route map. Always verify what we think happened. So I don't see another sequence number there. Hmm. Let me go ahead and do a show route map again, and look at that. All right.

13:27Well, that's good know. I'm glad I checked. So I'm going to go ahead and write that again, route map EIGRP to OSPF. I'll say permit explicitly, and I'm going to give it sequence number 20. And now we'll do a show route map. There we go. So there's our sequence 20. Now, sequence 20 has no match conditions in it whatsoever. What that means, if there's no match, it simply says, great. Everything matches, and there's no considerations as far as qualifying for a match in that sequence. So if we wanted to bring in all the routes from EIGRP, the first sequence number would get internal routes that match the ACL and do the metric type and everything else that's specified.

14:06And then the rest that didn't match that would hit sequence 20, match there, and then just be brought in as normal. What we could do, though-- let's do a set, and let's do a set tag of-- let's do a set tag of 333, and that way, what we should see is that the network 7.7.7.7 will have the tag of 90 and all the rest of the EIGRP routes that were brought in, because the sequence 20 that doesn't have a match condition, would automatically get the tag of 3.3.3.3. So let's go back up to R1, and on R1, let's do a show IP route, and here we have a whole bunch of additional routes, but by default, it brought him in as an external type two because we didn't specify.

14:48And if we did a show IP route for one of those specific routes, there's our tag of 3.3.3.3. So in this video, we've taken a look at an example on the syntax and logic of a route map that can have a whole bunch of pre-baked if-then statements, there are match and set statements, and then we can include those route maps as part of our redistribution to control what we want to come in, how we want it to be marked, which gives us the ability to control those attributes when those routes are being redistributed. So thanks for joining me in this video and lab, and I'll see you in the next video.

15:19Meanwhile, I hope this has been informative for you, and I'd like to thank you for viewing.

0:05There are situations where the default for a given routing protocol are going to help protect us, so that we don't even need to get creative with modifying the administrative distance, or filtering routes, or tagging routes, or looking for that tag. So in this video, I'd like to chat with you about some of those defaults that are really going to help us right out of the gate. Also, remind us of a few of the tools we can use regarding tagging and filtering, and also touch on the concept of split horizon, which in some situations can bite us as well. So let's take a look at the topology, and let's review those concepts together.

0:36So let's imagine we have routing domain A right here, and routing domain, including this network, B. And then-- or let me include him here also. And then routing domain C right here. One of the key things when [CHUCKLES] first of all, designing a network, is, you'd never want to design a network intentionally this way, where you'd have to do redistribution. It'd be much easier and simpler to run one routing domain. Let's start there. But as far as redistribution goes, if we have routes like the 12 network in routing domain A, and we're redistributing that into routing domain B, and then B is redistributing into routing domain C, what we'd want to do is make sure that we're not redistributing that route, the 12 route, back into routing domain A.

1:23Or a network in routing domain B to get put into C, we want to make sure that it doesn't get redistributed back into B. So we have AD that we can play with. Like in a GRP, the administrative distance for internal is a better AD than it is for externals. It's 90 and 170. But we can also manipulate the administrative distance for a given routing protocol on a specific router, and we say, hey, dear Mr. R6, you're going to believe that the administrative distance for OSPF is 89, and make it better or more believable. So that's a fairly graceful solution.

1:55But we could also-- if we needed to, we could also do tagging, and you could do tagging on the redistribution with or without a route map. And so you could tag all the routes that were redistributed, and then identify those with another route map before you redistribute it again. So that way, we can control, on redistribution for the match, what can be redistributed. We can look for or deny a certain tag, and that can also control whether or not a route will be redistributed. Along with that route map, of course, we can set the attributes appropriate for that routing protocol as well. So tagging is certainly an option that we can use, or bringing a route in, tagging it, and we can look for that tag later, and give that specific route either another redistribution or no redistribution, based on the tags that it has.

2:36That does take a little bit more planning, [CHUCKLES] but it is certainly doable, as far as routes that are going to be redistributed in, and then also as we redistribute them, what tag they are going to be given. Also, a really good key is to focus on one network at a time. So if we have the 12 network, for example, up here, or the 78 network, it's important to follow that network's progress through the network. And so as you do your redistribution, and if you identify, whoa, that route 78 is not showing up here at all, then we can identify why. OK, R4 is doing redistribution from B to A. That route got into B. Why isn't it picking up?

3:11And each routing protocol behaves a little bit differently based on the types of route, and did that route get into the routing table. And that's why some hands-on practice in doing the redistribution, looking at the results, and then having tools like offset lists, and distribute lists, and route maps, can be very helpful in controlling the traffic. Because at the end of the day, we want optimal paths through the network, and if the routing protocol or a bunch of routing protocols that are glued together with redistribution is not causing that to happen, that's when you start going in and adding additional techniques, and go ahead and make certain routes appear better than other routes, or doing additional filtering so that optimal paths are taken in the network.

3:51And if we simply need to make a route look worse, we could use a condition called route poisoning. And poisoning, from a general concept, is making it look worse. So we did that with offset lists, and with the offset list on R8, I believe we attached it to serial 3/2, so that any routes that were being learned on that interface would automatically have an additional offset or made to look worse, and that is a form of poisoning. There is also situations, like in DMVPN, if we are using Dynamic Multipoint VPN-- which we have another set of videos here in this course on-- but with DMVPN, we have a hub and we have spokes.

4:28Here's spoke 1 and spoke 2. And because we're coming into a single multipoint interface, split horizon, which is built in to the route-- like RIP has it, and GRP has it on by default. If router 1 advertises the route and it comes in on this interface, split horizon says, "Oh, I'm not going to advertise the route out on the same interface I learned it on." So it doesn't send it down here. However, in DMVPN, we need to turn off that feature. So that's in the DMVPN videos, where we go to that interface, and tell it not to use split horizon, because we do want a route that's advertised by spoke 1, that goes up to the hub, to be advertised back out that same logical multipoint tunnel interface, and be sent down to the [CHUCKLES] site 2, right there, so it can actually learn the route.

5:12So it's important to realize some of those behaviors and the defaults for the various routing protocols so that when we're implementing them, and our routes don't show up like we expect them to, we can go ahead and correct it by tweaking those defaults, in this case, by tweaking the split horizon rule on the multipoint interface at the hub. And well, another one to think about, one other trick that we can do with administrative distances, if we have some routes up here in this routing domain A, and we've got some from EIGRP which are external, and we have others that are EIGRP internal, by default, the administrative distance is going to be 170 for the external and 90 for the internal.

5:51And if we want to change those, we can. [CHUCKLES] We can manipulate the administrative distance for all external EIGRP-learned routes, or for a specific route, or we can change the administrative distance for a specific route learned from a specific neighbor. So we have an administrative distance that we can tweak. This is an EIGRP example. But that is yet another way to choose which route would be used when there's multiple routes presented, simply by going in and specifying, hey, this administrative distance is going to be 70 or 60. And that will make that route show up in the routing table, and then start to be used if we need it to be used, for optional padding in our network.

6:27So in this set of videos, we've had the opportunity to add some additional tools to our tool belt as far as manipulating and controlling routing behavior on a Cisco device. So I'm glad you joined me. I'll see you in the next video. Meanwhile, I hope this has been informative for you, and I'd like to thank you for viewing.