WEBVTT 1 00:00.000 --> 00:05.240 Well, it's one thing that SD-WAN is good at, it's making tunnels. 2 00:05.240 --> 00:09.240 We're going to have a whole lot of tunnels at play and this is going to apply 3 00:09.240 --> 00:09.480 to not 4 00:09.480 --> 00:13.240 just the data plane, but also the control plane. 5 00:13.240 --> 00:17.750 And so we're going to look at both of these here in this video and find that 6 00:17.750 --> 00:18.160 what we're 7 00:18.160 --> 00:24.000 really looking for here is to maintain a topology using the tunnels. 8 00:24.000 --> 00:28.640 Remember, we want to create that network that we want, but we also want to 9 00:28.640 --> 00:29.280 secure our 10 00:29.280 --> 00:31.040 communications. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 10 00:29.280 --> 00:31.040 communications. 11 00:31.040 --> 00:34.890 And this is especially going to be true for the control plane because we're 12 00:34.890 --> 00:35.400 sending 13 00:35.400 --> 00:37.480 critical information across it. 14 00:37.480 --> 00:40.120 But naturally we want to secure the data plane as well. 15 00:40.120 --> 00:43.560 And so we're actually going to find that we do this differently depending on 16 00:43.560 --> 00:44.560 the communications 17 00:44.560 --> 00:46.440 that we're talking about. 18 00:46.440 --> 00:49.760 So let's start with our data plane. 19 00:49.760 --> 00:55.750 When we build out the SD-WAN data plane, it's going to involve our WAN edges 20 00:55.750 --> 00:55.960 and they 21 00:55.960 --> 01:00.400 are going to form these IPsec tunnels with one another. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 21 00:55.960 --> 01:00.400 are going to form these IPsec tunnels with one another. 22 01:00.400 --> 01:07.960 Now it's worth noting that we can create non-secure tunnels using GRE. 23 01:07.960 --> 01:10.440 There might be a reason why we have to do this. 24 01:10.440 --> 01:15.330 And but outside of that situation, whatever that situation is, we should really 25 01:15.330 --> 01:15.880 never be 26 01:15.880 --> 01:18.960 looking at deploying non-encrypted tunnels. 27 01:18.960 --> 01:22.680 There's going to have to be a really specific reason why we want that. 28 01:22.680 --> 01:26.920 And there might just be some network infrastructures that don't support IPsec. 29 01:26.920 --> 01:31.600 So ideally, hopefully, we're building these tunnels on IPsec. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 29 01:26.920 --> 01:31.600 So ideally, hopefully, we're building these tunnels on IPsec. 30 01:31.600 --> 01:35.480 Now when we look at the data plane itself, we're going to have all of these WAN 31 01:35.480 --> 01:36.840 edge devices 32 01:36.840 --> 01:41.760 that exist and communicate through some kind of WAN circuit. 33 01:41.760 --> 01:46.970 Maybe we've got four routers here and they all connect into this MPLS 34 01:46.970 --> 01:48.360 environment. 35 01:48.360 --> 01:52.440 So at this point, we've got sites and subnets located behind all of these 36 01:52.440 --> 01:55.240 different WAN edges. 37 01:55.240 --> 01:59.920 We're going to want to enable communication between our WAN edge devices. 38 01:59.920 --> 02:04.740 Well remember, with SD-WAN, we're no longer exchanging routes back and forth WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 38 01:59.920 --> 02:04.740 Well remember, with SD-WAN, we're no longer exchanging routes back and forth 39 02:04.740 --> 02:05.480 with the service 40 02:05.480 --> 02:06.480 provider. 41 02:06.480 --> 02:08.240 We don't do that anymore. 42 02:08.240 --> 02:14.670 And so in order for me to get traffic from one subnet here to another subnet, 43 02:14.670 --> 02:15.160 well, 44 02:15.160 --> 02:20.120 I'm going to have to build a tunnel across this communications path. 45 02:20.120 --> 02:25.550 So this tunnel is again, ideally, an IPsec tunnel or again, it could be GRE if 46 02:25.550 --> 02:26.360 needed. 47 02:26.360 --> 02:30.350 And in a lot of situations, we're going to want to build these tunnels out to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 47 02:26.360 --> 02:30.350 And in a lot of situations, we're going to want to build these tunnels out to 48 02:30.350 --> 02:30.840 all of these 49 02:30.840 --> 02:34.480 other devices, usually in full mesh fashion. 50 02:34.480 --> 02:35.480 But here's the thing. 51 02:35.480 --> 02:41.930 We actually have a lot of different topology options for building out our data 52 02:41.930 --> 02:43.200 plane tunnels. 53 02:43.200 --> 02:48.640 For example, given what I just wrote out here, drew out, we actually have 54 02:48.640 --> 02:49.520 created a hub 55 02:49.520 --> 02:51.480 in spoke topology. 56 02:51.480 --> 02:53.000 And we can enforce this policy. 57 02:53.000 --> 02:54.000 Maybe we want this. 58 02:54.000 --> 02:59.400 Maybe we want all of the remote sites to go through our headquarters location. 59 02:59.400 --> 03:04.440 And so now if we want to communicate from this subnet to this subnet over here, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 59 02:59.400 --> 03:04.440 And so now if we want to communicate from this subnet to this subnet over here, 60 03:04.440 --> 03:04.680 we would 61 03:04.680 --> 03:09.850 actually have to go through the hub and then communicate out to the spoke, even 62 03:09.850 --> 03:10.200 though 63 03:10.200 --> 03:14.880 we could have formed a tunnel this way, but we chose not to in this situation. 64 03:14.880 --> 03:17.760 So that would be hub and spoke as an option. 65 03:17.760 --> 03:22.580 And we as the admins, we get to decide which one of these topology options that 66 03:22.580 --> 03:23.200 we want. 67 03:23.200 --> 03:24.760 We get to decide this. 68 03:24.760 --> 03:26.840 So maybe we choose hub and spoke. 69 03:26.840 --> 03:33.000 Maybe we actually want to rely on a point-to-point type of communications path. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 69 03:26.840 --> 03:33.000 Maybe we actually want to rely on a point-to-point type of communications path. 70 03:33.000 --> 03:37.930 So maybe there's a very specific path between these two sites that I'd want to 71 03:37.930 --> 03:39.280 build out. 72 03:39.280 --> 03:42.720 And so I could actually build that as a point-to-point link. 73 03:42.720 --> 03:45.960 And otherwise we're going to rely on the hub and spoke topology. 74 03:45.960 --> 03:49.520 So we can kind of tack that on where it makes sense to do so. 75 03:49.520 --> 03:54.040 We could also simply call this a partial mesh. 76 03:54.040 --> 03:59.710 And we see that given the line I just drew here between these two sites, that 77 03:59.710 --> 04:00.160 we just WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 77 03:59.710 --> 04:00.160 we just 78 04:00.160 --> 04:05.520 have sort of a mishmash or a hodgepodge or whatever we want to call it. 79 04:05.520 --> 04:10.250 There's a bunch of tunnels out there and we're all kind of connecting to other 80 04:10.250 --> 04:10.880 routers and 81 04:10.880 --> 04:12.280 various fashions. 82 04:12.280 --> 04:16.890 But in the end, if I want to get from any one site to any other site, I do have 83 04:16.890 --> 04:17.520 a path through 84 04:17.520 --> 04:22.000 the fabric and through all of these different tunnels in order to get from any 85 04:22.000 --> 04:22.680 location to 86 04:22.680 --> 04:24.520 any other location. 87 04:24.520 --> 04:30.060 Now naturally where we can go with this is to complete all of these connections WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 87 04:24.520 --> 04:30.060 Now naturally where we can go with this is to complete all of these connections 88 04:30.060 --> 04:30.200 . 89 04:30.200 --> 04:35.280 And once they're connected fully, that would be a full mesh topology. 90 04:35.280 --> 04:39.160 In a lot of situations, we're probably going to want to consider full mesh. 91 04:39.160 --> 04:41.680 It just allows for the greatest flexibility. 92 04:41.680 --> 04:45.720 If I want to go from this site to this site, why not just take a tunnel 93 04:45.720 --> 04:47.040 directly there? 94 04:47.040 --> 04:51.280 Why go through the headquarters location unless we have a good reason to do so? 95 04:51.280 --> 04:53.040 Now there might be a good reason to do so. 96 04:53.040 --> 04:57.790 And if so, we can certainly deploy a hub and spoke type of topology and SD-WAN 97 04:57.790 --> 04:58.560 makes that 98 04:58.560 --> 05:01.840 very simple for us to deploy and manage. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 98 04:58.560 --> 05:01.840 very simple for us to deploy and manage. 99 05:01.840 --> 05:04.120 So that's the data plane side of things. 100 05:04.120 --> 05:06.560 Now let's talk about the control plane. 101 05:06.560 --> 05:11.840 And we recall we have these three different devices that operate within the 102 05:11.840 --> 05:12.680 control plane 103 05:12.680 --> 05:13.680 side of things. 104 05:13.680 --> 05:20.000 And yes, I'm grouping in the management and orchestration planes as well. 105 05:20.000 --> 05:23.900 So we're really talking about everything other than the data plane at this 106 05:23.900 --> 05:24.480 point. 107 05:24.480 --> 05:29.840 And so those three devices are the V-smart, let's just draw it out like this. 108 05:29.840 --> 05:35.440 The V-smart, the V-bond, and the V-manage. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 108 05:29.840 --> 05:35.440 The V-smart, the V-bond, and the V-manage. 109 05:35.440 --> 05:41.040 And then we do still have our when edge devices down here. 110 05:41.040 --> 05:44.450 Because they're going to participate in control plane management and orchest 111 05:44.450 --> 05:45.120 ration plane 112 05:45.120 --> 05:46.960 communications. 113 05:46.960 --> 05:50.040 We have to receive information naturally. 114 05:50.040 --> 05:54.300 And so the question is how does the traffic flow among all of these different 115 05:54.300 --> 05:55.120 devices? 116 05:55.120 --> 06:00.360 Well, what we're going to find is we're also going to form tunnels. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 116 05:55.120 --> 06:00.360 Well, what we're going to find is we're also going to form tunnels. 117 06:00.360 --> 06:05.080 But in this case, we're not going to deploy IPsec or GRE tunnels. 118 06:05.080 --> 06:10.490 Instead, we're either going to use transport layer security or we can use dat 119 06:10.490 --> 06:11.560 agram transport 120 06:11.560 --> 06:16.000 layer security, so TLS or DTLS. 121 06:16.000 --> 06:17.600 What's the difference between them? 122 06:17.600 --> 06:21.680 Well, the big difference is that TLS is TCP based. 123 06:21.680 --> 06:26.160 And datagram TLS might give us a hint as to what this is doing. 124 06:26.160 --> 06:32.900 The user datagram protocol or UDP is going to be how we perform or how we form WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 124 06:26.160 --> 06:32.900 The user datagram protocol or UDP is going to be how we perform or how we form 125 06:32.900 --> 06:34.800 DTLS tunnels. 126 06:34.800 --> 06:40.060 So once again, we as the admins, we get to choose which one of these tunnel 127 06:40.060 --> 06:41.560 types to use 128 06:41.560 --> 06:44.760 in a lot of situations. 129 06:44.760 --> 06:47.760 Which one do we choose and why do we choose one over the other? 130 06:47.760 --> 06:51.240 Well, it's going to depend on our network. 131 06:51.240 --> 06:54.680 TCP is usually better for stateful inspections. 132 06:54.680 --> 07:00.810 If we have these communications paths going through firewalls and we want to be WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 132 06:54.680 --> 07:00.810 If we have these communications paths going through firewalls and we want to be 133 07:00.810 --> 07:01.400 able to 134 07:01.400 --> 07:06.480 track them and look at them, well, maybe we want to go with TCP. 135 07:06.480 --> 07:09.520 But UDP is typically a little bit more seamless in operation. 136 07:09.520 --> 07:12.200 We don't have to worry about forming connections. 137 07:12.200 --> 07:17.900 We don't have to worry about a lot of the pain points of TCP, especially in a 138 07:17.900 --> 07:18.640 situation 139 07:18.640 --> 07:20.240 where we're using NAT and the like. 140 07:20.240 --> 07:25.880 And so in a lot of cases, we might choose DTLS over TLS. 141 07:25.880 --> 07:29.680 But again, it's going to depend on our organizational needs. 142 07:29.680 --> 07:34.650 And if we really don't have a preference between one or the other, just choose WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 142 07:29.680 --> 07:34.650 And if we really don't have a preference between one or the other, just choose 143 07:34.650 --> 07:35.200 one and 144 07:35.200 --> 07:36.200 deploy it. 145 07:36.200 --> 07:37.680 It's as simple as that. 146 07:37.680 --> 07:39.520 So we need to deploy our tunnels. 147 07:39.520 --> 07:44.160 And the idea here is that by deploying a tunnel, let's say between the V-Smart 148 07:44.160 --> 07:44.520 and the 149 07:44.520 --> 07:50.200 V-EG, again, both of these TLS and DTLS, these are providing encryption. 150 07:50.200 --> 07:58.310 So it's not like the data plane where we could actually deploy a GRE and not 151 07:58.310 --> 07:58.960 encrypt our 152 07:58.960 --> 08:03.040 communications path with the control and management and orchestration plane. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 152 07:58.960 --> 08:03.040 communications path with the control and management and orchestration plane. 153 08:03.040 --> 08:08.970 We are going to have to deploy encryption because we have to choose TLS or DTLS 154 08:08.970 --> 08:09.000 . 155 08:09.000 --> 08:14.280 Now interestingly, when we are looking at this, we also find that we form 156 08:14.280 --> 08:15.200 tunnels among 157 08:15.200 --> 08:17.240 some of these devices up here. 158 08:17.240 --> 08:23.090 So we're going to leverage the V-Bond and we're going to form what must be DTLS 159 08:23.090 --> 08:24.240 connections 160 08:24.240 --> 08:26.640 to the V-Manage and the V-Smart. 161 08:26.640 --> 08:30.980 The reason why we're using DTLS here is recall that the V-Bond is going to be WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 161 08:26.640 --> 08:30.980 The reason why we're using DTLS here is recall that the V-Bond is going to be 162 08:30.980 --> 08:31.840 out on the public 163 08:31.840 --> 08:36.520 internet and it's responsible for things like net traversal. 164 08:36.520 --> 08:41.680 And so we want to leverage UDP-based connections for that sake. 165 08:41.680 --> 08:46.850 Now when the edge device comes online, it's also going to form a DTLS 166 08:46.850 --> 08:48.040 connection to the 167 08:48.040 --> 08:53.190 V-Bond and we're going to perform authentication and the discovery of the other 168 08:53.190 --> 08:54.080 devices. 169 08:54.080 --> 08:58.160 At this point, this is a temporary connection and once I have all the 170 08:58.160 --> 09:00.440 information, I actually WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 170 08:58.160 --> 09:00.440 information, I actually 171 09:00.440 --> 09:01.440 tear it down. 172 09:01.440 --> 09:05.160 I don't maintain that tunnel over the course of time. 173 09:05.160 --> 09:08.800 Because at that point, I'm going to form my tunnel to the V-Smart and my tunnel 174 09:08.800 --> 09:09.080 to the 175 09:09.080 --> 09:19.000 V-Manage and this is where we can choose the DTLS or the DTLS connections. 176 09:19.000 --> 09:23.690 Now something to keep in mind here is that recall that the V-Manage has an 177 09:23.690 --> 09:24.720 active standby 178 09:24.720 --> 09:25.720 option. 179 09:25.720 --> 09:30.210 So we could actually, ideally we will, have a second V-Manage here and we could WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 179 09:25.720 --> 09:30.210 So we could actually, ideally we will, have a second V-Manage here and we could 180 09:30.210 --> 09:31.320 have many 181 09:31.320 --> 09:36.040 different V-Smarts depending on the size and scope of our environment. 182 09:36.040 --> 09:40.170 And so yes, we are going to form the tunnels out to these redundant devices as 183 09:40.170 --> 09:40.720 well. 184 09:40.720 --> 09:44.720 Oh, and let's not forget that the V-Smart and V-Manage also have tunnels 185 09:44.720 --> 09:45.920 because the V-Manage 186 09:45.920 --> 09:49.390 needs to push policy out to the V-Smarts for the sake of distributing that out 187 09:49.390 --> 09:49.720 to the 188 09:49.720 --> 09:50.720 edge. 189 09:50.720 --> 09:53.900 So this is our tunnel framework we see we don't just use tunnels at the data 190 09:53.900 --> 09:54.440 plane, but 191 09:54.440 --> 09:58.100 we use tunnels at the control plane in order to secure all communications 192 09:58.100 --> 09:58.560 within our 193 09:58.560 --> 09:59.720 SD-WAN environment.