We just looked at a scenario where we integrated our access point in our
wireless lane controllers
into the SDA fabric.
We called it a fabric access point in a fabric wireless lane controller.
Well, believe it or not, there might be some situations where we say, "I don't
want to
integrate with the SDA fabric."
There might be some good reasons for that.
There might be some not-so-great reasons for that.
It just depends on the scenario.
But either way, we are able to deploy the wireless architecture, what we call
over-the-top, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
over-the-top,
or wireless OTT, over the top of the SDA fabric.
At that point, we're treating the SDA fabric as if it's just a layer or two set
of switches.
And I am going to use that set of switches to communicate between my access
points and
my wireless lane controller.
So just like before, I'm going to attach my access points to the fabric edge
nodes.
But now I'm going to attach my wireless lane controller outside of the internal WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But now I'm going to attach my wireless lane controller outside of the internal
border
nodes.
So notice, that's the first big change.
This wireless lane controller is going to exist outside of the fabric.
Because of this now, we are not performing registration with the control plane
node for
any of the wireless operations, nor are we going to form VXLAN tunnels here
between the
access point and the fabric edge node. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
access point and the fabric edge node.
That is only going to happen if we are fully fabric integrated.
So again, when we're talking about wireless over-the-top, or OTT, we are truly
saying
that we're just going to layer wireless on top of this fabric architecture.
So what we're going to do is we're going to maintain our CAPWAP communications
for both
control plane and data plane operations. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
control plane and data plane operations.
So all of my wireless station traffic will now go back into those CAPWAP
tunnels.
So what does this look like?
Well, essentially, we're just going to layer our CAPWAP tunnels over the top of
this architecture.
We're going to form CAPWAP tunnels between every access point and the wireless
lane
controller, just like we do with any other Cisco lightweight wireless
architecture.
Now because this traffic hits the fabric edge node, the fabric edge node is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now because this traffic hits the fabric edge node, the fabric edge node is
going to need
to know how to get to that wireless lane controller.
And so it's going to be important for the internal border node to take those
wireless
lane controller subnets, and we do need to perform registration for the
wireless lane
controller IP addresses into the fabric.
So our control plane node down here will be useful because I can say, "Hey,
where is the
wireless lane controller IP?"
And I get my answer and I forward it to the border node. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And I get my answer and I forward it to the border node.
So keep that part in mind that we do need to register the wireless lane
controller subnets
into the fabric so that they can be reached.
Otherwise, if we don't know where that subnet is, we'll get sent to the
external border
node and it'll get forwarded out to the internet.
And then we will never see that traffic land on the wireless lane controller,
and that's
certainly not what we want here.
So that's pretty much the extent of the conversation.
If we're going to deploy wireless over the top, then we are deploying a
traditional control
plane and data plane, CAPWAP architecture, and we're just using SDA as a means WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
plane and data plane, CAPWAP architecture, and we're just using SDA as a means
to communicate
between the access points and the wireless lane controllers.
So why would we do this?
What are the advantages of doing this type of architecture?
Well, there are two primary reasons for doing this.
One is just for the sake of migration assistance, meaning that if I want to
migrate to SDA,
when I'm changing all of my connections to access switches to layer three and I WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
when I'm changing all of my connections to access switches to layer three and I
'm doing
all of this upgrade, I might not necessarily want to upgrade all of my wireless
lane controllers
and all of my access points and get everything all attached to the fabric all
at the same
time.
So this allows for a phased approach to my SDA migration.
I migrate to SDA first, and then I migrate my wireless.
That's probably the biggest advantage to this. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
That's probably the biggest advantage to this.
The other aspect that we need to consider is that this supports legacy hardware
.
Remember those access points?
They need to support VXLAN in order to be fabric supported.
And Cisco started supporting VXLAN and specifically the hardware that is
required in order to
communicate via VXLAN in access points starting with specific models.
If we have a more legacy architecture, we've had access points around for a
little bit WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
little bit
longer.
Maybe these access points don't actually support VXLAN, at which point we can't
actually perform
SDA fabric integration.
I can't convert that access point to being a fabric AP.
Now certainly they're the biggest downside to all of this, which is simply that
I'm missing
out on my fabric integration benefits.
Some of that is simply managing all of this via catalyst center.
So not only bringing the wired side under catalyst center, but also the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So not only bringing the wired side under catalyst center, but also the
wireless.
And we miss out on this, and that is certainly a downside to using wireless
over the top.
But we also do have to consider the fact that, so first of all, the lack of
fabric integration
and all of those benefits, but also traffic flow.
So now our traffic flow has to leave the fabric, go external to the fabric, to
the wireless
LAN controller, and then back into the fabric for east and west flows. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
LAN controller, and then back into the fabric for east and west flows.
So if I want to communicate between a wireless device here, and maybe there's a
printer on
this access point over here, if I just want to communicate here east west style
, well
now I have to go out of the fabric and back into the fabric.
Now this isn't a huge deal because we would have to do some amount of traffic t
rombone
ing, even if this wasn't an SDA conversation, because I form my tunnels to the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
ing, even if this wasn't an SDA conversation, because I form my tunnels to the
wireless
LAN controller, I'd have to tunnel there, get forwarded back into the network,
and end
up wherever the access point is.
However, in this situation it might be a little bit different, just because now
we have
to traverse a border node, and that might require us deploying the wireless LAN
controllers
a little bit further away than they would have otherwise been installed.
And so we do need to consider the efficiency downside of the lack of efficiency
by deploying
wireless over the top. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But at least we know that it is an option in these situations where we say
there are
enough reasons for us to consider deploying wireless over the top, even if it's
a temporary
solution, and eventually we will migrate our wireless into the SDA fabric.