So we know that the data planes going to rely on our SD-WAN-edge devices,
communicating across
our wide-area network circuits, potentially multiple wide-area network circuits
to other
edge devices.
But as we already laid out in the previous video, our edge devices are not
going to know
how to form all of these IPsec tunnels.
They're not going to know where the different WAN-edge devices are without some
device offering
that information.
That device is going to be known as the SD-WAN controller.
The controller, which was formerly known as the VSMART, is going to sit out of
band of
all of the data plane of operations, which is typically what you want when you
're talking
about a control plane device.
So as we start to again, lock in which component goes to which plane of
operation the controller
or the VSMART is attached to the control plane.
The idea here is that we're going to have our controllers, again, sitting out
of band,
and yet having access to these devices.
Now we want to make sure that those connections are secure.
And so we're going to form either TLS connections or DTLS connections, both of
which involve
securely encrypted tunnels with TLS being TCP based and DTLS being UDP based.
But the point here is that these connections are secure.
The controller might say, well, where is it living if it's out of band?
Well, the controller is going to live as a virtual machine.
So this is not a iOSX-y based device.
This is actually running as a dedicated virtual machine or virtual appliance.
And I can either deploy this into the public cloud space.
There's always options to do it in the cloud, or I can deploy into my own
virtualization
environment.
Now from deploying into my own environment, this is probably going to be in a
data center
somewhere.
And so the controllers are going to need IP layer three access to all of these
different
devices.
Now right away, we can start to see a problem with this as far as where the
architecture
is going to lead us.
Because how does this new device, let's say we've got a new device over here
that's going
to connect in, how does it know where the control plane device is?
And how does it know where the device that just came online is?
I mean, that's a big question we have to answer.
And that is why we have an orchestration plane.
And so we have the device that was known as the V bond, which is now the valid
ator.
So it's important for us to log that in the back of our heads as far as how
does all
of this come together?
It's that whole chicken egg problem.
If I need to be pushing routes down to these devices in order to form IP sec
tunnels, but
they can't actually do that until they're known by the controller, then we
start to see
some problems there.
But yes, at this point, we have to assume that they all know where each other
are.
They're going to form the secure tunnels between the edge devices and the
controller.
And we're going to be pushing control plane information down.
So what exactly are we pushing down?
Well, we're going to be pushing down very important information.
We'll be covering the details of this information coming up soon, but it's
going to involve
something we call the transport locators or the T locks and the T lock routes
that are
going to help our edge devices form connections with other edge devices.
This is a very important part of the SD-WAN environment.
And then from there, we're also going to enforce policies that we as the admins
want the network
to be enforcing.
And so we do that via the control plane mechanism.
So next, we have to ask, OK, that's great and all, but what protocol are we
going to
use to push that information down when I think about control plane protocols?
I think of EGP and EIGRP and OSPF and the like.
Well, the protocol we're going to use to push this information down is going to
be the
overlay management protocol, otherwise known as OMP.
OMP is probably not a protocol we've heard of unless we've actually already
studied SD-WAN
because it's really only used within this context.
OMP is a very interesting protocol.
It is very BGP-like.
We can think of it as very similar to BGP without actually being BGP.
So what do we mean by that?
What makes a protocol BGP-like?
Well, a few things.
First of all, this is TCP-based as opposed to something like EIGRP and OSPF,
which use
multicast to discover their neighbors, BGP and OMP are able to form adjacencies
across
layer three domains.
Meaning I can reach out, whoops, wrong direction, I can reach out across the
layer three domain
to form this OMP relationship with one another.
Now, importantly, I don't form an OMP relationship this way.
I started to draw it the wrong way, but we don't actually form control plane
relationships
between edge devices.
That doesn't happen.
Instead, we all form a relationship with a control plane mechanism, which, by
the way,
kind of feels like BGP route reflectors.
Now, that's kind of interesting.
But either way, we see that OMP can reach out across the layer three world in
order to
form those adjacencies.
We're also going to carry information.
I keep mentioning that word information.
That's because we're not just carrying routes.
If we think about EIGRP and OSPF, well, we're only carrying routes.
And specifically, IPv4, IPv6.
I mean, to the point that I had to create a new version of OSPF, version three,
in order
to carry IPv6, because OSPF version two could only carry IPv4.
And we see the same thing with EIGRP and EIGRP, IPv6.
I needed a new protocol to carry new information because the protocols can only
carry one type
of information.
Whereas BGP, being an information-carrying protocol, can carry IPv4 route, IPv6
routes,
it can even carry MAC addresses depending on what information we're trying to
carry.
And so OMP is the same way.
We're carrying a bunch of information, which is going to allow us to carry
things like
RT lock routes and various other things.
And we'll learn about this in more detail later on.
So that's what makes it BGP-like.
The way we form our adjacencies, the information that's carried within, is
going to be not like
OSPF, an EIGRP, so much as it is like BGP.
Now there's one last note, and we will see this later on as well, but scaling
is a consideration
with our controllers, meaning that I am going to need, first of all, redundancy
.
We always want multiple controllers.
If one of those controllers were to go down, it would take the control plane
down, and
it's not good.
So we want multiple controllers just for the sake of redundancy.
But we also need to recognize that for larger networks, we're going to need
many controllers.
And so we'll look at those scaling numbers later on, but the point at this
phase is that
we need to recognize that we might actually have many, many different
controllers for a
very large SD-WAN environment for very large organizations.
And so that's going to be the case for several of these kind of more management
types of
devices, but that definitely applies to the SD-WAN controller and the VSmart as
well.
[BLANK_AUDIO]