All right, it's time to jump into software defined access.
So SDA is all about giving us a method for deploying a campus fabric.
Campus fabric is going to be a new way of deploying our access layer.
So we don't have to choose between layer two and layer three.
So once again, pause the questions before we get into the answers in order to
take a
crack at it yourself.
So question number one here, and there's eight questions this time as well.
What are two goals for deploying campus fabrics?
Well, what we're trying to do once again is evaluate layer two versus layer WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well, what we're trying to do once again is evaluate layer two versus layer
three to the
access layer.
And both of these have pain points.
Layer two is flexible, but it has spanning tree protocol.
Layer three has an immense amount of scale, but we lack the flexibility.
And so we want to try to find the best of both worlds.
And this leads us to the campus fabric.
The idea of the campus fabric is I will build a layer three underlay.
So we're basically embracing layer three to the access. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we're basically embracing layer three to the access.
So our switches all communicate via layer three to one another.
But we're going to build tunnels that allow us to still connect at layer two.
We've got this concept where yeah, I'm layer three segmented, but I've got
hosts over here.
I've got hosts over here and they're all part of the same subnet, whatever that
is pretty
fascinating and really neat.
And what this allows us to do is first of all, hey, eliminate spanning tree. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And what this allows us to do is first of all, hey, eliminate spanning tree.
One of the best things you can ever tell a network engineer is we'd never have
to deal
with spanning tree ever again, because our architecture is fully layer three.
We're not going to eliminate routing.
We're actually going to deploy routing some kind of routing protocol under the
hood there.
And the other goal here is to maintain our layer two networks.
We're not looking to remove them.
So in that sense, we're also embracing the layer two side of things.
I mean, I really can't describe any better.
It's a best of both worlds approach. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It's a best of both worlds approach.
We don't have to worry about the pain points for either one, but we get the
benefits of
each one.
It's pretty fascinating.
Now security is not an inherent part of deploying campus fabrics.
It is an inherent part of SDA.
It's go baked security into SDA from the ground up.
But for this question, we're specifically talking about campus fabrics
independent of
SD access.
Question two, what are the four layers of the Cisco SD access solution? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Question two, what are the four layers of the Cisco SD access solution?
So we talked about the four layers for SD when now we're talking about the four
layers
of SD access.
So the four different layers are going to be very different this time.
It's going to involve the physical layer, the network layer, the controller
layer, and
the management layer.
Now we're not going to dive too deep into any one of these, but as a very quick
overview, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
overview,
remember, a physical layer involves the different devices that are going to be
at play here.
We've got specific devices, catalyst nine case, for example, that we're going
to want
to deploy into the physical layer side of the network.
We're going to also, by the way, keep in mind, we've got wireless devices like
wireless
land controllers in there as well.
The network is where things start to get a little bit interesting.
We've got those three different components we're going to be talking about here
that
allow us to build out our fabrics. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
allow us to build out our fabrics.
And so I won't spoil it because we're going to ask questions about it coming up
.
But if you do recall those three different protocols that are very important as
part
of the network layer.
The controller is going to consist of our two controllers.
First of all, our primary one, what used to be known as DNA center or D-NAC is
now known
as catalyst center.
And then we've also got ICE for identity services engine and identity
management.
And then management layer itself, this is going to be where we have a graphical WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then management layer itself, this is going to be where we have a graphical
user
interface in order for us to manage the environment.
But we've also got REST APIs.
And we can be very programmatic in our approach to deploying software defined
access.
So let's remember these four different layers.
They're very different from SD-WAN.
We need to make sure that we're keeping all of these layers straight in our
minds.
All right, I said I wasn't going to spoil it.
And so now we're going to talk about those protocols.
So match the protocol to the plane of operation within the SD access network
layer. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
layer.
So now we've got layers and we've got planes.
What's going on here?
Well, when we're talking about planes of operation, we're talking about the
data plane, control
plane and policy plane.
This sounds a little closer to those planes of operation, the layers, whatever
we want
to call them in SD-WAN.
Within SD access, we're going to take that network layer and we're going to
split it
up into different planes.
And specifically these planes of operation.
So this is a layer. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So this is a layer.
These are planes.
Once again, we have to keep in mind which one is which, but the planes fit into
the layer.
Now the data plane, this is where we're going to, again, we've got to identify
the protocols
we're using at the data plane, we're forming tunnels.
We saw on SD-WAN, we're using IPsec tunnels, but that won't work with SD access
where we
need a layer two.
So we're going to rely on a different mechanism that gives us layer two and
that is the X-LAN.
We'll be diving into VX-LAN in more detail coming up here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We'll be diving into VX-LAN in more detail coming up here.
And by the way, we'll be diving into something else in more detail coming up,
which is the
control plane protocol known as LISP, which changes the way we share routes.
We don't push routes everywhere just in case anymore.
We just pull them in on an as needed basis and the policy plane is going to use
Cisco
trussec.
Cisco trussec is going to include a security tag, something called a scalable
group tag
used to be called security group tags, either way, they're SGTs. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
used to be called security group tags, either way, they're SGTs.
And that allows switches to know, hey, is this device allowed to talk to
another device?
It really helps us out with onboarding devices and generally speaking access
control.
Question four, identify the SD access device type that's responsible for each
of these
operations.
We need to go through all four of these.
So what device type, first of all, what are we talking about with the device
types?
Well, I'm thinking about things like the control plane nodes, we're thinking
about the border
nodes. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
nodes.
Some of these guys, we've got the just simply the fabric edge nodes.
These are a big one.
And then out of all of these, we might also be concerned about fabric wireless
and controllers.
So we'll look at gateway access to non-SDA networks.
When we're talking about non-SDA, we're talking about the external world.
We've got a fabric here.
We've got all of these switches.
These are all access closets.
At some point, we're going to need to get out to the network core to route out WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
At some point, we're going to need to get out to the network core to route out
to other
networks.
Maybe that's the internet.
Maybe that's the data center, wherever we're going.
Well, that's going to be the responsibility of the fabric border node.
And yes, Cisco does like to include the word fabric and we should probably
include it as
well.
So we have a fabric border node that sits here and we're going to send traffic
to the border
node with either the border node telling us, hey, I've got a route to the data
center,
or simply put, I don't think that we know where this destination is. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
or simply put, I don't think that we know where this destination is.
So I'm going to forward it to the border node, hoping it's destined out towards
the internet
and ultimately wherever the default gateway is pointing wireless AP manager.
This is indeed going to be the fabric wireless LAN controller.
There's a big difference between a standard wireless LAN controller and a
fabric wireless
LAN controller that changes the way that our wireless operates.
Access layer connectivity, that would be these guys right here.
And that would be the fabric edge node. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And that would be the fabric edge node.
Fabric edge node.
So the fabric edge node is what's going to form VX line tunnels among each
other.
They're essentially the access layer switches.
This is also where we have connectivity down to our endpoints like our, hey,
like our access
points, like our laptops and desktops and voice over IP phones.
Lastly, managing the endpoint tables, this is going to be that control plane WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Lastly, managing the endpoint tables, this is going to be that control plane
node.
If I want to send a packet to find a device somewhere out there in the SDA
fabric, I'm
going to have to know where it is.
I don't need to know where everybody in the network lives, but I do need to
know where
this person lives.
So I pull that information down, send it into a VX LAN tunnel and get it to
where it
belongs, whether that's another edge node or possibly to one of the border WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
belongs, whether that's another edge node or possibly to one of the border
nodes.
All right.
Halfway done.
This is question number five.
What are the two controllers that manage the SD access architecture?
Well, I just gave you this answer just a few questions ago.
Hopefully we're paying attention.
The answer here is going to be catalyst center and ice.
So catalyst center is going to be primarily how we manage the solution.
It's going to push configuration down, but Cisco has chosen to rely on another
very solid WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
very solid
controller and solid architecture that they have, which is the identity
services engine,
which is going to run Cisco trussec.
So there's going to be an integration between ice and catalyst center.
They haven't this again, at the least of the, as of the time of this video, we
haven't
actually seen Cisco combine those into one product.
I don't expect them to anytime soon.
I would expect them to leave them separated, but either way, until that changes
, we are
going to have to think about there being two different controllers in the SD WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
going to have to think about there being two different controllers in the SD
access
space.
And that would be catalyst center, which again used to be known as DNA center
or DNAC,
as well as the identity services engine.
Next up in an SD access to apology with five fabric edge nodes, where do the
gateways and
the switch virtual interfaces, another name for that would be the VLAN
interfaces, where
do these get deployed for each VLAN?
So what we're driving at here is the concept of our any cast gateways and do we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So what we're driving at here is the concept of our any cast gateways and do we
understand
how exactly this works?
And as a very quick overview, the idea here is, remember, we draw this
architecture, we
said, Hey, this is great.
I've got a note over here.
They're both part of the same subnet.
And we have layer three segmentation up here.
So yeah, I can tunnel via VX land between the two.
But here's the question, where does the gateway live?
Because of it lives over here, then this device is going to have to loop WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Because of it lives over here, then this device is going to have to loop
through and
possibly just get trombone back to talk to another device that's out the same
switch.
If it's over here, we have to do it vice versa.
And so really what we're trying to drive at here is we want D here, the gate
ways to
be duplicated onto all of the edges.
So yes, if I have five different switches, like the scenario says, I'm going to
deploy
one SVI, let's say for VLAN 100, that VLAN 100 SVI is going to be is going to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
one SVI, let's say for VLAN 100, that VLAN 100 SVI is going to be is going to
exist on
all five edge nodes.
So is this going to create a duplicate IP situation?
Sure.
If I try to SSH into this interface, I'm going to land on whichever one of
those I happen
to be the closest to.
It's called any cast truly is referring to the nearest resource.
And so in this case, we wouldn't want to use that interface to log into a
switch.
We don't know which switch we're logging into at that point. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We don't know which switch we're logging into at that point.
But what we could do is allow each one of these hosts to simply go up to the
nearest
instance of the SVI, which would be directly attached to them via the access
switch.
And then I can get routed to whatever other SVI or layer three interface I'm
trying to
get routed towards.
So any cast gateways are a huge part of Cap and fabrics.
We need to make sure we have a firm understanding of how those work.
All right.
Next question.
What is the purpose of the policy plane and ice in the SD access solution? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
What is the purpose of the policy plane and ice in the SD access solution?
So we've mentioned a couple of times we got this policy plane.
We're using ice.
What's it doing?
What exactly is it helping with?
Well, it's going to help with access control.
And that means a couple of things.
First of all, it does mean onboarding users, but second of all, if I have a
user here that's
trying to communicate to a resource over here, are we going to allow this?
This is very difficult to control in a layer two environment. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
This is very difficult to control in a layer two environment.
And we might even have the same situation on the same switch where we ask the
same question,
hey, should we be allowed to communicate with each other at layer two?
Well, ice and Cisco trussack and those scalable group tags, those are going to
be very difficult
to make it so yes, we can control whether or not this is allowed.
And that's why we keep saying that Cisco integrated security at a foundational
level
CTS, Cisco trussack is a required part of the solution.
Cisco did not want to deploy a campus fabric that didn't have security baked in WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Cisco did not want to deploy a campus fabric that didn't have security baked in
and just
layered on top, which is what seems to happen a lot with security.
Instead, it was one of the first thoughts that they had was this solution needs
to be secure.
And they do that by managing access control via ice and Cisco trussack.
All right, question number eight.
And you know what?
I might have been wrong.
I think I've got one more question.
So hang tight.
We might have nine here.
So what type of tunnels are used by fabric APs when integrated with SD access? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So what type of tunnels are used by fabric APs when integrated with SD access?
Again, there's a big difference between when we are integrating with SD access
and not,
or not, then we're going to do something called wireless over the top and just
sort of pretend
like the access SD access is just sort of an underlay and we're going to build
on top
of that.
But when we're integrated, what's interesting about this is I'm going to have
my access
switch here, which is really a fabric edge node.
And I'm going to attach an access point here.
And normally access points form a cap whap tunnel, some wherever the wireless WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And normally access points form a cap whap tunnel, some wherever the wireless
line controller
is in the environment.
This time I'm going to form a VX LAN tunnel for the sake of data plane traffic
to the
fabric edge node.
Now, I am still going to manage and maintain a cap whap node for control plane
traffic,
but for data plane traffic, meaning wireless station traffic, that is actually
going to
leverage the XLAN.
So if you were thinking, hey, wait a second, we're using both of these. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So if you were thinking, hey, wait a second, we're using both of these.
Well, technically correct.
That web is still used for control plane, but VX LAN is really the answer we
were looking
for here because when we're integrated, we're really looking at using VX LAN
for the sake
of the data plane.
All right.
Now the last question, when deploying that wireless over the top solution that
we just
mentioned for an SD access deployment, where is the wireless LAN controller
deployed?
So at this point, we are building our access points such that we want to be WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So at this point, we are building our access points such that we want to be
able to form
cap whap tunnels to the wireless LAN controller.
And here we are building out of fabric.
So where does it exist?
Well, the answer is A. It lives outside the SDA fabric.
It truly has to live on the other side of a border node in order for us to
deploy wireless
over the top.
So at this point, I really am treating again this fabric, SD access as an under WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So at this point, I really am treating again this fabric, SD access as an under
lay, and
I'm going to form a cap whap tunnel through it all the way to the wireless LAN
controller.
And at that point, my wireless network basically behaves as if SD access wasn't
even there,
which is the whole point of turning a network into an underlay to begin with.
So if we want our wireless to continue to operate as it is, we can use over the
top.
If we do want to integrate it into our SD access solution, it's going to make
things a whole
lot more efficient in a lot of ways because we'll have a whole lot less trom WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
lot more efficient in a lot of ways because we'll have a whole lot less trom
bone of traffic
if we have to come back into the SD access world.