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 mobility controller
As MA, the switch performs the datapath functions by terminating the CAPWAP tunnels that encapsulate 802.11 traffic sourced by wireless stations.
This allows the switch to apply features to wired and wireless traffic in a uniform fashion. As far as switch 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 switch 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 switch 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 switch. This ensures the multicast flows follow the user as it roams.
Routing – When the switch 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 switch supports the CAPWAP control and data planes. The switch 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 switch supports CAPWAP fragmentation and reassembly.
The main function of Mobility Controller is to handle the events in control plane. The other features of the mobility Controller are:
Station Database - The 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.
Mobility Oracle function can be enabled on an MC only if it is supported by the platform.
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 Catalyst 3850 and supports all the nodes to have their clocks synchronized with it.
The Mobility Oracle is responsible for the complete mobility domain and consists of the following features:
Station 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 the Switch clocks 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. If encryption is desired on the guest traffic, then both the Switch-to-MTE tunnel and the MTE-to-Guest Controller tunnel need to be encrypted.