WEBVTT 1 00:00.000 --> 00:07.760 So the claim at this point is that we have a set of win challenges and that SD- 2 00:07.760 --> 00:08.080 WAN is 3 00:08.080 --> 00:10.840 going to solve some of these problems for us. 4 00:10.840 --> 00:13.540 In order to prove that to ourselves, let's go ahead and list a few of the 5 00:13.540 --> 00:14.160 biggest win 6 00:14.160 --> 00:18.130 challenges we have and then talk about how this fancy new solution of ours is 7 00:18.130 --> 00:18.760 going to 8 00:18.760 --> 00:21.000 address the challenges. 9 00:21.000 --> 00:25.960 So first of all, as we talked about, we have routing complexities. 10 00:25.960 --> 00:29.320 The routing complexities are pretty enormous, really. 11 00:29.320 --> 00:34.860 I mean, for large organizations that are dealing with thousands of sites, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 11 00:29.320 --> 00:34.860 I mean, for large organizations that are dealing with thousands of sites, 12 00:34.860 --> 00:35.340 trying to wrap 13 00:35.340 --> 00:38.560 our arms around all of that, but we've talked about some specifics. 14 00:38.560 --> 00:46.120 We have to share routes, for example, with the SP when it comes to MPLS. 15 00:46.120 --> 00:50.290 And that makes it so we have to do routing redistribution and prevent routing 16 00:50.290 --> 00:51.040 loops and 17 00:51.040 --> 00:52.720 all of those types of things. 18 00:52.720 --> 00:58.020 We also talked about application-specific direction, meaning that maybe I want 19 00:58.020 --> 00:58.760 voiceover 20 00:58.760 --> 01:03.620 IP to go out MPLS and I want the rest of my traffic to go out the internet and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 20 00:58.760 --> 01:03.620 IP to go out MPLS and I want the rest of my traffic to go out the internet and 21 01:03.620 --> 01:04.160 I want 22 01:04.160 --> 01:09.720 to make sure that different applications maybe are using one or the other. 23 01:09.720 --> 01:13.710 So just the idea of directing out a particular win link depending on the 24 01:13.710 --> 01:14.840 traffic type is 25 01:14.840 --> 01:18.340 something that introduces a massive amount of complexities to traditional 26 01:18.340 --> 01:19.080 networking. 27 01:19.080 --> 01:24.560 Lastly, some amount of failover can be challenging. 28 01:24.560 --> 01:28.890 And again, it's not so much if a circuit goes down because routing protocols 29 01:28.890 --> 01:29.640 largely take 30 01:29.640 --> 01:31.080 care of that for us. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 30 01:29.640 --> 01:31.080 care of that for us. 31 01:31.080 --> 01:38.960 But what about not just outages, but also as we said, degradation. 32 01:38.960 --> 01:44.160 So if a particular circuit's having problems on this day for an hour, can we 33 01:44.160 --> 01:45.160 automatically 34 01:45.160 --> 01:50.250 divert traffic out the other win link and then allow us to detect when the 35 01:50.250 --> 01:51.160 first one is 36 01:51.160 --> 01:52.600 good and swing back over. 37 01:52.600 --> 01:54.600 So failover and failback. 38 01:54.600 --> 01:56.600 So lots of routing complexities. 39 01:56.600 --> 01:59.800 Now on top of all of this, we've got a lot of win circuits. 40 01:59.800 --> 02:02.280 We have a lot of devices that are out there. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 40 01:59.800 --> 02:02.280 We have a lot of devices that are out there. 41 02:02.280 --> 02:05.320 So just management of all these devices. 42 02:05.320 --> 02:09.150 When we're talking about software-defined networking one of the big benefits 43 02:09.150 --> 02:09.680 typically 44 02:09.680 --> 02:12.400 is in how we manage the system. 45 02:12.400 --> 02:15.680 Because we want to make sure that we can manage all these devices, but we don't 46 02:15.680 --> 02:16.600 have to 47 02:16.600 --> 02:21.000 want to have to log in and manage all these devices on top of being very 48 02:21.000 --> 02:22.280 specific in regards 49 02:22.280 --> 02:26.240 to our configurations of so many different policies and protocols. 50 02:26.240 --> 02:28.320 We also have a security problem. 51 02:28.320 --> 02:34.520 We've already mentioned that the internet has no encryption by default. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 51 02:28.320 --> 02:34.520 We've already mentioned that the internet has no encryption by default. 52 02:34.520 --> 02:38.600 And so we might want to encrypt our traffic that's going across the internet. 53 02:38.600 --> 02:40.520 And most organizations do that. 54 02:40.520 --> 02:43.040 But this isn't just about the internet. 55 02:43.040 --> 02:45.080 It's also about MPLS circuits. 56 02:45.080 --> 02:49.430 Now we say, well, why would we need to encrypt our traffic across an MPLS 57 02:49.430 --> 02:50.280 circuit? 58 02:50.280 --> 02:51.280 It's more private. 59 02:51.280 --> 02:53.280 It's not the public internet. 60 02:53.280 --> 02:58.000 Well MPLS is a multi-tenant environment. 61 02:58.000 --> 03:01.760 Meaning that this is a service provider that has many customers. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 61 02:58.000 --> 03:01.760 Meaning that this is a service provider that has many customers. 62 03:01.760 --> 03:06.960 And they might accidentally send our traffic to the wrong location. 63 03:06.960 --> 03:11.320 Maybe directly to a location that's logging all of the information. 64 03:11.320 --> 03:15.490 And so we just shared secrets by accident through no fault of our own 65 03:15.490 --> 03:17.920 technically to a different 66 03:17.920 --> 03:18.920 organization. 67 03:18.920 --> 03:23.330 That matter if there is a rogue employee working for the service provider that 68 03:23.330 --> 03:23.960 just wants to 69 03:23.960 --> 03:24.960 capture our traffic. 70 03:24.960 --> 03:30.160 I mean, we're opening ourselves up to risk that our traffic could become WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 70 03:24.960 --> 03:30.160 I mean, we're opening ourselves up to risk that our traffic could become 71 03:30.160 --> 03:31.480 available in some 72 03:31.480 --> 03:32.480 way. 73 03:32.480 --> 03:36.690 And so we have to worry about the fact that we have no encryption even over 74 03:36.690 --> 03:37.560 circuits such 75 03:37.560 --> 03:39.720 as MPLS. 76 03:39.720 --> 03:46.280 And then lastly, we mentioned it before, but the expense of our WANs. 77 03:46.280 --> 03:50.000 So we're especially talking about MPLS circuits. 78 03:50.000 --> 03:53.760 We're talking about maybe T3s and E3s. 79 03:53.760 --> 03:56.640 To some extent, T1s and E1s as well. 80 03:56.640 --> 04:02.300 If we have dark fiber services or for that matter, lit fiber services, a lot of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 80 03:56.640 --> 04:02.300 If we have dark fiber services or for that matter, lit fiber services, a lot of 81 04:02.300 --> 04:03.480 these WAN 82 04:03.480 --> 04:06.720 types can be very expensive. 83 04:06.720 --> 04:13.120 And so we find that we need to have one of them, maybe it's MPLS, as a reliable 84 04:13.120 --> 04:13.880 option. 85 04:13.880 --> 04:18.240 And then we try to have our redundant circuit via the internet because it's 86 04:18.240 --> 04:19.360 less expensive. 87 04:19.360 --> 04:24.160 But we can't replace both of these with the internet and be very inexpensive 88 04:24.160 --> 04:25.080 overall because 89 04:25.080 --> 04:28.680 of all of the downfalls that the internet brings with it. 90 04:28.680 --> 04:31.640 So that is our list of challenges that we need to address. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 90 04:28.680 --> 04:31.640 So that is our list of challenges that we need to address. 91 04:31.640 --> 04:37.540 So how does software defined WAN come into play as we start to unpack the 92 04:37.540 --> 04:39.000 architecture, 93 04:39.000 --> 04:43.120 which we really still have yet to do, but at a high level, what are we trying 94 04:43.120 --> 04:44.000 to accomplish 95 04:44.000 --> 04:52.000 with SD WAN and the solutions that it claims to bring? 96 04:52.000 --> 04:54.160 Well let's just go through these one by one. 97 04:54.160 --> 04:57.440 And we're going to start with the routing complexities. 98 04:57.440 --> 05:02.140 So the routing complexities are going to be resolved because we're adopting a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 98 04:57.440 --> 05:02.140 So the routing complexities are going to be resolved because we're adopting a 99 05:02.140 --> 05:02.800 software 100 05:02.800 --> 05:06.800 defined architecture or a software defined network. 101 05:06.800 --> 05:11.580 And I think back to when we studied VXLAN, and we talked about how we've got 102 05:11.580 --> 05:12.440 different 103 05:12.440 --> 05:17.770 architectures and we can leverage VXLAN over different fabrics, which allows us 104 05:17.770 --> 05:18.480 to pretty 105 05:18.480 --> 05:24.400 much create the network that I want. 106 05:24.400 --> 05:28.080 And that's compared to the network that I have. 107 05:28.080 --> 05:32.720 So what I have is a bunch of circuits. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 107 05:28.080 --> 05:32.720 So what I have is a bunch of circuits. 108 05:32.720 --> 05:33.960 But what do I want? 109 05:33.960 --> 05:38.250 I might want a completely different network and I'm going to use tunnels in 110 05:38.250 --> 05:39.640 order to create 111 05:39.640 --> 05:40.640 that network. 112 05:40.640 --> 05:43.080 And tunnels are like the Swiss Army knife of networking. 113 05:43.080 --> 05:47.890 I can kind of do whatever I want with tunnels because I just direct traffic and 114 05:47.890 --> 05:48.800 encapsulate 115 05:48.800 --> 05:50.640 it from one router to another. 116 05:50.640 --> 05:55.860 I might have this crazy network with a bunch of routers and I have to make sure 117 05:55.860 --> 05:56.560 that every 118 05:56.560 --> 06:00.480 router knows where the destination is because when a packet arrives there, they WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 118 05:56.560 --> 06:00.480 router knows where the destination is because when a packet arrives there, they 119 06:00.480 --> 06:00.920 have to 120 06:00.920 --> 06:04.200 forward it towards that destination. 121 06:04.200 --> 06:10.880 Or I can say, you know what, I'm going to build a tunnel from one router to the 122 06:10.880 --> 06:11.040 other and 123 06:11.040 --> 06:14.920 then all of these routers in the middle just have to know how to get to that 124 06:14.920 --> 06:15.880 router because 125 06:15.880 --> 06:18.040 I'm just sending it essentially to that router. 126 06:18.040 --> 06:19.840 I mean, encapsulating it here. 127 06:19.840 --> 06:23.910 I'm forwarding it to this router and so everybody's forwarding it to a 128 06:23.910 --> 06:25.640 different destination, 129 06:25.640 --> 06:30.730 not to the final destination, but to the router that is terminating the tunnel, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 129 06:25.640 --> 06:30.730 not to the final destination, but to the router that is terminating the tunnel, 130 06:30.730 --> 06:31.360 which is 131 06:31.360 --> 06:32.600 kind of interesting. 132 06:32.600 --> 06:37.120 So now we're hiding those inner headers and we're able to route between the 133 06:37.120 --> 06:38.240 edge routers. 134 06:38.240 --> 06:42.390 This is really important because now we don't need to worry about sharing 135 06:42.390 --> 06:43.320 routes with our 136 06:43.320 --> 06:44.840 service provider. 137 06:44.840 --> 06:48.000 The service provider's routers would be the ones here in the middle. 138 06:48.000 --> 06:51.450 If I'm forwarding traffic through an MPLS circuit, they have to know where the 139 06:51.450 --> 06:52.160 destination 140 06:52.160 --> 06:56.160 network is, which is why I usually have to share my routes with them. 141 06:56.160 --> 06:59.560 But if I'm building tunnels, well, I'm just going from one public IP address or 142 06:59.560 --> 06:59.960 at least 143 06:59.960 --> 07:05.280 an IP address that's in their network to an IP address that is also in their WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 143 06:59.960 --> 07:05.280 an IP address that's in their network to an IP address that is also in their 144 07:05.280 --> 07:06.280 network. 145 07:06.280 --> 07:08.400 I should need to share routes with them at all. 146 07:08.400 --> 07:12.190 They should know how to get from one of their subnets to another one of their 147 07:12.190 --> 07:12.840 subnets, 148 07:12.840 --> 07:16.480 which is absolutely amazing. 149 07:16.480 --> 07:21.680 Furthermore, because of tunneling architectures, I can now build tunnels 150 07:21.680 --> 07:23.280 through two different 151 07:23.280 --> 07:24.440 circuit types. 152 07:24.440 --> 07:30.930 So now I can have my router that is connected into whatever this circuit type WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 152 07:24.440 --> 07:30.930 So now I can have my router that is connected into whatever this circuit type 153 07:30.930 --> 07:31.560 is. 154 07:31.560 --> 07:33.320 We're just going to call it number one. 155 07:33.320 --> 07:37.080 And whatever this circuit type is down here, we're going to call it number two. 156 07:37.080 --> 07:40.720 And I've got circuits going again to this other router. 157 07:40.720 --> 07:43.960 Well, first of all, I am building the tunnel. 158 07:43.960 --> 07:46.560 I'm going to build a tunnel through this service provider. 159 07:46.560 --> 07:49.920 I'm going to build another tunnel through this service provider. 160 07:49.920 --> 07:55.870 And now I have a whole lot more control from an application perspective, 161 07:55.870 --> 07:56.640 because I can 162 07:56.640 --> 08:00.090 decide based on the application as defined in software, whether I'm going to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 162 07:56.640 --> 08:00.090 decide based on the application as defined in software, whether I'm going to 163 08:00.090 --> 08:00.600 send it out 164 08:00.600 --> 08:03.040 this tunnel or that tunnel. 165 08:03.040 --> 08:07.930 And that's the end of the story from a route switch architecture perspective 166 08:07.930 --> 08:08.560 with an SD 167 08:08.560 --> 08:09.560 WAN. 168 08:09.560 --> 08:12.960 I don't have to worry about what's happening inside either of these underlays. 169 08:12.960 --> 08:17.200 I just have to worry about inserting a particular traffic type into a 170 08:17.200 --> 08:18.600 particular tunnel. 171 08:18.600 --> 08:22.200 And that's going to help me take care of things from that perspective. 172 08:22.200 --> 08:29.520 I can also run a lot of metrics and detect when we have degradation. 173 08:29.520 --> 08:33.220 And if I can control which application through software is going out which of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 173 08:29.520 --> 08:33.220 And if I can control which application through software is going out which of 174 08:33.220 --> 08:34.200 these tunnels, 175 08:34.200 --> 08:39.070 what all I have to do is pass that information up to the application controller 176 08:39.070 --> 08:39.720 , which will 177 08:39.720 --> 08:42.120 determine which tunnel I'm going to use. 178 08:42.120 --> 08:48.780 So the routing complexities are going to be much reduced when it comes to SD W 179 08:48.780 --> 08:49.080 AN. 180 08:49.080 --> 08:53.860 And at a minimum, we can see very clearly how we no longer have to share routes 181 08:53.860 --> 08:54.320 with the 182 08:54.320 --> 08:56.040 service provider. 183 08:56.040 --> 08:59.120 Now the management is a relatively quick conversation. 184 08:59.120 --> 09:03.700 We are going to manage all this through a single pane of glass as we like to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 184 08:59.120 --> 09:03.700 We are going to manage all this through a single pane of glass as we like to 185 09:03.700 --> 09:04.280 say, meaning 186 09:04.280 --> 09:11.610 that I have a single controller, an SDN controller that I log into and I 187 09:11.610 --> 09:13.880 perform all of these configurations. 188 09:13.880 --> 09:19.360 When we say, talking about app control and all these metrics and analyzing all 189 09:19.360 --> 09:20.120 of that, 190 09:20.120 --> 09:25.810 that is going to be the responsibility of the SDN control plane and management 191 09:25.810 --> 09:26.560 plane. 192 09:26.560 --> 09:30.120 And that's going to be seen here via the single pane of glass. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 192 09:26.560 --> 09:30.120 And that's going to be seen here via the single pane of glass. 193 09:30.120 --> 09:34.070 I as the network admin, I can log into the single pane of glass rather than 194 09:34.070 --> 09:34.920 having to log 195 09:34.920 --> 09:40.240 into lots and lots of different routers. 196 09:40.240 --> 09:44.400 Next up from a security perspective, we are going to not just use tunnels, but 197 09:44.400 --> 09:45.040 we are going 198 09:45.040 --> 09:49.200 to use encrypted tunnels. 199 09:49.200 --> 09:54.910 Specifically, the tunnels we're talking about here, these are going to use IP 200 09:54.910 --> 09:56.080 sec, allowing 201 09:56.080 --> 10:01.130 us to encrypt our tunnels regardless of whether this is the internet circuit WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 201 09:56.080 --> 10:01.130 us to encrypt our tunnels regardless of whether this is the internet circuit 202 10:01.130 --> 10:01.960 and the MPLS 203 10:01.960 --> 10:05.360 circuit down here or vice versa, or maybe they're both MPLS circuits. 204 10:05.360 --> 10:06.360 It doesn't matter. 205 10:06.360 --> 10:08.880 I'm going to encrypt it no matter what. 206 10:08.880 --> 10:13.660 So now, not only am I not sharing my routes with my service provider, I'm not 207 10:13.660 --> 10:14.720 sending my 208 10:14.720 --> 10:17.480 data in plain text to them either. 209 10:17.480 --> 10:21.840 So overall, a big win from a security perspective. 210 10:21.840 --> 10:25.550 And last but not least, the cost from an IT perspective, we don't always care 211 10:25.550 --> 10:26.040 about the 212 10:26.040 --> 10:27.040 cost of a solution. 213 10:27.040 --> 10:32.480 We just want the best solution from an administrative management perspective. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 213 10:27.040 --> 10:32.480 We just want the best solution from an administrative management perspective. 214 10:32.480 --> 10:34.960 We like inexpensive solutions. 215 10:34.960 --> 10:39.240 This is an interesting conversation now because what have we said about the 216 10:39.240 --> 10:40.120 internet? 217 10:40.120 --> 10:43.800 The internet is cheap, but it's potentially unreliable. 218 10:43.800 --> 10:49.560 Now, when I say it's unreliable, it's usually not unreliable minute to minute. 219 10:49.560 --> 10:53.280 It's usually more like we have some congestion on the internet. 220 10:53.280 --> 10:55.440 I can't control quality of service as well. 221 10:55.440 --> 10:59.240 And therefore, there's going to be network drops at various times of day. 222 10:59.240 --> 11:04.000 So this unreliable nature, as long as it's not rampant, means that I could WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 222 10:59.240 --> 11:04.000 So this unreliable nature, as long as it's not rampant, means that I could 223 11:04.000 --> 11:04.800 probably run 224 11:04.800 --> 11:09.400 on the internet circuit 95% of the time. 225 11:09.400 --> 11:14.560 But what happens now, given that I have this app level of control, and I have 226 11:14.560 --> 11:15.480 the ability 227 11:15.480 --> 11:21.800 to detect when we have degradation, can I just deploy two internet circuits? 228 11:21.800 --> 11:24.400 We'll look at this topology up here. 229 11:24.400 --> 11:29.140 What happens if we have an internet circuit for topology one or circuit one, 230 11:29.140 --> 11:29.880 but we also 231 11:29.880 --> 11:34.070 have another internet circuit, a completely different service provider as my WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 231 11:29.880 --> 11:34.070 have another internet circuit, a completely different service provider as my 232 11:34.070 --> 11:35.800 second path. 233 11:35.800 --> 11:41.450 And so if we say, well, this is 95% reliable, and this one's 95% reliable, as 234 11:41.450 --> 11:42.440 long as the odds 235 11:42.440 --> 11:47.060 are pretty low that they're both unreliable at the same time, we, a lot of 236 11:47.060 --> 11:48.040 cases, can just 237 11:48.040 --> 11:50.040 adopt two different internet circuits. 238 11:50.040 --> 11:55.360 It at least allows us to have the conversation, and it truly is a conversation. 239 11:55.360 --> 12:00.520 This is not a recommendation from Cisco, or for me, for that matter, that we go WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 239 11:55.360 --> 12:00.520 This is not a recommendation from Cisco, or for me, for that matter, that we go 240 12:00.520 --> 12:01.000 out and 241 12:01.000 --> 12:02.400 cancel MPLS circuits. 242 12:02.400 --> 12:06.520 But we can at least have the conversation that, hey, if we live in a part of 243 12:06.520 --> 12:07.560 the world, 244 12:07.560 --> 12:12.540 and where we just got very reliable internet, then maybe we could have two 245 12:12.540 --> 12:13.880 internet circuits, 246 12:13.880 --> 12:16.800 and that would greatly drive the cost down. 247 12:16.800 --> 12:21.400 So that's going to be a potential that comes out of the SD-WAN world, which 248 12:21.400 --> 12:22.160 allows us to 249 12:22.160 --> 12:27.320 at least think outside the box of having to have MPLS circuits. 250 12:27.320 --> 12:32.040 So at this point, again, from a very high level, we can see that SD-WAN at WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 250 12:27.320 --> 12:32.040 So at this point, again, from a very high level, we can see that SD-WAN at 251 12:32.040 --> 12:32.880 least claims to 252 12:32.880 --> 12:36.840 have solutions to all of the different challenges that we have in our 253 12:36.840 --> 12:38.680 traditional WAN architectures.