- [Instructor] We want to now take a look
at deploying wireless topologies,
and some of the different deployment options
that we have at our disposal.
But before we do that we want to know that there are two
basic modes found with wireless access points
or APs for short and those are autonomous mode
and lightweight mode.
Autonomous Access Points are simply standalone devices
that can operate independently of any sort of centralized
controller, these are very commonly found
in smaller environments or home environments
or home office environments.
Cisco refers to this deployment model
as a controller list model or a distributed model,
because there's no need for a centralized controller
to manage everything,
but instead the management is distributed out
to the individual access points,
in the network.
You might be familiar with this model
because you probably have one in your own residence,
in your home or your apartment,
depending on the complexity and the size of your home
now of course larger homes can certainly use
controller based models,
but most commonly we see these controller-less
autonomous access points in a home environment,
and you can find these at just about any big-box store,
they're very, very common consumer network devices,
in fact most ISPs
will even bundle these devices into their modems
so I'm sure you're really familiar with these.
They offer complete functionality,
and all of the configuration is performed
on the device itself.
It's also very common to see these devices act
as a DHCP server,
so they'll even hand out IP addresses
that would be separate from the wired LAN.
If you have a smaller enterprise environment,
you might be able to use a controller less model just fine
but do be aware that this is less common
at the enterprise level.
Unless that's a small business.
When configuring a controller-less wireless deployments
each individual access point,
would have a management IP address,
configured for remote management,
so in this example,
we have a couple of access points
each with its own management IP address.
We see 10.1.1.1 and 20.1.1.1 in this case.
So in order to configure
or to manage each of these access points,
you would login remotely,
through the appropriate management IP address.
You would jump on a browser most likely,
put in an IP address and then login in order to manage
each individual access point.
So this again,
underscores the reason why this can be very inefficient
at the enterprise environment level.
Imagine you have a multi-level enterprise building,
maybe you have a five-storey building.
Can you imagine,
each time you need to change the Wi-Fi password
or to perform any sort of management,
how cumbersome that would be?
You have to log into each and every access point
to update the configuration,
because those are configured on a one by one basis.
So that means they're obviously not ideal
for large deployments.
Larger enterprise deployments,
would call for Lightweight Access Points or lightweight APs.
Using lightweight APs,
means that each one of those must communicate
with a centralized wireless land controller
or WLC for short.
This is referred to as a centralized
or controller-based wireless deployment model.
These central controllers can be either a physical device
or they can be a virtual cloud-based device,
used to manage the access points.
When we use this model,
all of the management is done at a single point,
and that point is the wireless controller itself.
Any changes or updates we make,
would need to be communicated from the controller,
out to the lightweight access points as needed,
which is much more efficient from a management perspective.
When you have a large wireless environment,
between the controller and the lightweight APs,
we find something called CAPWAP tunnels.
CAPWAP stands for the Control and Wireless Provisioning
of Access Points.
And this is simply a protocol,
that enables the controller to communicate
and to manage the access points.
Most commonly we would place that controller
in a central location within our network.
This provides good roaming capabilities for our users,
and that means that no matter which access point
they might be connected to in our network,
they should still have the same network connectivity.
So for example,
whether a user is connected on the third floor of a building
or on the fifth floor of a building,
the access point to which they're connected,
would be joined to the centralized controller.
And that centralized controller,
will be able to direct their traffic throughout
any point in the network as needed,
no matter where they're connected at.
Now in certain cases, in a really large network,
it may even be necessary
to have multiple wireless controllers,
so rather than simply roaming between the lightweight
access points as we would think about typically,
a client could potentially roam
between wireless LAN controllers themselves.
And that's what we refer to as Inter Controller Roaming,
and this can happen as layer two roaming
or layer three roaming.
With layer two roaming,
even though we have two separate wireless LAN controllers,
those two controllers in this case have interfaces
assigned to the same VLAN and the same subnets.
We can see that both wireless controllers
are in VLAN 100 and they share a common network as well.
Now since this is true,
this is typically a very fast undetectable handover,
between the controllers.
So the client would continue to use
it's existing IP address in most cases.
Now if there was an issue,
the client would try to obtain
a new IP address from the DHCP server first,
it would try to renew it's own IP address.
But in most cases when this is working well,
this will be a very fast handover really undetectable,
and very similar to the handover we would see
if it was a single Wireless LAN controller.
But what if our controllers are assigned
to different VLANs and different subnets?
Sometimes an extremely large network,
may have need of this configuration,
and that would require layer three roaming.
Here we can see, that we have two access points,
this time they're on separate VLANs
and separate subnets,
and our client is at 10.1.1.50 currently on VLAN 100.
Now that's the first controller,
if our client roams over to the second controller,
we can see that that controller is on VLAN 200,
and the subnet is also different, it's a 20.1.1.1/24 subnet.
So in order for this Inter Controller
layer three roam to work,
in additional CAPWAP tunnel is needed.
Remember that CAPWAP tunnels are used
between controllers and access points to enable management.
So in this case,
an additional CAPWAP tunnel would be formed
between the two wireless controllers,
and what this is going to do,
it's going to allow the client to have a connection point
back to the original controller,
with which it is associated,
and therefore the client can keep it's same IP address
and it's same VLAN assignment, this is true,
no matter how many controllers are roamed through.
The original controller,
is going to be referred to as the anchor controller,
while the new controller that it's roamed onto,
is called the foreign controller.
It's a very creative way that Cisco has made
wireless mobility even more seamless in our enterprise.
Another enterprise option that's available,
on certain models of access points, is called flex connect.
This allows you to configure
and control the wireless network,
for a remote branch office from a central location,
and that's done over a LAN link.
In a similar manner
that we examined with layer three roaming,
the FlexConnect capable access points
would establish a CAPWAP tunnel,
over the LAN link, with the central wireless LAN controller
and that's going to allow for management
and configuration over a LAN connection.
When using FlexConnect,
there are a couple of switching modes you want to know about
the first is central switch,
and this is the normal CAPWAP mode of operation.
Any wireless LANs that are at the remote site
will have their traffic tunneled
via CAPWAP back to the centralized controller,
at the main branch office,
and those are done using a dynamic VLAN,
which is the typical operation of CAPWAP.
Now typically this is not the recommended method
because we have the ability to unintentionally saturate
the LAN bandwidth,
and cause poor performance across the entire remote office.
So if a user at the branch office is trying
to communicate with resources within the same office even,
that traffic will still get tunneled
over to the central controller at the main office,
and then forwarded back as standard IP packets
over the LAN link back to the remote office.
So that is not by any means an ideal traffic flow,
and again we have the potential to unintentionally saturate
our LAN connection and cause performance issues.
The second and more preferred mode,
is called local switched mode.
Here the wireless LANs at the remote branch,
would map their user traffic to a VLAN
over an 802.1q trunk,
to a local switch,
that's adjacent to the access point.
All of the control and management traffic,
would still get sent via CAPWAP,
to the central controller,
as would be needed for remote management,
but any other traffic,
any traffic destined for the main office
that would be forwarded as standard IP
packets by the branch router.
So contrasting what we looked at with central switched,
if a branch user needs to access a resource,
within the branch network,
that traffic would not cross over the LAN
to the central location via CAPWAP,
that is instead handled by the local switch,
that is trunked to the access point.
So that's a much more efficient
and much less strenuous situation
for the LAN link.
So that's a look at some of the most common wireless
deployment models,
that you're likely to see in an enterprise environment.