The Mobility Agent (MA) interacts with the Mobility Controller (MC), which can be a Catalyst 3850 Switch, or a Cisco WLC 5760, or a Cisco Unified Wireless Networking Solution controller. The MA is responsible for:
Handling the mobility events on the switch
Configuring the datapath elements on the switch for mobility, and
Communicating with the mobility controller
As MA, the controller performs the datapath functions by terminating the CAPWAP tunnels that encapsulate 802.11 traffic sourced by wireless stations.
This allows the controller to apply features to wired and wireless traffic in a uniform fashion. As far as controller is concerned, 802.11 is just another access medium.
The MA performs the following functions:
Support the mobility protocol – The MA is responsible for responding in a timely manner, ensuring the controller 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 controller 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 controller. This ensures the multicast flows follow the user as it roams.
Routing – When the controller 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 provided.
802.1X Authenticator – The authenticator function is included in the MA, and handles both wired and wireless stations.
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 tunnels.
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 attachment.
CAPWAP – The controller supports the CAPWAP control and data planes. The controller 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 controller supports CAPWAP fragmentation and reassembly.
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
controller 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.
Configures MTE—The Mobility
Controller is the control point for the
controller 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
controller 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.