All right, and now I just want to have a quick discussion on SD-WAN. I am not here
to teach you all about SD-WAN. I'm here to make sure that you prepare properly
for the exam. So, SD-WAN, software-defined WAN, is what? Software-defined Wide Area
Networking. It's really a technological shift and a mind shift for us when it
comes to wide area networking. It says your SD-WAN is a technology that
utilizes software-defined networking principles to manage and optimize the
distribution of network traffic across a wide area network. It offers the ability
to dynamically route and prioritize network traffic based on factors such as
application type, network conditions, and business policies. Hmm. So, let me compare
that to my traditional WAN that I might have. My traditional WAN might be just a
simple MPLS connection between all of my different sites that I have, or it
might be IPsec site-to-site VPNs I have, or it might be DMVPNs that I have set up.
What's the difference then between that type of WAN setup versus SD-WAN? Well, the
difference is managing, monitor, maintaining, control, automation,
programmability, which I don't get with traditional WAN networking. All of those
buzzwords I just threw out there are greatly enhanced when we're talking
about SD-WAN. The ability to dynamically route and prioritize network traffic
based on factors such as application type, network conditions, and business
policies. I don't get that with traditional WANs. So, with SD-WAN, here's
your buzz list of benefits. Drag and drop the benefits of SD-WAN. Of the following
options, please pick benefits of SD-WAN. Improved network performance, shorter
installation times, cost savings, centralized management, application-aware
routing, flexible and agility, security enhancements, redundancy and failure, cloud
readiness, all compared to what? Traditional WANs. That's great. Thank you
for all those buzzwords, Cisco. Great marketing words that I may need to know
for the exam. Why would I want to choose SD-WAN over traditional, folks? Boom, there
you go. Those are great ones. Are they going to test you on its limitations?
No, of course not. But I'll tell you some limitations so that way you don't think
I'm a fanboy of SD-WAN and I'm just trying to promote it. Okay, initial
investment. Whoo! How many of you have implemented SD-WAN and the cost was a
lot? I once had a student who went through Encore with me. Yeah, answers like
yep. I once had a student who went through Encore with me and she, actually
she went through CCNA, Encore, and RC. My gosh, like she went through everything.
And her growth was phenomenal. She learned everything she could, studied
studies that took years, but my gosh. In the end, she contacted me. She goes, hey, I
just got contacted by Cisco, none of that, and they really want me to invest in SD-WAN.
She goes, but I don't see the benefit for me. So we had a conversation about it and
in the end, it was like, no, the numbers are like astronomical. It was like 50
times cheaper to just go out and buy like new ASAs and just simply set up IPsec
site-to-site VPN tunnels and DMVPNs and stuff like that and just go that route.
Because she didn't need all that extra stuff, a lot of those extra benefits. She
didn't need the centralized management. There wasn't enough sites that it would
make like the cost-benefit analysis. The flexibility and agility was not enough
to justify the costs. The security enhancements, again, was not enough to
justify the cost because with the IPsec site-to-site VPNs and the DMVPNs
using IPsec and all that, I mean, you got the security you want in that case. So
and again, the redundancy and failure, all that type of stuff just wasn't enough to
just justify the cost. So initial investment, high. Complexity, right?
Initially learning about it, doing it, yeah, it is complex. Dependency on
internet connectivity. So here's the thing. One of the things that you see in
a lot of marketing things is like, oh, you know, when it comes to SD-WAN, right, you
don't have to worry about your connections. Of course I do. I still need
an internet connection or an MPLS connection or an LTE connection. I still
have to pay for that. I still have to work with my service provider to get
that set up before we can do SD-WAN anyways. What am I doing with SD-WAN? I'm
building a virtual network on top of those connections. That's what I'm doing.
I'm building a virtual network on top of those different types of connections. So
I still have to deal with all that other stuff and that other stuff can still be
costly. There are security concerns as well when it comes to what? Securing this
stuff now, especially if it's in the cloud. I can totally lock in myself on a
vendor now. That's right. You can have quality of service issues. You can. I mean
although there are built-in mechanisms so you don't, you totally can, especially if
all of a sudden you are on the backup path and it's the internet because it
dynamically flipped over to that and it wasn't supposed to maybe. It can happen.
There are integration challenges. There's a learning curve, right? Some of the
things here as they say like centralized management is supposed to save you money.
That's a benefit. That's only if once you finish doing SD-WAN you are no longer
really worrying about it and it's just working as it should and magically doing
everything it should without you ever having to get involved. Yeah, that's where
you get savings but if you're constantly managing it, you're constantly having to
dive and you're constantly have to verify this, verify that, troubleshoot this, then I
mean you're in no better shape than you were before. So when I hear a lot of the
buzzwords for SD-WAN, for me personally, it's marketing stuff and in the end it's
up to you to figure out are we really gonna benefit from this before you pull
the trigger. That's important, right? Now that is not part of the exam, okay? Some
of those buzzwords, yes, okay? Like if they ask you, what are the benefits of going to SD-WAN?
Okay, know this stuff, right? Pick it out. I'm gonna have cost savings whether it's
true for you or not in the real world. I'm gonna have shorter install times. I'll
tell you right now, some people have had longer install times in the beginning
but down the road, right? When they added sites, it was shorter. You see there's the
payoff, right? If you're constantly growing and evolving then yes, over time
you can save on time, money, energy, right? That's over time but if you set up SD-WAN
and it's that forever, you may never save. It's really tough to know. You got to do
your cost-benefit analysis for the real world, okay? That's me telling you
personally about stuff like that. So for the exam though, I really need you to be
able to pick these four names out of a lineup for the certification exam. That's
your number one goal. Do you know what orchestration plane is? Do you know what
management plane is? Do you know what control plane is? Do you know what data
plane is? Number one. So what is our orchestration plane? So folks, our
orchestration plane is going to be the device, whether it's on-prem or in-cloud
that has the ability to do the onboarding of our entire SD-WAN. So here
is some keywords to keep in mind. Orchestrates to control in management
plane. So it's about onboarding all of the other devices. vManage, vSmart are
what? Our edge devices, whether they're virtual edge devices or physical edge
devices. Orchestrate them. Onboard them. It is the first point of authentication
as well. Are these devices and services actually allowed to be part of this SD-WAN
architecture? It then has the ability to distribute the vManage information and
the vSmart information to your edge devices, virtual and physical edge
devices. So meaning your routers that form your tunnels over the WAN. They can
do NAT traversal or well or facilitates NAT traversal vBOT. It's gonna have to
have a public IP address. Why? Because it needs to be reachable over what? The
internet. And it's gonna be a highly resilient device of some type. Meaning
you're gonna have to make sure it is resilient because it's responsible for
the onboarding of your devices when they come up. Key things to keep in mind, key
things to remember when it comes to your vBond device, the orchestration plane. So
yeah, in your on-prem data center you can set up your vBond. Or you could set it
up in Cisco, AWS, Azure. And what are we setting up? We're setting up a server that
has the ability to do the orchestration for us. Now what about the control plane?
Let's jump down to the control plane. So the control plane is this device right
here. We call it vSmart in the world of Cisco. vSmart. And what are we dealing
with in this case? We're dealing with our controller for the control plane. Now I'm
not talking about like your graphical user interface. I'm not talking about
that device. No, no, that's vManage, right? In this case vSmart is our software-based
component either on-prem, Azure, AWS, Cisco, running on a virtual machine, something
like that, okay? And this software-based component is responsible for the
centralized control plane of the SD-WAN network. So what is it going to do? It's
going to learn everything that you have defined. So it learns about all the
policies that you've defined. Through what? Through your vManage console that
you have. So it learns how the network needs to be based on the policies that
you have defined. It's your centralized enforcer of policy and control. In
addition, it can learn, as you can see, learn from other devices. So already it's
learning from vManage through you or vManage monitoring statistics and
measurements and realizing something's wrong and then telling vSmart
dynamically to make a change to the environment. Or vSmart can learn even
from the edge devices directly. So that way there it can make adjustments or
changes on the flight, all depending on how you set it up and how you want to
use it. So some things to keep in mind. vSmart is going to be used for what?
Facilitating the discovery of your fabric. So what devices are part of that
fabric? Through what? Through vBond as well. vBond has to let it know, right, who
is part of this fabric. Who do we need to register? Who do we need to work with? And
so on and so forth. And so this is your control plane information. Control plane
information for all those edge devices. So the edge devices are about what? Data
plane. Forwarding traffic. Forwarding traffic. That's your edge devices.
vSmart is the brains. Think of it. Brains making decisions. That's vSmart.
Control plane. And then it tells the data plane, tells the edge devices what to do.
Through what? Through things like routing policies, security policies, any other
types of policies that you set up. So it reduces your control plane complexity. So
here's one of the powers of SD-WAN over traditional WANs. In traditional WANs,
folks, how many control planes do you have in a traditional WAN? Okay, the
number of control planes you have in a traditional WAN equals the number of
devices you have. So if you have a hundred WAN routers between headquarters
and branches you have, then every single one of those devices have their own
control plane that you have to manage, monitor, and maintain. But if you switch
to SD-WAN, now you've got one centralized control plane and a backup,
hopefully, okay? Therefore, dramatically reducing the control plane complexity.
So all the brains of all the devices are here now. And you want to make sure it's
a highly resilient device.
When we talk about learning information from the edges, right, we can gather what
telemetry data from WAN devices. That's what we can do. And when we tell things,
distribute routes, policy, security, right, that's when we are updating it on, you
know, what do you need to do? How does your VPN need to be set up? How are you
going to handle traffic? What protocols are you going to use to secure it? Etc.,
etc. All right, now we got our data plane. So the data plane is what? That's where
you're going to have your physical edge devices or your virtual edge devices. So
virtual edge devices could be, for example, like a virtual router that is
set up in the cloud in an AWS network or a Cisco network. So that way there, you
can have your cloud infrastructure as part of your WAN architecture. So that way
there, you are going to have the same policies on that WAN architecture in the
cloud as you would in your headquarters and branch offices, as an example, right?
And then maybe your branch offices and headquarters, you'll have physical
devices. But you could still have virtual devices where maybe you have a server
set up so the traffic comes in. It first goes to the server or wherever in the
branch office, let's say, and then can go out to the users as it goes through that
edge device. So whether the edge device is physical or virtual, it doesn't really
matter, right? They're going to be responsible for the same thing. And
primarily that is traffic forwarding, security, encryption, quality of service.
But how does it know what to do? How does it know how to forward traffic? How does
it know how to secure traffic? How does it know how to encrypt traffic? How does
it know how to do quality of service? Well, that comes from who? That comes
from vSmart. And we said vSmart learns from what? From you configuring policies
through vManage, as an example. It can learn from the edge devices that are
constantly working and then sending data to vSmart. So then vSmart can say, oh my
gosh, wait a second. We've got such and such an issue with quality of service.
Let's go ahead and adjust what we're doing. So that way there, we don't have
the quality of service issue anymore. But our edge devices, not vSmart. Let me
take off that circle now. But our edge devices, like this device right here,
provide secure data plane with remote edge routers. Establish a secure control
plane with vSmart controllers using a protocol called OMP. So OMP is the
overlay management protocol. That is the protocol that runs between vSmart and
our edge devices. So that way there, we have the opportunity to talk to each
other. So whenever we have policies from vSmart that need to be told to
the edge devices, we use the overlay management protocol in order to
accomplish that. Implements data plane and application away routing policies. We
can export performance statistics up to vSmart from our edge devices. We can use
traditional routing protocols like OSPF, BGP, VRRP, other things like that with
our vEdge edge devices. We get zero touch deployment, meaning like plug and
play type of deployment where, let's say we had another branch office coming up.
We get a new device. We put it in. We'd have to go to our vManage and do the
initial, provide the information that we need to into vManage. And then from there,
vBond can do what it needs to do from an orchestration standpoint and onboard
that particular new device into our vManage and everything else that goes on
with that and confirm that it's actually a true Cisco product that's registered
and paid for it and all that stuff through serial numbers. There's a lot.
There's a lot going on there. And as I said, we got physical devices and virtual
devices with many different port speeds to accomplish whatever you need. And then
lastly here, we have vManage. vManage, I want you to remember, is your
management plane. This is your dashboard for management. It's your single plane
of management for Cisco SD-WAN. So on the exam, just think about how you might
be tested on these. What is your centralized network management system in
SD-WAN? It's called vManage, not dnaCenter. dnaCenter is for SD-Access.
vManage is for SD-WAN. dnaCenter is for SD-Access. vManage is for SD-WAN. That's
what you might be tested on. Right, you got your graphical user interface to
easily monitor, configure, and maintain your Cisco SD-WAN environment. So vBond,
onboarding. vManage, management. It's your dashboard, your graphical user interface,
control plane, vSmart, brains, data plane, edge, vEdge, power, brawn, forwarding.
That's what it's all about. So OMP, I mentioned it. I want to give you a little
bit of details for it in case anything comes up like this on the certification
exam. So OMP stands for overlay management protocol. It is TCP based,
control plane protocol. So essentially we're creating a TCP session from here
to here, from here to here. So that runs between what? It's going to run between
our edge devices, virtual or physical, and vSmart. And we are using this protocol inside
of a dynamic TLS, transport layer security connection. So how is OMP being
protected inside of dynamic transport layer security, DTLS? So DTLS is going to
be used to create secure control channels between what? Edge and vEdge
devices to vSmart, edge or vEdge devices to vManage, edge or vEdge devices to vBond.
And if you have multiple vSmart controllers, vSmart to vSmart
controllers. We use dynamic transport layer security connections.
So now with OMP, this is like we said, about sharing the information that we
need between the brains and the forwarders. So edge or vEdge devices to
vSmart for information sharing. Remember that for the exam. How do we share
information? OMP. How is OMP protected with DTLS? So some of the things that we
will share using OMP. Reachability information. So vSmart needs to tell our
edge devices who they can reach, who they can form tunnel with, who they can
route to and from. So subnets, routes, TLOCs. TLOCs are called transport
locators. Hmm, TLOCs. That sounds an awful lot like RLOCs, right? Well yeah,
same idea. Each of our edge devices need what? A locator ID. Well we call them
TLOCs here. So that way there we have the ability to create a tunnel from this
TLOC to that TLOC. So they have to learn dynamically about those TLOCs. They have
to learn about subnets. They have to learn about routes. You learn that from
vSmart using OMP. What about security parameters like the encryption keys?
Again that's going to be sent over a secure connection. So that's using OMP,
using DTLS. So whatever I specified up here, I said okay for encryption we want
to do this. For the integrity checking we want to do this. So remember when we set
up our site-to-site IPSec VPNs? I mean there's a lot of work there, wasn't there?
I had to specify everything and then I had to copy and paste it to all the
different devices. So now imagine if we had a hundred devices. So you can see
where SD-WAN can make your life a lot easier. I can now specify the policies
here and then my devices can learn those policies. And I don't have to go from
device to device to device to device. So if I have, if I wanted the same policy for all
my devices, well then I just have to configure it once and my devices can
learn about it. But if I wanted to have different policies for certain devices
and certain groups of devices and different things like that, well then we
can group them and do our things and you know get those different policies done
that we want. So you can see where yes, that definitely in a really massive
large-scale environment, using SD-WAN, if you don't already have something set up,
may be the way to go. But then again right, cost-benefit analysis, are we gonna
benefit from this long-term? If I spend all this money just to set it up now and
we don't expand or grow or add or see that nothing changes. So technically
speaking, could we spend all that money on a human being configuring it once on
traditional and just go with that and save money without having to pay yearly
fees to Cisco for all of this stuff to keep working? I mean, you got to make that
decision. It's a tough one, it's a tough one. I like it, don't get me wrong, I like
it. But if it doesn't make, for me, if it doesn't make sense financially, it
doesn't make sense doing it, right.
So depending on the environment, yes, it would make total sense to do this. Other
environments, no. Policy information, data policies, app route policies, right.
Policies saying, if traffic is here, wanting to go there, it's allowed. But if
it's this going to there, it's not allowed. What if you're using this app
then you can't. But if you're using this app, you can. So we can get very granular
with these policies, which is another added bonus. Whereas when you think about
something like traditional IPsec, it's really more about what, subnets, VLANs,
right, that's really it. Ports, source and destination ports, whatever you can do in
an access control list. But here, I mean, we get to be a lot more granular because
we would be able to maybe even inspect the traffic and say, hey, this type of
traffic, we don't want to allow it over that tunnel. Because that's not traffic
that should be going over that tunnel. So you're denied, you're blocked. So we do
have the ability to have like application-aware routing here now in
this particular case. We have the ability to do database routing. We have the
ability to enforce all of that based on our policies. All from what? Again, a
centralized location.
Now, when the tunnel is actually created between two devices dynamically on the
fly, what type of tunnel is that? It is an IPsec tunnel. So when you are managing
everything and you're defining your security policies for your tunnel,
you're going to have to use the IPsec framework. So what protocol, what this,
what that, what encryption algorithm, right, all that stuff is coming to play
here. So you still have to learn about IPsec even though you're using SD-WAN.
But again, some people don't learn about it and they're just like, I'll just pick
the most strongest one possible for every single option. Which may or may not
be a good thing. It really depends on the scenario and situation.
We get our secure transport of user data from one site to another. So based
on the fact that I have interesting traffic that arrives and it needs to go
from here to here, based on everything that I learned from vSmart, I can go
ahead and set that tunnel up and encapsulate my traffic. And based on
everything I learned over here, I can then decapsulate that traffic. Also the
tunnel uses what? Bi-directional forwarding detection. Hey, that's pretty
cool. What do we say bi-directional forwarding detection could be used for
in our dynamic routing protocols? To detect an outage across the link between
two neighboring devices. So if I had, for example, my router here and my router
here, if the interface goes down, or not interface goes down, but if I have issues
with that connection, even just across this link, it could take up to 40 seconds
for OSPF to make a change. But if I'm running BFD from here to here, from here
to here, we said that we could detect a change within milliseconds and then OSPF
could make its adjustment right away instead of waiting for its dead timer to
expire. So we utilize BFD here to what? Make sure that I have a connection from
here to here. In reality, okay, it's not from the tunnel, it's do I have a
connection from here over the internet over to here? That's what BFD is doing,
right? Can I get from my public IP connected either to internet, MPLS, or
LTE? So it might even be a private IP address with MPLS, right? But can I get
from that IP address over to the IP address over there, the tunnel endpoints?
So that's one thing you can do. It can test connectivity. If there's a loss, then
we could use a backup path. So for example, maybe we're primarily using MPLS.
Well, if MPLS goes down, maybe we'll have a backup of the internet. If internet
goes down, maybe we'll do a backup of LTE. So we might be paying for all three of
those connections, but the router is set up based on your policies to use MPLS
first. If BFD detects a failure, then fall back to the internet. If the
internet fails, then fall back to LTE. Possibilities, right? These are all things
that we can do. But if there's a loss, we can fail over, right? We can also though
measure latency here. So what if all of a sudden this is becoming very saturated
and we're not getting the performance requirements we need? Well then, if the
latency level gets too high, then we have the ability maybe to switch over to
one of these other options on the fly. Same thing with jitter. If jitter gets
too high, the jitter is the variation in delay, variation in latency. Well, if that's
what is detected, then we can go ahead and maybe fail over or switch over to
another one of our connections on the fly, right? So I already mentioned failure, so
an entire failure, but what about just loss? If we have excessive packet loss
across that, then maybe again if packet loss gets too high, we can fail over to
one of the other connections that we have. So if you have, for example, like the
need for mission-critical connections with certain loss, latency, jitter, and
failure values associated with them, SD-WAN gives the opportunity to
dynamically change on the fly, whereas something like our traditional WANs
don't do that. So there's a little added benefit as well to that one that may be
beneficial to your organization. Now when it comes to these IPsec
tunnels though, what we need to realize is that our IPsec tunnel can actually be
what's the word I want to use here? Segmented. Segmented. Into what?
Into different VPNs. So let me give you a visual representation of what I mean by
this. So let's go ahead and zoom in to our IPsec tunnel, and you will see inside
of the IPsec tunnel you can have different VPNs. So I want you to be
careful with that on the exam. See on the exam, when it comes to SD-WAN, right, your
IPsec tunnel, that's not your VPN, okay? Whereas when we talked about IPsec
site-to-site VPNs, well that was one VPN, that was your IPsec tunnel. That's
essentially what we built. But with SD-WAN, our IPsec tunnel can be
compartmentalized, or segmented I should say, into different VPNs, and therefore
each VPN gives us isolation. Kind of like VRFs, right? We now have different
tunnels that isolate and segment traffic from each other. They have their own
forwarding tables. Oh, this is sounding a lot more like VRFs. So we have what are
called sub-interfaces under each VPN, or associated I should say with each VPN,
for this IPsec tunnel. And then we'll have to label each of these VPNs
through OMP information, through OMP route attributes is how you say that. So
that way we can do the proper packet encapsulation, which identifies the VPN
a packet belongs to. So there are two types of VPNs that exist by default. You
have VPN 0, which is what we call the transport VPN. It contains the interfaces
that connect to the WAN transports. And then we have VPN 512, that's a
management VPN that exists, and it carries out-of-band management traffic
to and from the Cisco SD-WAN devices that we have. And then you can have as
many custom VPNs as you need, right? So multiple VPNs can exist in a tunnel. Each
VPN has its own forwarding table. That's what I want you to take away from that.
And that's what you need to know for SD-WAN for the certification exam folks.
So, know orchestration plane and what it's about. V-managed or data management
plane, what it's about. Buzzwords, keywords. Control plane, data plane, right? So V-bond,
V-manage, V-smart, V-edge, and edge at a minimum. And then everything else we
talked about, good things to know, except for those little side discussions I went
on based on my own personal feelings. Those are not going to be on the exam.