Well, it's one thing that SD-WAN is good at, it's making tunnels.
We're going to have a whole lot of tunnels at play and this is going to apply
to not
just the data plane, but also the control plane.
And so we're going to look at both of these here in this video and find that
what we're
really looking for here is to maintain a topology using the tunnels.
Remember, we want to create that network that we want, but we also want to
secure our
communications. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
communications.
And this is especially going to be true for the control plane because we're
sending
critical information across it.
But naturally we want to secure the data plane as well.
And so we're actually going to find that we do this differently depending on
the communications
that we're talking about.
So let's start with our data plane.
When we build out the SD-WAN data plane, it's going to involve our WAN edges
and they
are going to form these IPsec tunnels with one another. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
are going to form these IPsec tunnels with one another.
Now it's worth noting that we can create non-secure tunnels using GRE.
There might be a reason why we have to do this.
And but outside of that situation, whatever that situation is, we should really
never be
looking at deploying non-encrypted tunnels.
There's going to have to be a really specific reason why we want that.
And there might just be some network infrastructures that don't support IPsec.
So ideally, hopefully, we're building these tunnels on IPsec. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So ideally, hopefully, we're building these tunnels on IPsec.
Now when we look at the data plane itself, we're going to have all of these WAN
edge devices
that exist and communicate through some kind of WAN circuit.
Maybe we've got four routers here and they all connect into this MPLS
environment.
So at this point, we've got sites and subnets located behind all of these
different WAN edges.
We're going to want to enable communication between our WAN edge devices.
Well remember, with SD-WAN, we're no longer exchanging routes back and forth WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well remember, with SD-WAN, we're no longer exchanging routes back and forth
with the service
provider.
We don't do that anymore.
And so in order for me to get traffic from one subnet here to another subnet,
well,
I'm going to have to build a tunnel across this communications path.
So this tunnel is again, ideally, an IPsec tunnel or again, it could be GRE if
needed.
And in a lot of situations, we're going to want to build these tunnels out to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And in a lot of situations, we're going to want to build these tunnels out to
all of these
other devices, usually in full mesh fashion.
But here's the thing.
We actually have a lot of different topology options for building out our data
plane tunnels.
For example, given what I just wrote out here, drew out, we actually have
created a hub
in spoke topology.
And we can enforce this policy.
Maybe we want this.
Maybe we want all of the remote sites to go through our headquarters location.
And so now if we want to communicate from this subnet to this subnet over here, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so now if we want to communicate from this subnet to this subnet over here,
we would
actually have to go through the hub and then communicate out to the spoke, even
though
we could have formed a tunnel this way, but we chose not to in this situation.
So that would be hub and spoke as an option.
And we as the admins, we get to decide which one of these topology options that
we want.
We get to decide this.
So maybe we choose hub and spoke.
Maybe we actually want to rely on a point-to-point type of communications path. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Maybe we actually want to rely on a point-to-point type of communications path.
So maybe there's a very specific path between these two sites that I'd want to
build out.
And so I could actually build that as a point-to-point link.
And otherwise we're going to rely on the hub and spoke topology.
So we can kind of tack that on where it makes sense to do so.
We could also simply call this a partial mesh.
And we see that given the line I just drew here between these two sites, that
we just WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we just
have sort of a mishmash or a hodgepodge or whatever we want to call it.
There's a bunch of tunnels out there and we're all kind of connecting to other
routers and
various fashions.
But in the end, if I want to get from any one site to any other site, I do have
a path through
the fabric and through all of these different tunnels in order to get from any
location to
any other location.
Now naturally where we can go with this is to complete all of these connections WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now naturally where we can go with this is to complete all of these connections
.
And once they're connected fully, that would be a full mesh topology.
In a lot of situations, we're probably going to want to consider full mesh.
It just allows for the greatest flexibility.
If I want to go from this site to this site, why not just take a tunnel
directly there?
Why go through the headquarters location unless we have a good reason to do so?
Now there might be a good reason to do so.
And if so, we can certainly deploy a hub and spoke type of topology and SD-WAN
makes that
very simple for us to deploy and manage. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
very simple for us to deploy and manage.
So that's the data plane side of things.
Now let's talk about the control plane.
And we recall we have these three different devices that operate within the
control plane
side of things.
And yes, I'm grouping in the management and orchestration planes as well.
So we're really talking about everything other than the data plane at this
point.
And so those three devices are the V-smart, let's just draw it out like this.
The V-smart, the V-bond, and the V-manage. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The V-smart, the V-bond, and the V-manage.
And then we do still have our when edge devices down here.
Because they're going to participate in control plane management and orchest
ration plane
communications.
We have to receive information naturally.
And so the question is how does the traffic flow among all of these different
devices?
Well, what we're going to find is we're also going to form tunnels. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well, what we're going to find is we're also going to form tunnels.
But in this case, we're not going to deploy IPsec or GRE tunnels.
Instead, we're either going to use transport layer security or we can use dat
agram transport
layer security, so TLS or DTLS.
What's the difference between them?
Well, the big difference is that TLS is TCP based.
And datagram TLS might give us a hint as to what this is doing.
The user datagram protocol or UDP is going to be how we perform or how we form WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The user datagram protocol or UDP is going to be how we perform or how we form
DTLS tunnels.
So once again, we as the admins, we get to choose which one of these tunnel
types to use
in a lot of situations.
Which one do we choose and why do we choose one over the other?
Well, it's going to depend on our network.
TCP is usually better for stateful inspections.
If we have these communications paths going through firewalls and we want to be WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If we have these communications paths going through firewalls and we want to be
able to
track them and look at them, well, maybe we want to go with TCP.
But UDP is typically a little bit more seamless in operation.
We don't have to worry about forming connections.
We don't have to worry about a lot of the pain points of TCP, especially in a
situation
where we're using NAT and the like.
And so in a lot of cases, we might choose DTLS over TLS.
But again, it's going to depend on our organizational needs.
And if we really don't have a preference between one or the other, just choose WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And if we really don't have a preference between one or the other, just choose
one and
deploy it.
It's as simple as that.
So we need to deploy our tunnels.
And the idea here is that by deploying a tunnel, let's say between the V-Smart
and the
V-EG, again, both of these TLS and DTLS, these are providing encryption.
So it's not like the data plane where we could actually deploy a GRE and not
encrypt our
communications path with the control and management and orchestration plane. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
communications path with the control and management and orchestration plane.
We are going to have to deploy encryption because we have to choose TLS or DTLS
.
Now interestingly, when we are looking at this, we also find that we form
tunnels among
some of these devices up here.
So we're going to leverage the V-Bond and we're going to form what must be DTLS
connections
to the V-Manage and the V-Smart.
The reason why we're using DTLS here is recall that the V-Bond is going to be WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The reason why we're using DTLS here is recall that the V-Bond is going to be
out on the public
internet and it's responsible for things like net traversal.
And so we want to leverage UDP-based connections for that sake.
Now when the edge device comes online, it's also going to form a DTLS
connection to the
V-Bond and we're going to perform authentication and the discovery of the other
devices.
At this point, this is a temporary connection and once I have all the
information, I actually WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
information, I actually
tear it down.
I don't maintain that tunnel over the course of time.
Because at that point, I'm going to form my tunnel to the V-Smart and my tunnel
to the
V-Manage and this is where we can choose the DTLS or the DTLS connections.
Now something to keep in mind here is that recall that the V-Manage has an
active standby
option.
So we could actually, ideally we will, have a second V-Manage here and we could WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we could actually, ideally we will, have a second V-Manage here and we could
have many
different V-Smarts depending on the size and scope of our environment.
And so yes, we are going to form the tunnels out to these redundant devices as
well.
Oh, and let's not forget that the V-Smart and V-Manage also have tunnels
because the V-Manage
needs to push policy out to the V-Smarts for the sake of distributing that out
to the
edge.
So this is our tunnel framework we see we don't just use tunnels at the data
plane, but
we use tunnels at the control plane in order to secure all communications
within our
SD-WAN environment.