All right, let's jump into the next quiz here.
Now, we're going to be talking about the different components.
What better way to start that conversation
than to just make sure that our terminology is aligned?
Here, we're asked to identify
the rebranded component names according to
the classic SD-WAN names.
Here's the classic names,
meaning that this is what
Viptela called all of their different components.
Now that Cisco has absorbed it
and they're starting to rebrand it,
what exactly are those names again
So the V-Bond is known as the validator.
It's quite a name there.
We are validating our edges and helping them to come online.
The V-Edge is simply known as the SD-WAN edge.
Now, if you called this a C-Edge,
then that's also technically correct.
However, it went from V-Edge
to creating the concept of a C-Edge,
and now we just call them SD-WAN edges.
So even C-Edge is a little bit outdated.
Now, V-Smart has become known as the SD-WAN controller.
This is why Cisco refers to our V-Bond
and our V-Smart and our V-Manage.
They refer to these as control components.
We don't call them controllers.
We kind of used to call them controllers
because they were the controllers in the environment,
but now that we have something called an SD-WAN controller,
we now refer to the three collectively
as control components.
And V-Manage, probably the most straightforward of them all,
V-Manage became SD-WAN manager.
So let's make sure if we see something
like the SD-WAN validator is doing such and such,
we need to look at that and understand
that it's talking about a V-Bond and vice versa.
If you're first learning SD-WAN right now
and you haven't known about the classic names,
you might only know what a validator is.
And so if you see something about a V-Bond,
it's important that we know
that it's talking about the validator.
So Cisco is in the process of rebranding.
However, there's still going to be a lot of areas
where we see the classic names.
So at this point in our journey,
we're going to need to know both.
Question number two,
and it ties back to what we just talked about.
Now I left this as an open-ended question.
So however you want to answer it is fine,
but here's the fundamental difference.
The biggest difference has to do
with the software that it's running.
This is not a name change.
I want to be very clear.
When we talk about a vSmart now becoming a controller,
the software doesn't change.
We're still running Viptela software,
whether it's a vSmart or it's a controller.
Cisco hasn't created their own software,
at least at the time of this video,
that's based on iOS XE.
However, when we're talking about a V-Edge,
which runs Viptela software, which we might expect,
that's what the little V always means
in an SD-WAN environment is that it belongs to Viptela,
not virtual.
Sometimes we see these and we think it means virtual.
It's talking about Viptela here.
But when we go to a C-Edge,
that little C now is standing for Cisco
and it's running iOS XE.
It's no longer running Viptela software.
So if there's a command that I'm used to running
on the Viptela side, I usually have to,
one of two things, let's say I'm doing a show command,
so maybe show something
and maybe I want to do a configuration,
so I just do the configuration.
Well, now within iOS XE,
there's an entire SD-WAN set of commands.
And we'll see that later on when we're in the lab.
So I might say something like show,
instead of saying show this, I'll say show SD-WAN this.
And instead of just performing a configuration,
I might have to enter into SD-WAN configuration mode
and then perform these commands.
So the good news and bad news of it is yes,
we're running completely different software.
That's the bad news.
The good news is a lot of these commands
are still the same, relatively speaking.
We're just gonna have to make sure
we get the iOS XE version down,
which usually just involves including SD-WAN as a parameter.
And by the way, now that we have
just straight up our SD-WAN edges,
we don't call them C edges anymore.
We just call them an SD-WAN edge.
This really is just a name change.
Same thing as over here.
This is a name change.
This is just a name change.
So SD-WAN edges, all of this applies as well
when we're talking about the modern hardware and software.
All right, question number three.
In which plane of operation
do each of the following components run?
So this is a very important question
for us to be able to answer.
We are going to think back to the fact
that we just answered a question
about those four different planes of operation.
Now we need to make sure we map
each individual plane of operation to one of our devices,
whether it's a control component or whether it's an edge.
So when we're looking at the edge itself,
this is going to operate in the data plane.
That's the whole purpose of the edge
is to actually forward traffic,
which is the role of the data plane.
The controller, it's right there in the name,
this is going to be the control plane.
In a traditional network,
the control plane is where our routing protocols run.
It's where we share the information
that tells the data plane where to forward packets.
And that's no different here.
The controller is running OMP
and it's therefore sharing routes
via whatever policies we have set.
Now that still leaves two devices and we're like,
okay, well, data plane and control plane
are taking care of what else we got.
Well, validator is part of that orchestration plane,
which as we've said,
is going to help SD-WAN devices get onboarded.
So SD-WAN devices will come online,
reach out to the validator or V-Bond,
if we want to call it that.
And as part of the orchestration plane,
we're going to do NAT and NAT bypass,
and we're going to get online,
and we're going to be told a lot of information
about where our other edge devices are,
so we can start to form tunnels.
And that's all thanks to the validator.
Lastly, we have the management plane,
which as we might guess belongs to,
or maybe the manager belongs to the management plane.
But either way, this is how you and I as network admins
are able to log into the SD-WAN environment
Question number four,
and there are seven questions in this quiz,
so a few less than the last one.
Which SD-WAN component is responsible
for onboarding new edge devices onto the network?
Well, if you just listen to the explanation
for the last question, you already know what it is,
and it's C, the SD-WAN validator.
It's important for us to know the role
for all four of these,
but when it comes to anything related
to onboarding our new edge devices,
that is going to be the SD-WAN validator,
previously known as the V-Bond,
All right, question number five.
Which control component is only able
to form DTLS tunnels and not TLS tunnels?
So I said earlier in the quiz,
actually it was the last quiz,
that TLS is TCP-based, DTLS is UDP-based,
and so when we look at this,
we default to DTLS tunnels,
but we can change to TLS tunnels if we so desire,
but not for all of our control components.
So which one is the odd one out?
Well, it's not an edge,
because that's not even a control component,
but the odd one out here is going to be the validator,
and there's a reason why Cisco does it this way.
When an edge comes online,
it reaches out to the validator,
and the validator is going to facilitate
a lot of communications.
Cisco wants to rely on UDP for these communications,
or at least for the tunnel that houses those communications.
So we form a tunnel to the validator using UDP,
and when we do that,
we use DTLS to form that secure tunnel.
Now eventually, this tunnel to the edge gets torn down,
and so we're left with TLS connections
to the other control components,
but remember what we said.
These devices are also forming tunnels with one another,
and when they form tunnels with one another,
they are going to also require DTLS tunnels
to be formed to the validator.
Now, what about this tunnel between controller and manager,
and what about the tunnel from the controller
down to the edge and the manager down to the edge?
These three tunnels will start as DTLS,
but I could configure them to be TLS tunnels if I so desire,
and again, that's going to be determined largely
by my organizational policy
and whether I have a need
to convert the DTLS tunnels to TLS,
but it is important to know
that when we're talking outside the data plane,
we're not talking IPsec anymore, we're not talking GRE,
we are talking DTLS and TLS tunnels,
Question number six,
which control component uses NetConf
to push configurations to other devices?
So anytime we're studying
a software-defined network solution,
we're probably going to bring up NetConf.
NetConf was specifically designed as an API
to allow network device to network device communications.
This is not usually an API
that I as a programmatic network admin
am going to use to control my network devices.
Usually, me as a human,
I'm going to want to use REST APIs,
which are a whole lot more human-readable
to control devices.
So when I'm going to use network programmability
and APIs to configure my SD-WAN,
I'm going to perform REST API configuration to my manager.
But then the question is,
who's using NetConf on the other side
to push the policy down?
And that would be it, right there, it's the manager.
The manager is going to push this policy,
or whatever configuration I do here,
it's going to potentially make changes
to the edge via NetConf,
and importantly, also to the controller via NetConf as well.
The controller and the edge,
remember, these have an OMP relationship.
They are forming routing adjacencies
or routing peerings with one another.
And so everything that the controller is going to send
to the edge device is going to be via OMP.
But when it comes to the manager pushing configuration down,
well, that's going to be thanks to NetConf
that we're able to do that.
And furthermore, if I have policies that I want to configure
whether it's via the REST API, or for that matter,
just using the graphical user interface,
either way, manager will turn around
and push NetConf configuration
to either the controller or the edge,
depending on what exactly I'm trying to accomplish.
So the answer here, oops, I never circled it,
is D, the SD-WAN manager.
All right, last question.
How many edges can be managed
by a single SD-WAN manager appliance?
So the answer here is 2,000.
It's just something we're going to have to memorize
a little bit.
It's going to help us out
if we ever grow to a very large organization
or get hired by an organization that has a lot of edges.
And importantly, we can form a cluster
of up to six managers.
Well, if we do some basic math,
that means that I can support 12,000 edges total
via a cluster, but that still is 2,000
per SD-WAN manager appliance.
So if I have a more basic deployment
with just a single manager,
it's going to only allow me to support 2,000 edge devices.
So that wraps up our quiz around the components
and making sure we understand what all the components are
and what they're doing within the SD-WAN framework.