From the course: Implementing Cisco Software-Defined Wan (SD-WAN) for your Enterprise and Cloud
Cisco SD-WAN benefits and use cases - Cisco Tutorial
From the course: Implementing Cisco Software-Defined Wan (SD-WAN) for your Enterprise and Cloud
Cisco SD-WAN benefits and use cases
- [Instructor] I'd like to start out this lesson talking about some of the benefits and use cases for using SD-WAN. Now I'm going to show you a very high level model for a WAN. Now, within this model, users are going to respond at two different locations. They're either going to be at the branch or they're going to be at the headquarters. Now the great thing for those users that are at the headquarters is that the applications that they need access are going to be right next door in the data center. So they'll be able to access 'em across the high-speed LAN. Now, however, for those users that reside at the branch, they have to travel across a transport for the WAN. It could be dedicated circuits or MPLS or things along that nature. Now, the great thing is is if they're in a good organization, they have sufficient bandwidth. However, what I've found when I've talked to a variety of different network engineers is there's quite simply isn't enough bandwidth. Now, that could be for a variety of different reasons. It could be 'cause of the fact of their organization sees them as cost overhead, or could be because of the fact that users are becoming more and more data intensive with their applications they use, which kind of takes me to my next case. As we start to look at what's happening with the WAN and accessing data, they're going to the cloud. Now, quite simply, what is the cloud? It's basically using somebody else's data center, and that's because of the fact of, they could do it faster, cheaper, or better, or a combination of those variables. Now, when we talk about this, it's no longer about getting to your data center. It's about getting to your centers of data, wherever that may reside. That may still be in the actual data center, or it could be in the multi-cloud, or it could be as a software subscription, and it could even be just using the internet the way we've known and used it. Now, the other key thing that I want to call out is we're no longer concerned with disconnecting our users. Our users are also going to have things like tablets or eyeglasses for virtual reality to kind of help augment for training and safety, how to use certain devices depending upon your select vertical market. And then we have the new IoT industry with things for sensors, and that could be used for fog computing for manufacturing, or it could be even other sensors like with counting occupancy for health and safety reasons. So there's a variety of different reasons why we could have these things. Now what I want to do now is let's go through and talk through some of the different use cases that we have. So the first use case I'm going to talk about is using bandwidth augmentation. And quite simply, what this is is we're going to bring in a second circuit. I have showing internet, but it really doesn't matter what it is. It could be another MPLS provider, it could be LTE, it's just basically providing another transport. Now typically, some organizations, they might say, "All right, we're going to use the internet "and we're going to build a static IPsec tunnel, "and that will be our backup tunnel." And so that does a sufficient job, however, that is bandwidth that you have bought, you're just not utilizing, right? So if we're able to actually start using both of those transports and let the actual edge devices do the calculations and computations, we can take care of adding in more bandwidth where we typically didn't have that, and that's straightforward bandwidth augmentation. The next use case we're going to talk about is critical apps with a service-level agreement. And so basically what that boils down to is we've added other transports. And so we're now going to start running these VPN tunnels across these transports. We're going to run BFD probes to start monitoring, what is the health of each transport, right, from an end-to-end state. And with that, we can make forwarding decisions to make sure that the application like voice traffic will always flow across a transport that meets the needs, such as less than 150 milliseconds of latency. And for those other applications that are less sensitive, such as FTP, we could say you could take any transport you want, as long as the latency was at 500 milliseconds or less. And what this does is this allows us to provide a form of quality of service to our business applications by ensuring they will always take a transport that meets the needs of it. The next use case we'll talk about is secure segmentation. And quite simply, this is, we're already currently splitting up our network at our locations. We could either be using a firewall or access control list or something like that, but how do we keep that separation consistent as traffic goes across the WAN? Now, we can do that with subnetting ACLs, but that gets complicated when we start to talk about scale. So the other way that we can do this is we just place each form of traffic into its own appropriate VPN. Now, I've seen this used in manufacturing customers where they want to keep their corporate systems separate from their manufacturing robot process control networks, or the other use case that's quite common is in retail segments, where again, they'll have their corporate VPN system that they'll use and then they'll have a different VPN for their point of sales or cash registers or credit card machines that need the PCI compliance. Now, when we talk about this level of segmentation, we are able to, again, keep them completely separate. So if we take VPN 2, for example, VPN 2 lives in all three sites. So we'll be able to connect VPN 2 at Site 2 with Site 1 and with Site 2 at the HQ, and also at Site 1 and the HQ. And that traffic will be completely independent from VPN 1, which runs between Remote Site 1 and the data center. Now, you'll also notice that we don't have VPN 1 at Remote Site 2, which means that we don't have to provision VPN 1 at all locations. It's basically dependent upon where the VPN needs to reside. Now, if we happen to bring in the internet as a transport, the other use case we can talk about is using direct internet access. And so why would we want to be interested in direct internet access? So for direct internet access, if we're going through a centralized model, right, we're sending the traffic from the remote site across our WAN and up to the data center to get to the cloud. So if you think about it, we're paying for our internet twice. We're paying for it once at the data center, and then we're paying for it a second time as it travels across the WAN. Now that time, we're paying for typically on a premium 'cause that's going to be more of a dedicated circuit or more of an MPLS-type network. But again, if we're using the internet as a transport, we could just offload that direct. Now there's other things like latency that could come into play, or if you're backhauling traffic, say, from a site that would be in Mexico, back up into the US that's going to a site in Mexico, they might do things like language translation, so instead of seeing it as Spanish, they're seeing it as English because this traffic is seen as being originated out of the US, right? So that's another benefit towards this. Now, our security organizations, some of 'em I talked to, they're a little bit hesitant to go full bore and let everything go out on the internet because they're like, "Hey, look, "we've got all these great firewalls down here "at the corporate location. "Why aren't we sending the traffic through that?" And so my answer to that is, if they are starting to use like a cloud-based suite where they're starting to already send traffic out to them, they've already got contracts signed in place, well, we can do what is known as direct cloud access, which is a new concept where we're able to use the actual application patterns and say, "Hey look, we're going "to allow this application direct access out "onto the internet while everything else takes the MPLS path "to go back to the centralized model," right? So we can get that granular to the traffic that we're allowing to go out onto the internet. Now, along those same paths, so when the use case I talked about here, this was going to be more for employees, we could also do the same thing for our guest traffic. And instead of actually, most customers, what they'll do is they might have a wireless AP that is going to connect into an anchor controller before it gets out to the firewall, there may not be a need for that in the fact that we'll just allow that to offload direct to the guest wifi out onto the internet. So we'll do that as far as local switching, so we'll dump that onto to a VLAN and then just allow that to go direct out. Now, within that, we can still apply policy filtering and stuff like that to control the traffic, but why send that traffic across the transport only to go out, right? So we're paying for that internet, again, a second time. So that's another common use case is just to do DIA for the guest wifi. Now, with us providing the network connectivity with using the internet as a transport, this also allows us to provide direct connections into cloud providers such as AWS or Azure or Google. So instead of having to go back to the data center where we might have a direct link to get to a provider or having to wait for that latency for the return trip, we can actually establish a tunnel direct from all of our branches to a cloud provider, right? And this is done through Cloud OnRamp for Multicloud. And on that same context, we also have Cloud OnRamp for Multicloud with interconnect capabilities. And so with this, what we'll do is is we'll connect in with either Megaport or Equinix, which are located at colo facilities all over the world, and so within this, we'll be able to establish that IPsec tunnel towards those providers, and then from there, we'll be able to have our handoffs into those cloud providers like AWS or Microsoft Azure or Google Cloud. Now, with that being said, they're all over the world. We don't have to use just Megaport. We also have partnerships with Equinix, and with this configuration, it's all done through our management portal of vManage. Now, the great thing with having this is with these partnerships that we have with where they're located in the colo facilities, they can provide connectivity outside of AWS or Azure or Google Cloud, right? So there are other partners that, they may not be automated in the Cisco portfolio, but they can be connected in easily through their portfolio, could give you connectivity into clouds like IBM or SAP, right, for example. And there's hundreds of different cloud providers that they can get the cross-connects to at a lot faster. And the other key benefit with this is it's not just a one-to-one. You can have all of your branch locations connect into the same cloud provider. It doesn't really matter how you have the connectivity model, we can kind of diagram that out and get you that connection. And so this is known as Cloud OnRamp for Multicloud with interconnect capabilities, 'kay? And then going a little bit further, the last real use case that we have is providing regional secure perimeter. And so this is some really cool stuff. Basically, we have the capability of placing a firewall, such as what we've done right here, at a centralized location. It could be at a colo, it could be at a branch site, but we want the traffic to go through the firewall. It's between two branch sites. So we could say, "Hey, look, it's for, "traffic is going from this network to this network, "we want to steer it or traffic engineer it "so that it goes through the firewall and back out," or we can go as further as saying, "Hey, look, we want "to send specific traffic based off the application "that is going to go through that firewall." So we can go as far as saying, "This is going "to be HTTP traffic or FTP traffic, "while all the other traffic can go straight through, "it is not modified." And so that is the last use case that we have. Now, when I show you these use cases, there's one underlying theme that I want you to be aware of. These are use cases that the business will want to get behind 'cause it's going to help them respond to the needs of their users so that they can become more effective in meeting the needs, gaining capital, and things like that, right? Now, from my perspective, when we start talking about SD-WAN use cases, it's going to help with the centralization of the administration and it's going to less phone calls at three o'clock in the morning. So I want to thank you for reviewing the SD-WAN use cases and benefits with me.
Contents
-
-
-
Learning objectives39s
-
Cisco SD-WAN benefits and use cases12m 29s
-
Cisco SD-WAN architecture and components15m 32s
-
Cisco SD-WAN terminology and constructs4m 37s
-
Overlay Management Protocol (OMP)6m 27s
-
Cisco SD-WAN fabric operations3m 48s
-
Data tunnel connectivity11m 20s
-
Transport path selection5m 5s
-
VPN segmentation6m 35s
-
Control and data plane connectivity models10m 37s
-
(Locked)
Edge architecture6m
-
(Locked)
vManage dashboard demonstration12m 51s
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-