When we talk about tunnels in the SD-WAN environment, we're typically going to
lock in on the data
plane, which uses IPsec tunnels.
And technically, we do have the option of using GRE.
If we trust the underlying network, if it's a secured wide area network in some
capacity,
then we could just use GRE tunnels.
We wouldn't have to use IPsec.
But in most cases, we would use IPsec tunnels.
And so these are typically what we're thinking of when we look at tunnels in
the architecture
is here in the data plane.
However, we do have control plane tunnels as well, which is kind of interesting
.
We're going to find that we're going to use TLS and DTLS tunnels in order to
form relationships
among the different controllers.
And the reason for this is because we want to secure these communications as
well.
There's a lot of important information being sent around inside, or maybe I
should say
among the different control plane nodes.
Now, when I say control plane, this would also include the orchestration plane
as well
as the management plane, which really all of the non data planes wrapped up
into the
concept of control information.
So we're sending these via secure communication and we're using TLS and DTLS
tunnels to do
it.
Now real quick about TLS versus DTLS, TLS communications are TCP based.
Whereas DTLS, these are UDP based.
So which one is better?
Technically it just depends on the situation.
We're not going to find that one is technically superior to the other.
In fact, we actually as admins have a choice between which tunnel type is used
in most cases.
UDP is really good when we need to deploy seamlessly, maybe through certain
connection
types or what have you.
And then TCP is really good for stateless inspections.
If we want to control the TCP connection termination via firewalls, those kinds
of situations,
then TLS is probably the way to go.
So we as the admin need to make that choice.
And that's really something that's up to us when we're deploying our network.
So let's go into the details of each one of these.
We want to start with our data plane communications as we continue to drive
home, how exactly we're
building an SD-WAN architecture.
So as we mentioned, it's IPsec or GRE, usually IPsec.
And we get to build whatever overlay we want.
Remember, we're building this concept of an overlay network.
And the overlay is going to be built on top of the underlay.
We had diagrammed it out earlier like this, where we have this kind of network
on the
left, which is our organizational network.
And then we have another part of our organizational network over here on the
right.
And we want to form a connection, maybe, in fact, let's just throw another one
up here.
So now we've got all of these different routers that are our organizational
routers.
Maybe this is our headquarters, maybe the ones on the over here and up here.
These are our remote sites.
And I want to form, let's just say, a hub and spoke network.
So maybe I want to make it so that the network looks like this.
And that makes a lot of sense, depending on how exactly we want our
organization established.
However, think about physically what's actually happening.
What's actually happening is we're going to drop down here to the underlay and
connect
to service provider routers.
And there could be a lot of service provider routers.
And first of all, we might have a connection off of this router that connects
us to that
site, but then we actually have another series of layer three devices that
inevitably connect
us over to this site.
This is very interesting because now when we look at it, if I want to take this
green
path, the green path physically is doing this.
But now look at what we want to do.
And what's a good color for this?
Let's say orange.
So now what if I want to take this orange path?
Well, physically, it's kind of crazy.
We're going all the way around like this.
We end up overlapping the green path here and all ends up in the same place.
So logically, we're getting exactly what we wanted, but we understand
physically something
is a little bit different here.
And so the underlay is invisible to the transport of the network.
And the reason we can do that is because we are building these on tunnels,
whether IP
sec or GRE.
So we mentioned that we might have wanted to deploy a hub and spoke.
What are our different topology options?
Cisco's SD-WAN gives us quite a few different options, including first and
foremost, just
full mesh.
Let's allow all of the routers, all of our edges to be able to connect directly
to one
another.
And that means that even in our example up here, we would allow the two remote
sites
to be able to connect directly to one another.
Now again, when we say directly, we're talking about the overlay, the network
that we're
configuring.
And so let's be clear.
We only have control over the overlay network because it's a logical network.
I don't have control over the underlay because it's the physical service
provider network.
So this is a question of how to build out our overlay.
And I could allow for full mesh, which by the way, is the default.
However, I could start to limit some of those connections.
I could make it a partial mesh.
Maybe there are a few different sites out there that just have no business
communicating
with one another.
And if they do, I'd really like them to move through one of my head and
locations.
That's certainly an option.
We also could just flat out build a bunch of point to point links.
If I have a smaller network or I have very specific locations that I want to
connect directly
to one another, then I could use point to point.
And lastly, as we already said, we've got the hub and spoke option.
And the concept here is that I'm going to send everything through a
headquarters type
of site.
And this is really good if I want to inspect network traffic or if just most of
the flow
of the network happens to go that route anyways, then why bother allowing all
these other tunnels
that more or less create complicated topologies.
But even the most complex topologies are still all part of the overlay.
It's within my control as the SD-WAN administrator.
And I don't have to worry about what's happening in the underlay from a
physical perspective.
So now let's talk about those non-data plane tunnels.
So that would be our control plane and our organization plane and our
management plane.
So as we mentioned, we're going to use TLS or DTLS connections.
And for the most part, we get to choose however the validator, which is the V-b
ond, the validator
must always be DTLS.
And that has to do with the fact that it needs to be as accessible as possible.
We can't have a firewall in the way that's causing problems trying to terminate
secure
connections on our behalf.
Validator must be very simply reachable if at all possible.
So as we sketch these out with our different devices here, let's just put the
validator
here and I'll put the manager over here and the controller over here.
So we're going to start to form the secure tunnels with one another as
discovery is performed
and these controllers become part of our SD-WAN network.
We're going to form our DTLS tunnels here to the validator.
And then we're going to form a connection between manager and controller.
And this would be D or TLS, DTLS or TLS.
Also keep in mind that we can have multiple controllers and depending on the
size of our
network, we might well have quite a few different controllers here.
And so we're going to form these tunnels to all of these different controllers
as well.
So those would be the V smarts.
So just to kind of throw these up here.
So V-bond is at the top, V smart on the right, V-manage on the left using the
older terminology.
But we're actually not done yet with our non-data plane tunnels because I'm
going to have edge
devices down here and the edge devices are going to form our IPsec or GRE
tunnels to one
another.
However, they're also going to need to form tunnels to these controller devices
.
We don't just want to be pushing information down potentially across the
internet without
encrypting it and securing it.
And so we're also going to form DTLS or TLS connections to our edge devices.
So these are all DTLS or TLS depending on my configuration.
Now lastly, the tunnel to be aware of as far as operates a little bit different
is the
concept here that I'm drawing out as dotted lines.
Actually, let's use a slightly lighter color because that's really hard to see.
There we go.
Right, purple.
So now we've got tunnels to the validator from the edge device.
These connections are always going to be DTLS because the validator only allows
for DTLS
connections, and they are temporary.
The edges maintain connections with the manager and the controller.
However, the validator is only going to be temporary for the sake of onboarding
.
So the edges will connect to the validator, they'll figure out where all the
other controllers
are, they'll form their IPSec tunnels via the data plane, and then they will
end up
disconnecting these tunnels.
So those are not maintained over the course of time.
However, they do start off by initially connecting.
So when we look at this, it really does form a full mesh of tunnel
communications with
the caveat that that one tunnel does get torn down after it is complete.
And the edge is on the network.
[BLANK_AUDIO]