All right, it is time to build our lab.
We're going to start by deploying our controllers into the environment,
which actually takes quite a bit of setup.
We need to make sure our certificates are in place because everything is
authenticated via
certificates, including our controller objects.
So our SD-WAN controller, our SD-WAN manager,
SD-WAN validator, which used to be called the V-Smart, the V-Manage, and the V-
Bond.
So what we're going to do is we're going to deploy this using Cisco modeling
labs.
And again, if you have your own virtual environment or physical environment for
that matter,
then you're welcome to set it up yourself.
The CML templates will be provided though.
So if you are choosing to use CML, then we can just deploy the templates and
follow along
from a configuration perspective.
There are some interesting caveats to how we have to set all of this up.
And a lot of it has to do with the fact that this is being deployed into a
virtual environment.
And yet our devices, again, we're going to be deploying our three nodes here.
So we're going to deploy our validator, our manager, and our controller.
And these are going to have two different interfaces.
Remember, we're going to want to connect them to VPN 512.
This will be for management purposes.
And then we're also going to want to connect them to VPN zero.
And this is meant to be the underlay for our SD-WAN fabric.
Now the underlay is primarily referenced for the sake of deploying our edge
devices and
them having tunnels formed across the underlay.
But keep in mind that the controllers are also going to form tunnels down to
the edge
devices, which is why they need to be connected to the underlay.
But they're also going to form tunnels among each other as well.
And they're going to use the underlay for this.
This is really important for us to keep in mind because even as we focus on the
controllers
and not on the edge devices, we recognize that the management VPN here is going
to support
absolutely no tunneling.
So our tunnels are not going to form across VPN 512.
Instead, we're going to have to leverage VPN zero here for all of our tunnels,
whether
they're data plane tunnels between the edge devices or the control plane
tunnels among
the controller devices and controller to edge functionality.
Here's the rub.
We as our admins here, we are going to leverage VPN 512 in order to manage the
environment.
We're going to connect to our manager graphical user interface, which we used
to refer to
as the manage.
And we're going to come in through 512 in order to do that.
However, these devices, the validator, the manager and the controller, they are
going
to need to use VPN zero outbound to communicate to Cisco.
Why are we communicating to Cisco with a lab?
Well, because Cisco is going to help us out with our certificate signing.
We don't have to use Cisco, but it makes sense to use it because that's
probably what
we're going to do in a lot of production networks as well.
So we might as well do that with the lab and Cisco does allow us to do this.
But what we'll notice here is that we're using both VPN 512 and VPN zero for
actual
communication, even though this is a lab environment that has some implications
specifically
that we are going to need inbound technically and outbound traffic back and
forth inbound
and outbound traffic into VPN 512.
And we're going to need outbound traffic out towards Cisco through VPN zero.
When we're looking at Cisco modeling labs, Cisco modeling labs allows us to
configure
external connectivity.
But there's actually two different types of external connectivity.
We have a bridge option, which allows for inbound and outbound.
But what this does is it places us onto a real subnet.
Now this real subnet, when I say real, it just means that it is accessible.
So I as the network admin, or in my case, maybe just the person studying all of
this
and trying to lab it up, I need to be able to access real IP addresses here.
So if I'm going to, as we spin this up, we'll see we're using these IP
addresses of dot
171 dot 172 and dot 173.
Well these IP addresses need to be real reachable IP addresses out in the lab
network lab management
network, whatever that looks like.
So we're going to leverage the CML bridge extension in order to allow us to
communicate
on the same subnet as our CML virtual machine.
So that's very important.
Now in my lab environment, this is the 192 dot 168 dot 17 dot zero slash 24 sub
net.
And importantly, this is going to need to be adapted to your own environment.
So insert your own subnet here is going to be a very important part of this
process.
If you don't insert your own subnet, you're not going to be able to reach the
manager
address, which again, maybe it's dot 172 for me, it might be a different
address for you.
Now down here, we only need to worry about outbound, which allows us to use a
different
type of external network being the net type of external connectivity.
What the net does is it uses essentially, we'll call this a private subnet.
It's not real.
It's not accessible.
In fact, the default subnet that CML likes to use is the 192 dot 168 dot 255
dot zero
slash 24.
And we can change this if we want to.
But again, it's really a private range.
Yes, it's private because it's 192 dot 168, but it also is not a routable sub
net on my
network because we're going to leverage net.
And so what happens here, essentially, if I draw out my CML virtual machine, so
this
is my CML VM here, or if I built it on bare metal, then it's the equivalent
diagram here
applies still.
But what we're essentially saying is that we've got a layer three IP address,
let's
just call this dot X something like that.
And this interface is part of the routed network.
So we're going to call this subnet Y.
So subnet Y dot X again, in my case, it's 192 dot 168 dot 17 is the subnet Y.
But again, me as the admin, I access my CML box via this layer three address.
Okay, perfectly fine.
So we're going to do two things here.
First of all, we're going to use that bridge concept to essentially allow me to
put my
validator and my manager, very importantly, the manager.
That's the main thing that we need to worry about here.
This will be our VPN 512.
And this allows me to have, again, think subnet Y here addresses.
So now I've got dot whatever dot A dot B dot C. And that allows these devices
to have
real IP addresses.
What we can also do now is have this NAT option down here.
And this is VPN zero in our case.
And this is going to terminate here and get natted to dot X.
This is why we're allowing for outbound connectivity, but not really inbound.
And I can't really come inbound in a nap, but I can go outbound.
And so the last caveat in all of this is that this IP address really needs to
have access
to the internet because I'm trying to get to Cisco's cloud.
And furthermore, I is the network admin.
I'm trying to manage this dot B address down here.
And so I might come through a VPN or I might be coming in through some other
mechanism,
but either way, these devices will need internet access.
So back to the architecture.
Again, we're going to use two different external connectors, bridge and NAT.
We're going to use those for the two different VPNs, 512 and zero.
And we're going to connect these to our validator, our manager and our
controller.