Recall that we have two security mechanisms when we're onboarding our edges.
We are going to use white lists to make sure that we are in complete control of
what devices
are allowed on and which devices aren't.
And then beyond that, we're also going to use certificates.
Yeah, more certificates.
We just got through to playing those for our control devices.
Fortunately, it's a pretty straightforward process to get these on our edges.
In fact, our edges typically come installed with certificates.
However, that doesn't apply to virtual.
So we have to think about this from the perspective of whether my devices are
going to be physical,
meaning they're coming from Cisco or if they're virtual.
And if they're virtual, that just means that I downloaded them.
And if I downloaded them, then we're going to need to think through how exactly
we can
authenticate these because anybody can download a virtual router.
And then we don't want to necessarily have certificates baked in and we really
can't
do that.
We're going to have to think of a different method for doing this.
Now in our lab environment, we're going to only be doing virtual deployments.
And the real world might find yourself doing a whole lot of physical
deployments.
The good news about physical deployments is that when you purchase a router
from Cisco,
Cisco will automatically deploy that router into your plug-and-play portal.
So as an organization, you go out, you purchase a bunch of routers or edges,
you get into
your plug-and-play portal, all of those edges will be listed and you'll be able
to generate
the whitelist.
Furthermore, they're going to come with a certificate.
And so that allows us to go through that zero-touch provisioning concept, which
unfortunately
we can't take advantage of in our CML space.
So let's think about that, just break it down a little bit further.
So when we're talking about ZTP or zero-touch provisioning, what we're really
talking about
here is allowing truly zero touch.
That means that I send this edge device to a site where somebody is over here
and they're
sitting here thinking, "I don't know what exactly this is, but it doesn't
matter.
I just have to plug it in and connect it to the internet and then everything is
going
to happen magically."
So what exactly does happen?
Well, we've got this Cisco cloud up here.
Cisco plug-and-play cloud, sometimes referred to as the ZTP cloud, but Cisco
has taken
the ZTP concept, which was a phrase that was especially used with Viptela and
they had
their ZTP servers.
And Cisco has integrated this into now their plug-and-play connect portal.
So plug-and-play is something that Cisco uses for a lot of devices, even beyond
SD-WAN.
So it's all part of Cisco plug-and-play now.
So refer to it as zero touch provisioning, but the idea here is that this
physical device,
which comes with a certificate of authenticity, so we know that this came from
Cisco, this
is going to reach out to the plug-and-play portal.
Now this device has a serial number, and so if it's got serial number ABCD,
then Cisco
in their cloud for our organization knows, because we bought this from Cisco,
that we
have a serial number listed for ABCD, meaning that it belongs to our
organization.
So the good news here is there is a certificate exchange that happens here that
we authenticate
each other, everything looks good, and then we get directed to the V-bond or
the validator,
as we're calling it these days, which also belongs to our organization.
Now again, Cisco knows that our organization purchased this router, and so
there's a trust
level here that allows us to then hand it off to the validator.
Now the validator is going to check the certificate to make sure that
everything is good, and
we should be good there, and then it's also going to check the whitelist.
Now the interesting thing about this process is it gives us control really
technically
only over one part of this, because the certificates are all handled by Cisco,
yeah, it's good
that we're checking to make sure that everything is on the up and up, but we
don't have control
over that, and so if we didn't have the whitelist, then the certificate would,
in a sense, be
the only thing that we could use for gatekeeping, which would say, "Okay, hey,
you're good to
go, go ahead and join the SD-WAN environment," which means that just by plug
ging in a router
it automatically joins, we might not like that so much.
We might have purchased a lot of routers, and we are deploying them across the
globe,
and people are plugging them in, and we're not ready for them to join yet.
Or for that matter, maybe I is the IT admin, I'm behind on things, I haven't
gotten configurations
in place.
So I don't have control over the certificate part, but I do have control over
the whitelist
part, meaning that if I'm not ready for a router to join my SD-WAN environment,
I don't have
to place it into the whitelist.
Cisco does not do that for me, and that is the primary takeaway here of this
part of the
conversation.
So the whitelist is something that I, as the admin, am going to have full
control over.
How do I go about getting the whitelist into this space?
Well, this is going to involve manager, and it's going to involve the plug and
play connect.
So what I'm going to do is I'm going to go into my plug and play portal, and I
'm going
to allow this device, and the plug and play portal will provide for me the whit
elist, at
which point I can load it into manager.
So this is what we're going to do in our lab environment.
We're going to grab that whitelist, upload it to manager, and then manager will
update
it for the V-bond or the validator.
So that's great.
So if I have gone through this whole process right here, then that means that
by the time
this router reaches out to the validator, the whitelist says, yes, you're good,
and we push
into deploying and creating all of those tunnels.
So that's well and good.
Never naturally, if I'm not ready for that device to come online, then I
probably am
good with the device just sitting there waiting until I am ready.
Now the other thing we can do is we can, and let me go and do that in a
different color,
we can allow these to synchronize automatically.
It removes this manual process of me having to download it and then upload it
back into
manager.
So that is a nice part, and this is probably what we'd want to do, because I
still have
to allow the device in the plug and play portal, and then it will automatically
sync and will
come online.
So we've got a couple of options there.
But even though this diagram feels maybe a little bit complex and the arrows
kind of
going everywhere, just keep in mind that we have these two security mechanisms,
and the
certificates are kind of handled for us in a lot of ways.
It's the whitelist that we really need to make sure that we're explicitly a
part of.
Now there's two aspects to ZTP that's going to cause us problems.
First of all, it's going to require DHCP.
In order to come up, we have to truly support zero touch.
I shouldn't be in a place where I have to provide an IP address, for example.
I have to provide DNS configuration services.
So DHCP and DNS, if either of these aren't available, we can't use DTP.
Furthermore, we might have another reason why we can't use or don't want to use
ZTP.
And so all we're looking at here is saying, Hey, if we're not going to use ZTP,
then we
need another mechanism.
And that mechanism is going to be known as the bootstrap mechanism.
And this is what we'll be using in our CML environment, because again, we don't
have
DHCP.
Now if you're in an lab environment where you do have DHCP, then gives it a try
.
That's great.
That's a lot more experience that we have with these different mechanisms the
better.
But the bootstrap process is going to require manual configuration to be placed
onto the
device.
Now this can happen in two different ways.
First of all, we can just place a file onto the device, which maybe is going to
in some
situations make things a little easier for us to provision.
The other option is that we actually perform some amount of configuration
manually.
And so what we're going to do is we're going to take advantage of this, again,
from the
perspective of CML, by using some bootstrap code, or I suppose a script.
So this is how we're going to do it.
The other thing we have to consider again comes back to the fact that we're
using virtual
devices.
Anybody can spin up as many virtual devices as they want.
I could spin up a thousand virtual routers.
How exactly do I go about giving them an identity that can be used?
Furthermore, the fact that they don't come installed with a certificate.
What exactly is that going to look like here?
Well what we're going to do is we're going to spin up our edge devices and
these are
going to be 8,000 V's.
So catalyst 8,000 V's, Cisco famously calls them edge platforms instead of
routers.
They're basically routers that are designed to be part of SD-WAN.
So we have to be careful because Cisco also has a series of 8,000, well an 8,
000 series
of routers that are not compatible with SD-WAN.
So certainly anytime we're doing a design or making a purchase, we're going to
want
to make sure we're working with Cisco or our Cisco partners to make sure we're
making
the right purchase.
But when it comes to our virtual catalyst edge devices, we're going to be
looking at
8,000 V's.
So the idea here is that I can spin up 8,000 V's, but I need Cisco to provide
an identity
that we can then whitelist.
Because otherwise how are we using it?
Where are we getting a serial number from, etc, etc.
So instead what we're going to do is we're going to go out to the plug and play
portal
and we're going to generate, if we can spell that, generate, we're going to
generate a
bunch of IDs.
And furthermore, we're going to generate a bunch of one time passwords.
So the ID is known as a universal unique identifier or a UUID.
The one time password is going to take the place of an installed certificate.
So we sort of solve both problems at once.
We're going to have our UUID and we're going to have a one time password.
And then we're going to apply this via configuration and take advantage of the
bootstrap methodology.
Now as part of this configuration, we're not only going to provide the identity
, but we're
also going to provide the IP address and connectivity.
And so this is how we're going to ensure that when this 8,000 V loads up, first
of all,
that it has network connectivity so it can get out to the PNP cloud.
But second of all, not only does it have connectivity to get there, but it also
has
an identity.
And then instead of a certificate, it's going to say, hey, not only am I
claiming to be
this person, but I can prove it not because I have a certificate, but because I
have a
one time password.
So our objective in bringing all this up is to make sure that all of this is in
place.
And it's quite a process, but we're going to walk through it step by step and
make sure
that we can do it from start to finish and get our SD-WAN edges online.