So, we might also want to deploy our controllers on premise.
If we're going to do that, then we're going to have to deploy it into our own
environment.
So rather than rely on the Cisco cloud, I'm now going to have to deploy my
control devices
and put them onto my own servers, which are usually located in my own data
center, or
possibly an IaaS environment.
So, if I have the hardware, then I'm going to deploy into my own data center,
or I could
deploy it into the cloud.
So, we do have still options here.
Just keep in mind that when we say in the cloud, at this point, we're still
talking
about us having full control over the deployment of these devices, as well as
the management
of them.
So, in either case, we are now responsible for the scaling up of the devices.
And if there's any kind of redundancy or failover, we're going to have to take
care
of that as well.
And that could be a software issue or it could be a hardware issue, especially
if we're
deploying it into our own data center, because we manage our own hardware at
that point.
So that is how we go about doing this.
And keep in mind that we're talking about deploying virtual machines.
So we need to deploy these into a virtual environment.
Now, as of the time of this video, Cisco supports two different virtual machine
platforms
or hypervisors.
They deploy onto ESXi, which is VMware.
VMware's hypervisor product is known as ESXi.
Yes, that's a lot of letters.
If you're not familiar with it, to try to keep track of which product is which,
because
we have more letters here, which is KVM, which stands for kernel virtual
machine.
And this is a open source Linux solution.
So Cisco does support either one of these and we can deploy it into our
environment,
depending on which one we want to run it on.
And here's the other thing that we have to consider.
We have to consider our IP address assignment.
This creates a rather interesting conversation.
Remember, our VBond or our validator is going to require public IP addresses.
It doesn't need to be in a public IP subnet, but it does need a public address
reserved
for it.
So we can use NAT at one to one, or we can put it into a DMZ, depending on
which one makes
the most sense for our organization.
So what about the manager and what about the controller?
Well, this is going to lead to a conversation about how we go about connecting
to these
controllers, because it's really easy for us to draw a diagram with edges
connecting
to each other.
And then we've got the controller sitting over here, pushing our OMP out.
And this is great.
This is a logical diagram, for the most part, even the IP sectonals,
technically logical,
I suppose.
But the controller just sitting out in the middle of nowhere, that's not a
physical connection.
We're talking about deploying these controllers and managers onto actual real
servers, which
in theory connect to real actual switches.
So we need to think about things from a physical perspective and a topological
perspective.
And we can get logical from a, like a VLAN perspective, but we need to think
about how
the networking is actually going to flow.
Now remember, when we talk about our controller and our manager, we have two
different networks
that are going to be associated with them.
We have these VPNs, so VPN 512, which is for management.
And recall that when we say VPN, that is an old, the teleterm, Cisco's actually
trying
to phase this out.
We mentioned earlier, it's the equivalent of a VRF.
So we might still see VPN or VRF, depending on which documentation we're
reading, but
be aware that both of those terminologies exist.
And we're still going to see VPN in the configuration.
So we have the separate management VRF.
We can just connect it into a VLAN that's in our data center.
That's perfectly fine.
And maybe it's part of our normal layer three routing domain, or maybe it's
completely out
of band and we have to VPN into it or something along those lines.
But then when we think about the other side, what are we connecting into for
the data side
this is the management side up here.
This is the data side.
And when we say data, we're talking about the controller reaching out to these
edge devices
and forming tunnel relationships.
And for that matter, they've formed tunnel relationships to one another as well
.
Well this is going to be on VPN zero.
And at this point VPN zero means that we're going to need some or need these
devices to
be part of the underlay.
This is really interesting because if we're going to be part of the underlay,
that means
that an edge device has to reach out across the underlay to communicate with
them before
building the IP sec tunnels, a little bit of a chicken and egg problem.
We're going to address this in more detail in the next video.
But for right now, what we want to establish is that we're part of this under
lay.
Now usually what this leads to is us suggesting that we're going to use the
internet for
at least one of our options in SD-WAN, which is actually very, very common.
We're not going to see a real world scenario where we're not using the internet
as one
of our underlays.
That would be two or three MPLS circuits.
And usually we're at least going to rely on internet as a complete backup if
nothing
else.
So usually we're okay with connecting in via the internet.
And at this point, if the edge device has internet connectivity, well now this
is a public
IP space if it's the internet.
And as a result, we don't need to establish tunnels yet.
We can reach out across the internet and connect to our controller and our
manager device for
that matter and start to make these connections.
So that is great.
And by the way, I should include the validator in here.
The reason I didn't include the validator originally is because we know that
validators
need a public address and we're trying to figure out what to do about managers
and controllers.
Well in the end, we're probably going to deploy public IP addresses as well.
Now this is optional.
It's not required.
Meaning that the validator, which relies on a public IP to do things like net
bypass
and just flat out needs to be as easily discovered as possible from the very
beginning since
it's responsible for onboarding.
That's why it requires a public IP address.
But the manager and controller never require a public IP address, but it does
seem like
it makes it a whole lot simpler for connectivity.
Because now the edge devices can use the public internet to reach out and
communicate with
these devices.
So at that point, we would still need a, you know, potentially a NAT one to one
type of
scenario, but in the end, how we do this is up to us.
We just need to make sure that the edge devices can reach out and communicate
with the controller
and the manager once the validator actually says, Hey, here's where the
controller and
manager live.
We need to be able to communicate with it at that point.
Now we do have other options as well, but this is a very popular one.
As a result, we generally have two different models for our on-prem deployment.
We have a private IP model.
And the private IP model is going to require us to really think about how we're
going to
propagate private IP addresses to these edge devices.
It might require going through and advertising routes through an MPLS service
provider, but
it's certainly possible.
The other option is what we call the hybrid model with a private IP address.
At this point, we are deploying our private IP addresses here to our manager
and controller.
These have private IP addresses.
But as we've mentioned, we're probably going to tie it, tie it back to a public
IP address
via NAT.
So those are the two models that we need to consider.
So how do we get started?
Well, it all starts with our VM installation.
We're going to need to get into our virtual environment and spin up a virtual
appliance
for each one of these controllers.
Now here's the good news.
Cisco pre-packages these.
So if I'm going to deploy it into ESXi, VMware solution, then they provide an O
VA, which
stands for open virtual appliance.
This is essentially a template that is going to tell ESXi exactly how to build
out a virtual
appliance.
So I don't need to worry about deciding how much memory and VCP use to toss in
there.
I don't need to worry about misconfiguring it.
The template or the OVA is going to produce for me an actual virtual machine.
And at that point, we might refer to it as a virtual appliance, but either way,
it's fully
installed and configured.
Now that said, we're still going to need to configure the networking because we
need
to attach to the proper networks and the OVA is not going to know our own
network from
anybody else's.
So the other option, once again, is going to be with KVM and they have the
exact same
concept with the Q-COW, which will also produce a virtual machine in the KVM
environment.
At that point, we've got our controllers installed into our virtual
infrastructure.
We just again need to decide the proper networking format and we're going to
dive into a few
more details coming up in regards to that.