All right, we should have the entire environment set up now.
So hopefully, whether we imported this or whether we just decided to build it
ourselves
in CML or another platform, either way, we need to make sure our three
different controller
objects can ping one another and communicate not only externally to my computer
and to
the internet, but also to one another.
And so, what's probably the main thing that we should do to make sure
everything is working
is to do just that.
Now, the other thing, keep in mind, is that VPN 512 needs to be configured for
your environment.
VPN zero, it's not needed to be a routable address on your network, but VPN 512
should
be.
So where we have 192.168.17, you're going to need to find a subnet that works
for you
and our .171, 172.173.
You're probably going to land on different last octets for each one of these
devices.
That's perfectly fine.
I'd recommend also on here in CML, come in here and change the text so that
your diagram
is up to date with what your environment actually is.
So let's go ahead and flip over to our configuration.
So what we're going to want to do here is once again, ping externally to make
sure that
we can access the internet.
That's going to be important for signing our certificates.
And so I can ping something out on the internet like 8.8.8.8.
And then I'm going to hit enter and we'll notice a couple of important things
here.
First of all, notice it's pinging in VPN zero.
The VPNs are the equivalent of VRFs.
So it is choosing an interface to send this out based on my ping command.
And by default, if I don't specify a VPN, it chooses VPN zero.
The other thing we very quickly notice is this is not like iOS.
It's just going to sit here and ping repeatedly because it's built on Linux and
this is how
Linux behaves.
So we don't actually have the iOS method of sending five pings using ex
clamation points.
It's just giving us all the information with every single ping that we use.
The other thing we want to make sure of is that our DNS server is working.
So I could ping something like www.cptnuggets.com.
We should get resolution and then we also see that we're getting responses back
.
So it's not just a matter of getting out to the internet, although that's
important.
We also need to make sure that our DNS is working because we're going to need
to leverage
Cisco's cloud and these devices know to go out to specific URLs, which is why
we need
resolution via DNS.
But notice that was all via VPN zero.
So let's go ahead and now do this via VPN 512.
How do we do that?
Well, this time I'm going to specify it.
I'm going to say ping eight dot eight dot eight dot eight via well, not via.
I'm just going to type the word VPN and then 512.
So I hit enter here.
I am accessing VPN 512 internet as well.
And then I can also do ping CBT nuggets.com from VPN 512.
And so we do have internet access outvote both VPN.
So that's good.
But what if I don't have connectivity out both of my VPNs?
Well, at that point, we're going to need to double check to make sure our
configurations
correct, make sure the default gateway especially is correct.
Try pinging that default gateway.
Make sure that we have IP connectivity out to the internet and make sure that
maybe it's
not a DNS problem.
We're using a public DNS of eight dot eight dot eight.
But if you have one in your own environment, you can use then that may be
something you
can check.
But where again, it's very important that we have internet access out both VPNs
because
one of those we're going to use for management.
But keep in mind that VPN zero is going to be used by these devices to reach
out to Cisco's
smart accounts.
Well, our Cisco plug and play portal, but our smart accounts portal as well.
And that's going to allow for going out grabbing licenses, grabbing
configurations.
All that's going to be very, very important.
We need that internet access out VPN zero for that reason and VPN 512 for the
sake of
us managing the system.
The other thing I want to do is make sure I can ping my other controllers and
my other
controller objects.
Now notice I'm on the controller.
I know the verbiage here gets a little confusing.
This is our classic V smart and I need to be able to ping my V manager or my
manager
as well as my V bond or my validator address.
So I'm going to want to make sure I'm paying attention to the address that I'm
pinging.
For example, 192.168.17, I know 171 is my V bond or my validator, but I'm going
to have
to specify VPN 512 in order to make sure I can access that device across that
specific
VPN because that is my VPN 512 subnet.
So indeed I can.
And I also should be able to ping 172, which is my manager.
And indeed, we are good to go there.
Now some of this we expected to be working because we were already in the UI
and perform
some configuration and added some of these devices, but still good to see it
here at
the CLI.
Lastly, I'm going to test connectivity via VPN zero.
So I'm going to ping 192.168.255.171.
That's the validator.
I don't have to specify VPN because we'll assume VPN zero so I can ping out VPN
zero and I
can ping the manager as well out VPN zero.
So these are some things that we're going to want to make sure of we could.
I guess it's probably worth coming over to manager and also pinging the valid
ator, making
sure that we can all ping one another.
So just very briefly here, we'll say ping 192.168.17.171.
That's the validator via VRF VPN 512.
They really are VRFs.
We just use the term VPN and then we'll want to change this to 255.171 via VPN
zero is perfectly
fine.
That's what we want.
So that is the primary takeaway from what we're trying to accomplish here.
We really just wanted to get the controller objects online and get them pinging
one another.
We also want to pay special attention to the architecture, making sure we
understand that
VPN 512 is for management purposes only.
We really only need that for the sake of accessing the UI on manager VPN zero
is going
to be used for everything else.
We're going to form our secure tunnels to one another via VPN zero.
There's no tunnels formed across VPN 512.
Nothing is happening via VPN 512 other than me coming into the manager address,
which
is why we have to be able to have inbound and outbound.
But everything else goes out VPN zero, including accessing Cisco's cloud.
So if we're going to use Cisco's cloud to sign our certificates, then we're
absolutely
going to want to make sure, first of all, that DNS is working out VPN zero, but
also
that it has full internet access.
And that's where our NAT type is going to allow for outbound access.
And from here, that's where we're going to go.
We're going to go make sure we can sign our certificates, form secure tunnels
with one
another, and then after that, it is time to bring up our data plane, which is
the ultimate
goal of SD-WAN is to get those edges forming IP sect tunnels to one another.
I hope this has been informative for you, and I'd like to thank you for viewing
.