WEBVTT 00:00:00.000 --> 00:00:09.960 So let's dive into a discussion on policy-based routing. PBR for short. Policy-based routing. How 00:00:09.960 --> 00:00:15.640 many of you are doing policy-based routing? Anybody here? Anybody using policy-based routing at all? 00:00:15.640 --> 00:00:24.120 And if you are, what's the reason for you using policy-based routing? Because the whole purpose 00:00:24.120 --> 00:00:32.520 of policy-based routing is to override the default behavior of our routers. That's right. 00:00:33.799 --> 00:00:38.360 So in order to fully understand policy-based routing, we have to understand what the default 00:00:38.919 --> 00:00:46.439 behavior is of our routers. The default behavior of our router is to do what? Forward based on 00:00:47.000 --> 00:00:56.840 the destination IP address. Forward based on the destination IP address. So a packet comes in, 00:00:56.840 --> 00:01:02.360 we look at the destination IP address, we find the entry in the routing table that matches, 00:01:02.360 --> 00:01:06.199 and then we send it out the exiting interface associated with that. 00:01:07.879 --> 00:01:15.879 So policy-based routing means that we get to forward based on policies that we have defined. 00:01:17.080 --> 00:01:23.720 Meaning we don't, we get to override the default behavior of the routing table, 00:01:23.720 --> 00:01:30.279 or the default behavior of the router. So instead of forwarding based on just the destination IP 00:01:30.279 --> 00:01:37.559 address, I can forward based on anything I want. Well, sort of. I can forward based on anything 00:01:37.559 --> 00:01:46.919 I can define in an access control list. So for example, I could forward based on the source IP. 00:01:47.480 --> 00:01:53.400 So if the traffic matches this source IP address, then forward it this way. But wait, 00:01:53.400 --> 00:01:57.320 the routing table says that way. It doesn't matter. I say based on the policy-based routing 00:01:57.320 --> 00:02:03.320 to go that way. So my router has to do that. What if the source or destination port is a 00:02:03.320 --> 00:02:09.000 certain value or a range of values? I can forward based on that if I want to. Protocols, 00:02:09.559 --> 00:02:12.440 quality of service markings, and a whole lot more. 00:02:18.119 --> 00:02:25.399 So this is going to be used anytime you want to influence a certain set of traffic to go a 00:02:25.399 --> 00:02:30.279 certain way, which is different than what the normal traffic in your environment would follow. 00:02:30.839 --> 00:02:35.639 So essentially, let's say that all traffic in your environment took a certain path, 00:02:36.600 --> 00:02:40.279 but you wanted to make sure management traffic took a different path. 00:02:40.279 --> 00:02:43.000 Well, you could use policy-based routing for that management traffic. 00:02:46.759 --> 00:02:50.119 So that way there, if it comes from this management IP addressing space, 00:02:50.119 --> 00:02:53.880 and it's related to this type of management traffic using these port numbers and protocols 00:02:53.880 --> 00:02:59.000 and whatever, then I want my router to route it this way instead of using the normal 00:02:59.960 --> 00:03:06.759 behavior of the routing table. So to create or to implement policy-based routing, 00:03:07.559 --> 00:03:13.479 one, we need access control lists for identification purposes. We then need route 00:03:13.479 --> 00:03:21.399 maps to define what happens. So match these access control list entries and then set 00:03:21.479 --> 00:03:24.759 the next hop IP address to a certain value. 00:03:28.119 --> 00:03:30.199 So that way there, I can route it a different way. 00:03:32.119 --> 00:03:38.600 And then we can apply it either to our interfaces, and we always apply policy-based routing 00:03:38.600 --> 00:03:43.320 on the inbound interface. What does that mean? It means that if I have a router 00:03:44.119 --> 00:03:50.279 and traffic is flowing this way, I have to apply it to the interface when the traffic comes in. 00:03:51.080 --> 00:03:56.839 I can't apply to the interface that traffic is leaving because by then it's too late. 00:03:58.520 --> 00:04:01.639 Because by that point, we'd have already routed and it's over. 00:04:02.360 --> 00:04:08.039 Whereas we want to policy-based route before the routing table is checked. 00:04:10.600 --> 00:04:16.359 So you apply it on the inbound interface for the arriving packets. So you go to the interface and 00:04:16.359 --> 00:04:24.200 use the IP policy route map command. It's that simple. We can also perform policy-based routing 00:04:24.200 --> 00:04:31.480 on the control plate. Now, what is a control plate? It's a virtual interface on your router 00:04:32.040 --> 00:04:37.399 that controls the traffic that is being punted to the CPU. 00:04:38.359 --> 00:04:41.559 In session number eight, we're going to talk about control plane policing 00:04:42.839 --> 00:04:54.440 as a way that we can protect our control plane. So, what we have here is we have a virtual interface 00:05:00.519 --> 00:05:02.600 called the control plane interface. 00:05:03.559 --> 00:05:11.559 And any control traffic gets punted to the control plane. So, with policy-based routing, 00:05:15.079 --> 00:05:17.559 we could apply 00:05:23.880 --> 00:05:28.760 policy-based routing to that control plane interface. There it is. 00:05:33.480 --> 00:05:39.959 That would be for traffic generated by the router. So, in that case, instead of it applying to the 00:05:39.959 --> 00:05:49.320 traffic that is being punted, it's for the traffic that is being sent out of the control plane 00:05:49.320 --> 00:05:55.160 interface. Pardon me. I misspoke when I did that diagram drawing. Let's go back to that just to 00:05:55.160 --> 00:05:59.799 make sure we've got that clear. So, when we get to control plane policing, we'll show you how to 00:06:00.760 --> 00:06:08.119 protect the packets that are being punted, right? But in this case, we're protecting, so virtual, 00:06:08.119 --> 00:06:13.959 virtual interface. With control plane policing, we're going to protect traffic being punted this 00:06:13.959 --> 00:06:20.440 way. But with our policy-based routing, I'm going to be able to control which way it goes, 00:06:20.440 --> 00:06:24.839 whether it's this way or this way, as it leaves that interface, so traffic that is generated by 00:06:24.839 --> 00:06:29.239 the router. So, if I generate a ping packet on the router, then what will happen is that that 00:06:29.239 --> 00:06:36.519 traffic is leaving that virtual interface, then when it decides how to route it, it's the policy 00:06:36.519 --> 00:06:42.440 that will be applied for routing as opposed to the routing table. So, for example, when you ping from 00:06:42.440 --> 00:06:49.320 the router, the exiting interface based on the routing table information is what's going to be 00:06:49.320 --> 00:06:57.079 used. But if I policy-based route, then I can basically choose what interface I want to use 00:06:57.640 --> 00:07:03.320 in order to send that traffic based on the next hop IP address. So, that's what we're doing here 00:07:03.320 --> 00:07:09.160 in both these scenarios. So, as traffic's arriving inbound, I can tell my router to route that 00:07:09.160 --> 00:07:13.079 traffic a certain way without using the routing table. And then for packets that are generated 00:07:13.079 --> 00:07:16.359 by the router, it doesn't matter whether it's OSPF or BGP packets or ping packets or trace 00:07:16.359 --> 00:07:22.279 telnet pass, anything like that, I can control which interface they leave. SNMP packets, I can 00:07:22.279 --> 00:07:28.200 control NTP packets. You can control anything that is locally generated by the router and control 00:07:28.200 --> 00:07:32.600 which interface it goes out of. Why? Because anything you can imagine in ACL is what can be 00:07:32.600 --> 00:07:38.119 used here. All right. So, what are we going to do here? We are going to do a little silly, little 00:07:38.119 --> 00:07:43.480 tiny scenario. That's what we're going to do. And this scenario is going to be based on the fact 00:07:44.119 --> 00:07:55.880 that we are going to have traffic that starts here. It's going to end up getting to R2. 00:08:03.880 --> 00:08:11.480 And then that traffic normally goes like this up to the internet. 00:08:14.440 --> 00:08:32.599 So, in order for us to test this, let's go to our PC and let's see if our PC is even able to 00:08:32.599 --> 00:08:37.080 get to those networks right now because we've done a lot of crazy stuff. Oh, and by the way, 00:08:37.080 --> 00:08:41.479 I have removed BGP on all my routers. So, BGP is not even running anymore. So, 00:08:41.479 --> 00:08:47.320 that way we don't end up with BGP right now because we've done so much with BGP, it's a mess. 00:08:47.320 --> 00:08:51.479 So, I just got rid of BGP on all the routers. And so, right now, what do we have? We essentially 00:08:51.479 --> 00:08:58.520 have just OSPF running like this. So, this is all OSPF. And this is going to be our default 00:08:58.520 --> 00:09:03.960 routing out to the internet. So, our internet's here. And we're not running BGP anymore. So, 00:09:03.960 --> 00:09:08.919 let's do a trace to 8.8.8.8 and just see which way it's going. 00:09:22.440 --> 00:09:29.080 So, it looks like it followed this path. Looks like it followed that path perfectly. 00:09:29.960 --> 00:09:32.599 What about the other option that I want to do a test with? 00:09:34.520 --> 00:09:42.520 So, 00:09:53.080 --> 00:09:57.320 wait a second. No, it didn't. I'm looking at that right now knowing, wait a second. No, no. The 00:09:57.320 --> 00:10:02.840 first one actually went this way, folks. The first one actually went this way. 00:10:03.719 --> 00:10:08.039 The second one went this way. That's what happened to us right there. 00:10:11.479 --> 00:10:16.919 And the reason why is because right now we're learning about the default route from R1 00:10:17.559 --> 00:10:23.239 from our OSPF environment that we created a while back. So, in order for me to do my 00:10:23.239 --> 00:10:28.039 demonstration that I want to do, we got to get that out of here. I want everything to be going 00:10:28.039 --> 00:10:33.719 through R2 right now just for this discussion. So, let's do do show IP route. You'll see we're 00:10:33.719 --> 00:10:40.520 load balancing. Yep, there you go. We're load balancing. So, that's why 23.1 was actually R1. 00:10:40.520 --> 00:10:48.599 So, anyway, I was looking at the output of PC1. That's R1. That's R1. That one's R2. So, 00:10:48.679 --> 00:10:56.599 let's go ahead and just simply go to R1 and remove the default information originate 00:10:56.599 --> 00:10:59.719 command right now. So, I don't want that interfering with my demo. 00:11:08.440 --> 00:11:11.960 So, now that I've removed that, we should see that DSW1 only has one way to go. 00:11:12.919 --> 00:11:20.119 And now if we trace route on my client, both of them should be going to R2. And that's what I want 00:11:20.119 --> 00:11:23.799 for this demonstration right now. I mean, there's other ways we could have manipulated this, other 00:11:23.799 --> 00:11:29.080 things we could have done. But for right now, just to keep things simple, we'll just do it this way 00:11:29.080 --> 00:11:34.039 to make sure that we have the traffic going towards R2 for both of them. All right, good. 00:11:34.440 --> 00:11:41.000 So, now we're set up for the demonstration. Let's go ahead and policy-based route 00:11:43.159 --> 00:11:47.400 this traffic here. So, all the traffic going to 8.8.8.8. 00:11:49.400 --> 00:11:54.440 What I want to do is I want to force it to instead, and we're just going to force it to go this way. 00:11:57.320 --> 00:12:00.760 Now, I don't have a connection here right now. That's okay. 00:12:00.760 --> 00:12:05.159 The goal is to see how it's being forced to go that way. Even though it's not going to be 00:12:05.159 --> 00:12:11.400 successful at reaching the destination, the goal is, hey, as long as we policy-based route, 00:12:11.400 --> 00:12:16.520 our demo is exactly as we wanted it to be, just to show you the difference in traffic, 00:12:16.520 --> 00:12:20.840 how we can manipulate it. So, let's go to R2 right now. 00:12:25.239 --> 00:12:30.039 And over on R2, the first thing we're going to have to do is indicate the type of traffic that 00:12:30.039 --> 00:12:36.599 we want to match in this case. So, it's going to be all traffic coming from our PC at 10.0.0.10 00:12:37.159 --> 00:12:51.799 going to 8.8.8.8. So, we're going to type in IP access list. Oops. IP access list. There we go. 00:12:53.080 --> 00:12:58.200 We'll do an extended access control list. We'll call it access control list for our 00:12:58.200 --> 00:13:05.080 policy-based routing discussion. Now, what we're going to do is we're going to match, 00:13:05.080 --> 00:13:11.719 so we're going to permit, because we want to match the traffic that is ICMP-based. 00:13:11.719 --> 00:13:21.880 So, I'm pretty sure if I recall correctly, trace route traffic from a Windows PC is using ICMP and 00:13:21.880 --> 00:13:31.640 not UDP. So, ICMP coming from 10. or host, so specifically host, 10.0.0. let's say 10, 00:13:32.440 --> 00:13:39.159 going to host 8.8.8.8. So, that way there, in my example, I'm only affecting that very specific 00:13:39.159 --> 00:13:44.520 type of traffic from that source to that destination. If it's coming from any other 00:13:44.520 --> 00:13:47.640 source, it's not going to be affected. If it's going to any other destination, it's not going 00:13:47.640 --> 00:13:53.239 to be affected. That's just my goal in this particular example. So, just think about the 00:13:53.239 --> 00:14:00.200 fact that you could match TCP traffic related to port 443 and send it a certain way. You can match 00:14:00.200 --> 00:14:06.599 TCP traffic related to SSH and send it a different way. You could match what? You could match QoS 00:14:06.599 --> 00:14:11.960 markings in traffic and say, hey, if it's QoS 0, send it this way. If it's QoS 5, quality service 00:14:11.960 --> 00:14:17.559 marking of 5, let's say, then send it this way. You have so many different options because access 00:14:17.559 --> 00:14:22.840 control lists are so flexible, so versatile. So, whatever combination of ports and protocols and 00:14:22.840 --> 00:14:27.960 sources and destinations and QoS markings or anything else you can put in ACL, you can policy 00:14:27.960 --> 00:14:35.479 based route traffic based on that. Now, we need a route map because the route map is going to 00:14:35.479 --> 00:14:42.280 define what actually happens. So, we're going to create a route map. We'll call this our route 00:14:42.280 --> 00:14:48.679 map for policy based routing. And this is going to be a permit sequence because when it comes to 00:14:48.679 --> 00:14:57.799 our route maps for policy based routing, whenever you put a permit, it means I want this traffic to 00:14:57.799 --> 00:15:07.559 be policy based routed. That's what it means. Remember when we had our BGP discussion recently 00:15:07.559 --> 00:15:11.400 and I was showing you how to do route maps and I say, okay, permit because I want to 00:15:11.400 --> 00:15:18.760 learn this traffic, right? So, permit for that scenario meant I want to learn that traffic. 00:15:18.760 --> 00:15:22.520 I want to learn it from the neighbor or I want to share it with the neighbor. 00:15:23.400 --> 00:15:26.200 Whereas when I'm using a permit with policy based routing, it means I want to 00:15:27.000 --> 00:15:31.880 policy base the traffic that matches, right? So, what do I want to match? 00:15:31.880 --> 00:15:39.640 I want to match this access control list. So, IP address, ACL PBR. 00:15:43.479 --> 00:15:51.880 And then I want to do what? I want to set, in our case, I want to set the next top IP address this 00:15:51.880 --> 00:15:57.080 way. So, normally the next top IP address would be this way, but now we're going to make it go 00:15:57.080 --> 00:16:08.039 this way. So, set IP next top and we're going to put 10.45.33.2 as the next top IP address. 00:16:08.440 --> 00:16:15.400 Now, what about all the rest of the traffic? 00:16:17.000 --> 00:16:21.239 Well, you have to remember that when you create route maps, do show route hyphen map. 00:16:23.799 --> 00:16:27.719 How many do we have here? We have three different ones. So, let me clean this up so we can see just 00:16:27.719 --> 00:16:35.400 the one we want, route map underscore PBR. So, what I want you to realize is that when you create 00:16:36.200 --> 00:16:41.559 So, what I want you to realize is that there is another entry that you cannot see here. 00:16:42.440 --> 00:16:52.760 It's the implicit deny all. The implicit deny all. So, it's like sequence number infinity. 00:16:52.760 --> 00:16:59.159 Think of it that way. And the implicit deny all states for policy based routing, 00:17:00.039 --> 00:17:09.959 whatever matches, the deny sequence gets routed normally. Notice I didn't say dropped. 00:17:11.079 --> 00:17:19.160 Routed normally. So, what does that mean? It means sequence number 10 here matches this access 00:17:19.160 --> 00:17:25.959 control list. And if you match this access control list, you will be sent to the next top IP address 00:17:26.280 --> 00:17:38.280 this way. Everything else, all other traffic will match the invisible deny sequence. The implicit 00:17:38.280 --> 00:17:45.239 deny sequence that you can't see. And therefore, all the rest of the traffic gets automatically 00:17:45.800 --> 00:17:55.160 routed normally. How it works. Whereas with our BGP discussion, if I said deny, it means I would 00:17:55.160 --> 00:18:03.239 not learn that prefix, or I would not share that prefix that matched whatever was in that route 00:18:03.239 --> 00:18:11.640 map, deny sequence. So, you see how route maps would permit and deny me the access control list 00:18:11.959 --> 00:18:15.959 So, you see how route maps, what permit and deny means, 00:18:15.959 --> 00:18:20.280 is going to be highly dependent upon what you're using it for. 00:18:22.920 --> 00:18:27.160 And when it comes to redistribution, permit and deny means something different as well. Like permit 00:18:27.160 --> 00:18:32.280 means I want to redistribute this traffic, whereas deny means I don't want to redistribute. I said 00:18:32.280 --> 00:18:36.839 traffic, I meant route. So, permit means I want to redistribute this route, but deny means I do 00:18:36.839 --> 00:18:45.959 not want to redistribute this route. All that we get deeper into, because we'll look at all those 00:18:45.959 --> 00:18:54.359 scenarios in the advanced routing course called NRC for a 300-410 certification exam. And that 00:18:54.359 --> 00:18:58.280 route maps will be very, very important for that certification exam. If you can't read route maps 00:18:58.280 --> 00:19:11.560 or use route maps, you don't sit for that exam. So, now that we've created the route map, 00:19:12.680 --> 00:19:20.040 and we've created the ACL, now we need to apply it to our interface. So, in this case, we want 00:19:20.040 --> 00:19:28.439 to apply it to traffic coming in, gigabit 00 and gigabit 01, both of those interfaces inbound. 00:19:29.160 --> 00:19:36.199 So, we'll type in interface gigabit ethernet zero slash zero, and the command is IP 00:19:38.359 --> 00:19:44.199 policy route map, and then the name of our route map, route map PBR. 00:19:45.160 --> 00:19:50.280 And in this case, I don't even get to specify the directionality, because it's automatically 00:19:50.280 --> 00:19:57.400 applied inbound, no matter what. Then interface gigabit ethernet zero slash one, same command. 00:19:57.400 --> 00:20:04.040 So, it's applied to both those interfaces inbound now. So, let's go take a peek at our route map 00:20:04.040 --> 00:20:10.599 again, and now you'll see that our route map, did it change anything? Let me just double check that. 00:20:11.400 --> 00:20:17.239 Nope, it's the same in that case, but if we type in do show IP policy, 00:20:19.800 --> 00:20:24.359 there you go. You'll see that it tells us what interfaces the route map is applied to for the 00:20:24.359 --> 00:20:31.880 policy. Right now, what I want to do is I want to show you the actual 00:20:32.680 --> 00:20:40.040 routing with the policy, and the best way to do that is debug IP policy. So, that way we can see 00:20:40.040 --> 00:20:49.239 it in action. All right, so let's go to our PC right now, and if we go to our PC, let's trace 00:20:49.239 --> 00:20:51.560 route one, two, three, one, two, three, one, two, three, one, two, three. Now, based on our 00:20:51.560 --> 00:20:57.160 configuration, folks, is that going to be routed normally, or is it going to be policy-based 00:20:57.959 --> 00:21:02.359 routed, based on what we just configured? Do you remember? Is that going to be routed normally, 00:21:03.239 --> 00:21:08.359 or policy-based routed? Well, if you remember our access control list, 00:21:08.359 --> 00:21:16.839 the access control list was matching a destination of 8888. So, that was the only one that would be 00:21:16.839 --> 00:21:23.160 policy-based routed. So, this one, yes, Conrad, routed normally. Great job. So, let's go ahead 00:21:23.640 --> 00:21:30.520 and hit enter here, and what we're going to see, when we go back to R2 now, is that 00:21:33.079 --> 00:21:40.040 we've got a bunch of debugs. And so, you'll see here that we have traffic 00:21:43.000 --> 00:21:51.479 that is coming from 10.0.0.10, going to one, two, three, one, two, three, one, two, three, 00:21:51.479 --> 00:21:55.000 going to one, two, three, one, two, three, one, two, three, one, two, three. 00:21:56.280 --> 00:22:10.680 Notice what it says, policy rejected, normal forwarding. Policy rejected, normal forwarding. 00:22:13.560 --> 00:22:18.520 And it's saying that over and over and over again for each and every single one of them. 00:22:19.479 --> 00:22:25.479 No match. Now, that is a good thing, right? And this one is for that, the other, what are these? 00:22:25.479 --> 00:22:31.479 This one here is, what traffic's that? Coming from 240.23.2. 00:22:35.959 --> 00:22:39.560 I don't even know what that's for. I'm going to have to look into that after. It's interesting. 00:22:39.560 --> 00:22:50.439 Somebody's hacked my router. But the key here is to recognize that this traffic does not match 00:22:51.160 --> 00:22:55.959 that access control list. Therefore, since it doesn't match the access control list, 00:22:56.520 --> 00:23:02.680 it doesn't match sequence number 10. And what it matches is sequence number 20 of the route map. 00:23:02.680 --> 00:23:08.520 So, since it matches, not 20, sorry, it matches the implicit deny in this case. 00:23:09.880 --> 00:23:16.359 Entry of that route map. And so, that implicit deny is a deny meaning route normally, 00:23:16.359 --> 00:23:19.479 normal forwarding. So, even though it says policy rejected, that's not a bad thing. That's actually 00:23:19.479 --> 00:23:24.280 a good thing in this case. It means we're not policy-based routing. We're routing normally. 00:23:24.280 --> 00:23:29.079 And so, routing normally means what? It means show IP route. It means we're going to send 00:23:29.079 --> 00:23:34.040 our traffic to where? We're going to send our traffic using the default route in this case 00:23:34.040 --> 00:23:38.199 out to the internet. So, we should be able to see that here that we went 00:23:39.239 --> 00:23:43.800 from 10 to 001 over to R2 and then out to the internet. 00:23:45.560 --> 00:23:53.560 Right. Now, let's go ahead and trace 8.8.8.8 because 8.8.8.8 is 00:23:55.239 --> 00:24:02.199 actually going to then get routed this way. And so, we should see that happen now. We should see 00:24:02.199 --> 00:24:06.040 that we'll have the hop for here. Now, it's going to fail on us, okay, because I don't have 00:24:06.040 --> 00:24:11.160 everything set up properly to go out. I don't believe I do. I do. Oh, my gosh. Okay. So, 00:24:11.160 --> 00:24:15.880 I am set up to make it work. I was surprised. I didn't think we had it set up properly. 00:24:15.880 --> 00:24:18.680 But anyways, in the end, you can see that we went from where? 00:24:20.680 --> 00:24:24.280 Actually, no, loop. We routed loop. We did a loop here. That's a routing loop. So, 00:24:24.280 --> 00:24:29.160 it did not work properly. That's a routing loop. But it shows that policy-based routing worked. 00:24:29.160 --> 00:24:37.479 So, 10.0.0.1, out to R2, over to branch A, back to R2, then out to the internet. Why? Because if 00:24:37.479 --> 00:24:44.680 we go to branch A, its default route right now is pointing back to R2. That's why. But it shows 00:24:44.680 --> 00:24:49.640 that policy-based routing worked at least. But as I said, I wasn't expecting us to be able to 00:24:49.640 --> 00:24:53.560 get out that way because this is not set up properly. And so, we just routed right back 00:24:53.560 --> 00:24:58.439 because of default routing. But that's okay. The idea here is that we were successful at 00:24:58.439 --> 00:25:01.880 showing how the policy-based routing worked. But let's take a look at what our router actually 00:25:01.880 --> 00:25:12.520 tells us about this. If we go over to R2, we'll see there's a whole bunch of messages 00:25:12.520 --> 00:25:17.880 about policy-based routing that happened right here. So, you'll see here, let's go back up to 00:25:17.880 --> 00:25:25.640 the very beginning of it. Where are you? There it is. So, source IP 10.0.0.10 arrived on gigabit 00:25:25.640 --> 00:25:35.160 ethernet 060, going to a destination of 8.8.8.8. Policy match. We matched the route map called PVR, 00:25:35.160 --> 00:25:42.280 or route map underscore PVR. We matched sequence number 10. You see that? We matched sequence 00:25:42.280 --> 00:25:50.839 number 10. And it is a permit sequence, which means we must policy route it. So, now, 00:25:51.640 --> 00:25:58.040 10.0.0.10 as the source going to this destination has to be sent out this interface 00:25:58.680 --> 00:26:08.359 because that's how we get to the next top IP address of 10.45.33.2. So, therefore, we policy 00:26:08.359 --> 00:26:13.800 routed it. And then, the next trace packet that came in, same thing, over and over and over again 00:26:13.800 --> 00:26:18.920 for every single one of those. So, we policy routed those ones over to the other next hop. 00:26:18.920 --> 00:26:21.959 And if we look at the outputs, I'm going to type in do you all. 00:26:22.680 --> 00:26:25.800 If we look at the output of show IP or show route map, 00:26:29.160 --> 00:26:37.400 the route map underscore PVR, you'll see here that it tells us that we policy routed 12 packets. 00:26:38.359 --> 00:26:41.160 We policy routed 12 packets 00:26:44.760 --> 00:26:50.199 in total. So, that means 12 packets have matched this access control list. 00:26:51.160 --> 00:26:57.880 So, how do you verify if your policy is actually working or verify the number of packets 00:26:57.880 --> 00:27:02.280 that have been successfully policy-based routed? Just look at your route map. That's how you do it. 00:27:02.839 --> 00:27:08.760 Remember that if you type in show IP policy, it just shows you the – if you type in show IP 00:27:08.760 --> 00:27:14.040 policy, it just shows you the interfaces that are participating in policy-based routing and the 00:27:14.040 --> 00:27:19.400 route map that's applied. So, if you want to verify if packets are actually matching and being policy 00:27:19.400 --> 00:27:24.439 routed, then you type in show route map and the name of that route map, and it'll tell you at the 00:27:24.439 --> 00:27:30.119 bottom the number of packets that have matched that particular sequence. So, let's see what 00:27:30.119 --> 00:27:34.040 happened in this case if we did something very specific. Let's try this. We have the time. 00:27:34.680 --> 00:27:45.479 So, if we type in IP access hyphen list extended, can we do this all in the same sequence? 00:27:48.839 --> 00:27:54.599 Not – yeah, we should be able to. So, let's go – no, I don't want to do that. No. Okay. Let's 00:27:54.599 --> 00:28:04.680 create another one. Let's call it ACL underscore PBR2. And then I'm going to say I want to, in this 00:28:04.680 --> 00:28:13.880 case, permit – and we're going to permit our ICMP traffic from our host, our host being who? 00:28:13.880 --> 00:28:28.680 Our host being 10.0.0.0.10 going to host 123.123.123.123. Okay. So, this is that other 00:28:28.680 --> 00:28:31.959 traffic that we were not policy-based routing. But what I want to show you is that we're going 00:28:31.959 --> 00:28:39.079 to create now another route map. So, we're going to create a route map for this, but I'm going to 00:28:39.079 --> 00:28:47.000 say deny, and let's do sequence number 20. And now I want to match this access control list. 00:28:52.520 --> 00:29:00.199 And we are not going to provide any set. And why is that? Because it's a deny. Once you deny, 00:29:00.199 --> 00:29:04.040 you can't really set anything. You can't really do anything. I mean, you could technically, 00:29:04.040 --> 00:29:08.119 you know, do some things, but the key here is to realize that if you deny, what does that mean? 00:29:08.119 --> 00:29:12.359 Deny means route normally. That's what it means. That's what I'm trying to show you right now. 00:29:12.359 --> 00:29:17.400 So, when we look at this now, do show route-map. If you were looking at this on the exam, 00:29:28.280 --> 00:29:33.239 okay, if you were looking at this on the exam, then you would say, okay, so this right here, 00:29:33.239 --> 00:29:38.920 we are going to policy-based route because it says permit. And we'll policy-based route 00:29:38.920 --> 00:29:44.599 any traffic that matches this, and we'll set it to the next hop of this. Now, if you look at this 00:29:44.599 --> 00:29:48.599 one here, this is denied. Deny means do not policy-based route. It means route normally, 00:29:48.599 --> 00:29:53.959 folks. Keep that in mind. Route normally. So, anything that matches this ACL gets routed 00:29:53.959 --> 00:30:00.119 normally. So, this is what we call an explicit deny. Now, I don't really need this, right, 00:30:00.119 --> 00:30:04.439 because there is another deny sequence after the fact. And what is that deny sequence after 00:30:04.439 --> 00:30:09.160 the fact? It's the implicit deny that matches everything else anyways. But I'm just trying 00:30:09.160 --> 00:30:16.040 to show you that when it comes to the policy-based routing, what does deny actually mean? Deny 00:30:16.040 --> 00:30:23.880 actually means route normally. So, debug IP policy. Let's go ahead now to our PC, 00:30:24.599 --> 00:30:28.760 and let's trace to 1, 2, 3, 1, 2, 3, 1, 2, 3. And as long as I configured everything properly, 00:30:28.760 --> 00:30:33.560 we should see that we are routing normally, and we should get some output on our device about that, 00:30:34.280 --> 00:30:38.439 right? So, routed normally, it should be. There you go. So, as you can see, 00:30:38.439 --> 00:30:44.680 we're going from here to here. It's a policy match now. It's a policy match this time. Remember 00:30:44.680 --> 00:30:53.880 before, it didn't say policy match. Before, what did it say for that one? Please still be there. 00:30:53.880 --> 00:30:58.839 Please still be there. There it is. Okay. It just simply said policy rejected normal forwarding. 00:30:58.839 --> 00:31:04.920 Policy rejected normal forwarding, right? Okay. But if we go down now, because I have an explicit 00:31:04.920 --> 00:31:13.959 deny, the explicit deny says, ooh, we match the policy route map. Ooh, it's a deny. Okay. What 00:31:13.959 --> 00:31:20.599 does deny mean? It means reject the policy and route normally. Policy rejected route normally. 00:31:21.560 --> 00:31:25.239 All right. So, even though it's a policy match, the question now is, is it permit or deny? In 00:31:25.239 --> 00:31:31.000 this case, it's deny, meaning route normally. You see that? There it is. The proof right there 00:31:31.000 --> 00:31:34.280 that you can see. Now, if we look at the route map, is that going to actually show us that we 00:31:34.280 --> 00:31:41.640 have matches? No. You see, the packets are still zero. The packets are still zero because we didn't 00:31:41.640 --> 00:31:47.319 actually policy route anything, right? We just simply said, oh, you match a deny sequence, 00:31:47.319 --> 00:31:51.239 you're denied. So, you're not going to be able to do what? You're not going to be able to 00:31:57.719 --> 00:32:01.560 keep track of the packets that were routed normally based on that route map, 00:32:01.560 --> 00:32:08.439 but you can definitely keep track of the packets that matched the permits in those route maps. 00:32:18.359 --> 00:32:21.640 Policy-based routing, folks, simple example. So, think about it for the exam. 00:32:21.640 --> 00:32:25.160 You can get any scenario thrown at you on the exam about policy-based routing. 00:32:25.160 --> 00:32:30.280 It could be a troubleshooting scenario, it could be a configuration scenario, 00:32:30.280 --> 00:32:33.479 it could be just multiple choice questions based on information they provide to you, 00:32:33.479 --> 00:32:36.359 but the key here is to recognize what? One, what policy-based routing is for. 00:32:37.160 --> 00:32:41.800 So, we've covered that. Two, what interface you apply it to. Make sure it's applied to the right 00:32:41.800 --> 00:32:48.520 interface. Make sure the ACL is correct. Make sure the route map is correct. And the most important 00:32:48.520 --> 00:32:52.199 thing about that ACL is make sure the right protocol is being used, the right port number 00:32:52.199 --> 00:32:57.959 is being used, the right source of destination is being used. So, pay attention to the scenarios. 00:32:57.959 --> 00:33:03.880 The last thing you want to do is have a policy-based routing question that you are 00:33:03.880 --> 00:33:07.319 troubleshooting, you're configuring, you're verifying whatever it is. And in the end, 00:33:07.959 --> 00:33:12.040 the only thing that was wrong with the whole thing is that the access control list was using, 00:33:12.040 --> 00:33:17.719 let's say, UDP instead of TCP for port 443, right? The rest of it was all perfect. There 00:33:17.719 --> 00:33:21.640 was nothing wrong with it. Everything was good. But what they were doing was maybe testing you 00:33:21.640 --> 00:33:26.439 on an access control list in that case. So, be mindful that when you take this exam, 00:33:26.520 --> 00:33:30.359 you're going to get some pretty interesting questions that you may think are related to 00:33:30.359 --> 00:33:35.800 things like BGP or related to policy-based routing or related to OSPF. But in the end, 00:33:36.680 --> 00:33:40.119 after you verify everything, it could be something as simple as, oh, the ACL wasn't 00:33:40.119 --> 00:33:44.439 configured correctly or, oh, this wasn't done correctly or, oh, the interface was down. 00:33:44.439 --> 00:33:50.119 Why? Because they're testing you on the strange things that can happen to you in an environment 00:33:51.160 --> 00:33:55.880 to really test you. Do you really understand how everything works now as a cohesive, 00:33:55.880 --> 00:34:00.920 holistic situation and scenario? Now, you'll still get a lot of questions that are independent. 00:34:00.920 --> 00:34:03.880 What does this do? What does that do? How does this work? How does that work? Fine. 00:34:03.880 --> 00:34:08.520 But it's those other ones that are now trying to get you to put multiple things together, 00:34:08.520 --> 00:34:12.600 like was the route not configured properly? Was the ACL configured properly? Was it applied to 00:34:12.600 --> 00:34:15.879 the right interface? These are the ones that get a little bit more challenging. 00:34:17.080 --> 00:34:19.959 And so, before we put a bow on policy-based routing for the day, 00:34:21.239 --> 00:34:23.879 I want to look at these default keywords here right now. 00:34:26.199 --> 00:34:40.280 So, this is the one I gave you as a demonstration. Set IP next hop and then the next hop IP address. 00:34:40.280 --> 00:34:44.040 So, what is the next hop router along the path that you want to policy-based route the traffic to? 00:34:45.560 --> 00:34:55.080 So, in this case, the behavior is do exactly what this states. If traffic matches, 00:34:55.080 --> 00:35:02.520 then set the next hop to this value and route the packet that way. 00:35:06.120 --> 00:35:11.719 This is a little confusing at first until you wrap your head around what it really means. 00:35:13.239 --> 00:35:17.080 I struggled with this one in the beginning. I really had a hard time getting my head around 00:35:17.080 --> 00:35:21.639 what it does. And then all of a sudden, one day, I'm like, ah, yeah, it makes so much sense now. 00:35:21.719 --> 00:35:28.040 Notice what it says. Set IP default, next hop, next hop IP. The only difference is this keyword 00:35:28.040 --> 00:35:35.959 here. The default keyword. You see that? Default keyword. That's the only difference. 00:35:37.479 --> 00:35:47.080 What, though, does this change? What does it do? It really changes the entire behavior a lot. 00:35:47.639 --> 00:36:03.639 What it does is it says, only policy-based route. If you look in the routing table and do not find 00:36:04.600 --> 00:36:11.639 an explicit route for the destination, and you have to use the default route, 00:36:13.399 --> 00:36:18.199 that's when you policy-based route. All right, pause. And you're like, what? 00:36:19.399 --> 00:36:26.199 What did you just say? Okay, let's rewind. Let's rewind. Set IP default, next hop, 00:36:26.760 --> 00:36:42.360 next hop IP. What does that mean? This tells the router, only policy-based route 00:36:43.560 --> 00:36:51.560 if there is no explicit route for the destination IP address of the packet in the routing table, 00:36:52.120 --> 00:36:55.800 and you have to use the default route. If that is the case, 00:36:55.800 --> 00:37:01.399 and you have to use the default route, then policy-based route to this next hop IP address. 00:37:02.439 --> 00:37:07.320 Basically, what it allows you to do is only policy-based route if it's going to be the 00:37:07.320 --> 00:37:12.360 default route that's going to end up being used. If not, then you route normally. So, 00:37:12.360 --> 00:37:19.000 route normally based on the routing table, unless it's the default route that's going 00:37:19.000 --> 00:37:32.360 to be used to forward the traffic. Crazy, isn't it? But that's what it means. That's 00:37:32.360 --> 00:37:40.840 what I want you to know. I'll repeat it one more time. Only policy-based routing if there is no 00:37:40.840 --> 00:37:45.560 explicit route in the routing table for the destination of that packet, and you have to 00:37:45.560 --> 00:37:49.639 use the default route. So, if you have to use the default route, then you're going to policy-based 00:37:49.639 --> 00:37:53.239 route. If you don't have to use the default route, then you don't policy-based route. 00:37:54.439 --> 00:37:58.760 So, think about how you would craft that. You would craft that in a way that you have your 00:37:58.760 --> 00:38:04.040 access control list matching your traffic, and then you have your route map, and your route map 00:38:04.040 --> 00:38:11.800 would be what? Your route map would be a permit matching the access control list, and then you 00:38:11.800 --> 00:38:17.560 would say, set IP default next hop, next hop IP. Meaning that you're only going to do this 00:38:18.439 --> 00:38:26.280 if you've checked the routing table first, and no explicit route exists for the destination IP, 00:38:27.560 --> 00:38:33.239 and the default route's going to be used. Now that the default route's going to be used, now I do this. 00:38:37.320 --> 00:38:41.080 If the default route's not going to be used, then I don't do this, and I just use whatever's 00:38:41.080 --> 00:38:46.600 in the routing table. Like, I mean, really, it takes a while to get your head wrapped around 00:38:46.600 --> 00:38:52.199 that concept. All right, the other item we have here is CC set interface. So, same idea as this, 00:38:52.919 --> 00:38:57.479 and this is the same idea as this, but instead of setting the next hop IP address, 00:38:57.479 --> 00:39:02.520 you simply set the exiting interface. Now, is that actually a good idea, folks? 00:39:03.479 --> 00:39:09.879 Is that actually a good idea to set the exiting interface instead of the next hop IP address? 00:39:11.080 --> 00:39:27.000 Okay, the answer to that is no. If the interface is an Ethernet interface, 00:39:28.919 --> 00:39:36.199 if it's a serial interface that's point-to-point protocol, or a serial interface that is running 00:39:36.199 --> 00:39:44.439 HDLC, then that is okay. If it's a PPPoE interface, point-to-point protocol over Ethernet, 00:39:44.439 --> 00:39:49.479 that's okay as well. But if it's a Ethernet interface, a pure Ethernet interface not 00:39:49.479 --> 00:39:53.800 running PPPoE or anything like that, then you should never use this. 00:39:55.959 --> 00:40:00.679 And it's for the exact same reason why you should never do something like this. 00:40:36.199 --> 00:40:52.040 So, you see here how what I've done with my default route on Router2, I said I want you to 00:40:52.040 --> 00:40:59.879 use the exiting interface FASTX and a 0SI0SI0, this one right here, which is fine until you read 00:40:59.879 --> 00:41:05.000 this. Default route without gateway, if not a point-to-point interface, may impact performance. 00:41:06.919 --> 00:41:14.840 That same, same issue that I have here is the same issue I get in this scenario right here, 00:41:15.560 --> 00:41:21.800 using the exit interface, using the exit interface. What is the problem that I run 00:41:21.800 --> 00:41:27.399 into in these scenarios? So, the problem we run into in these scenarios is related to 00:41:30.199 --> 00:41:36.040 address resolution protocol. That's right. Let's take a look at this right now. Do 00:41:36.120 --> 00:41:42.919 show IP route. So, notice, folks, how when I typed in this command here, 00:41:43.879 --> 00:41:51.320 it even gave me a warning. Look at the entry in the routing table. Just read that for a second. 00:41:52.679 --> 00:42:04.439 And I want you to answer this question. Is this actually true? 0, 0, 0, 0 is directly 00:42:04.439 --> 00:42:27.239 connected. Is that true? Nope, not at all. Why? Because the only thing that's directly connected 00:42:27.239 --> 00:42:37.080 to me on FastEthernet 0SI0SI0SI0 is this network right here. Everything else is beyond that, 00:42:37.080 --> 00:42:46.120 right? Everything else is beyond that on the internet. So, this is a lie. And what does that 00:42:46.120 --> 00:42:56.520 cause? It causes excessive ARPs. Why is that? Because any time your router sees directly 00:42:56.520 --> 00:43:02.199 connected in the routing table, what does it do when it has to forward the packet? Well, 00:43:02.199 --> 00:43:08.360 it has to create a frame, if you recall. And the frame needs a source and destination MAC address. 00:43:09.159 --> 00:43:14.199 So, the source MAC address is the MAC address of the exiting interface. So, FastEthernet 0, 0, 0. 00:43:15.639 --> 00:43:20.360 But the destination MAC address in this case, it says it's directly connected. 00:43:21.000 --> 00:43:28.600 It says it's directly connected. So, what does that mean? It means I will ARP for the MAC address 00:43:29.239 --> 00:43:36.280 of the IP address that's in the packet. So, for example, if PC1 right now, 00:43:36.280 --> 00:43:51.639 for example, if PC1 right now is going source 10.0.0.10, destination 8.8.8.8, 00:43:52.439 --> 00:44:02.280 then when this router needs to send it out this interface, it ARPs for MAC of 8.8.8.8. 00:44:03.239 --> 00:44:10.919 Now, pretend 8.8.8.8.8 is out here somewhere. Will I get the MAC address back for 8.8.8.8.8? 00:44:11.879 --> 00:44:17.879 No, because 8.8.8.8 doesn't live on this directly connected network. 00:44:17.879 --> 00:44:25.639 So, I'm not going to get the MAC address back. However, we do have a feature enabled on Cisco 00:44:25.639 --> 00:44:32.120 devices called ProxyARP. And so, ProxyARP is enabled here, for example, by default. 00:44:32.919 --> 00:44:39.959 And what ProxyARP does is if the router receives an ARP request that doesn't make sense for that 00:44:40.919 --> 00:44:46.760 broadcast domain, but the router has an entry in its routing table to get there, 00:44:47.639 --> 00:44:53.719 then it will respond back with its own MAC address. So, now when I ARP for 8.8.8.8, 00:44:53.719 --> 00:44:57.959 I get this router's MAC address back. When I ARP for 8.8.8.8.9, I get this router's MAC 00:44:57.959 --> 00:45:02.679 address back. When I ARP for 8.8.8.8.10, I get this route. Every single packet, I'm going to 00:45:02.679 --> 00:45:08.040 have to ARP for the MAC address of, and this router is going to respond back with its MAC 00:45:08.040 --> 00:45:16.520 address each and every single time, over and over and over and over. Again, nonstop with ProxyARP 00:45:16.520 --> 00:45:25.879 enabled. So, for example, if we do something like, let's see if I can just kind of demo this. 00:45:25.879 --> 00:45:39.320 Let's see. We'll go 8.8.8.8. We'll just do 1. So, minus N1. Okay. And then let's do 9. Okay. 00:45:39.320 --> 00:45:46.199 That should fail. And that's fine. I want it to fail because it doesn't really exist. Okay. 10. 00:45:46.199 --> 00:45:51.320 But what you're going to see here is as we now go, if this demo works for me like I want it to, 00:45:51.320 --> 00:45:55.399 if I look at the ARP cache on router number two, 00:46:03.560 --> 00:46:08.439 what? Every single entry is showing up. So, in this case, you see how it's incomplete. 00:46:09.959 --> 00:46:15.320 It's incomplete in these cases because that router is not able to respond to those messages because 00:46:15.320 --> 00:46:19.719 it doesn't actually have a route to get to those particular networks. That's why. But if it had a 00:46:19.719 --> 00:46:23.159 route to get to those particular networks, then it would respond back. So, what does that mean? 00:46:23.159 --> 00:46:28.439 It means that if you have users in your environment and they're all going out to the internet, 00:46:29.159 --> 00:46:35.080 and let's say they go to a million different places that day, a million different IPs, 00:46:35.080 --> 00:46:40.040 then your router would have a million different ARP entries, but they would all point to the same 00:46:40.040 --> 00:46:46.360 next hop MAC address. Same, same, same, same. That's all really excessive. You see, remember 00:46:46.919 --> 00:46:52.919 that when we have our routers, when we specify the what? When we specify instead of the next hop, 00:46:52.919 --> 00:47:01.159 or sorry, instead of specifying the exiting interface, when we specify the next hop IP 00:47:01.159 --> 00:47:11.479 address instead, like 203.0.113.89 as the next hop, then what happens in those scenarios 00:47:13.159 --> 00:47:19.159 is that you only have to ARP for the MAC address of this because the frame goes from my router to 00:47:19.159 --> 00:47:23.479 your router, my router to your router. And when you look at the routing table, do show IP route 00:47:23.479 --> 00:47:28.120 now, it doesn't say directly connected. It says via this next hop. So, it changes the behavior of 00:47:28.120 --> 00:47:34.520 the router. So, now that the router has 203.0.113.89 as the next hop, that is going to be the destination 00:47:34.520 --> 00:47:39.959 MAC address for the frames. Source frame here, destination frame there. I don't have to ARP for 00:47:39.959 --> 00:47:43.479 the destination. I don't have to ARP for the MAC address of every single destination IP in the 00:47:43.479 --> 00:47:47.239 packet because they're not directly connected to me. I have to go to the next hop address. 00:47:47.239 --> 00:47:53.959 So, that's why we don't specify the exiting interface on ethernet, on static routes that 00:47:53.959 --> 00:47:59.080 go out ethernet interfaces or default routes that go out of ethernet interfaces. And if you do, 00:47:59.080 --> 00:48:02.919 it's not a good thing. It could actually degrade the performance of your router and fill up the 00:48:02.919 --> 00:48:08.679 ARP cache and cause problems. So, we always use the next hop IP address. So, the same philosophy 00:48:08.679 --> 00:48:14.679 applies in this scenario as well. If you use the exit interface, what's going to happen now when 00:48:14.679 --> 00:48:20.679 you policy-based route to the exit interface? You think you're directly connected. So, now you have 00:48:20.679 --> 00:48:26.120 to ARP for the MAC address of the destination IP in the packet, which it's not going to be there. 00:48:26.120 --> 00:48:30.679 And so, since it's not going to be there, it's going to be incomplete. Or proxy ARP's enabled, 00:48:30.679 --> 00:48:33.959 then you're going to get a response back. But that means the ARP cache on the router is going to fill 00:48:33.959 --> 00:48:37.320 up and fill up and fill up and fill up and fill up for every single packet that you policy-based 00:48:37.320 --> 00:48:42.280 route. And you don't want that. You don't want that. So, if it's an ethernet interface, this 00:48:42.280 --> 00:48:47.320 is the path you want to take. If it is a serial point-to-point protocol interface, which probably 00:48:47.320 --> 00:48:53.959 none of you have anymore, HDLC serial interface, again, point-to-point, a pure point-to-point 00:48:53.959 --> 00:48:59.080 interface, or PPPoE interface, then you can go ahead and use these. So, most modern-day 00:49:00.120 --> 00:49:05.080 static routing is not going to use the exiting interface anymore. We used it back in the day 00:49:05.080 --> 00:49:08.679 on PPP interfaces. We used it back in the day on HDLC interfaces. We used it back in the day on 00:49:08.679 --> 00:49:13.239 PPPoE interfaces, right? Same thing with this. If the exiting interface is one of those, no problem 00:49:13.239 --> 00:49:18.760 with policy-based routing. But ethernet interfaces don't use this in the real world. Stick with this 00:49:18.760 --> 00:49:21.959 for all those different types of scenarios that use ethernet interface. All right. That's the 00:49:21.959 --> 00:49:26.120 moral of that story, so you understand the differences between those for the certification 00:49:26.120 --> 00:49:31.399 exam and why one is more important than the other. All right. And there you go, folks. Policy-based 00:49:31.399 --> 00:49:32.840 routing, make sure you know it for the certification.