Wireless Roaming & Location Services Flashcards
Causes of Roaming
1) Maximum retries exceeded
2) Low RSSI
3) Low SNR
4) Proprietary roaming parameters
Active Scan
- occurs when a client changes its 802.11 radio to the channel that is being scanned, broadcasts a probe request, and then waits (usually ~ 10ms) to hear any probe responses (or periodic beacons) from APs on that channel (with a matching SSID)
Directed Probe
the client sends a probe request with a specific destination SSID; only APs with a matching SSID reply with a probe response
Broadcast Probe
- the client sends a broadcast SSID (actually a null SSID) in the probe request; all APs receiving the probe request respond with a probe response for each SSID they support
Passive Scan
- performed by changing the 802.11 radio of the client to the channel that is being scanned and waiting for a periodic beacon from any APs on that channel.
- by default, APs send beacons every ~100ms, so most client prefer an active scan
- during a channel scan, the client is unable to transmit or receive client data traffic
Background Scanning
- clients can scan available channels before they need to roam
- this scan builds knowledge of the RF environment and available APs so clients can roam faster if it becomes necessary
- minimize impact by only scanning when the client is not actively transmitting data, or by periodically scanning only a single alternate channel at a time (bc scanning a single channel incurs minimal data loss)
On-roam scanning
- occurs when a roam is necessary
- everyone has their own algorithms to minimize roam latency
Roam Algorithm Factors
1) Client data type (e.g. “voice call in progress”
2) Background scan information
Scan Algorithm Factors
1) Scan a subset of channels
2) Terminate the scan early
3) Change scan timers
Mobility Group
- a collection of mobility controllers (MCs) across which roaming needs to be supported
- can consist of up to 24 WLCs that share the context and state of client devices and WLC loading info
- wireless client can roam btwn any AP in a mobility group without needing to authenticate
- client info is transferred if it moves to another WLC
Mobility Domain
- when a WLC can recognize WLCs that belong to another mobility group, the WLCs are said to be in the same domain
- up to 3 separate mobility groups can be cross-populated into each other’s mobility lists to form a mobility domain and support up to 72 controllers
- to be in the same domain, the built-in MAC and mgmt IP of each controller has to be entered in the other controller
- to transmit mobility control msgs, Cisco WLCs use UDP 16666 for unencrypted traffic
- user data is transmitting via EoIP (IP protocol 97) or CAPWAP (UDP 5246) tunnels
Mobility Group Required Commonalities
1) Mobility domain name
2) Version of controller code
3) CAPWAP mode
4) ACLs
5) WLANs (SSIDs)
WLC Client Database Information
1) MAC and IP of the client
2) Security context and associations
3) QoS contexts
4) WLAN
5) associated AP
Layer 2 Roaming
- occurs when the client moves from one AP to another and is maintained in the same VLAN
- Intracontroller Roaming - controller updates the client database with the newly associated AP
- Intercontroller Roaming (L2) - the new controller exchanges mobility msgs with the original controller, and the client database entry is copied to the new controller
- if necessary, new security context, and associations are established
- remains transparent to user unless 1) client sends a DHCP discover request, or 2) the session timeout is exceeded
L2 Intercontroller Roaming Prerequisites
- involved WLCs are L2 adjacent, share the VLAN info, and are in the same mobility group. they share SSIDs that are mapped to the same VLAN and subnet
- compatible version of AireOS code in centralized deployments, and the controller is both the MC and MA