Well, the last device to talk about is the SD-WAN manager.
The manager is going to serve the role of being that single point of management
.
We want to make it so we don't have to log into all of the different routers
and all
of the different devices in the network.
We really want to log into one device and manage everything.
And so that's exactly what the manager is going to do for us.
So we're going to create this manager, which is going to, by the way, run as a
virtual
machine.
So if we're keeping track or keeping score at this point, we know that the edge
and the
validator, these are running as individual hardware or software packages.
And it's the same hardware software package.
It just depends on the configuration.
Meanwhile, if we're going to deploy our controller or possibly the manager,
either way, these
are going to be virtual machines.
And so this can be deployed either into a private cloud, like an on premise
data center, or it
can be deployed into the public cloud space if we have those types of spaces
configured
in our organization.
So we deploy this as a virtual machine.
It's part of the fabric.
It's part of the network.
And the idea here is that all of us over here as managers, we're all going to
log into, again,
the single point of management.
Now we've got different ways of managing this.
If I'm a user, a human user, I'm probably going to use a graphical user
interface, logging
in via my web browser.
Or if I'm going to create automation scripts down here, make some bunch of
gears representing
automation, then I might want to take advantage of APIs.
And specifically, these would be rest APIs.
So all of this is so that I can have my visibility that we've mentioned, and my
manage ability
to be able to manage, to look to see what's happening, to push configurations.
All of this is done using the graphical user interface or REST APIs.
Now how does this configuration get pushed out?
Well, the manager is going to establish, guess what?
Tunnel secure tunnels.
We're going to use TLS or DTLS tunnels to push configuration out to the v smart
s or our controllers.
So remember, we might have many controllers here.
And so this is all going to get pushed out to the controllers.
And we're going to not only establish these tunneled connections, but we're
going to then
use NetConf in order to configure this.
So this is a different set of APIs.
NetConf is designed to be a little bit less human readable and more for machine
to machine
communication between network devices, hence the word net there in NetConf.
Whereas REST APIs are meant to be very human readable, which is why it's over
here in terms
of how we configure the manager from an API perspective.
So we're going to use NetConf APIs.
This is going to send XML, which is our structured language, the way that we
can express very
explicitly to machines, what we want them to do.
And it's going to use an SSH connection in order to do that.
That's all part of NetConf natively.
That's not something that SD when does specifically, but at the same time, SSH
sessions inside
of secure tunnels.
Yes, this is very, very secure.
As we've said several times, the security was baked into this from the ground
up.
Now a couple of things to be aware of here.
First of all, we talked about a lot of users.
Well, these users could be all different levels.
And so we're going to leverage role-based access control or RBAC in order to
make sure
that, do we have read-only users?
Do we have read-write users?
These are going to be our network administrators or possibly network engineers,
depending on
how we structure things within our organization.
Whereas our NOC users, for example, or our help desk, maybe our interns, they
can at
least have read-only access and RBAC gives us a lot of flexibility in allowing
many different
user levels to log into the same interface and only have control over the
things they
should have control over.
We also need to consider redundancy and scaling.
So we'd mentioned this earlier with the controller, but if I'm going to deploy
something like
this, I'd better have redundancy baked in.
However, this is going to work from an active, passive perspective.
I'm not going to deploy this as a cluster out the gate, not for the sake of
redundancy,
because I'm just going to log into whichever one's the active.
And if it happens to go down or I lose access, then I can log into the second
controller.
However, I can cluster for the sake of scaling.
And so if I'm going to scale up to large environments, what we'll find is that
every
manager can manage up to 2,000 edge devices.
If I have an organization that's larger than 2,000 edge devices, which, yeah,
we're talking
about probably global operations, or at least very, very large operations at
that point,
we can cluster up to six of these to give us control over 12,000 edges.
So that's talking about a little bit greater scale than most organizations, but
at the
same time, Cisco naturally needs to be able to fulfill the responsibilities of
what SD
WAN can deliver to organizations of all sizes.
So we're going to end up pushing our policies out to the controllers, which
will then enforce
those policies by pushing those policies out to the edge devices downstream.
But in the end, we do see how the manager device comes together, how we deploy
it either into
a private or public space, and how we can deploy this redundantly and for the
sake of
scaling, cluster it to support more edge devices.