So the claim at this point is that we have a set of win challenges and that SD-
WAN is
going to solve some of these problems for us.
In order to prove that to ourselves, let's go ahead and list a few of the
biggest win
challenges we have and then talk about how this fancy new solution of ours is
going to
address the challenges.
So first of all, as we talked about, we have routing complexities.
The routing complexities are pretty enormous, really.
I mean, for large organizations that are dealing with thousands of sites, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I mean, for large organizations that are dealing with thousands of sites,
trying to wrap
our arms around all of that, but we've talked about some specifics.
We have to share routes, for example, with the SP when it comes to MPLS.
And that makes it so we have to do routing redistribution and prevent routing
loops and
all of those types of things.
We also talked about application-specific direction, meaning that maybe I want
voiceover
IP to go out MPLS and I want the rest of my traffic to go out the internet and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
IP to go out MPLS and I want the rest of my traffic to go out the internet and
I want
to make sure that different applications maybe are using one or the other.
So just the idea of directing out a particular win link depending on the
traffic type is
something that introduces a massive amount of complexities to traditional
networking.
Lastly, some amount of failover can be challenging.
And again, it's not so much if a circuit goes down because routing protocols
largely take
care of that for us. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
care of that for us.
But what about not just outages, but also as we said, degradation.
So if a particular circuit's having problems on this day for an hour, can we
automatically
divert traffic out the other win link and then allow us to detect when the
first one is
good and swing back over.
So failover and failback.
So lots of routing complexities.
Now on top of all of this, we've got a lot of win circuits.
We have a lot of devices that are out there. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We have a lot of devices that are out there.
So just management of all these devices.
When we're talking about software-defined networking one of the big benefits
typically
is in how we manage the system.
Because we want to make sure that we can manage all these devices, but we don't
have to
want to have to log in and manage all these devices on top of being very
specific in regards
to our configurations of so many different policies and protocols.
We also have a security problem.
We've already mentioned that the internet has no encryption by default. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We've already mentioned that the internet has no encryption by default.
And so we might want to encrypt our traffic that's going across the internet.
And most organizations do that.
But this isn't just about the internet.
It's also about MPLS circuits.
Now we say, well, why would we need to encrypt our traffic across an MPLS
circuit?
It's more private.
It's not the public internet.
Well MPLS is a multi-tenant environment.
Meaning that this is a service provider that has many customers. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Meaning that this is a service provider that has many customers.
And they might accidentally send our traffic to the wrong location.
Maybe directly to a location that's logging all of the information.
And so we just shared secrets by accident through no fault of our own
technically to a different
organization.
That matter if there is a rogue employee working for the service provider that
just wants to
capture our traffic.
I mean, we're opening ourselves up to risk that our traffic could become WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I mean, we're opening ourselves up to risk that our traffic could become
available in some
way.
And so we have to worry about the fact that we have no encryption even over
circuits such
as MPLS.
And then lastly, we mentioned it before, but the expense of our WANs.
So we're especially talking about MPLS circuits.
We're talking about maybe T3s and E3s.
To some extent, T1s and E1s as well.
If we have dark fiber services or for that matter, lit fiber services, a lot of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If we have dark fiber services or for that matter, lit fiber services, a lot of
these WAN
types can be very expensive.
And so we find that we need to have one of them, maybe it's MPLS, as a reliable
option.
And then we try to have our redundant circuit via the internet because it's
less expensive.
But we can't replace both of these with the internet and be very inexpensive
overall because
of all of the downfalls that the internet brings with it.
So that is our list of challenges that we need to address. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So that is our list of challenges that we need to address.
So how does software defined WAN come into play as we start to unpack the
architecture,
which we really still have yet to do, but at a high level, what are we trying
to accomplish
with SD WAN and the solutions that it claims to bring?
Well let's just go through these one by one.
And we're going to start with the routing complexities.
So the routing complexities are going to be resolved because we're adopting a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So the routing complexities are going to be resolved because we're adopting a
software
defined architecture or a software defined network.
And I think back to when we studied VXLAN, and we talked about how we've got
different
architectures and we can leverage VXLAN over different fabrics, which allows us
to pretty
much create the network that I want.
And that's compared to the network that I have.
So what I have is a bunch of circuits. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So what I have is a bunch of circuits.
But what do I want?
I might want a completely different network and I'm going to use tunnels in
order to create
that network.
And tunnels are like the Swiss Army knife of networking.
I can kind of do whatever I want with tunnels because I just direct traffic and
encapsulate
it from one router to another.
I might have this crazy network with a bunch of routers and I have to make sure
that every
router knows where the destination is because when a packet arrives there, they WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
router knows where the destination is because when a packet arrives there, they
have to
forward it towards that destination.
Or I can say, you know what, I'm going to build a tunnel from one router to the
other and
then all of these routers in the middle just have to know how to get to that
router because
I'm just sending it essentially to that router.
I mean, encapsulating it here.
I'm forwarding it to this router and so everybody's forwarding it to a
different destination,
not to the final destination, but to the router that is terminating the tunnel, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
not to the final destination, but to the router that is terminating the tunnel,
which is
kind of interesting.
So now we're hiding those inner headers and we're able to route between the
edge routers.
This is really important because now we don't need to worry about sharing
routes with our
service provider.
The service provider's routers would be the ones here in the middle.
If I'm forwarding traffic through an MPLS circuit, they have to know where the
destination
network is, which is why I usually have to share my routes with them.
But if I'm building tunnels, well, I'm just going from one public IP address or
at least
an IP address that's in their network to an IP address that is also in their WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
an IP address that's in their network to an IP address that is also in their
network.
I should need to share routes with them at all.
They should know how to get from one of their subnets to another one of their
subnets,
which is absolutely amazing.
Furthermore, because of tunneling architectures, I can now build tunnels
through two different
circuit types.
So now I can have my router that is connected into whatever this circuit type WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So now I can have my router that is connected into whatever this circuit type
is.
We're just going to call it number one.
And whatever this circuit type is down here, we're going to call it number two.
And I've got circuits going again to this other router.
Well, first of all, I am building the tunnel.
I'm going to build a tunnel through this service provider.
I'm going to build another tunnel through this service provider.
And now I have a whole lot more control from an application perspective,
because I can
decide based on the application as defined in software, whether I'm going to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
decide based on the application as defined in software, whether I'm going to
send it out
this tunnel or that tunnel.
And that's the end of the story from a route switch architecture perspective
with an SD
WAN.
I don't have to worry about what's happening inside either of these underlays.
I just have to worry about inserting a particular traffic type into a
particular tunnel.
And that's going to help me take care of things from that perspective.
I can also run a lot of metrics and detect when we have degradation.
And if I can control which application through software is going out which of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And if I can control which application through software is going out which of
these tunnels,
what all I have to do is pass that information up to the application controller
, which will
determine which tunnel I'm going to use.
So the routing complexities are going to be much reduced when it comes to SD W
AN.
And at a minimum, we can see very clearly how we no longer have to share routes
with the
service provider.
Now the management is a relatively quick conversation.
We are going to manage all this through a single pane of glass as we like to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We are going to manage all this through a single pane of glass as we like to
say, meaning
that I have a single controller, an SDN controller that I log into and I
perform all of these configurations.
When we say, talking about app control and all these metrics and analyzing all
of that,
that is going to be the responsibility of the SDN control plane and management
plane.
And that's going to be seen here via the single pane of glass. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And that's going to be seen here via the single pane of glass.
I as the network admin, I can log into the single pane of glass rather than
having to log
into lots and lots of different routers.
Next up from a security perspective, we are going to not just use tunnels, but
we are going
to use encrypted tunnels.
Specifically, the tunnels we're talking about here, these are going to use IP
sec, allowing
us to encrypt our tunnels regardless of whether this is the internet circuit WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
us to encrypt our tunnels regardless of whether this is the internet circuit
and the MPLS
circuit down here or vice versa, or maybe they're both MPLS circuits.
It doesn't matter.
I'm going to encrypt it no matter what.
So now, not only am I not sharing my routes with my service provider, I'm not
sending my
data in plain text to them either.
So overall, a big win from a security perspective.
And last but not least, the cost from an IT perspective, we don't always care
about the
cost of a solution.
We just want the best solution from an administrative management perspective. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We just want the best solution from an administrative management perspective.
We like inexpensive solutions.
This is an interesting conversation now because what have we said about the
internet?
The internet is cheap, but it's potentially unreliable.
Now, when I say it's unreliable, it's usually not unreliable minute to minute.
It's usually more like we have some congestion on the internet.
I can't control quality of service as well.
And therefore, there's going to be network drops at various times of day.
So this unreliable nature, as long as it's not rampant, means that I could WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So this unreliable nature, as long as it's not rampant, means that I could
probably run
on the internet circuit 95% of the time.
But what happens now, given that I have this app level of control, and I have
the ability
to detect when we have degradation, can I just deploy two internet circuits?
We'll look at this topology up here.
What happens if we have an internet circuit for topology one or circuit one,
but we also
have another internet circuit, a completely different service provider as my WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
have another internet circuit, a completely different service provider as my
second path.
And so if we say, well, this is 95% reliable, and this one's 95% reliable, as
long as the odds
are pretty low that they're both unreliable at the same time, we, a lot of
cases, can just
adopt two different internet circuits.
It at least allows us to have the conversation, and it truly is a conversation.
This is not a recommendation from Cisco, or for me, for that matter, that we go WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
This is not a recommendation from Cisco, or for me, for that matter, that we go
out and
cancel MPLS circuits.
But we can at least have the conversation that, hey, if we live in a part of
the world,
and where we just got very reliable internet, then maybe we could have two
internet circuits,
and that would greatly drive the cost down.
So that's going to be a potential that comes out of the SD-WAN world, which
allows us to
at least think outside the box of having to have MPLS circuits.
So at this point, again, from a very high level, we can see that SD-WAN at WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So at this point, again, from a very high level, we can see that SD-WAN at
least claims to
have solutions to all of the different challenges that we have in our
traditional WAN architectures.