The SD-WAN Edge device is the device that sits at the edge of the wire and
network.
And this is going to be the routers in our environment.
However, interestingly, Cisco doesn't like to use the word router, probably
because
they feel like router, maybe edge devices one day won't necessarily have to be
routers,
but for today, they are absolutely routers.
And so we'll actually see this in Cisco's portfolio when we look at the
catalyst 8,000
and find that they don't actually use the word router to describe them kind of
interesting.
But for all intents and purposes, that's exactly what they are.
So they're going to sit at the edge of the wide area network, hence their name,
and
they could connect back to a head-end site via some point-to-point link.
But as we said, we're going to use some kind of maybe layer two or layer three
technology
to share routes with other locations.
And as we've now described, edge devices in the Cisco SD-WAN environment, they
're going
to form these IPsec tunnels with one another, creating an overlay network.
And so this is going to offer us all kinds of benefits.
But this is the role of the edge device.
It's to form the IPsec tunnels and facilitate the traffic that comes in and
deciding which
IPsec tunnel to send it out to.
So for example, we might have a backup redundant SD-WAN environment, or well,
technically a
wide area network environment down here.
It's part of our SD-WAN.
And then we form an IPsec tunnel this way as well.
So now if I get voiceover IP traffic, maybe I want to send it out one tunnel.
But if I get bulk internet traffic, maybe I'm uploading something to the
internet or
I'm uploading something to a file server at the other location, then I might
want to
send it out a different connection.
Maybe this represents an internet circuit.
And so now I can securely send traffic across that as if it's a wide area
network connection.
So one of the beautiful things about SD-WAN is creating a unified environment
that is
essentially an overlay network created by the IPsec tunnels.
Now another interesting part about these edge devices.
So first of all, for the most part, we're going to see this deployed as
hardware.
And in the modern Cisco portfolio, they are going to want us to deploy these on
Catalyst
8000s.
Other hardware is supported.
We'll talk about that briefly.
But again, if we're going to go out today and purchase Cisco hardware, it would
be the
Catalyst 8000 line.
And yeah, this is probably going to be true for a while.
But it was always more covering hardware in a recorded session like this by the
time you're
watching this, maybe Cisco has moved on to a new platform.
But the point is that we're leaving behind some of Cisco's more legacy products
.
But the point I want to make here is that, yeah, for the most part, we'll
deploy this
as a physical router in a physical location.
However, we can also still deploy this as a virtual device, which is kind of
interesting.
So makes the Catalyst 8000 as an 8000 V, the V meaning virtual.
This is a cloud router.
And this can participate in the SD-WAN environment as if it's a hardware device
, which is actually
really cool.
So now I might have a virtual, let's just say it is an 8000 V virtual router.
And this is part of my Microsoft Azure cloud deployment.
So I've got a bunch of virtual machines up here, and there's a whole network of
these
that interact with one another.
And I can deploy the 8000 V as another virtual device into this environment,
connected up
through networking and attach it to the internet.
Well, if it's attached to the internet, now I can form IPsec tunnels to it.
And it can form IPsec tunnels to other devices as well.
Now it doesn't necessarily have access to whatever this is.
Maybe it's an MPLS circuit.
Generally speaking, we don't deploy MPLS circuits into the cloud.
It actually is technically possible, but we are usually going to rely on the
internet.
And so in our case here, now traffic destined for these virtual machines up
here, they would
have to take this bottom path, which is no problem.
It would take that path to get out there, but it is part of the SD-WAN
environment, even
though it's up in the cloud.
This is very, very cool.
Now something to keep in mind here as we continue to explore the different
components of SD-WAN
is that we do have those old V-smarts, which we now call SD-WAN controllers out
here.
And so our SD-WAN controllers are V-smarts.
These are going to be pushing control plane information to the V-edge or to the
, well,
the V-edge is the C-edge, the SD-WAN edges.
So it's going to push this out to all of these edge devices.
It's the responsibility of the controller, which we'll be talking about in an
upcoming
video.
But the reason I bring it up now is because, again, the controller is
responsible for the
control plane, but the control plane for the SD-WAN environment, not for the
network itself.
And what that means is that we might actually, not might, but we will actually
still be running
routing protocols throughout this domain.
And so we can expect to be running EIGRP or OSPF or BGP, and we'll be getting
these routes
propagated through the environment.
And that's still the responsibility of the edge device, because this is the
network's
control plane, whereas the SD-WAN's control plane is managed by the controller
or the
V-Smart, which is pushing that information down.
Now just like with the other devices, I already mentioned it, we do have some
legacy
terminology to be aware of, and that would be the difference between a V-edge
and a C-edge.
We covered this briefly earlier, but just as a quick reminder within the
context of this
conversation, the V-edge, this is very, very legacy.
This is running Viptela, and it's either running it as hardware or software,
because it can
run in the cloud as well.
But it's Viptela operating system, meaning that we're not running this on iOS X
E, and
as we might imagine, Cisco retired this very, very quickly after acquiring the
Viptela solution.
So the C-edge is what they deployed, and for a while we could deploy V-edge's
or C-edge's,
this is going to run on iOS XE.
But at this point, mostly because the V-edge has been retired, Cisco wanted to
drop the
term C-edge, and so that is why we now refer to this as simply an SD-WAN edge
device, because
all of the devices we deployed today should be running iOS XE and not Viptela
OS.
That said, we might in the real world see some V-edge's out there.
And the only caveat, Cisco says, aside from running hardware that maybe isn't
supported
anymore, which we're getting close to that time period where they won't be
supported,
but the only thing Cisco says is that we can't run these at the same site.
Something that if I want a redundant set of routers at, let's say, this
location, these
two devices could run, for example, VRRP to make sure that they stay online and
operational
if one of them goes down.
That would be more for the sake of the internal network.
But if I run one of these as a C-edge and one of these as a V-edge, Cisco says
that
won't work because there's fundamental differences in how they even run
standardized protocols
like VRRP.
And so don't deploy these at the same site.
If we do have a V-edge running somewhere, we want to deploy a redundant device.
It's probably best that we just replace that V-edge or alternatively deploy
another V-edge
in some capacity.
But again, we're very quickly moving on to a point where that information is
going to
be quite irrelevant.
The other thing to keep in mind is that when we say that our edge devices are
running iOS
XE, it is important to note that it still requires a special device.
So we have a special mode of operation.
And running in the special mode of operation requires sort of flipping a switch
to go from
standard iOS XE to running an SD-WAN mode of operation within iOS XE.
This can be a little bit confusing at first because it feels like I should just
be able
to get onto an iOS XE device and do some sort of config T and then run an SD-W
AN operation
or something along those lines.
But that's not actually how this happens.
Instead, we're going to need to switch over to this other mode and that
effectively is
going to erase the configuration.
Now that should be okay because if I'm migrating to this architecture from
whatever architecture
I had in place, the old configuration is probably no longer valid anyways.
So this isn't a big concern outside of maybe getting onto a production device
and wanting
to maybe play around with SD-WAN configuration.
Well it's not as simple as enabling it like we said down here in the
configuration.
Instead it's going to be much more intrusive for me to do this.
So definitely do this in a lab environment if I want to play around with it.
But just understand that we are going to need to run this special flavor.
Now the good news is this is just a software migration.
So the same hardware on this side can, you know, if we purchase it and it's
running
again standard WAN configuration, standard iOS XE, I can take the same hardware
and upgrade
it.
And so that is a great migration path if we maybe have deployed fairly new
hardware and
we now want to convert it to SD-WAN.
Now Cisco does give us that path to do so.
But again it's going to be an intrusive upgrade process.
[BLANK_AUDIO]