WEBVTT 1 00:00.000 --> 00:04.880 Well, the format for these quizzes is going to be what we've done several times 2 00:04.880 --> 00:05.240 up until 3 00:05.240 --> 00:09.410 now, which is to ask some quiz questions, but I'm not going to pause the video 4 00:09.410 --> 00:09.880 and give 5 00:09.880 --> 00:11.320 a lengthy silence. 6 00:11.320 --> 00:15.280 What I'd encourage you to do is once we get done reading the quiz question, you 7 00:15.280 --> 00:15.520 hit the 8 00:15.520 --> 00:20.050 pause button and make sure you can answer it yourself before unpause it and 9 00:20.050 --> 00:20.740 watching 10 00:20.740 --> 00:23.000 the solution in order to verify. 11 00:23.000 --> 00:26.670 So for example, with this question here, what are the four planes of operation 12 00:26.670 --> 00:27.200 for Cisco 13 00:27.200 --> 00:28.400 SD-WAN? 14 00:28.400 --> 00:29.840 This is an open ended question. 15 00:29.840 --> 00:35.240 So again, hit the pause button, maybe grab a piece of paper and a pad of paper, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 15 00:29.840 --> 00:35.240 So again, hit the pause button, maybe grab a piece of paper and a pad of paper, 16 00:35.240 --> 00:35.840 a piece 17 00:35.840 --> 00:39.550 of paper and a pencil, whatever you need to write stuff down and make sure that 18 00:39.550 --> 00:39.960 you can 19 00:39.960 --> 00:45.380 answer this question yourself before again, we start to talk about the solution 20 00:45.380 --> 00:45.400 . 21 00:45.400 --> 00:47.320 So what is the solution here? 22 00:47.320 --> 00:52.250 Well, Cisco's SD-WAN architecture is pretty sophisticated and it doesn't 23 00:52.250 --> 00:53.280 involve these 24 00:53.280 --> 00:55.840 four planes of operation. 25 00:55.840 --> 00:59.270 We might be used to control plane and data plane when we're talking about 26 00:59.270 --> 01:00.080 normal network WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 26 00:59.270 --> 01:00.080 normal network 27 01:00.080 --> 01:01.080 operations. 28 01:01.080 --> 01:03.160 And certainly that's going to be the first two. 29 01:03.160 --> 01:07.500 We're going to have a control plane of operation, which allows us to share 30 01:07.500 --> 01:09.160 routes with one another, 31 01:09.160 --> 01:14.080 make sure we know how to encapsulate our traffic and get it to the destination. 32 01:14.080 --> 01:17.590 We have the data plane, which involves building those secure tunnels and 33 01:17.590 --> 01:18.520 allowing us to send 34 01:18.520 --> 01:22.680 traffic from one WAN device to another WAN device. 35 01:22.680 --> 01:24.480 But there are a couple others here as well. 36 01:24.480 --> 01:27.480 First of all, we have a management plane of operation. 37 01:27.480 --> 01:32.420 This is how we manage the entire SD-WAN infrastructure from that single pane of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 37 01:27.480 --> 01:32.420 This is how we manage the entire SD-WAN infrastructure from that single pane of 38 01:32.420 --> 01:34.520 glass is a huge part 39 01:34.520 --> 01:38.530 of software defined infrastructure is getting us away from piecemealing 40 01:38.530 --> 01:40.400 everything, configuring 41 01:40.400 --> 01:46.520 dozens of devices to try to work in concert and orchestration with one another. 42 01:46.520 --> 01:52.040 Instead, we simply log into one interface, one device and tell the network how 43 01:52.040 --> 01:52.600 we want 44 01:52.600 --> 01:55.960 it to run and it pushes that configuration everywhere. 45 01:55.960 --> 02:00.480 It has an immense benefit to software defined architectures. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 45 01:55.960 --> 02:00.480 It has an immense benefit to software defined architectures. 46 02:00.480 --> 02:04.200 The last plane of operation is that orchestration plane. 47 02:04.200 --> 02:06.960 This is especially focused on onboarding. 48 02:06.960 --> 02:11.170 We want to be able to streamline our ability to spin up new software defined W 49 02:11.170 --> 02:12.240 AN, especially 50 02:12.240 --> 02:16.790 those WAN edge devices and the orchestration plane is going to help with the 51 02:16.790 --> 02:17.520 onboarding 52 02:17.520 --> 02:21.520 process, help with dealing with our NAT, bypass and such. 53 02:21.520 --> 02:27.460 And so all four of these planes of operation are mission critical for SD-WAN 54 02:27.460 --> 02:28.680 operation. 55 02:28.680 --> 02:33.760 Question number two, match the SD-WAN device to its plane of operation. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 55 02:28.680 --> 02:33.760 Question number two, match the SD-WAN device to its plane of operation. 56 02:33.760 --> 02:36.760 So we just talked about the four different planes. 57 02:36.760 --> 02:40.520 And what we find is that there's one device that belongs to each one of those 58 02:40.520 --> 02:41.120 planes of 59 02:41.120 --> 02:42.120 operation. 60 02:42.120 --> 02:43.560 So which one is which here? 61 02:43.560 --> 02:48.210 Well the SD-WAN edge devices would be the device that's actually sitting here 62 02:48.210 --> 02:49.200 at the edge 63 02:49.200 --> 02:52.800 of our network, of our wide area network specifically. 64 02:52.800 --> 02:57.600 And so usually this is our layer three router type of device that's going to 65 02:57.600 --> 02:58.560 communicate 66 02:58.560 --> 03:00.800 into the site. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 66 02:58.560 --> 03:00.800 into the site. 67 03:00.800 --> 03:05.770 And then it will have ideally a handful of wide area networking circuits back 68 03:05.770 --> 03:06.320 up into 69 03:06.320 --> 03:07.320 the network. 70 03:07.320 --> 03:13.230 So this is going to be responsible for sending traffic from one edge device to 71 03:13.230 --> 03:14.160 another edge 72 03:14.160 --> 03:17.040 device, which will communicate with another site. 73 03:17.040 --> 03:19.760 Maybe this is the headquarters. 74 03:19.760 --> 03:24.900 But either way, this device at the edge, this is part of our data plane of 75 03:24.900 --> 03:26.120 operations. 76 03:26.120 --> 03:27.320 So the V-Manage. 77 03:27.320 --> 03:32.840 The V-Manage is going to be our management plane as the name implies. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 77 03:27.320 --> 03:32.840 The V-Manage is going to be our management plane as the name implies. 78 03:32.840 --> 03:39.080 So this is where I as an admin once again need that single pane of glass. 79 03:39.080 --> 03:43.480 I'm going to log into V-Manage and it's going to push configuration everywhere. 80 03:43.480 --> 03:48.080 The V-Smart, this is the control plane device. 81 03:48.080 --> 03:53.900 So my V-Smart are going to receive routes and routing information and it's 82 03:53.900 --> 03:54.640 going to push 83 03:54.640 --> 03:59.920 it down to the other WAN edge devices. 84 03:59.920 --> 04:03.240 And then the V-Bond, this is part of that orchestration plane. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 84 03:59.920 --> 04:03.240 And then the V-Bond, this is part of that orchestration plane. 85 04:03.240 --> 04:06.520 And it's going to help me again with onboarding and that bypass. 86 04:06.520 --> 04:10.800 So the V-Bond has to be out here with a public IP address. 87 04:10.800 --> 04:17.170 It has to be reachable and fully accessible because again of that net bypass 88 04:17.170 --> 04:18.440 part of the 89 04:18.440 --> 04:19.680 operation. 90 04:19.680 --> 04:21.520 So these are the four devices. 91 04:21.520 --> 04:25.610 Also keep in mind, that Cisco has started to come up with new names for all of 92 04:25.610 --> 04:26.040 these 93 04:26.040 --> 04:27.040 devices. 94 04:27.040 --> 04:32.090 In fact, the edge device used to be known as the V-Edge and also the C-Edge as WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 94 04:27.040 --> 04:32.090 In fact, the edge device used to be known as the V-Edge and also the C-Edge as 95 04:32.090 --> 04:32.640 we talked 96 04:32.640 --> 04:33.640 about. 97 04:33.640 --> 04:35.400 So we're no longer calling the V-Edge. 98 04:35.400 --> 04:38.400 Well, Cisco started to migrate all of these as well. 99 04:38.400 --> 04:44.920 So when it comes to the V-Manage, we're talking about the SD WAN manager. 100 04:44.920 --> 04:49.950 With the V-Smart, we're talking about the controller, which fits pretty well 101 04:49.950 --> 04:50.580 with the 102 04:50.580 --> 04:52.400 control plane of operations. 103 04:52.400 --> 04:55.690 And then this is kind of the tricky one, orchestration plane, instead of 104 04:55.690 --> 04:56.200 calling it 105 04:56.200 --> 05:00.720 the V-Bond, they are now calling it the validator. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 105 04:56.200 --> 05:00.720 the V-Bond, they are now calling it the validator. 106 05:00.720 --> 05:05.670 So let's start to keep these new terms in mind as well as we learn the 107 05:05.670 --> 05:07.520 architecture and start 108 05:07.520 --> 05:09.520 to get our hands on it. 109 05:09.520 --> 05:13.740 It's going to depend on which Cisco documentation we're looking at, whether it 110 05:13.740 --> 05:14.400 's calling it 111 05:14.400 --> 05:16.160 the old names or the new names. 112 05:16.160 --> 05:20.400 And so that's why it's going to be important that we know both. 113 05:20.400 --> 05:25.640 Question number three, what type of tunnels are used for the SD WAN data plane? 114 05:25.640 --> 05:31.160 So the data plane is going to use secure tunnels that communicate between our WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 114 05:25.640 --> 05:31.160 So the data plane is going to use secure tunnels that communicate between our 115 05:31.160 --> 05:32.920 SD WAN edge devices. 116 05:32.920 --> 05:37.040 And so those secure tunnels are going to be formed using IPsec. 117 05:37.040 --> 05:42.630 So keep that in mind that when we've got our devices at the edge here, we've 118 05:42.630 --> 05:43.880 got lots of 119 05:43.880 --> 05:48.680 physical circuits and physical paths to one another. 120 05:48.680 --> 05:53.320 But one of the ways that SD WAN simplifies everything is by building tunnels. 121 05:53.320 --> 05:59.240 So I'm going to build, for example, an IPsec tunnel here across one WAN circuit 122 05:59.240 --> 05:59.720 over here 123 05:59.720 --> 06:03.160 as well with another WAN circuit or across the other WAN circuit. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 123 05:59.720 --> 06:03.160 as well with another WAN circuit or across the other WAN circuit. 124 06:03.160 --> 06:07.500 If they happen to both use the internet, we might see a full mesh of tunnels 125 06:07.500 --> 06:08.240 forming. 126 06:08.240 --> 06:11.080 But either way, these data plane tunnels are using IPsec. 127 06:11.080 --> 06:14.480 So when a packet shows up on this router, it needs to go over to this other 128 06:14.480 --> 06:15.160 site, it's 129 06:15.160 --> 06:19.440 going to ride one of those IPsec tunnels to the other side. 130 06:19.440 --> 06:22.120 That's what we mean by data plane operation. 131 06:22.120 --> 06:25.080 And it's very important that we're using IPsec because a huge part of what we 132 06:25.080 --> 06:25.640 're trying 133 06:25.640 --> 06:30.210 to accomplish with SD WAN is not only simplifying our traffic flow and giving WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 133 06:25.640 --> 06:30.210 to accomplish with SD WAN is not only simplifying our traffic flow and giving 134 06:30.210 --> 06:31.240 us more control 135 06:31.240 --> 06:35.900 over it, but also adding a layer of security, whether that's because we're 136 06:35.900 --> 06:36.760 riding over 137 06:36.760 --> 06:41.890 the internet or because we're using a service provider technology like MPLS 138 06:41.890 --> 06:42.760 that would be 139 06:42.760 --> 06:46.760 shared with other organizations. 140 06:46.760 --> 06:52.640 And question four, what does a VPN represent in Cisco's SD WAN architecture? 141 06:52.640 --> 06:55.980 This one might be a little bit tricky because VPN, as we've said, this usually 142 06:55.980 --> 06:56.800 means something 143 06:56.800 --> 07:01.120 different, especially when we're already talking about IPsec tunnels. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 143 06:56.800 --> 07:01.120 different, especially when we're already talking about IPsec tunnels. 144 07:01.120 --> 07:05.640 But within SD WAN architecture, the VPN is sort of like a VRF, which we'll be 145 07:05.640 --> 07:06.240 talking 146 07:06.240 --> 07:08.960 about in more detail coming up soon. 147 07:08.960 --> 07:13.080 But a VRF is essentially just a completely different routed domain. 148 07:13.080 --> 07:16.360 And so the answer here is going to be D. It's a segmented routing domain. 149 07:16.360 --> 07:21.240 And the primary reason we have this is for the sake of multi-tenancy. 150 07:21.240 --> 07:26.570 SD WAN is a technology that regularly gets deployed by service providers, and 151 07:26.570 --> 07:27.280 they sort 152 07:27.280 --> 07:30.280 of sell the solution and manage it. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 152 07:27.280 --> 07:30.280 of sell the solution and manage it. 153 07:30.280 --> 07:33.200 But the customer doesn't get to interface with it. 154 07:33.200 --> 07:36.940 We, as the service provider, are managing a multi-tenant environment, and 155 07:36.940 --> 07:37.880 therefore every 156 07:37.880 --> 07:42.040 customer is going to get their own VPN. 157 07:42.040 --> 07:45.540 That's why it's called a virtual private network, even though from a strict 158 07:45.540 --> 07:46.880 routing and switching 159 07:46.880 --> 07:50.760 perspective, it really is closer to a VRF. 160 07:50.760 --> 07:53.560 And so we need to think of it from both perspectives there. 161 07:53.560 --> 07:57.600 But either way, it is a segmented routing domain, and it's going to allow us to 162 07:57.600 --> 07:58.040 build 163 07:58.040 --> 08:01.760 things out securely if we do have multiple customers. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 163 07:58.040 --> 08:01.760 things out securely if we do have multiple customers. 164 08:01.760 --> 08:06.880 If we're an enterprise customer, we're probably going to have just one VPN in 165 08:06.880 --> 08:08.240 most situations 166 08:08.240 --> 08:11.960 outside of some of the other VPNs that are used for management. 167 08:11.960 --> 08:16.230 But if we have a use case for deploying multiple VPNs, then we can certainly 168 08:16.230 --> 08:17.200 take advantage 169 08:17.200 --> 08:18.840 of that as well. 170 08:18.840 --> 08:21.120 All right, question number five. 171 08:21.120 --> 08:22.520 We're halfway done, by the way. 172 08:22.520 --> 08:25.120 I didn't say it at the start, but we have eight questions. 173 08:25.120 --> 08:28.200 So we've answered four of them, four more to go, starting here with question 174 08:28.200 --> 08:29.520 number five. 175 08:29.520 --> 08:36.360 So what is the full VPN range in Cisco SD WAN and how are VPNs zero and 512 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 175 08:29.520 --> 08:36.360 So what is the full VPN range in Cisco SD WAN and how are VPNs zero and 512 176 08:36.360 --> 08:37.280 used? 177 08:37.280 --> 08:43.300 Well, the full range here originally actually was zero to 512, which is kind of 178 08:43.300 --> 08:44.320 interesting 179 08:44.320 --> 08:50.160 because, yeah, 512 is a binary number, but it goes one past the value. 180 08:50.160 --> 08:55.280 Like if we were actually using nine bits, then we would have zero to five 11. 181 08:55.280 --> 08:56.640 So we know we have more bits there. 182 08:56.640 --> 09:01.360 It's just the Cisco and Viptela, especially originally, we're restricting it. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 182 08:56.640 --> 09:01.360 It's just the Cisco and Viptela, especially originally, we're restricting it. 183 09:01.360 --> 09:07.720 The full range, at least at the time of this video is up to 65,530. 184 09:07.720 --> 09:12.980 Yeah, not three or five 35 like we might expect, which is again, is another 185 09:12.980 --> 09:14.560 binary number. 186 09:14.560 --> 09:18.480 Those last five must be reserved by Cisco for some reason at this point. 187 09:18.480 --> 09:20.680 But either way, that's the full range. 188 09:20.680 --> 09:26.240 However, two of those values, zero and 512 are reserved. 189 09:26.240 --> 09:30.010 And the reason why is zero and 512 of all these numbers comes back to the fact WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 189 09:26.240 --> 09:30.010 And the reason why is zero and 512 of all these numbers comes back to the fact 190 09:30.010 --> 09:30.360 that it 191 09:30.360 --> 09:35.920 used to be zero to 512 was allowed with the first and last being reserved. 192 09:35.920 --> 09:40.040 So our usable range actually is from one to five 11. 193 09:40.040 --> 09:46.120 And then we have to put a break here and say five 13 to 65,530. 194 09:46.120 --> 09:52.440 So this is the usable range of VPN IDs and zero and 512. 195 09:52.440 --> 09:53.640 Again, our reserve. 196 09:53.640 --> 09:54.960 So what are they reserved for? 197 09:54.960 --> 10:00.200 Well, VPN zero, this is going to be reserved for the actual WAN circuits, which WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 197 09:54.960 --> 10:00.200 Well, VPN zero, this is going to be reserved for the actual WAN circuits, which 198 10:00.200 --> 10:00.320 is the 199 10:00.320 --> 10:02.720 ultimately saying this is the underlay. 200 10:02.720 --> 10:09.160 Again, this is a completely segmented isolated routing environment. 201 10:09.160 --> 10:13.610 And what we're trying to create here is the idea that whatever this underlay 202 10:13.610 --> 10:14.400 looks like 203 10:14.400 --> 10:20.960 with multiple routers in the path that I'm just forming this tunnel and 204 10:20.960 --> 10:22.120 allowing my routes 205 10:22.120 --> 10:24.480 to flow over this tunnel. 206 10:24.480 --> 10:29.590 And I don't need to know these routes in the overlay and the underlay doesn't 207 10:29.590 --> 10:30.200 need to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 207 10:29.590 --> 10:30.200 need to 208 10:30.200 --> 10:32.160 know the overlay routes. 209 10:32.160 --> 10:34.240 So we're creating this. 210 10:34.240 --> 10:35.240 Draw it like this here. 211 10:35.240 --> 10:37.720 We're creating these two different routing domains. 212 10:37.720 --> 10:41.920 We're creating the underlay here and we're creating the overlay up here. 213 10:41.920 --> 10:45.940 And generally speaking, we don't want those routes to mix, which is why we have 214 10:45.940 --> 10:46.320 again, 215 10:46.320 --> 10:52.370 if we think about VPNs as VRFs, that's why we have our YN circuits listed and 216 10:52.370 --> 10:53.360 dedicated 217 10:53.360 --> 10:55.800 as a as VPN zero. 218 10:55.800 --> 10:58.460 Now we also have VPN 512. 219 10:58.460 --> 11:01.680 This is used for out of band management. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 219 10:58.460 --> 11:01.680 This is used for out of band management. 220 11:01.680 --> 11:06.360 And so this is really helpful and useful for organizations that like to isolate 221 11:06.360 --> 11:06.800 their 222 11:06.800 --> 11:10.600 management and keep that in a dedicated route and domain. 223 11:10.600 --> 11:17.030 But as far as our actual usable VPNs for our data traffic, we're going to have 224 11:17.030 --> 11:17.480 to pick 225 11:17.480 --> 11:18.640 one of these VPNs. 226 11:18.640 --> 11:21.700 Again, if we're an enterprise shop, we're probably just going to pick one of 227 11:21.700 --> 11:22.240 these. 228 11:22.240 --> 11:24.720 If we're a service provider, then we're going to use a whole lot of them 229 11:24.720 --> 11:25.840 because every customer 230 11:25.840 --> 11:28.760 is going to get their own. 231 11:28.760 --> 11:30.720 Question number six, it's about T locks here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 231 11:28.760 --> 11:30.720 Question number six, it's about T locks here. 232 11:30.720 --> 11:35.520 So what are the three components of a T lock, a transport locator? 233 11:35.520 --> 11:41.850 So the T locks are interesting because the T lock essentially defines a path to 234 11:41.850 --> 11:42.640 a router 235 11:42.640 --> 11:45.480 or really a WAN edge device. 236 11:45.480 --> 11:48.520 And yet it doesn't actually tell us how to get there. 237 11:48.520 --> 11:49.920 Kind of curious. 238 11:49.920 --> 11:53.120 We're going to need to rely on OMP to say, Hey, if you're trying to get to this 239 11:53.120 --> 11:53.600 T lock, 240 11:53.600 --> 11:55.840 go to this address. 241 11:55.840 --> 11:58.080 So what's the purpose of the T lock? 242 11:58.080 --> 12:00.920 Well, the T lock is used for making decisions. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 242 11:58.080 --> 12:00.920 Well, the T lock is used for making decisions. 243 12:00.920 --> 12:05.860 And I need to make decisions based on this three tuple set of data that's being 244 12:05.860 --> 12:06.660 presented 245 12:06.660 --> 12:11.060 by the WAN edge device, sort of describing itself and describing these 246 12:11.060 --> 12:12.360 different paths. 247 12:12.360 --> 12:16.080 So we can think of them as paths and how would we describe paths? 248 12:16.080 --> 12:20.600 Well, first of all, we're going to include the system IP here. 249 12:20.600 --> 12:27.200 So the system IP is again, not a routable or necessarily a routable IP address. 250 12:27.200 --> 12:31.080 It's just simply an identifier to say, Hey, this is me. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 250 12:27.200 --> 12:31.080 It's just simply an identifier to say, Hey, this is me. 251 12:31.080 --> 12:33.960 And I'm going to use the same system IP across different T locks. 252 12:33.960 --> 12:38.760 If I have different paths, the second part of the tuple is going to be the 253 12:38.760 --> 12:39.560 concept of 254 12:39.560 --> 12:40.760 the color. 255 12:40.760 --> 12:46.220 The color is essentially trying to say that this is part of a particular wide 256 12:46.220 --> 12:47.240 area network 257 12:47.240 --> 12:48.520 domain. 258 12:48.520 --> 12:53.990 So we've mentioned that a WAN edge device likely has at least a couple of upl 259 12:53.990 --> 12:55.160 ink circuits, 260 12:55.160 --> 12:59.410 especially if we're deploying SD WAN, if we just have a single uplink circuit, 261 12:59.410 --> 12:59.800 SD WAN 262 12:59.800 --> 13:02.080 isn't going to bring us a whole lot of value. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 262 12:59.800 --> 13:02.080 isn't going to bring us a whole lot of value. 263 13:02.080 --> 13:05.890 So it's usually going to be seen that we're deploying SD WAN when we have 264 13:05.890 --> 13:07.080 multiple circuits, 265 13:07.080 --> 13:11.120 we might even have three or four circuits at some critical sites. 266 13:11.120 --> 13:15.400 Well, this creates three different service provider paths. 267 13:15.400 --> 13:17.890 And as part of the T lock, I want you to know that, Hey, if you're trying to 268 13:17.890 --> 13:18.440 come in on 269 13:18.440 --> 13:23.680 this path, you're going to use this particular service provider. 270 13:23.680 --> 13:26.960 So the color remember is a string. 271 13:26.960 --> 13:30.050 And for better or worse, we can't define that ourselves, but Cisco gives us a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 271 13:26.960 --> 13:30.050 And for better or worse, we can't define that ourselves, but Cisco gives us a 272 13:30.050 --> 13:31.560 lot of options. 273 13:31.560 --> 13:35.680 And we can use things like red and green or gold and silver. 274 13:35.680 --> 13:40.840 And there's all kinds of other ones as well, even descriptors like MPLS. 275 13:40.840 --> 13:46.940 But this color is going to tell us about how I can approach and use this T lock 276 13:46.940 --> 13:46.960 . 277 13:46.960 --> 13:49.280 The last thing we need is the encapsulation. 278 13:49.280 --> 13:55.680 So the encapsulation is going to tell me what I'm using, whether it's IP sec or 279 13:55.680 --> 13:56.680 GRE. 280 13:56.680 --> 14:02.040 But we just got done saying that IP sec is used at the data plane. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 280 13:56.680 --> 14:02.040 But we just got done saying that IP sec is used at the data plane. 281 14:02.040 --> 14:05.400 And in every SD WAN deployment, this should be the case. 282 14:05.400 --> 14:09.680 Outside of maybe a lab environment, I suppose. 283 14:09.680 --> 14:11.880 But we do have GRE as an option. 284 14:11.880 --> 14:15.730 GRE is essentially just saying, Hey, we're going to use an unsecured tunnel 285 14:15.730 --> 14:16.600 rather than 286 14:16.600 --> 14:19.040 relying on the security of IP sec. 287 14:19.040 --> 14:23.990 There might be some really niche type of situations or corner case scenarios 288 14:23.990 --> 14:24.400 where we 289 14:24.400 --> 14:27.200 can't encrypt our traffic for one reason or another. 290 14:27.200 --> 14:30.000 Maybe it has to do with the country of operation. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 290 14:27.200 --> 14:30.000 Maybe it has to do with the country of operation. 291 14:30.000 --> 14:33.400 But generally speaking, we're going to be using IP sec. 292 14:33.400 --> 14:37.640 As I have said, keep in mind GRE is technically an option. 293 14:37.640 --> 14:40.960 And as a result, it's going to have to be included in the T lock. 294 14:40.960 --> 14:43.160 So the T lock again consists of three components. 295 14:43.160 --> 14:44.320 It's the system IP. 296 14:44.320 --> 14:48.440 It's the color and it's the encapsulation that can include in the T lock. 297 14:48.440 --> 14:54.640 And remember, these don't by themselves tell us how to route and get here. 298 14:54.640 --> 14:59.240 We're going to need OMP to glue that part together later. 299 14:59.240 --> 15:05.110 Question seven, which SD WAN device serves as an OMP route reflector among the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 299 14:59.240 --> 15:05.110 Question seven, which SD WAN device serves as an OMP route reflector among the 300 15:05.110 --> 15:06.400 WAN edges? 301 15:06.400 --> 15:12.400 Well, the answer here is just straight up the V smart, otherwise known as the 302 15:12.400 --> 15:12.960 SD WAN 303 15:12.960 --> 15:15.600 controller, I suppose with modern terms. 304 15:15.600 --> 15:19.800 But either way, this V smart is going to serve as a route reflector. 305 15:19.800 --> 15:21.160 What do we mean by route reflector? 306 15:21.160 --> 15:24.000 And why did I use quotes here to describe it? 307 15:24.000 --> 15:28.720 Well, it's because route reflector is actually a BGP term. 308 15:28.720 --> 15:34.560 But as we've said a few times, OMP is very BGP like in its behavior. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 308 15:28.720 --> 15:34.560 But as we've said a few times, OMP is very BGP like in its behavior. 309 15:34.560 --> 15:39.670 One of the ways that's BGP like is that it can perform its operations as a 310 15:39.670 --> 15:41.280 route reflector. 311 15:41.280 --> 15:45.680 Because unlike with our other routing protocols that use multicast, we're not 312 15:45.680 --> 15:46.440 just forming 313 15:46.440 --> 15:47.840 relationships with everybody. 314 15:47.840 --> 15:50.920 We can kind of choose who we form relationships with. 315 15:50.920 --> 15:54.760 And so I might have multiple WAN edge devices here. 316 15:54.760 --> 16:00.200 And I want to share a route into this space. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 316 15:54.760 --> 16:00.200 And I want to share a route into this space. 317 16:00.200 --> 16:05.450 Well, if I'm not using intelligence here, as far like trying to make it a 318 16:05.450 --> 16:06.080 little more 319 16:06.080 --> 16:11.880 efficient, I might have many, many, many WAN edges here. 320 16:11.880 --> 16:16.110 And if I was not going to use a route reflector or anything other, again, more 321 16:16.110 --> 16:16.920 efficient, 322 16:16.920 --> 16:21.750 I'd have to share this with every single other WAN edge device so they know how 323 16:21.750 --> 16:22.560 to get to 324 16:22.560 --> 16:23.560 this route. 325 16:23.560 --> 16:25.560 Well, fortunately, I don't have to worry about that. 326 16:25.560 --> 16:30.290 I don't have to maintain a full mesh of adjacencies, which as we can imagine, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 326 16:25.560 --> 16:30.290 I don't have to maintain a full mesh of adjacencies, which as we can imagine, 327 16:30.290 --> 16:31.200 as this grows out, 328 16:31.200 --> 16:36.130 it would become very unsustainable for us to have that many OMP adjacencies or 329 16:36.130 --> 16:36.820 whatever 330 16:36.820 --> 16:39.240 routing protocol we're using at that point. 331 16:39.240 --> 16:42.900 Instead, the V smarts going to serve as a route reflector, which means I 332 16:42.900 --> 16:43.680 advertise it 333 16:43.680 --> 16:49.270 one time to the V smart and it's responsible for pushing it down to all of the 334 16:49.270 --> 16:50.080 other WAN 335 16:50.080 --> 16:51.760 edge devices. 336 16:51.760 --> 16:54.240 So the V smart is a very important part of this. 337 16:54.240 --> 16:56.120 OMP is a very important part of this. 338 16:56.120 --> 17:00.170 And in this case, our focus is just simply trying to say, "Hey, I've got this WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 338 16:56.120 --> 17:00.170 And in this case, our focus is just simply trying to say, "Hey, I've got this 339 17:00.170 --> 17:01.120 route subnet 340 17:01.120 --> 17:03.520 A I want you all to know about." 341 17:03.520 --> 17:07.640 And the V smart helps me get the word out to the rest of the WAN edges that 342 17:07.640 --> 17:09.080 route A lives 343 17:09.080 --> 17:10.720 on my port. 344 17:10.720 --> 17:15.720 All right, question number eight, the last question, which six parameters are 345 17:15.720 --> 17:16.240 used to 346 17:16.240 --> 17:22.440 identify a traffic flow for application aware routing when DPI isn't in use? 347 17:22.440 --> 17:27.820 Cisco's deep packet inspection or DPI is really great for identifying traffic 348 17:27.820 --> 17:28.720 types. 349 17:28.720 --> 17:35.190 And this is important because as part of deploying SD WAN, I can look at WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 349 17:28.720 --> 17:35.190 And this is important because as part of deploying SD WAN, I can look at 350 17:35.190 --> 17:36.560 traffic coming 351 17:36.560 --> 17:40.320 in and identify the traffic. 352 17:40.320 --> 17:44.000 And depending on the traffic type, I might want to send some traffic one way 353 17:44.000 --> 17:44.320 and some 354 17:44.320 --> 17:45.920 traffic another way. 355 17:45.920 --> 17:49.280 For example, I might want to send my bulk traffic across an internet circuit, 356 17:49.280 --> 17:49.640 but my 357 17:49.640 --> 17:55.920 voiceover IP traffic should go out towards MPLS, something along those lines. 358 17:55.920 --> 18:00.160 So the question is, how do I identify the traffic? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 358 17:55.920 --> 18:00.160 So the question is, how do I identify the traffic? 359 18:00.160 --> 18:04.250 And deep packet inspection is a great way to do it, but as we recall, it does 360 18:04.250 --> 18:04.800 require 361 18:04.800 --> 18:06.560 an additional license. 362 18:06.560 --> 18:10.160 And we make sure we have the right hardware in place and all of that. 363 18:10.160 --> 18:14.840 So we have a backup plan, which is to use the six tuple. 364 18:14.840 --> 18:18.160 We talked about the three tuple, tuple earlier with T locks. 365 18:18.160 --> 18:19.880 Now we're talking about the six tuple. 366 18:19.880 --> 18:25.080 So we're simply going to equate a flow to the six tuple. 367 18:25.080 --> 18:29.890 If we share these six pieces of information, then we are part of the same 368 18:29.890 --> 18:31.120 traffic flow. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 368 18:29.890 --> 18:31.120 traffic flow. 369 18:31.120 --> 18:33.640 And so that's how we're going to identify our traffic. 370 18:33.640 --> 18:34.800 So how do we do this? 371 18:34.800 --> 18:40.960 Well, we're going to take a look at the six different, six different, I guess, 372 18:40.960 --> 18:42.680 identifiers. 373 18:42.680 --> 18:44.080 We have to look through each one of these. 374 18:44.080 --> 18:47.000 So first of all, we're going to look at the IP address for source and 375 18:47.000 --> 18:47.840 destination. 376 18:47.840 --> 18:49.400 So that would be two of them. 377 18:49.400 --> 18:52.850 We're not going to look at the MAC addresses because MAC addresses can be 378 18:52.850 --> 18:53.680 deceptive. 379 18:53.680 --> 18:58.060 If we're routing between two different routers, well, the source of destination 380 18:58.060 --> 18:59.120 MAC address, 381 18:59.120 --> 19:00.120 those are brand new. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 381 18:59.120 --> 19:00.120 those are brand new. 382 19:00.120 --> 19:01.120 They're just for those routers. 383 19:01.120 --> 19:04.240 It doesn't tell us what actually is communicating. 384 19:04.240 --> 19:06.520 So we don't want to rely on MAC addresses. 385 19:06.520 --> 19:09.160 IP addresses are persistent end to end. 386 19:09.160 --> 19:11.600 So would be the source and destination port. 387 19:11.600 --> 19:12.840 That's another two of our six. 388 19:12.840 --> 19:15.240 So we're up to four so far. 389 19:15.240 --> 19:20.320 And then we're also going to take a look at DSCP and protocol number. 390 19:20.320 --> 19:22.760 So these would be our six points of identifications. 391 19:22.760 --> 19:26.540 It's going to allow us to identify traffic as it comes into the router, make 392 19:26.540 --> 19:27.120 sure that's 393 19:27.120 --> 19:31.760 going out the appropriate up link when we're using application aware routing. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 393 19:27.120 --> 19:31.760 going out the appropriate up link when we're using application aware routing. 394 19:31.760 --> 19:34.760 So that ends the quiz for SDWAN. 395 19:34.760 --> 19:38.230 Let's go ahead and jump into a challenge to make sure that we fully grasp how 396 19:38.230 --> 19:38.960 the architecture 397 19:38.960 --> 19:39.640 comes together.