WEBVTT 1 00:00.000 --> 00:07.000 So what we want to do next is jump in and take a closer look at our data 2 00:07.000 --> 00:08.360 policies. 3 00:08.360 --> 00:13.730 Now as a reminder, the data policies can be used not only to permit or deny 4 00:13.730 --> 00:14.560 specific 5 00:14.560 --> 00:19.450 traffic through our network, but we can also use it to control traffic flow 6 00:19.450 --> 00:20.560 with something 7 00:20.560 --> 00:22.760 we call traffic engineering. 8 00:22.760 --> 00:27.810 We do that with things like application-aware routing or AAR and things like 9 00:27.810 --> 00:28.360 this that 10 00:28.360 --> 00:31.280 are functioning as a data policy. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 10 00:28.360 --> 00:31.280 are functioning as a data policy. 11 00:31.280 --> 00:35.900 Also keep in mind that these can be centralized or localized, so as we go 12 00:35.900 --> 00:36.760 through, we'll 13 00:36.760 --> 00:40.880 be talking about those differences in a little more detail as well. 14 00:40.880 --> 00:47.640 So all of that said, let's jump in with a closer look at our data policies. 15 00:47.640 --> 00:52.300 So the first thing is remember that our data policies do come in two different 16 00:52.300 --> 00:53.120 flavors. 17 00:53.120 --> 00:59.970 First is localized, again, these are going to affect one or more interfaces on 18 00:59.970 --> 01:00.800 a single WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 18 00:59.970 --> 01:00.800 a single 19 01:00.800 --> 01:01.960 router. 20 01:01.960 --> 01:05.890 Now previously we said one interface on one router, that's of course the 21 01:05.890 --> 01:07.040 default behavior, 22 01:07.040 --> 01:12.920 but we can reuse a policy and put it on an additional interface. 23 01:12.920 --> 01:19.030 These are going to be implemented on the device with access control lists or AC 24 01:19.030 --> 01:19.320 Ls, and 25 01:19.320 --> 01:24.400 as such they are going to be stored locally on that edge device. 26 01:24.400 --> 01:29.060 They're going to be part of the configuration and if the device reloads and so 27 01:29.060 --> 01:29.560 on, these 28 01:29.560 --> 01:32.360 policies will still be in place. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 28 01:29.560 --> 01:32.360 policies will still be in place. 29 01:32.360 --> 01:37.490 And they can be used for other things as well, such as doing QOS marking or 30 01:37.490 --> 01:38.880 mirroring traffic 31 01:38.880 --> 01:40.400 to a different port. 32 01:40.400 --> 01:45.060 So this is if we want to of course monitor traffic, do packet capturing, that 33 01:45.060 --> 01:45.880 sort of thing. 34 01:45.880 --> 01:50.640 We can use this to mirror traffic to an additional port. 35 01:50.640 --> 01:55.010 And there's of course the centralized policies, the centralized policies of 36 01:55.010 --> 01:56.080 course affect that 37 01:56.080 --> 01:58.040 network wide traffic. 38 01:58.040 --> 02:01.160 So all of the traffic in the network. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 38 01:58.040 --> 02:01.160 So all of the traffic in the network. 39 02:01.160 --> 02:06.360 And as such, these are going to be provisioned on the controllers themselves. 40 02:06.360 --> 02:12.170 Now since the policy is actually being implemented in the data plane, it of 41 02:12.170 --> 02:13.880 course has to end up 42 02:13.880 --> 02:15.800 on the edge device. 43 02:15.800 --> 02:22.290 However, it is pushed as read only to the edge device and it's not a part of 44 02:22.290 --> 02:24.160 the configuration. 45 02:24.160 --> 02:29.520 Rather, it's simply stored in memory on that edge device. 46 02:29.520 --> 02:34.880 So again in the case of something like a reload, this policy would be gone. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 46 02:29.520 --> 02:34.880 So again in the case of something like a reload, this policy would be gone. 47 02:34.880 --> 02:39.550 Now of course as soon as it comes online, it's going to be reprovisioned by the 48 02:39.550 --> 02:40.600 controllers, 49 02:40.600 --> 02:44.800 pushed back down to the RAM on the edge devices. 50 02:44.800 --> 02:48.920 So of course they'll get the policy again, but the point is they don't become 51 02:48.920 --> 02:49.520 part of that 52 02:49.520 --> 02:52.880 configuration on the edge device. 53 02:52.880 --> 02:59.650 Now as we go through this video, our main focus will be these centralized 54 02:59.650 --> 03:00.960 policies. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 54 02:59.650 --> 03:00.960 policies. 55 03:00.960 --> 03:06.390 So on the topic of the centralized data policies, a couple things to get out of 56 03:06.390 --> 03:07.240 the way. 57 03:07.240 --> 03:11.080 There is no default policy. 58 03:11.080 --> 03:17.830 As such, that means that any to any communication is going to be permitted and 59 03:17.830 --> 03:19.160 it will simply 60 03:19.160 --> 03:25.520 be using the best path selection as chosen by the routing protocol. 61 03:25.520 --> 03:29.670 When we do implement a policy and we want to start matching, remember that this 62 03:29.670 --> 03:30.080 is going WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 62 03:29.670 --> 03:30.080 is going 63 03:30.080 --> 03:34.440 to use a six-tuple of the headers. 64 03:34.440 --> 03:39.290 So again, that's going to be the source and destination IP addresses, the 65 03:39.290 --> 03:39.760 source and 66 03:39.760 --> 03:47.560 destination TCP or UDP port numbers, the DSCP header and the protocol header. 67 03:47.560 --> 03:51.290 So those are the things we're going to be using to match on the traffic if we 68 03:51.290 --> 03:52.040 're matching 69 03:52.040 --> 03:54.880 on the headers specifically. 70 03:54.880 --> 04:00.680 Now something else to note is we can look past the IP header. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 70 03:54.880 --> 04:00.680 Now something else to note is we can look past the IP header. 71 04:00.680 --> 04:06.360 When we're talking about a centralized policy, this can do something called DPI 72 04:06.360 --> 04:07.240 or Deep Packet 73 04:07.240 --> 04:08.800 Inspection. 74 04:08.800 --> 04:13.210 This is where it actually looks into the payload of the traffic to determine 75 04:13.210 --> 04:14.480 what type of traffic 76 04:14.480 --> 04:16.000 it is. 77 04:16.000 --> 04:22.090 This means that if we want specific applications, maybe voice, maybe telnet 78 04:22.090 --> 04:24.680 traffic or SSH traffic 79 04:24.680 --> 04:29.730 or mission critical data, whatever it is, however we want to break up our 80 04:29.730 --> 04:30.560 traffic, this WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 80 04:29.730 --> 04:30.560 traffic, this 81 04:30.560 --> 04:36.400 can be sent over certain or specific tunnels that we choose to use. 82 04:36.400 --> 04:40.840 And again, it may be because it's low priority traffic, might be because it's 83 04:40.840 --> 04:41.800 high priority 84 04:41.800 --> 04:43.120 traffic. 85 04:43.120 --> 04:48.520 The other important thing here is we can do this based on the attributes of the 86 04:48.520 --> 04:49.280 tunnel, 87 04:49.280 --> 04:55.790 such as latency, reliability, packet loss, things that we're going to learn and 88 04:55.790 --> 04:56.120 monitor with 89 04:56.120 --> 04:58.040 an SLA. 90 04:58.040 --> 05:00.880 So this is going to be based on decisions. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 90 04:58.040 --> 05:00.880 So this is going to be based on decisions. 91 05:00.880 --> 05:06.680 Now this overall feature is called AAR or application aware routing and we have 92 05:06.680 --> 05:07.600 mentioned 93 05:07.600 --> 05:13.240 this previously and we're going to be covering it more in the next video. 94 05:13.240 --> 05:18.560 Keep in mind that the primary function of these centralized policies is to 95 05:18.560 --> 05:19.400 affect that 96 05:19.400 --> 05:25.020 traffic flow in the network, either to allow the communication, not allow the 97 05:25.020 --> 05:26.200 communication 98 05:26.200 --> 05:31.830 or to, as we mentioned up here, choose which tunnel is going to be used for WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 98 05:26.200 --> 05:31.830 or to, as we mentioned up here, choose which tunnel is going to be used for 99 05:31.830 --> 05:32.760 particular type 100 05:32.760 --> 05:34.080 of traffic. 101 05:34.080 --> 05:38.600 But overall, this is going to be using traffic engineering. 102 05:38.600 --> 05:42.740 But since it is a centralized policy, keep in mind that it's going to be 103 05:42.740 --> 05:45.240 applied to a VPN, 104 05:45.240 --> 05:51.470 in other words, traffic going into the overlay, not an interface like localized 105 05:51.470 --> 05:53.560 policies are. 106 05:53.560 --> 05:57.360 Of course, this is also not just about traffic engineering. 107 05:57.360 --> 06:03.080 There are several other features that can be enabled with our data policies. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 107 05:57.360 --> 06:03.080 There are several other features that can be enabled with our data policies. 108 06:03.080 --> 06:06.040 First, we can implement service chaining. 109 06:06.040 --> 06:10.120 So for example, we could push our traffic through a firewall or an intrusion 110 06:10.120 --> 06:10.840 prevention 111 06:10.840 --> 06:12.880 system or both. 112 06:12.880 --> 06:16.720 We can implement network address translation or not. 113 06:16.720 --> 06:23.140 We can do traffic policing and counting, which if you're not familiar, policing 114 06:23.140 --> 06:24.160 is limiting 115 06:24.160 --> 06:28.800 how much traffic of a certain type can go through an interface. 116 06:28.800 --> 06:31.040 Counting, of course, is just as it sounds. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 116 06:28.800 --> 06:31.040 Counting, of course, is just as it sounds. 117 06:31.040 --> 06:35.640 We can use this to find out how much of a certain traffic is going through a 118 06:35.640 --> 06:36.520 particular 119 06:36.520 --> 06:38.360 VPN. 120 06:38.360 --> 06:42.690 Of course, we've mentioned this one a few times now that it's going to do 121 06:42.690 --> 06:44.040 transport selection. 122 06:44.040 --> 06:47.320 In other words, choosing an appropriate tunnel. 123 06:47.320 --> 06:50.220 This is usually going to be using a. 124 06:50.220 --> 06:53.520 R. So that's the main thing we're talking about here. 125 06:53.520 --> 06:56.290 There we're going to be doing the traffic engineering to send certain traffic 126 06:56.290 --> 06:56.680 that we 127 06:56.680 --> 07:01.520 prefer down certain tunnels of our selection. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 127 06:56.680 --> 07:01.520 prefer down certain tunnels of our selection. 128 07:01.520 --> 07:06.580 And of course, something else we can do is quality of service or QOS, which is 129 07:06.580 --> 07:07.240 of course, 130 07:07.240 --> 07:11.320 simply prioritizing some traffic over other traffic. 131 07:11.320 --> 07:16.600 But before we can modify how we behave with certain traffic, we have to have a 132 07:16.600 --> 07:17.760 way to identify 133 07:17.760 --> 07:18.760 it. 134 07:18.760 --> 07:21.840 The way we identify it is with classification. 135 07:21.840 --> 07:26.840 And of course, we can classify the traffic using our data policy. 136 07:26.840 --> 07:33.280 Now the policies themselves are a set of sequential match action pairs. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 136 07:26.840 --> 07:33.280 Now the policies themselves are a set of sequential match action pairs. 137 07:33.280 --> 07:39.000 So in other words, match on X and do Y. 138 07:39.000 --> 07:43.320 These are very similar in how they function to a route map. 139 07:43.320 --> 07:47.400 In other words, they are going to be processed from the top down. 140 07:47.400 --> 07:54.240 So from the lowest to the highest, lowest to highest, meaning sequence numbers, 141 07:54.240 --> 07:54.840 anytime 142 07:54.840 --> 08:01.120 there is a match, we are then going to stop processing and do the action that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 142 07:54.840 --> 08:01.120 there is a match, we are then going to stop processing and do the action that 143 08:01.120 --> 08:01.800 that match 144 08:01.800 --> 08:03.400 says to do. 145 08:03.400 --> 08:04.400 Maybe that's permit. 146 08:04.400 --> 08:05.400 Maybe that's drop. 147 08:05.400 --> 08:08.080 Maybe that's set a QOS classification. 148 08:08.080 --> 08:13.130 But whatever that match says to do is going to be done and then we stop 149 08:13.130 --> 08:14.400 processing. 150 08:14.400 --> 08:19.200 And also like access lists and route maps, if there's no match. 151 08:19.200 --> 08:23.080 So in other words, if we get all the way to the bottom of our policy and we 152 08:23.080 --> 08:23.960 haven't matched 153 08:23.960 --> 08:31.480 on anything yet, there is a default drop at the bottom of the data policy. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 153 08:23.960 --> 08:31.480 on anything yet, there is a default drop at the bottom of the data policy. 154 08:31.480 --> 08:35.320 Now all of this may sound a little bit complex. 155 08:35.320 --> 08:39.600 All of these moving parts and honestly it is to a certain extent. 156 08:39.600 --> 08:45.700 However, one of the really cool things is SD-WAN manager actually has a policy 157 08:45.700 --> 08:47.520 creation wizard 158 08:47.520 --> 08:53.860 which is going to walk us through as Cisco calls it the four significant steps 159 08:53.860 --> 08:55.200 of implementing 160 08:55.200 --> 08:57.800 our centralized data policy. 161 08:57.800 --> 09:00.960 Personally I probably would have called it five. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 161 08:57.800 --> 09:00.960 Personally I probably would have called it five. 162 09:00.960 --> 09:02.560 You'll see what I mean. 163 09:02.560 --> 09:08.040 But according to Cisco, step one is to create those groups of interest that of 164 09:08.040 --> 09:08.780 course we're 165 09:08.780 --> 09:12.000 going to use for matching our traffic. 166 09:12.000 --> 09:15.960 We then configure our topology and VPN membership. 167 09:15.960 --> 09:21.840 So in other words, which VPNs that we want to apply this to in our topology. 168 09:21.840 --> 09:24.520 Then we configure the actual traffic rules. 169 09:24.520 --> 09:28.160 Of course this is where we're going to be matching on the groups of interest 170 09:28.160 --> 09:28.840 and deciding 171 09:28.840 --> 09:31.480 what to do with that traffic. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 171 09:28.840 --> 09:31.480 what to do with that traffic. 172 09:31.480 --> 09:37.750 And our final step is to apply these policies to specific sites and the VPNs 173 09:37.750 --> 09:39.280 that we specified 174 09:39.280 --> 09:40.840 up here. 175 09:40.840 --> 09:45.540 Those are overall the four significant steps and this is what the wizard walks 176 09:45.540 --> 09:46.840 us through. 177 09:46.840 --> 09:49.960 Makes it very easy to configure all of this. 178 09:49.960 --> 09:53.740 Now the reason I'm sort of joking about the four steps in case you didn't pick 179 09:53.740 --> 09:54.720 up on that 180 09:54.720 --> 09:59.720 is we also have to activate the policy. 181 09:59.720 --> 10:01.680 It has to be activated. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 181 09:59.720 --> 10:01.680 It has to be activated. 182 10:01.680 --> 10:02.680 I don't know. 183 10:02.680 --> 10:05.880 Personally I would probably just call that step five. 184 10:05.880 --> 10:07.480 Activate the policy. 185 10:07.480 --> 10:11.960 However just so we're on the same page as Cisco, these are our four steps to 186 10:11.960 --> 10:12.480 create the 187 10:12.480 --> 10:17.360 policy and then it has to be activated. 188 10:17.360 --> 10:22.280 So in this video, we jumped in and we took a closer look at our data policies. 189 10:22.280 --> 10:27.070 Now of course we sort of already knew that they could be either centralized or 190 10:27.070 --> 10:27.920 localized. 191 10:27.920 --> 10:32.880 So we really took this video as an opportunity to delve a little deeper into WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 191 10:27.920 --> 10:32.880 So we really took this video as an opportunity to delve a little deeper into 192 10:32.880 --> 10:34.200 those centralized 193 10:34.200 --> 10:38.850 policies, the things we can accomplish with them and then of course the final 194 10:38.850 --> 10:39.800 steps here 195 10:39.800 --> 10:41.760 that we need to actually implement them. 196 10:41.760 --> 10:45.710 We'll be taking a look at all this but it's important to know the steps before 197 10:45.710 --> 10:46.160 we just 198 10:46.160 --> 10:47.160 jump in. 199 10:47.160 --> 10:52.350 Next, let's take a closer look at our application aware routing in the next 200 10:52.350 --> 10:53.080 video. 201 10:53.080 --> 11:03.080 [BLANK_AUDIO]