When a lightweight access point comes online, it forms a tunnel to the wireless
lane controller.
This tunnel is known as the control and provisioning of wireless access points
or capwap.
Capwap is a very important part of a wireless controller architecture,
because what we have is not just a wireless lane controller communicating
through the network to an access point.
Instead, what we have is we have a tunnel that is built, then we send our WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Instead, what we have is we have a tunnel that is built, then we send our
management traffic into this tunnel.
But it's not just the management traffic.
We also send our wireless client or station traffic in here as well.
So it's our management traffic and our data traffic.
And so both of these types of traffic will traverse the tunnel through the
network to get to the wireless lane controller.
Now we might need a quick refresher on what exactly a tunnel architecture is. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now we might need a quick refresher on what exactly a tunnel architecture is.
If we think back to the VXLAN tunnels for our fabric types of architecture, it
's going to be a very similar concept.
The idea is I take an original packet and I encapsulate it further.
Normally I'm encapsulating it at layer 3 and layer 2, but then I throw another
header in front of this.
And this additional tunnel header is going to be what the network is paying
attention to.
The network doesn't see inside of this packet. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The network doesn't see inside of this packet.
So this external tunnel header is saying, "Hey, you know what I'm destined for?
The wireless client might be destined out to the internet."
But this tunnel destination is the wireless lane controller IP address.
And the source is not the client, the source is the access point IP address.
So the underlay, this local area network, whatever this is, a bunch of switches
and routers potentially, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and routers potentially,
it's going to look at this destination and source IP address.
It has no idea what the client source is as no idea what the internet
destination is.
Those are inside of the inner packet and those aren't seen.
Once the wireless lane controller receives this packet, it's going to strip off
the tunnel header,
look at the original packet and it's going to send it on to the network,
which funny enough usually involves sending it right back out one of the links WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
which funny enough usually involves sending it right back out one of the links
that it brought it in on.
But in this case, it doesn't have a tunnel header anymore.
So the local area network can look at the actual destination and forward it on
to wherever it's supposed to be going.
So this creates a lot of interesting conversations around our client traffic.
And this brings us back to what we said is important, which is the wireless
lane controller location. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
lane controller location.
The reason why the location matters so much, and there's actually quite a few
reasons.
But one of the main reasons is because the location of the wireless lane
controller
is where our wireless subnets are going to live,
which might seem logical at first that wireless subnets should live where the
wireless lane controller is,
except before wireless lane controllers existed, these clients were part of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
except before wireless lane controllers existed, these clients were part of
whatever local network
existed out here. They weren't part of another network. So if I have a site,
for example,
let's say I have a switched architecture here, I have an SVI and a gateway
address for maybe VLAN 10,
and this is where my wired clients go. Well, maybe I have another VLAN VLAN 20,
and this connects my wireless clients. But either way, both of these subnets WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and this connects my wireless clients. But either way, both of these subnets
live here on this layer
three switch. Well, what did we just do here? We just said that our wireless
clients aren't going to
live here on this local VLAN 20 subnet, whatever that subnet is. Instead, this
20 subnet will provide an
IP address to the access point, but not to the wireless clients. These wireless
clients are going to
get tunneled through VLAN 20, through the layer three infrastructure, out to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
get tunneled through VLAN 20, through the layer three infrastructure, out to
wherever the wireless
lane controller lives, and this is where the wireless stations are going to pop
out.
Tunneling is kind of funny. I like to think of it in terms of SIFI, because in
SIFI worlds,
like Star Trek, but either way, you see the ability to perform these kind of
warps, where you just
sort of pop out somewhere. And I can star wars they have that too. I digress, I
'm not sure why we're
getting into that conversation. Well, you've got this concept that you sort of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
getting into that conversation. Well, you've got this concept that you sort of
disappear and you reappear
somewhere else. And it's because you go so fast in the SIFI world that it's
like you warp. You just
disappear here, reappear here. In networking, that same concept applies, except
it has nothing to do
with speed. It has everything to do with the fact that the underlying network
can't see the information.
It's invisible to the network. And so we still warp the client traffic, which
started here,
pops up over here. Again, right here, when it shows back up on the network. Up WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
pops up over here. Again, right here, when it shows back up on the network. Up
until then,
it was hidden inside of that tunnel. It's why we call it a tunnel is because
the network can't see
inside the tunnel until we pull that traffic outside of it and send it back to
the network.
So what exactly are we saying here? Why is this matter so much? Well, if we
look at the architecture
of saying I have a wireless LAN controller here, and this wireless LAN
controller is part of a
trunk infrastructure. So I'm trunking to a switch and I'm trunking the VLANs 10 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
trunk infrastructure. So I'm trunking to a switch and I'm trunking the VLANs 10
and 20 and 30,
whatever VLANs I want to trunk over to it. Now I have to have SVIs here for
these different VLANs.
So let's say VLAN 30 is a wireless station or wireless client VLAN. So whatever
subnet's associated
with VLAN 30 here, I'm going to send my traffic through some kind of layer WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
with VLAN 30 here, I'm going to send my traffic through some kind of layer
three infrastructure,
generally speaking, and I'm going to arrive on the wireless LAN controller. The
wireless LAN
controller, again, strips out the original packet and sends it down from a
layer two perspective
into the local network. Well, now this station that's all the way out here at
some other location,
some other site is now going to be using this SVI as its gateway. It's like it WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
some other site is now going to be using this SVI as its gateway. It's like it
's attached here
from a logical perspective. Because if I am trying to get out to the internet,
this station is going to
have a destination MAC address of this gateway very far away from where it
physically showed up on
the network. So this is where the station physically lives. This is where the
station logically lives.
And this can be a really bad thing. For example, what if this is inside of my WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And this can be a really bad thing. For example, what if this is inside of my
data center?
Do I want any of my users to have direct connection into the data center
network? No, I would never want my
wired stations, let's say, to show up inside of the data center. I wouldn't
want a user to be on
the same VLAN as my servers or even on the same layer to switch as my servers. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the same VLAN as my servers or even on the same layer to switch as my servers.
I would want segmentation
there. Except doesn't it make sense for us to deploy the wireless line
controller in a redundant
location such as the data center? So if we decide to deploy the wireless line
controller into the
data center, now the wireless line controller here is connecting to a data
center switch.
And therefore the gateway and the subnet and the VLAN and all of these things
that live on a data
center switch are going to play host to our wireless stations. So this is why WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
center switch are going to play host to our wireless stations. So this is why
we need to pay attention
to the wireless line controller location because the wireless subnets are going
to exist where the
WLC lives. So generally speaking, we don't actually want to deploy it into the
data center. It's more
common for us to want to deploy it into the distribution layer somewhere out on
the network.
But at the same time, this can get tricky because we might have a lot of
distribution layers,
a distribution block. So which one do we pick? Do we pick all of them? The WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
a distribution block. So which one do we pick? Do we pick all of them? The
conversation continues
at that point, but this is a foundational concept that we need to understand
about the flow of
wireless traffic because it will impact where the wireless line controller gets
deployed.
Now the other reason we have to consider this is because we also need access to
the wireless
line controller. If an access point is communicating with the wireless line WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
line controller. If an access point is communicating with the wireless line
controller and it loses
this connection, by default, a lightweight access point will go down because we
just said a lot of
the intelligence, the management, the configuration, all of the things that it
was receiving from the
wireless line controller it no longer has. And so the wireless line controller
is going to
shut down operations and try to find a new wireless line controller using those WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
shut down operations and try to find a new wireless line controller using those
discovery methods
we talked about, which might be possible, but it also might not be possible
depending on
the situation here. We remote location and the whan link went down. If so, and
there's no
local wireless line controller, we're never going to find one, which means that
our wireless
environment is going to stay down. So we need to maintain access to the
wireless line controller,
which will again play a role in determining the location so that it's close to
our wireless
clients in some capacity and also that it's in a redundant location that's WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
clients in some capacity and also that it's in a redundant location that's
unlikely to go down.
Now unfortunately, especially for remote locations, we might have a single whan
link and
survivability can be a concern. Fortunately Cisco does have an option for
remote survivability,
which is FlexConnect. FlexConnect maintains wireless line controller
connectivity,
but it does not use the wireless line controller for its data plane operations, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
but it does not use the wireless line controller for its data plane operations,
meaning it's not
going to send data into the tunnels. The data stays local. And as such, we can
stay online
if the wireless line controller is down. This is a very important part of
wireless designs,
because I do not want to lose my wireless LAN necessarily, just because I lose WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
because I do not want to lose my wireless LAN necessarily, just because I lose
access to the controller.
Now for larger infrastructure rich environments like our campus architectures,
distribution and
access, this isn't a concern, and we would never want to use FlexConnect for a
lot of reasons. But
as much as anything, Cisco just doesn't support that many FlexConnect access
points all at once.
We need to be looking at our remote sites for FlexConnect. And ultimately, what WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We need to be looking at our remote sites for FlexConnect. And ultimately, what
we're going to find
is that if they do lose access to the wireless line controller, they can stay
online, which is very
important for us for those remote sites that maybe don't have the best
connections back to the network.