All right, let's wrap up this review by
focusing in on the different technologies we talked about.
So when we build an SD-WAN fabric,
we build it according to the architecture,
we build it using the components,
and then we have basic routing in place.
But we can actually use the fact that we've got
this great software-defined solution to deploy
a lot of different types of features,
call them enhancements,
things that we really couldn't do with traditional WANs.
And so we're going to talk about the different technologies
that we can deploy thanks to SD-WAN.
And it starts with this question here.
Which SD-WAN feature enables simplified edge onboarding?
So the architecture includes the fact
that we've got that orchestration plane,
which means we've got the validator or the V-bond in place.
And so now we can actually plug an edge in
and have it reach out automatically to the validator,
which then starts the process of connecting us
to the other control components,
and then even connecting to other edges.
And the best part about all of this
is I don't have to have anybody with Cisco knowledge
on site to make this all happen.
We just need somebody to essentially plug in
the edge device into the wall to get power.
So first of all, we need power.
Now, this ideally just involves us plugging in a cable,
and so it can come online thanks to DHCP.
If we can't rely on DHCP,
then we'll have to take some additional steps
in order to bring it online.
But if DHCP is available,
we truly have the concept of spinning this device up
without smart hands, as we call them.
Again, somebody with Cisco knowledge on site,
ready to bring it up.
So what's this process called?
It is called zero-touch provisioning.
Yeah, this is a lot of acronyms.
We've got Overlay Management Protocol,
Bidirectional Forwarding Detection,
and Virtual Private Networks.
However, zero-touch provisioning, or ZTP, is that concept.
We call it zero-touch because, again,
I just need to plug it in, more or less.
I don't have to touch it.
I don't have to configure it.
And then the provisioning part is just coming online.
So zero-touch provisioning was developed by Viptela.
that Cisco is going to take advantage
of their plug-and-play network functionality
in order to offer the same service.
Question number two,
what protocol is run by SD-WAN edges
across every data plane tunnel?
So when we think about the edges forming SD-WAN edge,
we don't necessarily always think about
what information is being sent back and forth,
especially when we realize that the routing protocol, OMP,
isn't even run inside of this tunnel.
So yeah, if I have a packet arrive,
it's going to get sent into this tunnel,
and it's going to arrive on the tunnel
and get sent out to whatever host
happens to be at that location.
But what else is running inside of that tunnel?
Well, very importantly, BFD,
or Bidirectional Forwarding Detection,
is running inside of that tunnel.
BFD, as we covered,
is a protocol that runs out of band, in a sense.
It's going to run outside of different protocols,
and yet different protocols can rely on BFD.
Protocols like OSPF, and BGP, and EIGRP.
So those are some routing protocols,
but we can use it in a lot of places,
including the fact that we're using it
inside of our SD-WAN data plane tunnels.
So what's BFD do?
Well, it is a keep-alive mechanism
that ensures that I detect
when a partnership or a peering goes down.
And it's not only going to detect when an outage occurs,
but it's going to do so very, very quickly.
It is very fast, very speedy detection of outages.
So if for any reason this tunnel goes down,
we need to know that we should use a different tunnel,
or otherwise that we just understand
that we're going to have to black hole traffic
for a little while until it comes back up.
But obviously we need to detect that this outage occurred
in order for us to react very quickly to it.
And so this is where BFD helps us out.
So if I have an edge device
and I've got four different tunnels,
I am running BFD in every single one
of those data plane tunnels,
so that I can detect when that individual tunnel goes down,
if it does, and then I can ideally fail over
to a different tunnel, just leveraging the routing table
All right, here's a load balancing question.
So we do have the scenario where an edge
is going to have connections to another edge,
potentially via multiple transports.
In fact, we might even see
cross-transport communication like this.
So we might have a lot of tunnels,
but even if we just have two tunnels going,
which tunnels should I use as I get traffic in?
And that's going to be
where my load balancing policy comes into play.
which load balancing option would be a good fit
for always sending VoIP traffic
across an MPLS link when it's up?
So this is actually a really good real world scenario.
We understand that the internet tends
to have a lot of bandwidth,
but also not a lot of reliability.
Whereas MPLS down here has less bandwidth
and much greater reliability.
So there's a trade-off with going with MPLS.
And also, by the way, MPLS tends to be a lot more expensive.
So we don't necessarily want to use MPLS
for any applications that don't need it.
So this money here,
if I'm running a hundred meg circuit versus a gig circuit,
there's a big price difference there.
So what can I do?
Well, I can load balance my traffic accordingly.
So I can send most of my traffic,
maybe via the internet,
especially low late or high latency.
What am I trying to say?
Latency insensitive traffic can go across the internet,
whereas something like VoIP
can go across the MPLS tunnel
and it's all destined for the same site.
So here's the question that we're asking,
what is a good fit for always sending VoIP traffic
across an MPLS link when it's up,
knowing that I'd want to then send it across the internet
if MPLS goes down?
The answer here is C, active standby pinning.
So when we're looking at active active,
that means that as traffic comes in,
we're more or less just sending traffic out
the different circuits in alternating fashion.
We're just taking turns, sending it out.
Now, if it's active active weighted,
we might do something like this
where I send three traffic flows one way
for every one traffic flow I send across MPLS.
And so that is certainly an option
when we have different bandwidths
on our two different transports.
Active standby is now saying for VoIP
that I'm always going to keep MPLS as my active
as long as it's up.
And then my standby will be the internet.
Pinning means that I'm pinning.
So every time traffic arrives,
it will always go out the pinned transport.
In our case, the MPLS circuit.
Now, what about application aware SLA?
That sounds good.
Remember what this is.
If MPLS is up, then in theory, I want to use it.
That's what an active standby pinning says.
But what if, and by the way, if it goes down,
then like we said, we fail over.
But what if this isn't down?
What if it's up, but it's impaired?
What if MPLS is having a bad day
and the latency is actually higher than the internet?
Well, that's what a service level agreement
is supposed to be.
I'm going to leverage the SD-WAN solution set
and the technology to detect when there are problems.
And so if I have an application aware SLA,
I can say that the fact that the MPLS circuit is impaired
means that even though it's online,
I'm going to fail my voice over IP to the internet.
Now, that's not what the question's asking.
We're just making sure we recall
what all of the different load balancing options are,
and we will explore these load balancing options later on
when we're in the lab.
All right, question number four,
and there are eight questions in this quiz.
When a global network deploys a multi-region fabric,
what aspect of the data plane is changed?
So the answer here is C, edges don't peer to other regions.
So remember, by default, we want to make as many
peer-to-peer connections as possible,
and that's why we result in full mesh.
What the multi-region fabric gives us
is a little bit of architecture
around something that isn't full mesh.
I'm going to create a core of edges,
and so when I have edges over here in this region,
region one over here,
I'm going to form a full mesh of tunnels for all of these.
Actually, I'll draw them over here
so they're out of the way.
And then I'm going to form meshes out here
to these different core devices.
But as I build this region out,
my full mesh over here is going to continue to build out
if that's what I want as a full mesh.
Now, whether I want a full mesh in the region or not
is up to me, but if I build a bunch of edge routers
over here in region two,
then they will all connect to one another,
and then they will connect into the core.
So that's the idea here,
is that we're building a multi-tiered architecture
that allows us to scale out in different regions
and connect those regions via a set of core edges.
Question five, what does middle-mile optimization do?
Middle-mile optimization is actually very interesting.
So the answer here is B.
We're going to leverage these SDCIs for high-speed pipes.
What we're saying here is that I might, from a site,
well, let's just actually draw this out
So if I have a set of users out here
connecting to some kind of transport mechanism,
that maybe this transport mechanism
could actually be stretched out globally
to where my other region is.
And the question is,
what kind of transport mechanism can I get here?
Because chances are I'm not getting
any kind of high-speed fiber connectivity.
I'm probably relying on a service provider network.
And depending on the situation,
maybe that service provider has good circuits,
but in a lot of cases, maybe it doesn't.
So instead, what we can do
is we can ride somebody else's backbone.
And so now we're jumping on and connecting to an SDCI,
which is going to allow me to ride
a very, very high-bandwidth backbone,
low latency, usually fiber,
to get to my other region here.
And so this is what we call the middle mile.
And what we're essentially trying to accomplish here
is we're trying to make it
so that we don't have to build the infrastructure out
globally to get all the way across
to where my other device is, wherever it is in the world.
Instead, I can rely on some of these service providers
that have built some very high-bandwidth links.
And I maybe could use one service provider
to provide me with the transport mechanisms,
but in order to get from one region to another,
I instead am going to rely on this SDCI,
which, by the way,
stands for a software-defined cloud interconnect.
Question six, when using Cisco SD-WAN on-ramp
for multi-cloud,
which architecture can be used for middle mile optimization?
So I just mentioned using middle mile optimization
via an SDCI.
But what I can also do is take advantage
of one of these cloud providers.
And rather than building a cloud infrastructure
where I'm trying to connect
to all of my own virtual machines in the cloud,
instead, I build a software edge
and I form an edge-to-edge connection.
And then I also put another edge
on the other side of the cloud,
which connects down to my network over here.
What this does is it turns the cloud
into sort of this SDCI,
or at least middle mile optimization,
because now I'm writing whatever network connections exist
within the cloud service provider.
And these cloud service providers
tend to have very high bandwidth,
low latency links within their networks.
Now, when we look at the solutions here,
D isn't an option.
Cloud to site's really the same as site to cloud.
And site to cloud is really just half of this,
where we're connecting into the cloud,
or some virtual machines we're trying to connect to.
Site to site is what we're looking for,
because this is a site and this is a site,
and I'm going to connect from one site to another.
Now, cloud to cloud is another option,
because now we could actually connect one cloud
to another cloud like this,
but we're not actually doing that in this scenario.
Instead, we're leveraging site to site architecture
within the on-ramp for multi-cloud solution,
which gives us the ability to leverage that cloud network
All right, question seven,
which cloud service is used by Cisco
for its hosted controller solution?
Well, we had mentioned earlier
that we can use our own data center
to deploy our control components as virtual appliances,
but Cisco does offer a hosted solution.
Now, Cisco doesn't run their own cloud infrastructure.
Instead, they built it out on AWS.
If we're going to leverage Cisco,
we will be connecting to our control components
that exist inside of AWS.
All right, last question here
in the series of three quizzes.
What is the range of VPN IDs
that can be used for edge networks?
So this comes down to the fact
Yes, it cuts off at 530,
at least at the time of this video.
Maybe Cisco has updated that,
but they have some reserved at the end of the range.
And furthermore, they have reserved zero,
which is going to represent the underlay in the network,
and then 512, which is for our management.
Originally, when Viptela first created the solution,
the full range was zero to 512,
and so we could use one to 11, or one to 511.
So one to 511 for VPNs used for edge networks,
those would be the service side VPNs.
But then, because now we can support up to 65, 530,
we start at 513 and go up to the maximum of that range.
So that would be the range of VPNs
that we can use for our edge networks,
keeping in mind, as always,
that VPN zero and VPN 512
are reserved for the respective use cases.
So once again, as I said at the very start,
the purpose of this quiz wasn't to make sure
we can get 100% on it, especially not the first try.
We've covered a lot of information up until now,
and we just want to make sure
that we identify any areas of weakness.
So whether we go back and review that now,
either way, this serves as a really good opportunity
to just make sure we've got all of the facts down
before we jump into what's coming next,
which is, guess what?
Time to jump into the lab
and start to put our hands on the configuration
of Cisco SD-WAN.
I hope this has been informative for you,
and I'd like to thank you for viewing.