Ch.07. Roaming

2008, Cisco Systems, Inc. All rights reserved. Printed in USA.

2010 Cisco Systems, Inc. All rights reserved. CUWN v7.03-1

Cisco Unified Wireless Network Administration: Roaming and Mobility

Cisco Unified Wireless Network Administration: Roaming and Mobility


Lesson Overview & Objectives

Overview This lesson provides a detailed discussion of client roaming between APs and controllers in a Cisco Unified Wireless Network environment.

Objectives - Upon completing this lesson, you will be able to establish and configure mobility groups to support roaming. This ability includes being able to meet these objectives:

List three of the Cisco Best Practices for roaming

Describe client roaming within a Layer 2 subnetwork

Describe client roaming within a Layer 3 subnetwork

Describe the configuration of the Mobility Group

Describe IRCM

Identify the two caveats to be aware when using IRCM

Explain how to configure Mobility Anchors



Cisco Wireless Roaming

Roaming refers to movement of clients across Cisco APs, Cisco REAPs, and third-party APs.

A mobility group is a group of WLAN controllers that are set up to allow roaming amongst themselves.

The Cisco WLC can belong to only a single mobility group.

A maximum of 24 Cisco WLCs may belong to a single mobility group.

Roaming supported across mobility groups.

Cisco wireless requires the following for mobility groups:

Consistent mobility group membership

Consistent ACLs configured on all member Controllers

Two types of roaming.

Layer 2 (intra-subnet) roaming

Layer 3 (inter-subnet) roaming


Roaming Best Practices

All controllers in the mobility group should use the same IP address for their virtual interface, and the virtual interface IP address must not be routable.

IP connectivity must exist between the management interfaces of all controllers in the mobility group.

In most situations, all controllers must be configured with the same mobility group name.

You must have gathered the MAC and IP addresses for each controller in a mobility group.

Do not create unnecessarily large mobility groups. Include only controllers that are in the area in which a client can roam.

Try to accommodate the AP distribution across controllers in the mobility group. Avoid salt-and-pepper AP placement.

If using version 5.x or later, take advantage of the multicast mobility feature.




Cisco Wireless Layer 2 Roaming

Single Cisco WLC or multiple Cisco WLCs are in the same subnetwork.

Roaming is transparent to the client.

The session is sustained during connection to the new AP.

The client continues using the same DHCP-assigned or static IP address.

Reauthentication is required if the client sends a DHCP discover with a 0.0.0.0 client IP address or a 169.254.*.* client auto-IP address or when the operator-set session timeout is exceeded.



Client Roaming within a SubnetLayer 2 Roam

WLC-1 WLC-2

WLC-1 Client Database


Mobility Message Exchange

Pre Roaming Data Path

Client Data (MAC, IP, QoS, Security)

VLAN X


Client Roaming within a SubnetLayer 2 Roam (Cont.)

WLC-1 WLC -2




Roaming Data Path

Client Data (MAC, IP, QoS,

Security)

VLAN X

Client roams to different AP



Cisco Wireless Layer 3 Roaming

Multiple Cisco WLCs in different subnetworks.

Transparent to the client.

The session is sustained during connection to the new AP.

Tunnel between the anchor Cisco WLC and foreign Cisco WLC and special handling of the client traffic by both controllers allows the client to continue using the same DHCP or client-assigned IP address while the session remains active.

Reauthentication is required if the client sends a DHCP discover with a 0.0.0.0 client IP address or a 169.254.*.* client auto-IP address or when the operator-set session timeout is exceeded.

Set up via a symmetric tunnel between the anchor WLC and the foreign WLC.


VLAN X

Client Roaming Between SubnetsLayer 3 Roam

WLC-1 WLC-2






VLAN Z


Security)



Client Roaming Between SubnetsLayer 3 Roam (Cont.)

VLAN X

WLC-1 WLC-2






VLAN Z


Security)

Foreign Controller

Anchor Controller


Encrypted Data Tunnel


Mobility Group Configuration



Creating and Managing Mobility Group Members

Two methods for defining the mobility groupadd a member using either the New or Edit All option, in which all members are represented in a text format.


Mobility Group Communications

Whenever a new client joins a controller, the controller sends out a message to all of the controllers in the mobility group.

In release 5.0 and later, this messaging can be setup to use multicast, rather than unicast.

The controller to which the client was previously connected passes on the status of the client.

All mobility message exchanges between controllers are carried out using UDP packets on port 16666 (if using IPSec encryption, port 16667).



Seamless Roaming Between Mobility Groups

Controllers can communicate and clients can roam between mobility groups.

