As we dive into this conversation about software defined access, it's important
for us to think back to our earlier conversations about network architecture.
The software defined access is supposed to be solving some of the problems that
we've had for a long time with our traditional network architectures.
We just didn't have technology that could do it any better.
And the idea here is that now we do have that technology.
And so let's go ahead and start taking advantage of it.
And so let's think back to those challenges when we talk about our access layer WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so let's think back to those challenges when we talk about our access layer
designs.
We had to, first of all, choose between layer 2 and layer 3.
And both of these architecture types came with challenges.
So when we look at layer 2, layer 2 is how a lot of our organizations deploy
the access layer.
But we have to have a conversation about our redundancy versus the loops in our
environment, recognizing that every loop that we create adds redundancy and
that's good.
But it also creates the possibility of an actual network loop. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But it also creates the possibility of an actual network loop.
And so we're relying on spanning tree in order to offer us loop prevention.
So we think about STP loops, but we also think about the fact that we have to
deploy spanning tree protocol policy.
So we think about defining the spanning tree roots and the priorities and the
costs and deploying things like root guard and BPU guard.
This is a mission critical part of deploying layer 2 to the edge. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And we have to be very intentional about this.
And what we find eventually is that layer 2 just runs into scaling issues.
We can't build massive layer 2 networks.
Not only do we have issues from a subnetting perspective.
For example, we might have to explore going from a slash 24 to a slash 23.
And now we have 512 IP addresses in there.
Or we go to a slash 22 and we have over a thousand.
So that's from an IP perspective.
But we also have an issue at layer 2 from a broadcast perspective. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But we also have an issue at layer 2 from a broadcast perspective.
And so things start to get really dicey as we scale out to very large
organizational networks that are built on layer 2.
And so we might think about layer 3 and saying, hey, let's create a layer 3
access layer design to solve some of these problems, which is wonderful.
From a scaling perspective, I can scale up to as large of networks as I want.
I don't have to worry about spanning tree loops.
All of this is wonderful from a layer 3 perspective. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
All of this is wonderful from a layer 3 perspective.
However, now I need to manage routing protocols.
So I've got to run OSPF or EIGRP in my network all the way down to the access
layer, which can add complexity.
We also have flexibility limitations.
So our flexibility is overall down because there's no subnet sharing among my
access closets.
Because I'm now layer 3 segmented, I don't have the luxury of extending the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Because I'm now layer 3 segmented, I don't have the luxury of extending the
same subnet everywhere.
And so if I have printers that need to be on the same subnet, well, that's just
not going to be an option, which is why we say our flexibility is lower.
Even if we don't need this function, the day we deploy our network, we might
one day need it.
And flexibility is going to be what drives our capabilities when it comes to
making quick network changes.
And we also have to concern ourselves with layer 3 wireless roaming. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And we also have to concern ourselves with layer 3 wireless roaming.
Within an access layer design, we typically have wireless access points, and we
want to be able to roam from access point to access point in the same physical
space.
Well, if now I have layer 3 between my access closets, I'm going to have to
perform layer 3 rooms short of potentially.
We can get around this with wireless lane controllers, and especially talking
about our capwap tunnels.
So this can help us in this scenario, but if we're not using Cisco wireless WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So this can help us in this scenario, but if we're not using Cisco wireless
lane controllers on premise, for example, well, then we're going to have to
deal with layer 3 wireless roaming.
So these are challenges that we have just in the operation and scaling of our
access layer designs.
But this goes beyond just talking about layer 2 and layer 3 challenges.
We also have additional challenges around management of our campus infrast
ructures, because when we think about a very large campus architecture with lots WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
ructures, because when we think about a very large campus architecture with lots
of access layer closets, we have an enormous number of access layer switches.
So our access switch count can be very high, which leads to maybe not always
doing the right things when it comes to managing our switches.
For example, how much do we manage our iOS XC versions?
In a perfect world, we'd be running the exact same version of code on all of
our switches. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So this is important from an operational perspective, making sure we're not
running into major bugs. We want to find a stable version and stick with it.
But it's also important from a security perspective, because we want to find a
version of code that we feel is secure.
And if I have a known security issue on a particular version of code, I need to
make sure it's not running in my environment.
But if I have hundreds of access layer switches, it's very difficult to make
sure that all of them are running the correct code. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
sure that all of them are running the correct code.
We also have the problem of configuration sprawl.
It's easy for me to deploy configurations where it makes sense to do so, and
then kind of forget to go back later and remove some of those configurations,
making sure that our standards are being enforced across all of our campus
buildings,
and also all of our access layer closets that they all have very similar
configurations.
But this conversation also goes in the direction of talking about different WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But this conversation also goes in the direction of talking about different
hardware versions.
Again, in a perfect world, we would ideally deploy the exact same version of
hardware to all of our access closets.
So, as hardware gets retired from a staggered perspective, I might replace some
hardware with a new type of hardware, but then by the time I replace other clos
ets, even newer version of hardware is out, and we have lots of these different WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
ets, even newer version of hardware is out, and we have lots of these different
hardware versions.
This can be difficult not only from a code management perspective like we just
talked about, but also from a configuration management perspective.
We think about configurations such as quality of service, especially quality of
service tends to differ greatly between our different hardware platforms.
And so if I have 90/200s in some parts of my network and 9300s in other parts
and maybe even some more legacy 38/50s, well, how do I make sure that QOS is an WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and maybe even some more legacy 38/50s, well, how do I make sure that QOS is an
end-to-end configuration that works well from end to end when I have so many
different versions of hardware in my network?
And a big part of managing any network is going to be my ability to see what's
happening.
So my visibility into network operations, understanding what's happening, if
there's a problem, how quickly can we identify it, and then we want to be able
to quickly troubleshoot any issues. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to quickly troubleshoot any issues.
So visibility and troubleshooting can be very difficult if we have a sudden
network outage. Today I might have to log into the CLI and I might have to hop
from device to device to device to try to figure out what's going on in this
network.
And some issues like maybe wireless connectivity issues, they could be a
problem with the switch, it could be a problem with the access point, it could
even be a problem with our authentication server.
And so how quickly can identify issues and for that matter, could we have been WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so how quickly can identify issues and for that matter, could we have been
more proactive in identifying that an issue was going to occur?
Maybe we saw that we were running out of bandwidth or maybe we could have seen
we were running out of bandwidth on a particular uplink.
It's been that way for months and all of a sudden today it's just completely
slammed and we've lost network connectivity to a particular access closet. We
really should have seen this coming and could have seen it coming.
But because we're so busy with everything else, it's really hard to gain the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But because we're so busy with everything else, it's really hard to gain the
network visibility required in order to be proactive in preventing issues.
Now lastly and arguably the most important aspect in all of this comes back to
network security. These days network security cannot be tacked on to a network
design.
It must be foundationally deployed. We need it in the architecture and in the
design from the very beginning.
So how do we do that in a local area network type of environment? Well WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So how do we do that in a local area network type of environment? Well
typically we're performing network segmentation for the sake of access control,
which is a decent policy.
Access control is going to define for us how many devices can talk to what
other devices or which devices can communicate with which devices.
And typically we're going to perform access control via access control lists.
What we're doing access control list get applied access control list gets get WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
What we're doing access control list get applied access control list gets get
applied on a usually an SVI of VLAN interface, which means that this is VLAN
based segmentation.
And this works well enough in a lot of cases, but it's not particularly
granular. I think about it. If we've got a switch here with two SVI's and this
SVI connects to this VLAN and this SVI connects to this VLAN.
Well at this point my segmentation exists here at the SVI level, meaning that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well at this point my segmentation exists here at the SVI level, meaning that
if I try to go from this host on one subnet to this host on the other subnet, I
can put policy at the SVI's to prevent this and say no that traffic is not
allowed.
But what if this host here wants to communicate to this host over here? Well
logically it looks like they don't hit the switch, but physically these are
both attached to physical switch ports. They're both going to hit this switch
and yet they're not going to communicate through the SVI because we don't need WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and yet they're not going to communicate through the SVI because we don't need
to route.
And because of that we have to get into the complexity of VLAN access control
lists, which don't particularly migrate well. And so our segmentation is not
only VLAN based, but it's also very static.
We're hoping our devices don't move around and for that matter again the
granularity is a concern.
So we have a lot of challenges and a lot of issues within our traditional WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we have a lot of challenges and a lot of issues within our traditional
network constructs and some of the questions we can ask for example, why are we
relying on spanning tree protocol in this day and age.
We should have something better than layer two loops in spanning tree protocol,
kind of keeping us all together.
We also want to know about the fact that we have to manage our devices
individually and we've got configuration sprawl and trying to manage all this.
Why can't I have one click in an interface that says, check all of my switches,
make sure they're all running the right version of code and if they're not WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
make sure they're all running the right version of code and if they're not
start to push those software upgrades.
We also want to talk about these policies, QOS policies, security policies. I
want these to be end to end and I want them to be extremely granular. If I say
that I want two devices to not be able to talk to each other, well those two
devices should not be able to talk to each other and it shouldn't require me to
completely redefine my VLAN architecture in order to make that happen.
There are so many different questions we can ask and that doesn't even cover
half of what we've just talked about here but we do see that the traditional WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
half of what we've just talked about here but we do see that the traditional
way of building out our networks is not ideal in the modern era.
We need something that can address these challenges and give us a better way of
doing things.
Naturally we are leading to a conversation around software to find access and
Cisco is making the claim that software to find access is going to be able to
solve all of these problems for us.
As we continue through this conversation hopefully we're going to start to see
some of these problems getting addressed.