Alright, it is time for us to pause for a moment and make sure that we have
absorbed
everything that we've learned.
I would encourage you not to skip over or rush this skill.
Yes, it's going to be a review skill and it's hard to hit the brakes and you'll
need
to think about all the things that we've learned, but I promise you it's an
important
part of this journey to be able to sit here and try to think through all the
things that
we've learned.
We're going to start with a couple of quizzes and then we're going to jump into
some topology
discussion and hopefully be able to just shake the rust off of some things we
haven't thought
about in a while and also make sure that we've absorbed the things that we have
recently
discussed.
So we're going to go all the way back to when we first started deploying SD-WAN
into
CML.
And we're just going to start with a practical question here about the CML
breakout tool.
So which of the following best describes the function of the CML breakout tool
in Cisco
modeling labs?
And the way we're going to do this is I'm going to ask the question aloud and I
'm not
going to pause the video for a long time.
So feel free to pause the video and think through all of the different answers
that are
given and try to decide what the best one is.
So go ahead and take that moment and then as we move through these quizzes,
feel free
to do the same for future questions as well.
So when we think about the breakout tool, this is an important part of Cisco
modeling
labs because it allows us to use our favorite terminal.
CML has a lot of amazing features.
Using the CLI inside of CML is not the best experience.
And that's because Cisco didn't really design it to be the best experience.
They gave us the breakout tool so we can use putty or we can use secure CRT or
whatever
application that we want to use if we're using the breakout tool.
So the answer here is C, it's to enable external terminal connectivity.
Now using the breakout tool, if we get some experience with it, does require a
little
bit of finagling at times.
For example, if I add a new device into the environment and spin it up, I have
to go refresh
the breakout tool, which removes all of my existing active connections, which
can be
a little bit painful.
But overall, the breakout tool is a very important part of using CML as if it's
a real
lab environment, physically in a rack down the hall or wherever my physical
rack might
be.
So that is the answer to the first question.
All right, question number two, during SD-WAN controller deployment, which VPN
is used to
connect to each other and build tunnels?
All right, so importantly, very, very importantly, all of our tunnels are going
to be built on
VPN zero.
VPN 512 is for out of band management.
That means that you and I can log into these devices and we can perform
management and
our management traffic is not going to impact the data plane side of things.
So if I see something like this where I've got the manager and the controller
and the
validator, and we've got edges out here and we're forming tunnels with one
another and
we're forming tunnels out to the different devices out here, you know, starting
with the
validator and then forming tunnels to the manager and the controller, all of
this is
happening on VPN zero.
Meanwhile, I or as the admin, you and I, we are going to be potentially logging
in here.
This is zero on the right.
We are going to be logging in potential in VPN 512.
Now we can log in via VPN zero, but the whole reason we have VPN 512 and the
ability to have
out of band management is so that I don't have to do that anymore.
I don't have to log into the same interface and be giving manager traffic flow
on the
same interface that are we're trying to actually perform real SD-WAN operations
out of.
So I can log in to manager this way, which is going to be my primary access, of
course,
because if I'm performing any kind of monitoring or configuration via manager
or V-manage,
then I'm going to be logging into that.
But if we did have to log into controller or validator to perform any kind of
operation
at the CLI or otherwise, then at that point, we would, well, I don't know what
I said otherwise
at the CLI, maybe doing some monitoring or what have you, maybe some minor
configuration
tweaks, then we could do that via VPN 512 as well.
But we are always going to form tunnels out VPN zero, forming the tunnels this
way out
VPN 512 is simply not an option.
Question number three, what is used to sign individual device certificates via
CSR in
SD-WAN?
All right, so we're throwing some acronyms out here.
I see CSR, which stands for certificate signing request.
I see the one time password here OTP.
So let's think about this.
Again, when we are onboarding our SD-WAN environment, this can be very
difficult to get
started because we have edge devices and we have our manager and our controller
and our
validator up here and we need these devices to be able to authenticate one
another.
And this is so important in the SD-WAN world because I'm going to be
potentially putting
a lot of these edge devices directly onto the internet.
And so that means that I'm going to maybe ship an edge out to a remote site and
allow
it to come online while in the same way somebody a little bit more nefarious
might say, hey,
I'm going to spin up an edge device and attempt to join some public
organizations SD-WAN environment.
Maybe they had a public release and said, hey, they've partnered with Cisco to
deploy
SD-WAN.
Cool, I'm going to try to join their SD-WAN with my edge device.
Maybe I'm some kind of malicious hacker or maybe I'm just, you know, somebody
who's
messing around.
I don't know.
I mean, we've got to prevent that from happening.
And so that authentication has to happen two ways.
First of all, I need to make sure that my network is safe from some threat
actor getting
their edge to join our network.
So I need to authenticate the edge.
Likewise, when I bring a new edge online, I need to authenticate the network
and make
sure I'm not joining a threat actor's dummy network that's posed to be like
mine.
And then I'm sending traffic to them as a man in the middle attack.
So the fact that SD-WAN exists on the internet is why so much security has to
be enforced,
especially when we're talking about zero touch provisioning or Cisco plug and
play connect.
And the fact that these devices are going to be automatically coming online.
So that's why this is so important.
Now, what exactly are we doing to authenticate?
Well, we are using certificates.
The certificate process involves first and foremost, the answer here is D, a
generated
root certificate.
Now, usually we're going to use our certificate authority to do this.
In our lab environment, we were able to use a Linux machine to spin up a mini
certificate
authority.
And then we could use that CA to generate the root certificate.
But in our organizations, we probably already have a CA sitting and performing
this role.
And so we can go to the CA and perform that, create a root certificate, and
then keep in
mind, I can take this root certificate and upload it to Cisco, which can then
perform
the certificate signings for me.
Now whether it's Cisco that's doing it, whether it's the CA that's doing it
either
way, I must have this root certificate generated.
And that's what's going to allow me to again sign the individual device
certificates, which
then get deployed onto my different devices.
Question number four, which Cisco service provides the edge device list that
allows edges to
join the SD-WAN?
All right, so we just mentioned certificates for the sake of security.
This is very important.
We just said all the reasons why security is so important.
And so the certificate is certainly one way of doing that.
The other thing we do is we have this device list concept, which follows the
whitelist
model, meaning that if a device isn't on the device list, it's not allowed onto
my network.
This is important for security, but it also allows me some amount of logistical
management
of my environment.
For example, I might have a new site with an edge that's already attached to
the internet,
but I'm not ready for that site to come online yet.
Well, I simply don't add it to my device list until I'm ready for it.
So maybe we're building this network out.
We want to make sure everything's in place first.
It happened to be plugged in and powered up and connected to the internet, but
I'm not
ready for it to join the network.
I want to wait for a particular service window that's maybe this coming weekend
.
So that would be how I can allow it to be online and operational and yet not be
allowed
onto the network yet.
So yes, logistical also security driven.
Where does this device list come from?
The device list can be manually managed, but generally speaking, we're going to
rely on
this Cisco service, which is the plug and play connect portal.
And yes, this is part of software central within the Cisco framework, but we
always like the
most specific answers here.
But just keep in mind, manager has nothing to do with this.
We're not getting into other Cisco products like catalyst center.
This is a service that is managed by Cisco via the plug and play portal or
sometimes
called the plug and play connect portal.
And that would be a cloud service that we can go to and make sure number one
that any
hardware models that we've purchased, those will show up there and allow us to
create
a device list based on that.
But number two, also any software edges, especially like those we use in our
lab environment, but
also anything we might deploy to the cloud or maybe to deploy to some kind of
server hardware
that will run the edge software.
At that point, this can be managed as well.
But all that is done and managed through the Cisco plug and play connect portal
.
Question number five, which two configurations are used to identify a software
edge like
the C8000V and bring it online?
Okay, so we just mentioned that we can have physical edge devices and we can
have software
edge devices.
I'm just using a square in a circle to represent that there's a difference
there.
So the question is, remember, we said that we need to perform authentication to
our controllers,
let's say, so our validator, we're trying to come online.
And so I'm wanting to perform authentication.
I want to use certificates for this.
So how do we go about doing this?
Well, physical devices come with an installed certificate.
The installed certificate is part of the initial authentication process, which
allows us to
bring an edge online.
And that's great when we're talking about physical edges.
This device is not only having an installed certificate, but it also has a
serial number
and that's been registered to the plug and play connect portal.
Everything from a physical perspective is wonderful.
It's already established.
I don't have to worry too much about anything.
In fact, usually by the time I get my hardware and plug it in because of Cisco
's integrations,
the validators already aware that this device might be coming online.
Software edges are very different.
I might deploy that catalyst.
Oh, yeah, 8000 V does have the catalyst name on it.
The catalyst 8000 V, which is what we're using in our lab environment here as
part of this
course.
This can't come with anything installed because it's software.
And furthermore, the serial number is going to be generated.
So how exactly do we get all of this, you know, basically all of the lack for
lack of
better words, I guess, all these transient types of information where I could
apply any
serial number and I can apply a lot of things to a software that comes online.
How do I get that into this framework?
Well, we're going to leverage two different constructs in order to do this.
We're going to use a UU idea, a universally unique identifier, and we're going
to use
a one time password.
The way this works is as we demonstrated earlier in the skill, I'm going to get
into
the plug and play connect portal and I am going to generate a universally
unique identifier
and I'm going to generate that one time password.
And then now, just like before, plug and play is aware of this concept.
It's then up to me to apply this to the software configuration so that when it
tries to come
online by mapping to the validator, it's going to provide the UID in one time
password, which
assures that it can come online.
So it's important for us to recognize that it's a little bit more, it takes a
few extra
steps, I should say, to bring a software edge online compared to a hardware
edge.
But it's this fact that we can create a UU ID and OTP in the plug and play
connect portal
and apply it to the software edge when it comes online.
This is what allows it to map into our SD-WAN and be able to come online and
authenticate.
[BLANK_AUDIO]