Release 5.1 or later supports up to 24 controllers in a mobility group and up to 72 controllers in the mobility list.

When a client crosses a mobility group boundary, the client is fully authenticated, but the IP address is maintained, and Ethernet IP tunnel is initiated for Layer 3 roaming.

Cisco Centralized Key Management and PKC are supported only for intra-mobility-group roaming.


Client Roaming Between SubnetsLayer 3 Roam Different Mobility Groups

MobilityGroup

2

MobilityGroup1

VLAN X

WLC-1 WLC-2






VLAN Z


Security)

Foreign Controller

Anchor Controller


Encrypted Data Tunnel

Controller in a different mobility group, client reauthentication required



Inter-release Controller Mobility

Available in release 6.0

Supports seamless mobility and Cisco Unified wireless network services across controllers with different software versions.

Allows features such as mobility (Layer2/Layer3 roaming, CCKM Fast Roaming), RRM, AP Fallback, Guest Access, WCS, MFP, and Rogue Detection.

For example, two controllersone running version 4.2.x and another controller running version 6.0.x codewill be able to support roaming and AP Fallback across the two controllers.


Scenarios Where IRCM Would Be Used

During controller upgradewhere certain sections of the network may still be on old code

End of Life support for APscertain sections of the network cannot be upgraded until the older EoL APs are replaced

Guest Access across geographical locationsremote and anchor controllers may be running on different code version



Mobility Features Affected By IRCM

Layer 2 and Layer 3 roaming

Supported between 4.2.207 and 6.0.188 code.

Version number of the mobility packet was incremented in 5.2 and later releases.

Controller will keep track of the mobility version number of other controllers in its mobility list and communicate accordingly.

Feature support across controllers in the mobility list would be of the lowest common denominator.

Guest access termination

Ether-over-IP (EoIP) tunnels for guest access will be supported between 4.2.x and 6.0.x controllers.

Anchor and remote controller can have different software versions.


Caveats For IRCM

Controllers on version 5.1 or earlier code support both symmetric tunneling and asymmetric tunneling. Controllers on version 5.2 or later code support only symmetric tunneling.

Version 5.1 and earlier controllers need to be configured for symmetric tunneling to support layer 3 roaming with controllers running 5.2 or later code.

Controllers on version 5.0 or later code support mobility multicast, but controllers on 4.2.207 (4.2.MR4) do not support mobility multicast.

Version 4.2 controllers cannot be in a mobility group that is using mobility multicast.



Cisco Wireless Mobility Anchor

cc

dd ee

4.4.4.2

3.3.3.3

5.5.5.2

AnchorController

C

bb

aa 4.4.4.4

AClient traffic travels a symmetric path.

ForeignController


Cisco Wireless Mobility AnchorGuest Tunneling Example

AnchorController

C

4.4.4.4

GuestClient

ForeignController

Tunnels are not per user but per SSID (for the inside Controller), which requires a mobility anchor Controller.

4.4.4.2 SSID: Internal SSID: GUEST

Internet



Client Announce

Client Announce

No Handoff

Timeout; Foreign Now Becomes Anchor for Client

No Handoff

No Handoff

Client Announce

AnchorController

ForeignController

Normal Mobility Event

Export Foreign

Export Anchor

Export Anchor Request ACK

Export Anchor Request

AnchorController

ForeignController

Mobility Anchor Event(Guest Tunneling Example)

Cisco Wireless Mobility AnchorMessage Flow


Cisco Wireless Mobility Anchor Considerations

Initial contact Controller may receive a handoff for the client during the client announce.

If the handoff does not specify a configured anchor Controller, the handoff will be discarded.

A foreign session to the anchor is set up ahead of client IP address determination.

The foreign Controller will have no knowledge of Layer 3 client information.

Web Authentication is supported, but authentication will occur on the mobility anchor as opposed to the local Controller.

Not supported on 2xxx Series Controllers or Cisco WLCM.



Configuring Mobility Anchors in WLANs


Controller > Mobility Management > Mobility StatisticsViewing Mobility Statistics



Summary

The Cisco Unified Wireless Network environment allows for roaming between APs.

Layer 2 roaming occurs whenever a client roams between APs on the same Controller.

A Layer 3 roam event requires more processing power and controller coordination than a Layer 2 roam event.

All controllers that will be part of the same mobility group must be configured to have the same default mobility domain name.

Inter-release Controller Mobility (IRCM) is a new feature that allows seamless roaming.

There are two caveats to be aware of when taking advantage of the IRCM feature.

Mobility anchors in WLANs need to be configured.


Ch.07. Roaming

Documents