Let's go ahead and take a moment to pause and reflect on everything that we've been
learning and make sure that we're taking the key pieces of information with us.
We're going to have a review skill here, and the way we're going to do this is we're going
to have a quiz in this format that we've done before where I'm going to ask a question,
and you're welcome to pause the video.
Make sure you can answer it yourself before they then give you the solution.
And so the goal here is not necessarily to get 100% because we're going to ask a lot
of questions that cover a lot of ground.
The main point here is to identify any areas of weakness so that we know moving forward
that maybe, or maybe before I move forward rather, I should go back and review a particular
skill.
So at the bottom of each quiz question, we're going to give the source skill.
You can go review that skill if you feel like you need to based on these quiz questions.
If everything feels good and you feel like you've got all of that down, then feel free
to move on from here.
But again, let's go ahead and take a moment and take the time to make sure that we do
have some of these fundamental concepts down.
So first question here, what are two benefits that SD-WAN offers over traditional WANs?
And I will say, if we don't have this concept down, this is not going to be a question on
an exam or anything necessarily.
I mean, maybe, I mean, I guess I shouldn't say that for sure.
But generally speaking, the reason I'm asking this question is because if we don't understand
the benefit of SD-WAN, it's going to make it very difficult for us to really understand
why the solution is put together the way it is.
For example, why do we have control components and why is the control plane split off from
the data plane and so on and so forth.
And so understanding the benefits that SD-WAN offers allows us to really absorb better what
the architecture is, why it was built that way, what technologies that are being deployed
are, what they're being used for and why.
So in the end here, the answer is going to be simpler management because now we have
a single point of management that can manage many, many edges, potentially thousands of
edges rather than logging into each device on its own.
We're also able to secure traffic using IPsec.
And yeah, we had solutions like DMVPN, for example, that would make it so that our traffic
was secure.
But if we were relying on T1s or MPLS, oftentimes we weren't securing our wide area networks.
As for the rest of these, we're not using VXLAN, we're not using site-to-site routing
protocols, we're relying on SD-WAN and its routing protocol, which we talked about was
OMP.
And yeah, unfortunately it doesn't make for cheaper hardware solutions, however, it does
allow us to take advantage of cheaper internet circuits, where before it might have been
too complex or just flat out not possible to use those kinds of circuits.
And as a result, we could actually end up saving money by deploying SD-WAN, which is
pretty fascinating because oftentimes these newer solutions from a technology perspective,
they don't necessarily save us any money in the long run.
But SD-WAN very might well do that by allowing us to deploy cheaper circuits, but it's not
going to help us out by allowing us to deploy cheaper hardware.
Question number two, how are SD-WAN control components deployed into the network?
So remember, we've got these control components, we've got three of them.
So we have our edges, which are the routers, and they're going to be forming tunnels to
each other.
But then we have these three control components up here, and we'll be forming some tunnels
and allowing our edge devices to come online and get information like routes and such.
And so the question is, yeah, I could go deploy physical edge device, but what are these devices?
How do I deploy them into my network?
Well, the answer is B here, it's as virtual appliances.
They're not going to run on existing hardware like routers and switches, and we're not deploying
these as physical appliances.
Some Cisco solutions allow us to deploy physical devices as our controllers.
For example, I think of ACI and physical APICS, for example, like that, or possibly
wireless LAN controllers.
But in the SD-WAN environment, they are going to be deployed as virtual appliances or virtual
machines, and we can deploy that up into the cloud, or we can deploy it into our own infrastructure.
All right, question number three, and it is out of nine questions, by the way.
So three out of nine, which two tunnel types can be used for SD-WAN data plane operations?
All right, very important here.
We're talking about data plane operations.
When we draw out our topology and we see that our edge devices are forming tunnels to one
another, what are these tunnels and what protocol are we using for them?
The answer here is B, IPSec tunnels.
So we're going to deploy IPSec when we want to perform a secure data plane.
Like we said earlier, we're able to actually secure it ourselves.
However, it does say that there are two tunnel types.
So what's that other type?
Well, the other answer is going to be GRE.
In most production environments, we'll be using IPSec.
We want to take advantage of the fact that we can secure our tunnels, for example.
But GRE might be used in lab environments, it might be used in situations where we're
already securing the wide area network in some fashion and we don't need to add the
overhead of IPSec.
And so we do have two different options here.
But understand that at the data plane, these are our only two options.
We're not going to be using anything else to form our tunnels.
Question number four, what are the four planes of operation in the Cisco SD-WAN solution?
So you might have noticed that I left this as an open-ended question rather than putting
out answer choices.
And so, yeah, we want to make sure that we can recall these kinds of facts, I guess,
off the top of our heads.
So what are those four planes of operation?
Well, in a traditional network architecture, we're going to expect that we'd have a data
plane and a control plane.
And certainly those are going to be the first two planes of operation for us within the
scope of SD-WAN.
Now, we might also look at a traditional network and say that we've also got a management plane
or maybe an out-of-band management network, whether we consider that a plane or not.
Cisco, for example, they include options to secure the management plane for us to be able
to protect our devices from a management perspective.
And so those are certainly three traditional planes of operation.
But there is one more that we've got to make sure we remember, which is the
orchestration plane.
Orchestration plane is new because we don't need this in a traditional network architecture.
And by the way, we don't even necessarily need it in other software-defined networking
solutions like ACI, like Cisco's software-defined access.
We don't necessarily need an orchestration plane.
However, given the nature of the SD-WAN environment and the fact that we have routers
around the world trying to connect in through the internet, we might want to really
understand that the orchestration plane is going to help us in those situations, which
is why it's part of the solution.
So that orchestration plane, which is where the V-Bond or the validator hangs out, is
going to allow our edges to find the SD-WAN and be able to securely connect to it.
Remember, we want our edges to know for sure that they're connecting to the right SD-WAN,
and we want the SD-WAN to protect itself from rogue edges trying to join the network,
whether it's accidentally connecting a device that we don't want on the network yet, or
if it's some malicious actor trying to actually connect an edge device to the SD-WAN so that
they can start to play man in the middle as our traffic is flowing around the wide area network.
All right, question five.
What are the two tunnel types used by the Cisco SD-WAN solution outside of data plane operations?
Well, we just asked what we're using inside of data plane operations.
That would be IPsec and GRE, but now we have two other tunnel types used by SD-WAN outside
of data plane, and that would be DTLS and EDTLS, and these are primarily going to be
used by those control components.
SD-WAN edges are going to communicate with each other, usually via IPsec, possibly GRE,
but this is the data plane.
Meanwhile, we've got these other control components that are sitting out here that are helping
us to manage the environment, to deploy policy and such, to onboard new edges.
Those would be the validator, the controller, and the manager, and these devices are going
to be forming tunnels to the edge devices, and they're going to use TLS, which is the
TCP version of this tunnel, or DTLS, which is the UDP version, and DTLS would be the
default solution there.
Which one should we use?
Should we activate TLS instead of DTLS?
Well, that depends on our corporate policies and whether we're trying to perform some kind
of inspection on the traffic.
The reason DTLS is used is primarily to enable it to be seamless.
We don't have it, or we're not using TCP, so it's not connection-based, and that can
sometimes cause problems via firewalls.
So keep in mind that these control components are using that TLS or DTLS set of connections
to communicate with each other, and then to communicate down to the edges.
Question six.
What is the default topology formed by SD-WAN edge devices at the data plane?
So the default topology is going to be full mesh.
This is important.
If I have a bunch of edge devices at all of these different sites, maybe I've got six
sites in my network, and I have a headquarters location, and for the most part, all of the
resources that all of these devices need, or all these branches need, their users need
to access, are sitting at the headquarters.
And so we might think that we want to just form tunnels kind of like this, and what's
actually going to happen is that all of these edges are going to form connections to each
other as well.
And so this starts to form that full mesh of communication because all of these devices
are just going to want to form, according to the default topology, all of their data
plane tunnels.
So we might want to get in here and change that.
We might want to change it into a hub and spoke.
If really all of our resources are at the headquarters anyways, might as well send traffic
directly to the headquarters.
And worst case scenario, if I need to get to a resource out here, then I can get routed
that way.
It's not efficient, but at least it gets the job done.
Meanwhile, since most of the traffic is flowing to the headquarters, I'm not being inefficient
with my tunnel propagation and the creation of all my tunnels.
Now with six devices, it doesn't really matter if I form a full mesh because our routers
can handle six different tunnels or whatever that amounts to.
I guess that'd be five other tunnels, and I think I missed one in there.
But what if I have a thousand edge devices?
Well, I definitely don't want a thousand edge devices forming 999 tunnels out to all of
the other edge devices.
And so this is why we want to take ownership of the topology, and we don't necessarily
want to leverage the default topology, which is indeed full mesh.
All right, next question.
An SD-WAN VPN is most like what classic network object?
And the answer here is the VRF.
So we can't get lost in this phrase VPN.
This was a Viptela term that they used.
They wanted to make sure that when you're running a service provider network, that if
you've got multiple customers, like customer one at many different locations they have,
and the customer two has many locations, they wanted to make sure that we understood that
there's a VPN, essentially a virtual private network, among all of the customer one sites
and another VPN among all of the customer two sites.
This is why they used the word or the phrase virtual private network to describe this segmentation.
Well Cisco didn't love that, and so they're starting to change this over to calling it
a VRF in certain places, but we're going to see this term VPN used for a very long time.
Any time we're on Viptela code, it's going to call it a VPN.
Any time we're on iOS XE code, it's going to be configured as a VRF.
And so that is the idea here, a VRF is its own routing table.
It allows us to have its own set of subnets, and I don't have to worry about them being unique.
Because in the end, if I have a subnet like 10.0.0.0 slash 24 that customer one has, which
is a pretty common subnet to deploy, it's just part of that 10 range, well we can also
deploy that same subnet into customer two's network, and that way we don't have to tell
customer one that you're not allowed to use certain subnets or vice versa.
So we would never want to do that, it would not scale to a bunch of customers, that's
why the service provider build is going to rely on VPNs.
Now what about an enterprise build?
Well typically we're only going to use a single VPN.
So we can use one of the service VPN IDs, so something like VPN 10 or VPN 100, and all
of my sites are going to be part of VPN 100.
Meanwhile, if I do need some kind of segmented network, then I can deploy another VPN, maybe
VPN 200, and now my hosts over here can only communicate with each other.
But again, there's true isolation here between the VPNs, because it's like deploying VRFs,
and so if we do end up deploying multiple VPNs, that's great, but in an enterprise network
it's not super common.
It's primarily a thought process of, hey, what do we need to do to give the service
providers the capability of deploying this for all of their customers, and that's what
the VPNs are designed to be.
All right, we're down to our last two questions here.
Question eight, what are the three components of a TLOC?
So this TLOC is a really interesting concept, and it doesn't have a direct mapping to anything
in the classic network world.
We just saw where a VPN, for example, is very similar to a VRF, in fact, they really
parallel one another.
But a TLOC doesn't have that.
A TLOC we like to call an attachment point, just sort of something in the network so that
we know where this attachment point is, how to connect to it if we want to, but really
it's just describing something that says, hey, if you want to attach, there is something
out here to attach to.
And by default, we're going to try to attach to all these attachment points.
That's where we get full mesh connectivity.
And so a TLOC is really this three tuple or this set of three components that describe
what it is and where it is in the SD-WAN.
So what are we looking at here?
Well, we're looking at a system address that identifies which device is advertising it.
We've got a color string.
Now keep in mind, a color is always a string.
There's no such thing as a number.
The string would be something like red if we want to truly use colors, or we could do
something a little more descriptive like MPLS.
These are predefined settings inside the SD-WAN solution.
I am not allowed to make up my own color strings.
I can't make something that's, you know, CBT as a color in my lab environment.
That's not going to be allowed.
I have to use a predefined color string.
Unfortunately, we've got descriptive ones, and then we've got color ones as well when
we want to maybe just leverage that to differentiate among my circuits.
And yes, that's exactly what a color describes.
A color represents a circuit or really ultimately a transport mechanism, hence MPLS.
And lastly, it's encapsulation.
So this is just saying, hey, is this IPsec or is it GRE?
So what's interesting about this is I said it's an attachment point that tells us where
it is or how to connect to it, but it doesn't actually contain an IP address.
So is it telling us where to attach?
Kind of.
That's what the color is for.
Because if I've got an edge device and I see a T-lock out here that says, hey, I'm part
of the red color, well, now I know because I've got a red circuit and I've got a blue
circuit.
Now I know that I can form connections this way.
But interestingly, I will still try to form a connection this way if I'm allowed to do
so.
And this is where our full mesh of data plane tunnels can get even more full meshy if that
was possible, because now I've got not just full mesh within one transport cloud, but
even between transport clouds.
And that starts to create a whole lot of data plane tunnels.
But independent of any of that, just understand that the T-lock, which by the way, stands
for transport locator, is going to give us an attachment point on the network, which
allows me to decide whether I want to form a tunnel to that attachment point.
All right, last question here in our first quiz, our architecture quiz.
Number nine, OMP peerings occur between which devices on the SD-WAN?
So we covered OMP just in a little bit of detail here.
OMP is very similar in nature to BGP.
If you have studied BGP, then a lot of OMP's properties are going to feel familiar.
If you haven't studied BGP, then don't worry about it.
We're going to cover OMP in a lot more detail later on in this course.
Well the answer is between my edges and not my other edges, but the vSmart, which is now
Furthermore, other SD-WAN controllers will form OMP relationships.
So we might have something like this, where I've got multiple edge devices, and OMP is
running where all those lines are drawn, between edges and controllers, and between controllers
and controllers.
So that's what we'd want to keep in mind.
It's an edge-to-controller connection, and it's a controller-to-controller connection.
Notice the most important part that we might assume is the case, and it's missing here,
which is edge-to-edge.
We do not form OMP connections between edge devices.
Now what is OMP carrying?
OMP is telling me about these subnets.
So I advertise subnet A to the controllers, and the controllers push that down to the
other side, and vice versa.
We advertise subnet B, and the controllers push subnet B down.
Now edge, on the left here, we'll call it edge 1 and edge 2, now edge 1 knows that if
I want to send traffic to subnet B, I have been told where subnet B lives.
I'm not sending my traffic to the controllers.
That's part of the control plane.
I'm not worried about that.
I do, however, have an, well, I'm not going to draw it here because these are OMP connections,
but I do have a data plane tunnel formed between edges 1 and 2, and so now edge 1 knows to
send it to edge 2, and vice versa.
So that is the role of OMP.
Importantly, the big takeaway here is that there are no edge-to-edge OMP peerings.
OMP only peers between an edge and a controller, and from controller to controller.
And by the way, no other control components, notice manager and validator are not in this
diagram.