There are two main ways that we're going to deploy our SD-WAN controllers.
Now we have to be careful.
I'm going to call them control devices.
We used to be able to call them controllers because we had the V-Smart and the
V-Manage
and the V-Bond, but now we have the controller and we have the manager and we
have the validator.
And this word controller now is sort of isolated down to just a single device.
So we're just going to talk about our control devices.
We're really talking about these, whereas the edge devices, those would be on
the data plane.
So our conversation is revolving around these control devices.
We want to call them controllers, then Zobia, that's perfectly fine.
But either way, we have two different ways to deploy these.
We can deploy them into a cloud model, meaning that we're not deploying them
into our own
environment, but rather we're paying a service to have these deployed and
managed for us,
or we can deploy them on premise.
One-prem would be deploying them into my own virtual environment as virtual
machines,
usually hosted in my own data center.
So we're going to focus in here on the cloud model first and then we'll look at
on-prem.
Now as far as why we would choose one over the other, this is primarily a
conversation
to be had between our technical resources and our management, because there are
technical
reasons for wanting to deploy on-premise and there are technical reasons for
deploying
in the cloud.
But there's also security reasons for why we might want to play one over the
other.
And some organizations would say that on-prem is far more secure, other
organizations who
may be lack physical security in their data center, or maybe they don't have a
data center
at all, and so they want to make sure that the control devices are more secure,
they
might view the cloud as being the more secure option.
So this is a conversation to have internally to decide which one makes sense.
Our job is typically just to understand the solution that each one offers and
therefore
we can provide as much information as needed in order to have the team make a
proper decision.
So let's now again dive into the cloud model.
And what we're going to find is that there's one cloud provider for this
service and that
would be Cisco.
Hey, how about that?
Cisco has actually spun up a cloud instance that allows us to deploy
controllers just virtually
in the cloud, in Cisco's cloud.
Now you say, well, Cisco doesn't own a cloud infrastructure.
Did they build one?
And no, they didn't actually build one.
They have built it in the Amazon Web Services cloud.
So this is just the infrastructure that Cisco built on.
Cisco is the one providing the service.
So Cisco would technically be our cloud service provider if we decided to go
with the solution.
Now Cisco does deploy into two different regions within AWS for the sake of
redundancy.
That way, if AWS has a regional outage, then we will in theory still have
access to all
of our control devices because of the redundancy that Cisco has built into this
.
But the idea here is that we can deploy all of our control devices, again,
controllers.
I'm so used to calling them controllers, but we can deploy all of our control
devices via
their cloud environment.
Now notice this is not infrastructure as a service.
This is not me as the customer simply going out to an AWS region and spinning
up virtual
machines.
Instead, I'm relying on Cisco to do that spin up process.
I'm basically going to Cisco and say, please give me an instance for a
controller, a manager,
and a validator and potentially more, by the way.
So as we look at this, Cisco is going to assign us with public IP addresses for
our
control devices.
And there will be private addresses as well that are for the local networking
component
for management and such.
But the public IPs will make them reachable by all of our edge devices, which
are trying
to connect into the network.
And that's very important.
And we're going to be talking more about this coming up here as we explore
controller
architecture.
Now the other thing that Cisco is going to do for us is scaling.
This is actually a very important concept, because when we look at our control
devices,
such as manager, we're probably going to want to deploy a couple devices.
A manager, as we've said, runs in an active and a standby operation, meaning
that only
one is active at a time.
This doesn't scale out to a bunch of different devices, depending on how big
our network
is.
Us as the admins, we're simply going to log into a manager.
And if this goes down, then we can log into the other one.
And it takes over from a failover perspective.
So that's deployed for the sake of redundancy, in case one of them fails, it's
not deployed
for the sake of scaling.
So I just want to get the manager component out of the way.
However, the other two are validator and our controller, formerly the V bond
and the V smart,
these devices are going to scale up depending on how many devices and
specifically edge devices
that we have in our network.
So we might end up with a bunch of controllers.
And these are all in an active state.
What happens here is we end up using these again as the route reflectors for O
MP.
And this is going to enable us to scale out to all of the different edge
devices and manage
all of the OMP relationships.
But again, all of these are active.
And furthermore, if we have need for more validators, then we can spin up more
validators.
And these are also going to be all active.
So again, as the number of edges increases, we're going to need to increase the
number
of controllers in our environment and increase the number of validators.
And the good news is Cisco takes care of this for us.
Like, keep in mind, again, what we said, Amazon is not serving up the ability
for us
to create our own virtual machines for this solution.
Cisco is providing us with a service, which means that they provide us with
scaling.
And for that matter, just generally speaking, they are the ones managing the
virtual machines.
I don't have to worry about spinning up additional controllers and additional
validators with
Cisco solution.
I simply subscribe to their service.
And as my edges increase, they will increase the number of control devices as
needed in
order to properly scale.
Now it's worth bringing up in the cloud conversation that there are managed
service provider solutions
out there as well.
But these take things usually a step further than with Cisco, what they do.
For example, Cisco's focus is on the control devices.
And they're simply managing them as virtual machines for us, but we still have
control
over their configurations.
We have access to the edges and so on and so forth.
A managed service provider is going to usually say, hey, we manage a wide area
network solution,
potentially the one that our organization is using.
And so let's convert that into an SD-WAN type of solution.
Maybe we'll use the internet as a secondary connection.
So rather than go out and build our own SD-WAN environment, the service
provider is going
to do everything.
They're going to manage the control devices and they're going to manage the
edges for us.
Now everybody's offering might is going to be a little bit different.
And for that matter, it might not even be Cisco necessarily.
But at this point, we don't care as an organization because we're consuming
this as a service.
So the way this works now is I might just take like a layer three switch.
Maybe it is an edge router at a site and I connect it into the SD-WAN managed
environment.
So all I know is my other layer three switches are all out here at different
locations and
I can form routing relationships and I can make sure that my environment works.
And I know that under the hood, I'm running some kind of MPLS plus internet
circuit combination.
So that's great, except when I look at it from an SD-WAN perspective, we know
that there's
something happening under the hood.
Indeed, they're going to be deploying edge devices.
These edges will connect with their controllers.
They'll form the IPsec tunnels.
We've got multiple service providers in here between probably the service
providers own
underlying network for the wide area network side of things, but then also
building tunnels
across the internet, like we said, over here.
And so just be aware that this can feel like a cloud service, but this is more
of a consumption
model where I'm no longer doing anything to manage SD-WAN at all because the
service
provider is doing that for me.
So I wanted to mention again, as part of the cloud conversation, because there
are multiple
ways of consuming software defined WAN as a service.
Cisco's offering is a lot more focused on just managing those controller
devices for
us.
So we don't have to deploy them into our own environment and try to figure out
the networking,
which as we're about to explore,
could potentially be a challenge.