WEBVTT 00:00:01.000 --> 00:00:06.560 All right, and now I just want to have a quick discussion on SD-WAN. I am not here 00:00:06.560 --> 00:00:10.840 to teach you all about SD-WAN. I'm here to make sure that you prepare properly 00:00:10.840 --> 00:00:17.440 for the exam. So, SD-WAN, software-defined WAN, is what? Software-defined Wide Area 00:00:17.440 --> 00:00:23.400 Networking. It's really a technological shift and a mind shift for us when it 00:00:23.400 --> 00:00:27.520 comes to wide area networking. It says your SD-WAN is a technology that 00:00:27.559 --> 00:00:30.639 utilizes software-defined networking principles to manage and optimize the 00:00:30.639 --> 00:00:36.680 distribution of network traffic across a wide area network. It offers the ability 00:00:36.680 --> 00:00:42.279 to dynamically route and prioritize network traffic based on factors such as 00:00:42.279 --> 00:00:51.000 application type, network conditions, and business policies. Hmm. So, let me compare 00:00:51.000 --> 00:00:55.639 that to my traditional WAN that I might have. My traditional WAN might be just a 00:00:55.639 --> 00:01:00.599 simple MPLS connection between all of my different sites that I have, or it 00:01:00.599 --> 00:01:07.879 might be IPsec site-to-site VPNs I have, or it might be DMVPNs that I have set up. 00:01:07.879 --> 00:01:15.040 What's the difference then between that type of WAN setup versus SD-WAN? Well, the 00:01:15.040 --> 00:01:24.760 difference is managing, monitor, maintaining, control, automation, 00:01:24.760 --> 00:01:34.839 programmability, which I don't get with traditional WAN networking. All of those 00:01:34.839 --> 00:01:40.559 buzzwords I just threw out there are greatly enhanced when we're talking 00:01:40.559 --> 00:01:49.360 about SD-WAN. The ability to dynamically route and prioritize network traffic 00:01:49.360 --> 00:01:53.400 based on factors such as application type, network conditions, and business 00:01:53.400 --> 00:01:59.519 policies. I don't get that with traditional WANs. So, with SD-WAN, here's 00:01:59.519 --> 00:02:05.800 your buzz list of benefits. Drag and drop the benefits of SD-WAN. Of the following 00:02:05.800 --> 00:02:10.039 options, please pick benefits of SD-WAN. Improved network performance, shorter 00:02:10.039 --> 00:02:12.800 installation times, cost savings, centralized management, application-aware 00:02:12.800 --> 00:02:16.639 routing, flexible and agility, security enhancements, redundancy and failure, cloud 00:02:16.639 --> 00:02:23.520 readiness, all compared to what? Traditional WANs. That's great. Thank you 00:02:23.520 --> 00:02:27.880 for all those buzzwords, Cisco. Great marketing words that I may need to know 00:02:27.880 --> 00:02:32.080 for the exam. Why would I want to choose SD-WAN over traditional, folks? Boom, there 00:02:32.080 --> 00:02:36.720 you go. Those are great ones. Are they going to test you on its limitations? 00:02:36.759 --> 00:02:40.800 No, of course not. But I'll tell you some limitations so that way you don't think 00:02:40.800 --> 00:02:44.360 I'm a fanboy of SD-WAN and I'm just trying to promote it. Okay, initial 00:02:44.360 --> 00:02:49.080 investment. Whoo! How many of you have implemented SD-WAN and the cost was a 00:02:49.080 --> 00:02:56.520 lot? I once had a student who went through Encore with me. Yeah, answers like 00:02:56.520 --> 00:03:03.720 yep. I once had a student who went through Encore with me and she, actually 00:03:03.720 --> 00:03:07.279 she went through CCNA, Encore, and RC. My gosh, like she went through everything. 00:03:07.279 --> 00:03:12.320 And her growth was phenomenal. She learned everything she could, studied 00:03:12.320 --> 00:03:16.119 studies that took years, but my gosh. In the end, she contacted me. She goes, hey, I 00:03:16.119 --> 00:03:22.320 just got contacted by Cisco, none of that, and they really want me to invest in SD-WAN. 00:03:22.320 --> 00:03:29.360 She goes, but I don't see the benefit for me. So we had a conversation about it and 00:03:30.000 --> 00:03:37.720 in the end, it was like, no, the numbers are like astronomical. It was like 50 00:03:37.720 --> 00:03:45.160 times cheaper to just go out and buy like new ASAs and just simply set up IPsec 00:03:45.160 --> 00:03:50.119 site-to-site VPN tunnels and DMVPNs and stuff like that and just go that route. 00:03:50.119 --> 00:03:57.039 Because she didn't need all that extra stuff, a lot of those extra benefits. She 00:03:57.039 --> 00:04:00.479 didn't need the centralized management. There wasn't enough sites that it would 00:04:00.479 --> 00:04:05.559 make like the cost-benefit analysis. The flexibility and agility was not enough 00:04:05.559 --> 00:04:09.800 to justify the costs. The security enhancements, again, was not enough to 00:04:09.800 --> 00:04:16.000 justify the cost because with the IPsec site-to-site VPNs and the DMVPNs 00:04:16.000 --> 00:04:20.720 using IPsec and all that, I mean, you got the security you want in that case. So 00:04:20.720 --> 00:04:26.640 and again, the redundancy and failure, all that type of stuff just wasn't enough to 00:04:26.640 --> 00:04:39.559 just justify the cost. So initial investment, high. Complexity, right? 00:04:39.559 --> 00:04:45.679 Initially learning about it, doing it, yeah, it is complex. Dependency on 00:04:45.679 --> 00:04:49.440 internet connectivity. So here's the thing. One of the things that you see in 00:04:49.440 --> 00:04:54.839 a lot of marketing things is like, oh, you know, when it comes to SD-WAN, right, you 00:04:55.600 --> 00:04:58.320 don't have to worry about your connections. Of course I do. I still need 00:04:58.320 --> 00:05:02.200 an internet connection or an MPLS connection or an LTE connection. I still 00:05:02.200 --> 00:05:05.320 have to pay for that. I still have to work with my service provider to get 00:05:05.320 --> 00:05:10.160 that set up before we can do SD-WAN anyways. What am I doing with SD-WAN? I'm 00:05:10.160 --> 00:05:13.000 building a virtual network on top of those connections. That's what I'm doing. 00:05:13.000 --> 00:05:19.440 I'm building a virtual network on top of those different types of connections. So 00:05:19.440 --> 00:05:22.920 I still have to deal with all that other stuff and that other stuff can still be 00:05:22.920 --> 00:05:29.119 costly. There are security concerns as well when it comes to what? Securing this 00:05:29.119 --> 00:05:35.519 stuff now, especially if it's in the cloud. I can totally lock in myself on a 00:05:35.519 --> 00:05:43.720 vendor now. That's right. You can have quality of service issues. You can. I mean 00:05:43.720 --> 00:05:48.320 although there are built-in mechanisms so you don't, you totally can, especially if 00:05:48.320 --> 00:05:51.959 all of a sudden you are on the backup path and it's the internet because it 00:05:51.959 --> 00:05:56.600 dynamically flipped over to that and it wasn't supposed to maybe. It can happen. 00:05:56.600 --> 00:06:01.920 There are integration challenges. There's a learning curve, right? Some of the 00:06:01.920 --> 00:06:05.480 things here as they say like centralized management is supposed to save you money. 00:06:05.480 --> 00:06:13.279 That's a benefit. That's only if once you finish doing SD-WAN you are no longer 00:06:13.279 --> 00:06:19.399 really worrying about it and it's just working as it should and magically doing 00:06:19.399 --> 00:06:23.119 everything it should without you ever having to get involved. Yeah, that's where 00:06:23.119 --> 00:06:27.600 you get savings but if you're constantly managing it, you're constantly having to 00:06:27.600 --> 00:06:31.200 dive and you're constantly have to verify this, verify that, troubleshoot this, then I 00:06:31.200 --> 00:06:36.119 mean you're in no better shape than you were before. So when I hear a lot of the 00:06:36.119 --> 00:06:41.720 buzzwords for SD-WAN, for me personally, it's marketing stuff and in the end it's 00:06:41.720 --> 00:06:45.079 up to you to figure out are we really gonna benefit from this before you pull 00:06:45.079 --> 00:06:52.519 the trigger. That's important, right? Now that is not part of the exam, okay? Some 00:06:52.519 --> 00:06:55.920 of those buzzwords, yes, okay? Like if they ask you, what are the benefits of going to SD-WAN? 00:06:55.920 --> 00:07:00.119 Okay, know this stuff, right? Pick it out. I'm gonna have cost savings whether it's 00:07:00.119 --> 00:07:03.480 true for you or not in the real world. I'm gonna have shorter install times. I'll 00:07:03.480 --> 00:07:07.480 tell you right now, some people have had longer install times in the beginning 00:07:07.480 --> 00:07:13.619 but down the road, right? When they added sites, it was shorter. You see there's the 00:07:14.100 --> 00:07:21.059 payoff, right? If you're constantly growing and evolving then yes, over time 00:07:21.059 --> 00:07:29.940 you can save on time, money, energy, right? That's over time but if you set up SD-WAN 00:07:29.940 --> 00:07:36.140 and it's that forever, you may never save. It's really tough to know. You got to do 00:07:36.140 --> 00:07:39.820 your cost-benefit analysis for the real world, okay? That's me telling you 00:07:39.820 --> 00:07:45.579 personally about stuff like that. So for the exam though, I really need you to be 00:07:45.579 --> 00:07:51.019 able to pick these four names out of a lineup for the certification exam. That's 00:07:51.019 --> 00:07:54.820 your number one goal. Do you know what orchestration plane is? Do you know what 00:07:54.820 --> 00:07:57.859 management plane is? Do you know what control plane is? Do you know what data 00:07:57.859 --> 00:08:07.739 plane is? Number one. So what is our orchestration plane? So folks, our 00:08:07.779 --> 00:08:20.380 orchestration plane is going to be the device, whether it's on-prem or in-cloud 00:08:20.380 --> 00:08:33.340 that has the ability to do the onboarding of our entire SD-WAN. So here 00:08:33.340 --> 00:08:39.500 is some keywords to keep in mind. Orchestrates to control in management 00:08:39.500 --> 00:08:45.020 plane. So it's about onboarding all of the other devices. vManage, vSmart are 00:08:45.020 --> 00:08:49.419 what? Our edge devices, whether they're virtual edge devices or physical edge 00:08:49.419 --> 00:08:56.099 devices. Orchestrate them. Onboard them. It is the first point of authentication 00:08:56.099 --> 00:09:00.780 as well. Are these devices and services actually allowed to be part of this SD-WAN 00:09:00.780 --> 00:09:08.619 architecture? It then has the ability to distribute the vManage information and 00:09:08.619 --> 00:09:12.859 the vSmart information to your edge devices, virtual and physical edge 00:09:12.859 --> 00:09:18.299 devices. So meaning your routers that form your tunnels over the WAN. They can 00:09:18.299 --> 00:09:23.580 do NAT traversal or well or facilitates NAT traversal vBOT. It's gonna have to 00:09:23.580 --> 00:09:28.219 have a public IP address. Why? Because it needs to be reachable over what? The 00:09:28.219 --> 00:09:35.140 internet. And it's gonna be a highly resilient device of some type. Meaning 00:09:35.140 --> 00:09:37.900 you're gonna have to make sure it is resilient because it's responsible for 00:09:37.900 --> 00:09:45.140 the onboarding of your devices when they come up. Key things to keep in mind, key 00:09:45.140 --> 00:09:51.219 things to remember when it comes to your vBond device, the orchestration plane. So 00:09:51.219 --> 00:09:55.260 yeah, in your on-prem data center you can set up your vBond. Or you could set it 00:09:55.260 --> 00:09:59.260 up in Cisco, AWS, Azure. And what are we setting up? We're setting up a server that 00:09:59.260 --> 00:10:03.940 has the ability to do the orchestration for us. Now what about the control plane? 00:10:03.940 --> 00:10:09.140 Let's jump down to the control plane. So the control plane is this device right 00:10:09.140 --> 00:10:16.140 here. We call it vSmart in the world of Cisco. vSmart. And what are we dealing 00:10:16.140 --> 00:10:22.820 with in this case? We're dealing with our controller for the control plane. Now I'm 00:10:22.820 --> 00:10:26.539 not talking about like your graphical user interface. I'm not talking about 00:10:26.539 --> 00:10:31.859 that device. No, no, that's vManage, right? In this case vSmart is our software-based 00:10:31.859 --> 00:10:36.739 component either on-prem, Azure, AWS, Cisco, running on a virtual machine, something 00:10:36.739 --> 00:10:40.820 like that, okay? And this software-based component is responsible for the 00:10:40.820 --> 00:10:46.179 centralized control plane of the SD-WAN network. So what is it going to do? It's 00:10:46.179 --> 00:10:51.580 going to learn everything that you have defined. So it learns about all the 00:10:51.580 --> 00:10:56.140 policies that you've defined. Through what? Through your vManage console that 00:10:56.140 --> 00:11:03.340 you have. So it learns how the network needs to be based on the policies that 00:11:03.340 --> 00:11:11.659 you have defined. It's your centralized enforcer of policy and control. In 00:11:11.659 --> 00:11:17.340 addition, it can learn, as you can see, learn from other devices. So already it's 00:11:17.340 --> 00:11:23.539 learning from vManage through you or vManage monitoring statistics and 00:11:23.539 --> 00:11:28.619 measurements and realizing something's wrong and then telling vSmart 00:11:28.619 --> 00:11:34.859 dynamically to make a change to the environment. Or vSmart can learn even 00:11:34.859 --> 00:11:39.340 from the edge devices directly. So that way there it can make adjustments or 00:11:39.340 --> 00:11:43.099 changes on the flight, all depending on how you set it up and how you want to 00:11:43.099 --> 00:11:48.099 use it. So some things to keep in mind. vSmart is going to be used for what? 00:11:48.099 --> 00:11:53.580 Facilitating the discovery of your fabric. So what devices are part of that 00:11:53.580 --> 00:11:58.659 fabric? Through what? Through vBond as well. vBond has to let it know, right, who 00:11:58.659 --> 00:12:02.859 is part of this fabric. Who do we need to register? Who do we need to work with? And 00:12:02.859 --> 00:12:08.099 so on and so forth. And so this is your control plane information. Control plane 00:12:08.099 --> 00:12:12.900 information for all those edge devices. So the edge devices are about what? Data 00:12:12.900 --> 00:12:17.460 plane. Forwarding traffic. Forwarding traffic. That's your edge devices. 00:12:17.460 --> 00:12:24.780 vSmart is the brains. Think of it. Brains making decisions. That's vSmart. 00:12:24.780 --> 00:12:32.340 Control plane. And then it tells the data plane, tells the edge devices what to do. 00:12:32.340 --> 00:12:39.419 Through what? Through things like routing policies, security policies, any other 00:12:39.460 --> 00:12:45.859 types of policies that you set up. So it reduces your control plane complexity. So 00:12:45.859 --> 00:12:51.460 here's one of the powers of SD-WAN over traditional WANs. In traditional WANs, 00:12:51.460 --> 00:13:00.380 folks, how many control planes do you have in a traditional WAN? Okay, the 00:13:00.380 --> 00:13:04.380 number of control planes you have in a traditional WAN equals the number of 00:13:04.380 --> 00:13:12.580 devices you have. So if you have a hundred WAN routers between headquarters 00:13:12.580 --> 00:13:18.059 and branches you have, then every single one of those devices have their own 00:13:18.059 --> 00:13:24.780 control plane that you have to manage, monitor, and maintain. But if you switch 00:13:24.780 --> 00:13:30.859 to SD-WAN, now you've got one centralized control plane and a backup, 00:13:30.859 --> 00:13:35.859 hopefully, okay? Therefore, dramatically reducing the control plane complexity. 00:13:35.859 --> 00:13:45.140 So all the brains of all the devices are here now. And you want to make sure it's 00:13:45.140 --> 00:13:48.219 a highly resilient device. 00:13:48.219 --> 00:14:05.419 When we talk about learning information from the edges, right, we can gather what 00:14:05.419 --> 00:14:14.500 telemetry data from WAN devices. That's what we can do. And when we tell things, 00:14:14.539 --> 00:14:18.900 distribute routes, policy, security, right, that's when we are updating it on, you 00:14:18.900 --> 00:14:22.099 know, what do you need to do? How does your VPN need to be set up? How are you 00:14:22.099 --> 00:14:25.059 going to handle traffic? What protocols are you going to use to secure it? Etc., 00:14:25.059 --> 00:14:31.299 etc. All right, now we got our data plane. So the data plane is what? That's where 00:14:31.299 --> 00:14:35.780 you're going to have your physical edge devices or your virtual edge devices. So 00:14:35.780 --> 00:14:40.900 virtual edge devices could be, for example, like a virtual router that is 00:14:40.900 --> 00:14:45.940 set up in the cloud in an AWS network or a Cisco network. So that way there, you 00:14:45.940 --> 00:14:52.979 can have your cloud infrastructure as part of your WAN architecture. So that way 00:14:52.979 --> 00:14:59.020 there, you are going to have the same policies on that WAN architecture in the 00:14:59.020 --> 00:15:03.739 cloud as you would in your headquarters and branch offices, as an example, right? 00:15:03.739 --> 00:15:06.099 And then maybe your branch offices and headquarters, you'll have physical 00:15:06.099 --> 00:15:08.859 devices. But you could still have virtual devices where maybe you have a server 00:15:08.859 --> 00:15:12.219 set up so the traffic comes in. It first goes to the server or wherever in the 00:15:12.219 --> 00:15:16.940 branch office, let's say, and then can go out to the users as it goes through that 00:15:16.940 --> 00:15:20.020 edge device. So whether the edge device is physical or virtual, it doesn't really 00:15:20.020 --> 00:15:22.340 matter, right? They're going to be responsible for the same thing. And 00:15:22.340 --> 00:15:26.539 primarily that is traffic forwarding, security, encryption, quality of service. 00:15:26.539 --> 00:15:30.580 But how does it know what to do? How does it know how to forward traffic? How does 00:15:30.580 --> 00:15:33.859 it know how to secure traffic? How does it know how to encrypt traffic? How does 00:15:33.859 --> 00:15:36.140 it know how to do quality of service? Well, that comes from who? That comes 00:15:36.140 --> 00:15:42.260 from vSmart. And we said vSmart learns from what? From you configuring policies 00:15:42.260 --> 00:15:47.179 through vManage, as an example. It can learn from the edge devices that are 00:15:47.179 --> 00:15:53.619 constantly working and then sending data to vSmart. So then vSmart can say, oh my 00:15:53.619 --> 00:15:56.299 gosh, wait a second. We've got such and such an issue with quality of service. 00:15:56.299 --> 00:15:59.739 Let's go ahead and adjust what we're doing. So that way there, we don't have 00:15:59.739 --> 00:16:06.119 the quality of service issue anymore. But our edge devices, not vSmart. Let me 00:16:06.119 --> 00:16:11.440 take off that circle now. But our edge devices, like this device right here, 00:16:11.440 --> 00:16:16.359 provide secure data plane with remote edge routers. Establish a secure control 00:16:16.359 --> 00:16:23.000 plane with vSmart controllers using a protocol called OMP. So OMP is the 00:16:23.000 --> 00:16:28.280 overlay management protocol. That is the protocol that runs between vSmart and 00:16:28.280 --> 00:16:33.359 our edge devices. So that way there, we have the opportunity to talk to each 00:16:33.359 --> 00:16:39.960 other. So whenever we have policies from vSmart that need to be told to 00:16:39.960 --> 00:16:45.000 the edge devices, we use the overlay management protocol in order to 00:16:45.000 --> 00:16:52.200 accomplish that. Implements data plane and application away routing policies. We 00:16:52.200 --> 00:16:57.200 can export performance statistics up to vSmart from our edge devices. We can use 00:16:57.200 --> 00:17:01.080 traditional routing protocols like OSPF, BGP, VRRP, other things like that with 00:17:01.080 --> 00:17:05.640 our vEdge edge devices. We get zero touch deployment, meaning like plug and 00:17:05.640 --> 00:17:09.119 play type of deployment where, let's say we had another branch office coming up. 00:17:09.119 --> 00:17:14.359 We get a new device. We put it in. We'd have to go to our vManage and do the 00:17:14.359 --> 00:17:20.880 initial, provide the information that we need to into vManage. And then from there, 00:17:20.880 --> 00:17:28.520 vBond can do what it needs to do from an orchestration standpoint and onboard 00:17:28.520 --> 00:17:31.680 that particular new device into our vManage and everything else that goes on 00:17:31.680 --> 00:17:35.160 with that and confirm that it's actually a true Cisco product that's registered 00:17:35.160 --> 00:17:39.000 and paid for it and all that stuff through serial numbers. There's a lot. 00:17:39.000 --> 00:17:44.599 There's a lot going on there. And as I said, we got physical devices and virtual 00:17:44.599 --> 00:17:48.680 devices with many different port speeds to accomplish whatever you need. And then 00:17:48.680 --> 00:17:52.119 lastly here, we have vManage. vManage, I want you to remember, is your 00:17:52.119 --> 00:17:57.880 management plane. This is your dashboard for management. It's your single plane 00:17:57.880 --> 00:18:03.959 of management for Cisco SD-WAN. So on the exam, just think about how you might 00:18:03.959 --> 00:18:07.599 be tested on these. What is your centralized network management system in 00:18:07.599 --> 00:18:12.400 SD-WAN? It's called vManage, not dnaCenter. dnaCenter is for SD-Access. 00:18:12.400 --> 00:18:18.560 vManage is for SD-WAN. dnaCenter is for SD-Access. vManage is for SD-WAN. That's 00:18:18.560 --> 00:18:22.839 what you might be tested on. Right, you got your graphical user interface to 00:18:22.839 --> 00:18:30.079 easily monitor, configure, and maintain your Cisco SD-WAN environment. So vBond, 00:18:30.079 --> 00:18:34.760 onboarding. vManage, management. It's your dashboard, your graphical user interface, 00:18:34.760 --> 00:18:43.199 control plane, vSmart, brains, data plane, edge, vEdge, power, brawn, forwarding. 00:18:43.199 --> 00:18:50.479 That's what it's all about. So OMP, I mentioned it. I want to give you a little 00:18:50.479 --> 00:18:53.400 bit of details for it in case anything comes up like this on the certification 00:18:53.400 --> 00:19:02.280 exam. So OMP stands for overlay management protocol. It is TCP based, 00:19:02.280 --> 00:19:06.439 control plane protocol. So essentially we're creating a TCP session from here 00:19:06.439 --> 00:19:13.239 to here, from here to here. So that runs between what? It's going to run between 00:19:13.239 --> 00:19:22.000 our edge devices, virtual or physical, and vSmart. And we are using this protocol inside 00:19:22.000 --> 00:19:30.280 of a dynamic TLS, transport layer security connection. So how is OMP being 00:19:30.280 --> 00:19:36.800 protected inside of dynamic transport layer security, DTLS? So DTLS is going to 00:19:36.800 --> 00:19:41.439 be used to create secure control channels between what? Edge and vEdge 00:19:41.439 --> 00:19:46.359 devices to vSmart, edge or vEdge devices to vManage, edge or vEdge devices to vBond. 00:19:46.359 --> 00:19:49.760 And if you have multiple vSmart controllers, vSmart to vSmart 00:19:49.760 --> 00:19:56.680 controllers. We use dynamic transport layer security connections. 00:20:02.400 --> 00:20:10.000 So now with OMP, this is like we said, about sharing the information that we 00:20:10.000 --> 00:20:15.239 need between the brains and the forwarders. So edge or vEdge devices to 00:20:15.239 --> 00:20:19.479 vSmart for information sharing. Remember that for the exam. How do we share 00:20:19.479 --> 00:20:32.000 information? OMP. How is OMP protected with DTLS? So some of the things that we 00:20:32.000 --> 00:20:39.880 will share using OMP. Reachability information. So vSmart needs to tell our 00:20:39.959 --> 00:20:46.079 edge devices who they can reach, who they can form tunnel with, who they can 00:20:46.079 --> 00:20:55.439 route to and from. So subnets, routes, TLOCs. TLOCs are called transport 00:20:55.439 --> 00:21:04.520 locators. Hmm, TLOCs. That sounds an awful lot like RLOCs, right? Well yeah, 00:21:04.520 --> 00:21:11.560 same idea. Each of our edge devices need what? A locator ID. Well we call them 00:21:11.560 --> 00:21:16.520 TLOCs here. So that way there we have the ability to create a tunnel from this 00:21:16.520 --> 00:21:28.199 TLOC to that TLOC. So they have to learn dynamically about those TLOCs. They have 00:21:28.199 --> 00:21:31.599 to learn about subnets. They have to learn about routes. You learn that from 00:21:31.599 --> 00:21:38.800 vSmart using OMP. What about security parameters like the encryption keys? 00:21:38.800 --> 00:21:43.719 Again that's going to be sent over a secure connection. So that's using OMP, 00:21:43.719 --> 00:21:48.439 using DTLS. So whatever I specified up here, I said okay for encryption we want 00:21:48.439 --> 00:21:52.119 to do this. For the integrity checking we want to do this. So remember when we set 00:21:52.119 --> 00:21:57.040 up our site-to-site IPSec VPNs? I mean there's a lot of work there, wasn't there? 00:21:57.040 --> 00:22:01.000 I had to specify everything and then I had to copy and paste it to all the 00:22:01.000 --> 00:22:06.599 different devices. So now imagine if we had a hundred devices. So you can see 00:22:06.599 --> 00:22:12.119 where SD-WAN can make your life a lot easier. I can now specify the policies 00:22:12.119 --> 00:22:18.400 here and then my devices can learn those policies. And I don't have to go from 00:22:18.400 --> 00:22:23.400 device to device to device to device. So if I have, if I wanted the same policy for all 00:22:23.400 --> 00:22:27.400 my devices, well then I just have to configure it once and my devices can 00:22:27.400 --> 00:22:31.160 learn about it. But if I wanted to have different policies for certain devices 00:22:31.160 --> 00:22:33.640 and certain groups of devices and different things like that, well then we 00:22:33.640 --> 00:22:36.280 can group them and do our things and you know get those different policies done 00:22:36.280 --> 00:22:43.040 that we want. So you can see where yes, that definitely in a really massive 00:22:43.040 --> 00:22:49.000 large-scale environment, using SD-WAN, if you don't already have something set up, 00:22:49.000 --> 00:22:55.760 may be the way to go. But then again right, cost-benefit analysis, are we gonna 00:22:55.760 --> 00:23:00.079 benefit from this long-term? If I spend all this money just to set it up now and 00:23:00.079 --> 00:23:05.079 we don't expand or grow or add or see that nothing changes. So technically 00:23:05.079 --> 00:23:10.839 speaking, could we spend all that money on a human being configuring it once on 00:23:10.839 --> 00:23:16.479 traditional and just go with that and save money without having to pay yearly 00:23:16.479 --> 00:23:22.479 fees to Cisco for all of this stuff to keep working? I mean, you got to make that 00:23:22.479 --> 00:23:31.359 decision. It's a tough one, it's a tough one. I like it, don't get me wrong, I like 00:23:31.359 --> 00:23:35.439 it. But if it doesn't make, for me, if it doesn't make sense financially, it 00:23:35.439 --> 00:23:39.479 doesn't make sense doing it, right. 00:23:45.479 --> 00:23:49.319 So depending on the environment, yes, it would make total sense to do this. Other 00:23:49.359 --> 00:24:06.560 environments, no. Policy information, data policies, app route policies, right. 00:24:06.560 --> 00:24:13.000 Policies saying, if traffic is here, wanting to go there, it's allowed. But if 00:24:13.000 --> 00:24:15.800 it's this going to there, it's not allowed. What if you're using this app 00:24:15.839 --> 00:24:19.479 then you can't. But if you're using this app, you can. So we can get very granular 00:24:19.479 --> 00:24:23.280 with these policies, which is another added bonus. Whereas when you think about 00:24:23.280 --> 00:24:29.400 something like traditional IPsec, it's really more about what, subnets, VLANs, 00:24:29.400 --> 00:24:34.319 right, that's really it. Ports, source and destination ports, whatever you can do in 00:24:34.319 --> 00:24:40.640 an access control list. But here, I mean, we get to be a lot more granular because 00:24:40.640 --> 00:24:43.640 we would be able to maybe even inspect the traffic and say, hey, this type of 00:24:43.640 --> 00:24:48.640 traffic, we don't want to allow it over that tunnel. Because that's not traffic 00:24:48.640 --> 00:24:53.400 that should be going over that tunnel. So you're denied, you're blocked. So we do 00:24:53.400 --> 00:24:56.959 have the ability to have like application-aware routing here now in 00:24:56.959 --> 00:25:01.319 this particular case. We have the ability to do database routing. We have the 00:25:01.319 --> 00:25:07.839 ability to enforce all of that based on our policies. All from what? Again, a 00:25:07.839 --> 00:25:11.280 centralized location. 00:25:13.640 --> 00:25:27.520 Now, when the tunnel is actually created between two devices dynamically on the 00:25:27.520 --> 00:25:34.160 fly, what type of tunnel is that? It is an IPsec tunnel. So when you are managing 00:25:34.160 --> 00:25:39.119 everything and you're defining your security policies for your tunnel, 00:25:39.119 --> 00:25:44.000 you're going to have to use the IPsec framework. So what protocol, what this, 00:25:44.000 --> 00:25:47.280 what that, what encryption algorithm, right, all that stuff is coming to play 00:25:47.280 --> 00:25:54.479 here. So you still have to learn about IPsec even though you're using SD-WAN. 00:25:54.479 --> 00:25:57.439 But again, some people don't learn about it and they're just like, I'll just pick 00:25:57.439 --> 00:26:03.760 the most strongest one possible for every single option. Which may or may not 00:26:03.760 --> 00:26:08.319 be a good thing. It really depends on the scenario and situation. 00:26:09.119 --> 00:26:17.599 We get our secure transport of user data from one site to another. So based 00:26:17.599 --> 00:26:20.800 on the fact that I have interesting traffic that arrives and it needs to go 00:26:20.800 --> 00:26:25.479 from here to here, based on everything that I learned from vSmart, I can go 00:26:25.479 --> 00:26:28.920 ahead and set that tunnel up and encapsulate my traffic. And based on 00:26:28.920 --> 00:26:39.359 everything I learned over here, I can then decapsulate that traffic. Also the 00:26:39.359 --> 00:26:42.400 tunnel uses what? Bi-directional forwarding detection. Hey, that's pretty 00:26:42.400 --> 00:26:45.959 cool. What do we say bi-directional forwarding detection could be used for 00:26:45.959 --> 00:26:53.640 in our dynamic routing protocols? To detect an outage across the link between 00:26:53.680 --> 00:26:59.040 two neighboring devices. So if I had, for example, my router here and my router 00:26:59.040 --> 00:27:03.119 here, if the interface goes down, or not interface goes down, but if I have issues 00:27:03.119 --> 00:27:07.760 with that connection, even just across this link, it could take up to 40 seconds 00:27:07.760 --> 00:27:12.000 for OSPF to make a change. But if I'm running BFD from here to here, from here 00:27:12.000 --> 00:27:16.560 to here, we said that we could detect a change within milliseconds and then OSPF 00:27:16.560 --> 00:27:19.880 could make its adjustment right away instead of waiting for its dead timer to 00:27:19.880 --> 00:27:25.920 expire. So we utilize BFD here to what? Make sure that I have a connection from 00:27:25.920 --> 00:27:30.599 here to here. In reality, okay, it's not from the tunnel, it's do I have a 00:27:30.599 --> 00:27:36.560 connection from here over the internet over to here? That's what BFD is doing, 00:27:36.560 --> 00:27:42.160 right? Can I get from my public IP connected either to internet, MPLS, or 00:27:42.160 --> 00:27:46.400 LTE? So it might even be a private IP address with MPLS, right? But can I get 00:27:46.400 --> 00:27:51.959 from that IP address over to the IP address over there, the tunnel endpoints? 00:27:51.959 --> 00:27:57.880 So that's one thing you can do. It can test connectivity. If there's a loss, then 00:27:57.880 --> 00:28:01.599 we could use a backup path. So for example, maybe we're primarily using MPLS. 00:28:01.599 --> 00:28:05.800 Well, if MPLS goes down, maybe we'll have a backup of the internet. If internet 00:28:05.800 --> 00:28:09.880 goes down, maybe we'll do a backup of LTE. So we might be paying for all three of 00:28:09.880 --> 00:28:15.719 those connections, but the router is set up based on your policies to use MPLS 00:28:15.719 --> 00:28:20.640 first. If BFD detects a failure, then fall back to the internet. If the 00:28:20.640 --> 00:28:24.839 internet fails, then fall back to LTE. Possibilities, right? These are all things 00:28:24.839 --> 00:28:33.640 that we can do. But if there's a loss, we can fail over, right? We can also though 00:28:33.640 --> 00:28:40.079 measure latency here. So what if all of a sudden this is becoming very saturated 00:28:40.079 --> 00:28:44.520 and we're not getting the performance requirements we need? Well then, if the 00:28:44.520 --> 00:28:49.880 latency level gets too high, then we have the ability maybe to switch over to 00:28:49.880 --> 00:28:55.479 one of these other options on the fly. Same thing with jitter. If jitter gets 00:28:55.479 --> 00:29:01.000 too high, the jitter is the variation in delay, variation in latency. Well, if that's 00:29:01.000 --> 00:29:06.199 what is detected, then we can go ahead and maybe fail over or switch over to 00:29:06.199 --> 00:29:11.119 another one of our connections on the fly, right? So I already mentioned failure, so 00:29:11.119 --> 00:29:15.319 an entire failure, but what about just loss? If we have excessive packet loss 00:29:15.319 --> 00:29:21.640 across that, then maybe again if packet loss gets too high, we can fail over to 00:29:21.640 --> 00:29:26.800 one of the other connections that we have. So if you have, for example, like the 00:29:26.800 --> 00:29:32.000 need for mission-critical connections with certain loss, latency, jitter, and 00:29:32.000 --> 00:29:36.520 failure values associated with them, SD-WAN gives the opportunity to 00:29:36.520 --> 00:29:39.839 dynamically change on the fly, whereas something like our traditional WANs 00:29:39.839 --> 00:29:43.479 don't do that. So there's a little added benefit as well to that one that may be 00:29:43.479 --> 00:29:49.040 beneficial to your organization. Now when it comes to these IPsec 00:29:49.040 --> 00:29:54.400 tunnels though, what we need to realize is that our IPsec tunnel can actually be 00:29:54.400 --> 00:30:00.880 what's the word I want to use here? Segmented. Segmented. Into what? 00:30:00.880 --> 00:30:06.359 Into different VPNs. So let me give you a visual representation of what I mean by 00:30:06.359 --> 00:30:11.959 this. So let's go ahead and zoom in to our IPsec tunnel, and you will see inside 00:30:11.959 --> 00:30:16.359 of the IPsec tunnel you can have different VPNs. So I want you to be 00:30:16.359 --> 00:30:22.760 careful with that on the exam. See on the exam, when it comes to SD-WAN, right, your 00:30:22.760 --> 00:30:30.439 IPsec tunnel, that's not your VPN, okay? Whereas when we talked about IPsec 00:30:30.439 --> 00:30:35.239 site-to-site VPNs, well that was one VPN, that was your IPsec tunnel. That's 00:30:35.239 --> 00:30:40.400 essentially what we built. But with SD-WAN, our IPsec tunnel can be 00:30:40.400 --> 00:30:47.359 compartmentalized, or segmented I should say, into different VPNs, and therefore 00:30:47.359 --> 00:30:53.599 each VPN gives us isolation. Kind of like VRFs, right? We now have different 00:30:53.599 --> 00:31:01.800 tunnels that isolate and segment traffic from each other. They have their own 00:31:01.800 --> 00:31:08.959 forwarding tables. Oh, this is sounding a lot more like VRFs. So we have what are 00:31:08.959 --> 00:31:16.920 called sub-interfaces under each VPN, or associated I should say with each VPN, 00:31:16.920 --> 00:31:23.119 for this IPsec tunnel. And then we'll have to label each of these VPNs 00:31:23.119 --> 00:31:30.280 through OMP information, through OMP route attributes is how you say that. So 00:31:30.280 --> 00:31:34.680 that way we can do the proper packet encapsulation, which identifies the VPN 00:31:34.680 --> 00:31:39.920 a packet belongs to. So there are two types of VPNs that exist by default. You 00:31:39.920 --> 00:31:45.479 have VPN 0, which is what we call the transport VPN. It contains the interfaces 00:31:45.479 --> 00:31:49.920 that connect to the WAN transports. And then we have VPN 512, that's a 00:31:49.920 --> 00:31:53.920 management VPN that exists, and it carries out-of-band management traffic 00:31:54.400 --> 00:32:01.599 to and from the Cisco SD-WAN devices that we have. And then you can have as 00:32:01.599 --> 00:32:07.800 many custom VPNs as you need, right? So multiple VPNs can exist in a tunnel. Each 00:32:07.800 --> 00:32:11.760 VPN has its own forwarding table. That's what I want you to take away from that. 00:32:11.760 --> 00:32:19.839 And that's what you need to know for SD-WAN for the certification exam folks. 00:32:20.160 --> 00:32:28.920 So, know orchestration plane and what it's about. V-managed or data management 00:32:28.920 --> 00:32:37.520 plane, what it's about. Buzzwords, keywords. Control plane, data plane, right? So V-bond, 00:32:37.520 --> 00:32:45.199 V-manage, V-smart, V-edge, and edge at a minimum. And then everything else we 00:32:45.199 --> 00:32:48.920 talked about, good things to know, except for those little side discussions I went 00:32:48.920 --> 00:32:55.400 on based on my own personal feelings. Those are not going to be on the exam.