So with all the problems identified, let's make a checklist for ourselves.
That's going to hopefully serve as validation that SD-WAN is actually going to
solve all
these problems.
So first of all, we mentioned a few at the end.
We said manageability is a big one, and we can pretty well include visibility
into that
as well.
Us being able to log into our wide area network as a single entity rather than
a bunch of
routers would be really cool, especially if it gives us visibility into what's
going on
there.
So we put a little check box there and see if we can check it off.
We also want to address security.
We mentioned that there's two big problems with wide area networks from a
security perspective.
One is the fact that it's unencrypted.
Meaning I'm just sending my traffic into a shared service provider space.
We know that.
There we go.
If I have an MPLS provider, for example, I am sending the traffic unencrypted
into a shared
space, but I'm also, keep in mind, sharing routes.
This is interesting.
This is something that I have to do with layer three providers and technologies
, which includes
MPLS.
And I don't necessarily love sharing routes.
That's a little bit of personal private information to my organization, and yet
I have to share
that with an entity in hope that nobody within that entity goes rogue and tries
to capture
my traffic or capture my routes.
For that matter, that the service provider doesn't make an honest mistake and
send my
routes and traffic to another customer.
So there's another check box.
We also saw that routing complexity is a big problem with traditional networks
or traditional
wide area networks.
And that especially is going to be true when we look at our redundancy.
So having many routers, many service providers going to be a big problem.
We also want to make sure that we have application considerations.
So an application per circuit, especially as it relates to voice over IP
traffic, for
example, as well as bulk internet traffic.
And then lastly, we have cost considerations.
So we would definitely want to address that in some fashion.
And yeah, SD-WAN might cost more than a traditional network because we're
deploying additional
services.
But can we overall reduce the cost of our wide area network in some form?
Because if so, then that would pay for the upgrade on its own.
All right.
So now we want to look at our software defined wide area network or SD-WAN
solutions.
And keep in mind, a lot of this is going to be a benefit that belongs to SD-WAN
technologies
even outside of the Cisco product world.
So yes, this course and this exam is all based on Cisco, but Cisco is not the
only provider
of SD-WAN.
This is not a Cisco only set of technologies.
Now Cisco would argue, and probably most of us, in the Cisco world would argue
that Cisco's
solution is superior for a lot of different reasons.
If not, then why are we here learning about it and why are we deploying it into
our networks
at all?
But understand again, where some things make sense to call proprietary to Cisco
, other
solutions do exist in other forms with different vendors.
So when I look at SD-WAN solutions, one of the big things we want to provide is
what
we call a single pane of glass management system.
So single pane management.
This takes the form, or ideally would take the form of me as an admin and
potentially
other admins as well, logging into what I said earlier, which is my wide area
network
from an interface perspective, meaning that my wide area network back here with
all of
the complexities of connecting all of the different sites is going to be
entirely managed
through this interface.
This means that I have one place to go to log in and make changes to my wide
area network.
So this is going to allow me to perform configuration changes.
It's also going to allow me to have that visibility to look and see what
exactly is happening
inside of my network.
Now this is important because we might have an admin leave.
Maybe it's our primary admin that decides to go on and take a new job somewhere
, which
is fine.
That happens.
It's part of life.
Now these other admins have a much better chance of being able to log into a
what would
otherwise be a very complex solution and simply gain access to the environment
in that way
and learn quickly if they need to do any learning.
Now access to the single pane of management typically is going to take the form
of a graphical
user interface.
However, in our modern world, we also want to see that we have API access,
which I'll
allow for programmability of our software defined solution, which is pretty
typical with any
kind of software defined architecture.
So we can check off the manageability and visibility box.
We've already greatly simplified our wide area network space just by giving us
that
single pane of management.
Now next, we also are going to build our architecture on IP sec tunnels.
This is going to accomplish quite a bit for us.
In fact, a very important part of this architecture that we're building out is
the fact that it's
built on IP sec tunnels.
Now there's a lot to unpack here and we'll be unpacking this over the course of
time.
But what we do with IP sec tunnels and just tunnels in general is we're going
to form
the concept of an overlay and an underlay.
I always like to say that the overlay is the network I want, but the underlay
is the network
that I have.
Without building tunnels, what we have or what we have is what we have.
I can't build something else on top of it.
However, I can build tunnels on top of my existing physical architecture and
then I
can run routing protocols across those tunnels, which is pretty interesting.
Here's what happens here is we see an underlay that consists of our service
provider routers.
Then the overlay, which is my routers up here and my whole network that exists
maybe
at my headquarters, maybe at my remote sites.
The IP sec tunnel is going to allow me to send traffic through the tunnel
across this
physical infrastructure that I have.
This would be the architecture that I have all of these routers, but what I
really want
is for this device on the left, this edge router to talk directly to this edge
router
on the right.
Pretty fascinating how what happens when we build out these software defined
architectures
using overlay technology, in our case IP sec tunnels.
What does this accomplish?
Well, a number of things.
Again, you said there's a lot to unpack here.
First of all, let's address things from a security perspective.
From a security perspective, we have just encrypted our traffic.
That is huge.
We said the unencrypted traffic is a problem and normally I would just bring a
packet in
to my edge router and send it to my service provider router without encrypting
it.
This is why the service provider we hope is not only honest, but also doesn't
make any
mistakes in terms of sending my traffic to the wrong customer.
Because keep in mind that they do have other customers down here and they are
fully capable
of accidentally sending my traffic to the wrong customer, which might be some
very sensitive
information.
The encrypted traffic is great because now it's using IP sec.
But beyond that, I can also do direct routing.
In a traditional MPLS network, again, if I'm handing my packet off with a
destination
of a network over here, well, in order for this router to send to this network,
it needs
to know where that network is, which is why I have to share routes.
I have to tell this router, "Hey, I've got these private internal routes and if
you see
traffic for it, you need to send it to me."
Well, that isn't required anymore because this router just needs to know how to
get to
the edge router, whichever one of these is technically the service provider
edge in this
scenario.
That's all it has to know.
Which means that I can bring traffic in and again from an overlay perspective,
send it
directly to the other side.
Meanwhile, thanks to the power of encapsulation and tunnels, these underlay
devices don't
need to know anything more than their own network.
So this is huge security.
We've just checked that off from both perspectives.
We're now encrypting our traffic and we're no longer sharing routes with our
service provider.
On top of that, our routing complexity, our routing environment has actually
just gotten
a whole lot better because, again, without having to share my routes, I don't
have to
do any route sharing anymore, and the ability for me to perform direct routing
protocol
adjacencies, this is huge.
Remember the example we gave where we had external redistributed routes versus
internal
routes depending on the technology we chose.
Well, now there is no redistribution required because I can run the same
protocol everywhere.
This massively simplifies my architecture.
Furthermore, we mentioned that we want to control which applications use which
circuit.
Now, we can't go into the details of this until later on as we dig into the
weeds, but
what I can say is that because of this management pane, we have a whole lot
more direct access
as far as sending applications per circuit.
So it's going to use the same concept as policy-based routing except it's
managed.
You and I, as an admin, we don't have to worry about forming very complex
policy-based routing
policies, which is very cool.
So the routing complexity has been greatly simplified, both from something we
can tell
directly here as we have laid out using the same protocols everywhere, not
having to
redistribute, but also a little bit of trust-based teaching at this point that
eventually we
will see how the policy-based routing more or less is handled via the solution.
Now, lastly, the cost.
This is an interesting part of the conversation because, like we mentioned, SD-
WAN hardware
typically is going to cost more, not just because it's running different
hardware, but
also because there's going to be software costs, there's going to be licensing
costs,
it does require more cost.
And yet, what we'll find is that we can actually overall reduce the cost.
Now, this happens in a couple of different ways.
First of all, when we lower complexity, this is going to naturally lead to cost
savings,
even if it's kind of difficult to track that down sometimes.
But if we think about it, I don't need nearly the size of the team dedicated to
working
on things.
Now, we're not saying we can go out there and start firing people, but what we
are saying
is we can redirect the team to other activities.
We can be more efficient, and if we do our calculations correctly, we should be
able
to translate this efficiency into cost savings.
Now the other way is a little bit more tangible.
Remember those service providers that we talked about earlier, how MPLS
typically involves
a lot more reliability.
Well, that's great and all, except it also comes at a much larger cost.
So I might still deploy MPLS to one of these service providers, but now I don't
need to
worry nearly as much about making sure VoiceOver IP is taken care of.
I can deploy the internet as a backup, swing my VoiceOver IP traffic down, and
because
routing is handled for me a little bit more, I can swing that traffic right
back.
So that's very important.
But some organizations have even been able to remove MPLS and do dual internet
circuits.
This makes the wide area network enormously less expensive, and the reason we
can do this
is because we can always favor the more reliable, better performing internet
circuit depending
on the day.
Now we want to be very careful.
I am not saying that this is the right answer.
In fact, very rarely it is the right answer, but it is something that is now
technically
possible.
So we can build SD-WAN connections directly over internet circuits, regardless
of whether
it's in both locations or just in one, either way, that's a very tangible
reduction in monthly
recurring costs.
So these are the ways that we have chosen to address the challenges of wide
area networking
and manageability, security, routing complexity, and yes, even cost overall can
be seen as
being more effective by deploying SD-WAN technology.