A Mobility Controller resides on the switch. It is both,
control path and data path entity and is responsible for:
Handling the mobility events
on the switch
Configuring the datapath
elements on the switch for mobility, and
Communicating with the
As MA, the
performs the datapath functions by terminating the CAPWAP tunnels that
encapsulate 802.11 traffic sourced by wireless stations.
This allows the
to apply features to wired and wireless traffic in a uniform fashion. As far as
is concerned, 802.11 is just another access medium.
The MA performs the
Support the mobility protocol
– The MA is responsible for responding in a timely manner, ensuring the
is capable of achieving its roaming budget.
Point of presence – If the
wireless subnets are not available at the MC, the MA assumes the point of
presence if the wireless client VLAN is not available at the new point of
attachment and tunnel the client traffic accordingly.
ARP Server – When the
network is configured in a layer 2 mode, the MA is responsible for advertising
reachability for the stations connected to it. If tunneling is employed, the
ARP request is transmitted on behalf of the station through the tunnel, which
the point of presence (anchor switch) would bridge onto its uplink interface.
Proxy IGMP – The MA on the
is responsible for subscribing to multicast groups on behalf of a station after
a roaming event has occurred. This information is passed as part of the context
to the new
This ensures the multicast flows follow the user as it roams.
Routing – When the
is connected to a layer 3 access network, the MA is responsible for injecting
routes for the stations that are associated with it for which tunneling is not
802.1X Authenticator – The
authenticator function is included in the MA, and handles both wired and
Secure PMK Sharing – When a
station successfully authenticates to the network, the MA forwards the PMK to
the MC. The MC is responsible for flooding the PMK to all the MAs under its
sub-domain and to the peer MCs in the mobility group.
The MA also performs
the following datapath functions:
Mobility tunnel – If
tunneling is used, the MA encapsulates and decapsulates packets from the
mobility tunnel to the MC, and to other MA in the peer group, if the access
switches are serving as points of presence. The MA supports the tunneling of
client data traffic between the point of attachment and the point of
attachment. The packet format used for other switches is CAPWAP with an 802.3
payload. The MA also supports reassembly and fragmentation for mobility
Encryption – The
mobility control traffic between the mobility nodes is DTLS encrypted. The MA
also encrypts the CAPWAP control and data (optional) at the point of
CAPWAP – The
supports the CAPWAP control and data planes. The
forwarding logic is responsible for terminating the CAPWAP tunnels with 802.11
as well as 802.3 payloads. Since support for large frames (greater than
1500bytes) is not universally available, the
supports CAPWAP fragmentation and reassembly.
tunnel path via an L3 interface on the 4500 or the L3 interface on the uplink
port is not supported. It is not possible to have an L3 wireless management
interface. Even if the tunnel comes up, packet forwarding is not possible as it
is not supported. 4510 drops DHCP packets from wireless clients if SSID is
anchored to a different Cisco WLC.
The main function of
mobility controller is to coordinate the client roaming beyond a switch peer
group. The other features of the mobility controller are:
Mobility Controller maintains a database of all the clients that are connected
within the local mobility sub-domain.
Mobility Protocol—The MC
supports the mobility protocol which ensures the target roaming point responds
in a timely manner and achieves the 150ms roaming budget
Interface to Mobility
Oracle—The Mobility Controller acts as a gateway between the
switch and the Mobility Oracle. When the Mobility
Controller does not find a match in its local database, it suggests a match for
a wireless client entry (in its database) and forwards the request to the
Mobility Oracle, which manages the Mobility Domain.
Oracle function can be enabled on an MC only if it is supported by the
ARP Server—When tunneling is
employed for a station, its point of presence on the network is the Mobility
Tunnel Endpoint (MTE). The Mobility Controller responds to any ARP requests
received for the stations it is responsible for.
Routing—When the Mobility
Controller is connected to a layer three network, the Mobility Controller is
responsible for injecting routes for the stations it supports into the network.
Configures MTE—The Mobility
Controller is the control point for the
switch for all mobility management related
requests. When a change in a station’s point of attachment occurs, the Mobility
Controller is responsible for configuring the forwarding policy on the MTE.
NTP Server—The Mobility
Controller acts as an NTP server to the
switch and supports all the nodes to have their
clocks synchronized with it.
The Cisco 5700
series WLC and other controller platforms that have the Mobility Controller
function enabled by default should not be added to a switch peer group (SPG).
The Mobility Oracle
coordinates the client roams beyond the subdomain on a need basis and consists
of the following features:
Database—The Mobility Oracle maintains a database of all stations that are
serviced within the mobility domain. This database is populated during the
Mobility Oracle's interactions with all the Mobility Controllers, in all of the
mobility sub-domains it supports.
Interface to Mobility
Controller—When the Mobility Oracle receives a request from a Mobility
Controller, it performs a station lookup, and forwards, whenever needed, the
request to the proper Mobility Controller.
NTP Server—The Mobility
Oracle acts as an NTP server to the Mobility Controllers and synchronizes all
within the mobility domain.
The guest access
feature provides guest access to wireless clients. The guest tunnels use the
same format as the mobility tunnels. Using the guest access feature, there is
no need to configure guest VLANs on the access switch. Traffic from the wired
and wireless clients terminates on Guest Controller. Since the guest VLAN is
not present on the access switch, the traffic is tunneled to the MTE over the
existing mobility tunnel, and then via a guest tunnel to the Guest Controller.
The advantage of this
approach is that all guest traffic passes through the MTE before it is tunneled
to the Guest Controller. The Guest Controller only needs to support tunnels
between itself and all the MTEs.
The disadvantage is
that the traffic from the guest client is tunneled twice - once to the MTE and
then again to the Guest Controller.
Clients cannot roam to
Guest Controllers because roaming is not supported on Guest Controllers. This
restriction is applicable only for the IOS-XE guest anchor, and not for AireOS.