Mobility Groups

Information About Mobility

Mobility, or roaming, is a wireless LAN client’s ability to maintain its association seamlessly from one access point to another securely and with as little latency as possible. This section explains how mobility works when controllers are included in a wireless network.

When a wireless client associates and authenticates to an access point, the access point’s controller places an entry for that client in its client database. This entry includes the client’s MAC and IP addresses, security context and associations, quality of service (QoS) contexts, the WLAN, and the associated access point. The controller uses this information to forward frames and manage traffic to and from the wireless client.

Figure 1. Intracontroller Roaming. This figure shows a wireless client that roams from one access point to another when both access points are joined to the same controller.

When the wireless client moves its association from one access point to another, the controller simply updates the client database with the newly associated access point. If necessary, new security context and associations are established as well.

The process becomes more complicated, however, when a client roams from an access point joined to one controller to an access point joined to a different controller. It also varies based on whether the controllers are operating on the same subnet.

Figure 2. Intercontroller Roaming. This figure shows intercontroller roaming, which occurs when the wireless LAN interfaces of the controllers are on the same IP subnet.

When the client associates to an access point joined to a new controller, the new controller exchanges mobility messages with the original controller, and the client database entry is moved to the new controller. New security context and associations are established if necessary, and the client database entry is updated for the new access point. This process remains transparent to the user.


Note

All clients configured with 802.1X/Wi-Fi Protected Access (WPA) security complete a full authentication in order to comply with the IEEE standard.

Figure 3. Intersubnet Roaming. This figure shows intersubnet roaming, which occurs when the wireless LAN interfaces of the controllers are on different IP subnets.

Inter-subnet roaming is similar to inter-controller roaming in that the controllers exchange mobility messages on the client roam. However, instead of moving the client database entry to the new controller, the original controller marks the client with an “Anchor” entry in its own client database. The database entry is copied to the new controller client database and marked with a “Foreign” entry in the new controller. The roam remains transparent to the wireless client, and the client maintains its original IP address.

In inter-subnet roaming, WLANs on both anchor and foreign controllers need to have the same network access privileges and no source-based routing or source-based firewalls in place. Otherwise, the clients may have network connectivity issues after the handoff.

In a static anchor setup using controllers and ACS, if AAA override is enabled to dynamically assign VLAN and QoS, the foreign controller updates the anchor controller with the right VLAN after a Layer 2 authentication (802.1x). For Layer 3 RADIUS authentication, the RADIUS requests for authentication are sent by the anchor controller.

Mobility is not supported for SSIDs with security type configured for Webauth on MAC filter failure.

If the management VLAN of one Cisco WLC is present as a dynamic VLAN on another Cisco WLC, the mobility feature is not supported.


Note

If a client roams in web authentication state, the client is considered as a new client on another controller instead of considering it as a mobile client.


Note

New Mobility with WebAuth and MAC filter is not supported. For a client, if L2 authentication fails and it falls back to L3 authentication and then tries to roam to a different Cisco WLC, the roaming will fail. The same behavior is applicable to FlexConnect central switching and local mode as well.

Information About Mobility Groups

A mobility group is a set of controllers, identified by the same mobility group name, that defines the realm of seamless roaming for wireless clients. By creating a mobility group, you can enable multiple controllers in a network to dynamically share information and forward data traffic when inter-controller or inter-subnet roaming occurs. Controllers in the same mobility group can share the context and state of client devices as well as their list of access points so that they do not consider each other’s access points as rogue devices. With this information, the network can support inter-controller wireless LAN roaming and controller redundancy.


Note

Controllers do not have to be of the same model to be a member of a mobility group. Mobility groups can be comprised of any combination of controller platforms.

Figure 4. Example of a Single Mobility Group

As shown above, each controller is configured with a list of the other members of the mobility group. Whenever a new client joins a controller, the controller sends out a unicast message (or multicast message if mobility multicast is configured) to all of the controllers in the mobility group. The controller to which the client was previously connected passes on the status of the client.

For example, if a controller supports 6000 access points, a mobility group that consists of 24 such controllers supports up to 144,000 access points (24 * 6000 = 144,000 access points).

Mobility groups enable you to limit roaming between different floors, buildings, or campuses in the same enterprise by assigning different mobility group names to different controllers within the same wireless network.

Figure 5. Two Mobility Groups. This figure shows the results of creating distinct mobility group names for two groups of controllers.

The controllers in the ABC mobility group share access point and client information with each other. The controllers in the ABC mobility group do not share the access point or client information with the XYZ controllers, which are in a different mobility group. Likewise, the controllers in the XYZ mobility group do not share access point or client information with the controllers in the ABC mobility group. This feature ensures mobility group isolation across the network.

Every controller maintains information about its peer controllers in a mobility list. Controllers can communicate across mobility groups and clients may roam between access points in different mobility groups if the controllers are included in each other’s mobility lists. In the following example, controller 1 can communicate with either controller 2 or 3, but controller 2 and controller 3 can communicate only with controller 1 and not with each other. Similarly, clients can roam between controller 1 and controller 2 or between controller 1 and controller 3 but not between controller 2 and controller 3.

Table 1 Example
Controller 1

Mobility group: A

Mobility list:

Controller 1 (group A)

Controller 2 (group A)

Controller 3 (group C) ?

Controller 2

Mobility group: A

Mobility list:

Controller 1 (group A)

Controller 2 (group A)

Controller 3

Mobility group: C

Mobility list:

Controller 1 (group A)

Controller 3 (group C)

In a mobility list, the following combinations of mobility groups and members are allowed:

  • 3 mobility groups with 24 members in each group

  • 12 mobility groups with 6 members in each group

  • 24 mobility groups with 3 members in each group

  • 72 mobility groups with 1 member in each group

The controller supports seamless roaming across multiple mobility groups. During seamless roaming, the client maintains its IP address across all mobility groups; however, Cisco Centralized Key Management (CCKM) and proactive key caching (PKC) are supported only for inter-mobility-group roaming. When a client crosses a mobility group boundary during a roam, the client is fully authenticated, but the IP address is maintained, and mobility tunneling is initiated for Layer 3 roaming.


Note
When a controller is added to a mobility group, some of the APs (which are running in local mode) do not get the complete controllers list updated, those APs are connected to controllers that are in the same mobility group. You can view the controller list in the APs using the command "show capwap client config" AP-NAME command. For example, if the mobility group is for 19 controllers and then you add two more controllers to the mobility group, the AP shows 19 controllers instead of 21 in its list. To address this issue, you can reboot the AP or move it to another controller that is part of the same mobility group to get the controller list updated. This issue is observed in AP1242 connected to different 5508 controllers running code 7.6.120.0.

Note

When client moves to a non anchored SSID from an anchored sSSID on foreign, there is a stale entry on foreign .This happens when multicast mobile announce does not reach from foreign to guest anchor due to whatsoever reason, due to this the service is not impacted and configuration goes unnoticed but silently leaks MSCB on GA .There is no debug or error message shown nor does the GA runs a timer per client to cleanup. A HandoffEnd needs to be sent from foreign to Anchor since there is no timer.

Messaging Among Mobility Groups

The controller provides intersubnet mobility for clients by sending mobility messages to other member controllers.

  • The controller sends a Mobile Announce message to members in the mobility list each time that a new client associates to it. The controller sends the message only to those members that are in the same group as the controller (the local group) and then includes all of the other members while sending retries.

  • You can configure the controller to use multicast to send the Mobile Announce messages. This behavior allows the controller to send only one copy of the message to the network, which destines it to the multicast group that contains all the mobility members. To derive the maximum benefit from multicast messaging, we recommend that it be enabled on all group members.

Using Mobility Groups with NAT Devices

Mobility message payloads carry IP address information about the source controller. This IP address is validated with the source IP address of the IP header. This behavior is a problem when a NAT device is introduced in the network because it changes the source IP address in the IP header. In the guest WLAN feature, any mobility packet, that is being routed through a NAT device is dropped because of the IP address mismatch.

The mobility group lookup uses the MAC address of the source controller. Because the source IP address is changed due to the mapping in the NAT device, the mobility group database is searched before a reply is sent to get the IP address of the requesting controller. This process is done using the MAC address of the requesting controller.

When configuring the mobility group in a network where NAT is enabled, enter the IP address that is sent to the controller from the NAT device rather than the controller’s management interface IP address. Also, make sure that the following ports are open on the firewall if you are using a firewall such as PIX:

  • UDP 16666 for tunnel control traffic

  • IP protocol 97 for user data traffic

  • UDP 161 and 162 for SNMP


Note

Client mobility among controllers works only if auto-anchor mobility (also called guest tunneling) or symmetric mobility tunneling is enabled. Asymmetric tunneling is not supported when mobility controllers are behind the NAT device. See the Configuring Auto-Anchor Mobility and Using Symmetric Mobility Tunneling sections for details on these mobility options.

Mobility Groups

Prerequisites for Configuring Mobility Groups

Before you add controllers to a mobility group, you must verify that the following requirements have been met for all controllers that are to be included in the group:

  • IP connectivity must exist between the management interfaces of all controllers.


    Note

    You can verify IP connectivity by pinging the controllers.


    Note

    Mobility control packets can use any interface address as the source, based on routing table. It is recommended that all controllers in the mobility group should have the management interface in the same subnet. A topology where one controller's management interface and other controller's dynamic interface are on same subnet not recommended for seamless mobility.

  • When controllers in the mobility list use different software versions, Layer 2 or Layer 3 clients have limited roaming support. Layer 2 or Layer 3 client roaming is supported only between controllers that use the same version or with controllers that run versions 7.X.X.


    Note

    If you inadvertently configure a controller with a failover controller that runs a different software release, the access point might take a long time to join the failover controller because the access point starts the discovery process in CAPWAP and then changes to LWAPP discovery.

  • All controllers must be configured with the same virtual interface IP address.


    Note

    If necessary, you can change the virtual interface IP address by editing the virtual interface name on the Controller > Interfaces page.


    Note

    If all the controllers within a mobility group are not using the same virtual interface, inter-controller roaming may appear to work, but the handoff does not complete, and the client loses connectivity for a period of time.

  • You must have gathered the MAC address and IP address of every controller that is to be included in the mobility group. This information is necessary because you will be configuring all controllers with the MAC address and IP address of all the other mobility group members.


    Note

    You can find the MAC and IP addresses of the other controllers to be included in the mobility group on the Controller > Mobility Groups page of each controller’s GUI.

  • When you configure mobility groups using a third-party firewall, for example, Cisco PIX, or Cisco ASA, you must open port 16666, and IP protocol 97.

  • For intercontroller CAPWAP data and control traffic, you must open the ports 5247 and 5246.

This table lists the protocols and port numbers that must be used for management and operational purposes:



Table 2 Protocol/Service and Port Number

Protocol/Service

Port Number

SSH/Telnet

TCP Port 22 or 29

TFTP

UDP Port 69

NTP/SNTP

UDP Port 123

SNMP

UDP Port 161 for gets and sets and UDP port 162 for traps.

HTTPS/HTTP

TCP port 443 for HTTPS and port 80 for HTTP

Syslog

TCP port 514

Radius Auth/Account

UDP port 1812 and 1813


Note

To view information on mobility support across controllers with different software versions, see the http:/​/​www.cisco.com/​c/​en/​us/​td/​docs/​wireless/​compatibility/​matrix/​compatibility-matrix.html. .


Note

You cannot perform port address translation (PAT) on the firewall. You must configure one-to-one network address translation (NAT).

Configuring Mobility Groups (GUI)

    Step 1   Choose Controller > Mobility Management > Mobility Groups to open the Static Mobility Group Members page.

    This page shows the mobility group name in the Default Mobility Group text box and lists the MAC address and IPv4/IPv6 address of each controller that is currently a member of the mobility group. The first entry is the local controller, which cannot be deleted.

    Note    If you want to delete any of the remote controllers from the mobility group, hover your cursor over the blue drop-down arrow for the desired controller and choose Remove.
    Step 2   Perform one of the following to add controllers to a mobility group:

    • If you are adding only one controller or want to individually add multiple controllers, click New and go.

      OR

    • If you are adding multiple controllers and want to add them in bulk, click EditAll and go to.

    Note    The EditAll option enables you to enter the MAC and IPv4/IPv6 addresses of all the current mobility group members and then copy and paste all the entries from one controller to the other controllers in the mobility group.
    Step 3   Click New to open the Mobility Group Member > New page.
    Step 4   Add a controller to the mobility group as follows:

    1. In the Member IP Address text box, enter the management interface IPv4/IPv6 address of the controller to be added.

      Note    If you are configuring the mobility group in a network where network address translation (NAT) is enabled, enter the IPv4/IPv6 address that is sent to the controller from the NAT device rather than the controller’s management interface IPv4/IPv6 address. Otherwise, mobility will fail among controllers in the mobility group.

    2. In the Member MAC Address text box, enter the MAC address of the controller to be added.

    3. In the Group Name text box, enter the name of the mobility group.

      Note    The mobility group name is case sensitive.

    4. In the Hash text box, enter the hash key of the peer mobility controller, which should be a virtual controller in the same domain.

      You must configure the hash only if the peer mobility controller is a virtual controller in the same domain.

      Note    Hash is not supported for IPv6 members.

    5. Click Apply to commit your changes. The new controller is added to the list of mobility group members on the Static Mobility Group Members page.

    6. Click Save Configuration to save your changes.

    7. Repeat Step a through Step e to add all of the controllers in the mobility group.

    8. Repeat this procedure on every controller to be included in the mobility group. All controllers in the mobility group must be configured with the MAC address and IPv4/IPv6 address of all other mobility group members.

    The Mobility Group Members > Edit All page lists the MAC address, IPv4/IPv6 address, and mobility group name (optional) of all the controllers currently in the mobility group. The controllers are listed one per line with the local controller at the top of the list.

    Note    If desired, you can edit or delete any of the controllers in the list.
    Step 5   Add more controllers to the mobility group as follows:

    1. Click inside the edit box to start a new line.

    2. Enter the MAC address, the management interface IPv4/IPv6 address, and the name of the mobility group for the controller to be added.

      Note    You should enter these values on one line and separate each value with one or two spaces.
      Note    The mobility group name is case sensitive.

    3. Repeat Step a and Step b for each additional controller that you want to add to the mobility group.

    4. Highlight and copy the complete list of entries in the edit box.

    5. Click Apply to commit your changes. The new controllers are added to the list of mobility group members on the Static Mobility Group Members page.

    6. Click Save Configuration to save your changes.

    7. Paste the list into the text box on the Mobility Group Members > Edit All page of all the other controllers in the mobility group and click Apply and Save Configuration.

    Step 6   Choose Mobility Management > Multicast Messaging to open the Mobility Multicast Messaging page.

    The names of all the currently configured mobility groups appear in the middle of the page.

    Step 7   On the Mobility Multicast Messaging page, select the Enable Multicast Messaging check box to enable the controller to use multicast mode to send Mobile Announce messages to the mobility members. If you leave it unselected, the controller uses unicast mode to send the Mobile Announce messages. The default value is unselected.
    Step 8   If you enabled multicast messaging in the previous step, enter the multicast group IPv4 address for the local mobility group in the Local Group Multicast IPv4 Address text box. This address is used for multicast mobility messaging.
    Note    In order to use multicast messaging, you must configure the IPv4 address for the local mobility group.
    Note    In release 8.0, IPv6 is not supported for mobility multicast.
    Step 9   Click Apply to commit your changes.
    Step 10   If desired, you can also configure the multicast group IPv4 address for non-local groups within the mobility list. To do so, click the name of a non-local mobility group to open the Mobility Multicast Messaging > Edit page, and enter the multicast group IPv4 address for the non-local mobility group in the Multicast IP Address text box.
    Note    If you do not configure the multicast IPv4 address for non-local groups, the controller uses unicast mode to send mobility messages to those members.
    Step 11   Click Apply to commit your changes.
    Step 12   Click Save Configuration to save your changes.

    Configuring Mobility Groups (CLI)

      Step 1   Check the current mobility settings by entering this command:

      show mobility summary

      Step 2   Create a mobility group by entering this command:

      config mobility group domain domain_name

      Note   

      Enter up to 31 case-sensitive ASCII characters for the group name. Spaces are not allowed in mobility group names.

      Step 3   Add a group member by entering this command:

      config mobility group member add mac_address ip_address

      Note    If you are configuring the mobility group in a network where network address translation (NAT) is enabled, enter the IP address that is sent to the controller from the NAT device rather than the controller’s management interface IP address. Otherwise, mobility will fail among controllers in the mobility group.
      Note   

      Enter the config mobility group member delete mac_address command if you want to delete a group member.

      Step 4   To configure the hash key of a peer mobility controller, which is a virtual controller in the same domain, enter this command:

      config mobility group member hash peer-ip-address key

      Step 5   Enable or disable multicast mobility mode by entering this command:

      config mobility multicast-mode {enable | disable} local_group_multicast_address

      where local_group_multicast_address is the multicast group IPv4 address for the local mobility group. This address is used for multicast mobility messaging.

      Note    In order to use multicast messaging, you must configure the IPv4 address for the local mobility group.
      Note    In release 8.0, IPv6 is not supported for mobility multicast.

      If you enable multicast mobility mode, the controller uses multicast mode to send Mobile Announce messages to the local group. If you disable multicast mobility mode, the controller uses unicast mode to send the Mobile Announce messages to the local group. The default value is disabled.

      Step 6   (Optional) You can also configure the multicast group IPv4 address for non-local groups within the mobility list. To do so, enter this command:

      config mobility group multicast-address group_name IP_address

      If you do not configure the multicast IPv4 address for non-local groups, the controller uses unicast mode to send mobility messages to those members.

      Step 7   Verify the mobility configuration by entering this command:

      show mobility summary

      Step 8   To see the hash key of mobility group members in the same domain, enter this command:

      show mobility group member hash

      Step 9   Save your changes by entering this command:

      save config

      Step 10   Repeat this procedure on every controller to be included in the mobility group. All controllers in the mobility group must be configured with the MAC address and IP address of all other mobility group members.
      Step 11   Enable or disable debugging of multicast usage for mobility messages by entering this command:

      debug mobility multicast {enable | disable}

      Viewing Mobility Group Statistics

      You can view three types of mobility group statistics from the controller GUI:

      • Global statistics—Affect all mobility transactions

      • Mobility initiator statistics—Generated by the controller initiating a mobility event

      • Mobility responder statistics—Generated by the controller responding to a mobility event

      You can view mobility group statistics using the controller GUI or CLI.

      Viewing Mobility Group Statistics (GUI)

        Step 1   Choose Monitor > Statistics > Mobility Statistics to open the Mobility Statistics page.

        This page contains the following fields

        • Group Mobility Statistics

          • Rx Errors—Generic protocol packet receive errors, such as packet too short or format incorrect.

          • Tx Errors—Generic protocol packet transmit errors, such as packet transmission fail.

          • Responses Retransmitted—Mobility protocol that uses UDP and resends requests several times if it does not receive a response. Because of network or processing delays, the responder may receive one or more retry requests after it initially responds to a request. This text box shows a count of the response resends.

          • Handoff Requests Received—Total number of handoff requests received, ignored, or responded to.

          • Handoff End Requests Received—Total number of handoff end requests received. These requests are sent by the anchor or foreign controller to notify the other about the close of a client session.

          • State Transitions Disallowed—Policy enforcement module (PEM) that has denied a client state transition, usually resulting in the handoff being aborted.

          • Resource Unavailable—Necessary resource, such as a buffer, was unavailable, resulting in the handoff being aborted.

        • Mobility Initiator Statistics

          • Handoff Requests Sent—Number of clients that have associated to the controller and have been announced to the mobility group.

          • Handoff Replies Received—Number of handoff replies that have been received in response to the requests sent.

          • Handoff as Local Received—Number of handoffs in which the entire client session has been transferred.

          • Handoff as Foreign Received—Number of handoffs in which the client session was anchored elsewhere.

          • Handoff Denys Received—Number of handoffs that were denied.

          • Anchor Request Sent—Number of anchor requests that were sent for a three-party (foreign-to-foreign) handoff. The handoff was received from another foreign controller, and the new controller is requesting the anchor to move the client.

          • Anchor Deny Received—Number of anchor requests that were denied by the current anchor.

          • Anchor Grant Received—Number of anchor requests that were approved by the current anchor.

          • Anchor Transfer Received—Number of anchor requests that closed the session on the current anchor and transferred the anchor back to the requestor.

        • Mobility Responder Statistics

          • Handoff Requests Ignored—Number of handoff requests or client announcements that were ignored because the controller had no knowledge of that client.

          • Ping Pong Handoff Requests Dropped—Number of handoff requests that were denied because the handoff period was too short (3 seconds).

          • Handoff Requests Dropped—Number of handoff requests that were dropped due to either an incomplete knowledge of the client or a problem with the packet.

          • Handoff Requests Denied—Number of handoff requests that were denied.

          • Client Handoff as Local—Number of handoff responses sent while the client is in the local role.

          • Client Handoff as Foreign—Number of handoff responses sent while the client is in the foreign role.

          • Anchor Requests Received—Number of anchor requests received.

          • Anchor Requests Denied—Number of anchor requests denied.

          • Anchor Requests Granted—Number of anchor requests granted.

          • Anchor Transferred—Number of anchors transferred because the client has moved from a foreign controller to a controller on the same subnet as the current anchor.

        Step 2   If you want to clear the current mobility statistics, click Clear Stats.

        Viewing Mobility Group Statistics (CLI)

        • See mobility group statistics by entering the show mobility statistics command.

        • To clear the current mobility statistics, enter the clear stats mobility command.

        Configuring Auto-Anchor Mobility

        Information About Auto-Anchor Mobility

        You can use auto-anchor mobility (also called guest tunneling) to improve load balancing and security for roaming clients on your wireless LANs. Under normal roaming conditions, client devices join a wireless LAN and are anchored to the first controller that they contact. If a client roams to a different subnet, the controller to which the client roamed sets up a foreign session for the client with the anchor controller. However, when you use the auto-anchor mobility feature, you can specify a controller or set of controllers as the anchor points for clients on a wireless LAN.

        In auto-anchor mobility mode, a subset of a mobility group is specified as the anchor controllers for a WLAN. You can use this feature to restrict a WLAN to a single subnet, regardless of a client’s entry point into the network. Clients can then access a guest WLAN throughout an enterprise but still be restricted to a specific subnet. Auto-anchor mobility can also provide geographic load balancing because the WLANs can represent a particular section of a building (such as a lobby, a restaurant, and so on), effectively creating a set of home controllers for a WLAN. Instead of being anchored to the first controller that they happen to contact, mobile clients can be anchored to controllers that control access points in a particular vicinity.

        When a client first associates to a controller of a mobility group that has been preconfigured as a mobility anchor for a WLAN, the client associates to the controller locally, and a local session is created for the client. Clients can be anchored only to preconfigured anchor controllers of the WLAN. For a given WLAN, you should configure the same set of anchor controllers on all controllers in the mobility group.

        When a client first associates to a controller of a mobility group that has not been configured as a mobility anchor for a WLAN, the client associates to the controller locally, a local session is created for the client, and the client is announced to the other controllers in the mobility list. If the announcement is not answered, the controller contacts one of the anchor controllers configured for the WLAN and creates a foreign session for the client on the local switch. Packets from the client are encapsulated through a mobility tunnel using EtherIP and sent to the anchor controller, where they are decapsulated and delivered to the wired network. Packets to the client are received by the anchor controller and forwarded to the foreign controller through a mobility tunnel using EtherIP. The foreign controller decapsulates the packets and forwards them to the client.

        If multiple controllers are added as mobility anchors for a particular WLAN on a foreign controller, the foreign controller internally sorts the controller by their IP address. The controller with the lowest IP address is the first anchor. For example, a typical ordered list would be 172.16.7.25, 172.16.7.28, 192.168.5.15. If the first client associates to the foreign controller's anchored WLAN, the client database entry is sent to the first anchor controller in the list, the second client is sent to the second controller in the list, and so on, until the end of the anchor list is reached. The process is repeated starting with the first anchor controller. If any of the anchor controller is detected to be down, all the clients anchored to the controller are deauthenticated, and the clients then go through the authentication/anchoring process again in a round-robin manner with the remaining controller in the anchor list. This functionality is also extended to regular mobility clients through mobility failover. This feature enables mobility group members to detect failed members and reroute clients.

        Restrictions on Auto-Anchor Mobility

        • Mobility list members can send ping requests to one another to check the data and control paths among them to find failed members and reroute clients. You can configure the number and interval of ping requests that are sent to each anchor controller. This functionality provides guest N+1 redundancy for guest tunneling and mobility failover for regular mobility.

        • You must add controllers to the mobility group member list before you can designate them as mobility anchors for a WLAN.

        • You can configure multiple controllers as mobility anchors for a WLAN.

        • Auto-anchor mobility supports web authentication but does not support other Layer 3 security types.

        • You must configure the WLANs on both the foreign controller and the anchor controller with mobility anchors. On the anchor controller, configure the anchor controller itself as a mobility anchor. On the foreign controller, configure the anchor as a mobility anchor.

        • It is not possible for clients, WGB, and wired clients to directly connect to a DMZ guest anchor and move to a foreign controller.

        • Auto-anchor mobility is not supported for use with DHCP option 82.

        • When using the guest N+1 redundancy and mobility failover features with a firewall, make sure that the following ports are open:

          • UDP 16666 for tunnel control traffic

          • IP Protocol 97 for user data traffic

          • UDP 161 and 162 for SNMP

        • In case of roaming between anchor controller and foreign mobility, the client addresses learned at the anchor controller is shown at the foreign controller. You must check the foreign controller to view the RA throttle statistics.

        • For Layer 3 RADIUS authentication, the RADIUS requests for authentication are sent by the anchor controller.

        • The mobility anchor is not supported on virtual wireless LAN controllers.

        • In a guest anchor Cisco WLC deployment, ensure that the foreign Cisco WLC does not have a WLAN mapped to a VLAN that is associated with the guest anchor Cisco WLC.

        Configuring Auto-Anchor Mobility (GUI)

          Step 1   Configure the controller to detect failed anchor controllers within a mobility group as follows:
          1. Choose Controller > Mobility Management > Mobility Anchor Config to open the Mobility Anchor Config page.
          2. In the Keep Alive Count text box, enter the number of times a ping request is sent to an anchor controller before the anchor is considered to be unreachable. The valid range is 3 to 20, and the default value is 3.
          3. In the Keep Alive Interval text box, enter the amount of time (in seconds) between each ping request that is sent to an anchor controller. The valid range is 1 to 30 seconds, and the default value is 10 seconds.
          4. In the DSCP Value text box, enter the DSCP value. The default is 0.
            Note    While configuring the Mobility DSCP value, the mobility control socket (i.e control messages exchanged between mobility peers only and not the data) is also updated. The configured value must reflect in the IPV4 header TOS field. This is a global configuration on the controller that is used to communicate among configured mobility peers only.
          5. Click Apply to commit your changes.
          Step 2   Choose WLANs to open the WLANs page.
          Step 3   Click the blue drop-down arrow for the desired WLAN or wired guest LAN and choose Mobility Anchors. The Mobility Anchors page appears.

          This page lists the controllers that have already been configured as mobility anchors and shows the current state of their data and control paths. Controllers within a mobility group communicate among themselves over a well-known UDP port and exchange data traffic through an Ethernet-over-IP (EoIP) tunnel. They send mpings, which test mobility control packet reachability over the management interface over mobility UDP port 16666 and they send epings, which test the mobility data traffic over the management interface over EoIP port 97. The Control Path text box shows whether mpings have passed (up) or failed (down), and the Data Path text box shows whether epings have passed (up) or failed (down). If the Data or Control Path text box shows “down,” the mobility anchor cannot be reached and is considered failed.

          Step 4   Select the IPv4/IPv6 address of the controller to be designated a mobility anchor in the Switch IP Address (Anchor) drop-down list.
          Step 5   Click Mobility Anchor Create. The selected controller becomes an anchor for this WLAN or wired guest LAN.
          Note    To delete a mobility anchor for a WLAN or wired guest LAN, hover your cursor over the blue drop-down arrow for the anchor and choose Remove.
          Step 6   Click Save Configuration.
          Step 7   Repeat Step 4 and Step 6 to set any other controllers as mobility anchors for this WLAN or wired guest LAN.
          Step 8   Configure the same set of mobility anchors on every controller in the mobility group.

          Configuring Auto-Anchor Mobility (CLI)

          • The controller is programmed to always detect failed mobility list members. To change the parameters for the ping exchange between mobility members, enter these commands:

            • config mobility group keepalive count count—Specifies the number of times a ping request is sent to a mobility list member before the member is considered to be unreachable. The valid range is 3 to 20, and the default value is 3.

            • config mobility group keepalive interval seconds—Specifies the amount of time (in seconds) between each ping request sent to a mobility list member. The valid range is 1 to 30 seconds, and the default value is 10 seconds.

          • Disable the WLAN or wired guest LAN for which you are configuring mobility anchors by entering this command:

            config {wlan | guest-lan} disable {wlan_id | guest_lan_id}

          • Create a new mobility anchor for the WLAN or wired guest LAN by entering one of these commands:

            • config mobility group anchor add {wlan | guest-lan} {wlan_id | guest_lan_id} anchor_controller_ip_address

            • config {wlan | guest-lan} mobility anchor add {wlan_id | guest_lan_id} anchor_controller_ip_address


              Note

              The wlan_id or guest_lan_id must exist and be disabled, and the anchor_controller_ip_address must be a member of the default mobility group.


              Note

              Auto-anchor mobility is enabled for the WLAN or wired guest LAN when you configure the first mobility anchor.

          • Delete a mobility anchor for the WLAN or wired guest LAN by entering one of these commands:

            • config mobility group anchor delete {wlan | guest-lan} {wlan_id | guest_lan_id} anchor_controller_ip_address

            • config {wlan | guest-lan} mobility anchor delete {wlan_id | guest_lan_id} anchor_controller_ip_address


              Note

              The wlan_id or guest_lan_id must exist and be disabled.


              Note

              Deleting the last anchor disables the auto-anchor mobility feature and resumes normal mobility for new associations.

          • Save your settings by entering this command:

            save config

          • See a list and status of controllers configured as mobility anchors for a specific WLAN or wired guest LAN by entering this command:

            show mobility anchor {wlan | guest-lan} {wlan_id | guest_lan_id}


            Note

            The wlan_id and guest_lan_id parameters are optional and constrain the list to the anchors in a particular WLAN or guest LAN. To see all of the mobility anchors on your system, enter the show mobility anchor command.

            The Status text box shows one of these values:

            UP—The controller is reachable and able to pass data.

            CNTRL_PATH_DOWN—The mpings failed. The controller cannot be reached through the control path and is considered failed.

            DATA_PATH_DOWN—The epings failed. The controller cannot be reached and is considered failed.

            CNTRL_DATA_PATH_DOWN—Both the mpings and epings failed. The controller cannot be reached and is considered failed.

          • See the status of all mobility group members by entering this command:

            show mobility summary

          • Troubleshoot mobility issues by entering these commands:

            • debug mobility handoff {enable | disable}—Debugs mobility handoff issues.

            • debug mobility keep-alive {enable | disable} all—Dumps the keepalive packets for all mobility anchors.

            • debug mobility keep-alive {enable | disable} IP_address—Dumps the keepalive packets for a specific mobility anchor.

          Validating WLAN Mobility Security Values

          Information About WLAN Mobility Security Values

          For any anchoring or mobility event, the WLAN security policy values on each controller must match. These values can be validated in the controller debugs. This table lists the WLAN mobility security values and their corresponding security policy.

          Table 3 WLAN Mobility Security Values

          Security Hexadecimal Value

          Security Policy

          0x00000000

          Security_None

          0x00000001

          Security_WEP

          0x00000002

          Security_802_1X

          0x00000004

          Security_IPSec*

          0x00000008

          Security_IPSec_Passthrough*

          0x00000010

          Security_Web

          0x00000020

          Security_PPTP*

          0x00000040

          Security_DHCP_Required

          0x00000080

          Security_WPA_NotUsed

          0x00000100

          Security_Cranite_Passthrough*

          0x00000200

          Security_Fortress_Passthrough*

          0x00000400

          Security_L2TP_IPSec*

          0x00000800

          Security_802_11i_NotUsed

          Note   

          Controllers running software release 6.0 or later do not support this security policy.

          0x00001000

          Security_Web_Passthrough

          Using Symmetric Mobility Tunneling

          Information About Symmetric Mobility Tunneling

          When symmetric mobility tunneling is enabled, all client traffic is sent to the anchor controller and can then successfully pass the RPF check.

          Figure 6. Symmetric Mobility Tunneling or Bi-Directional Tunneling

          Symmetric mobility tunneling is also useful in the following situations:

          • If a firewall installation in the client packet path drops packets because the source IP address does not match the subnet on which the packets are received.

          • If the access-point group VLAN on the anchor controller is different than the WLAN interface VLAN on the foreign controller. In this case, client traffic could be sent on an incorrect VLAN during mobility events.

          Guidelines and Limitations

          • Symmetric mobility tunneling is enabled by default.

          Verifying Symmetric Mobility Tunneling

          Verifying Symmetric Mobility Tunneling (GUI)

            Step 1   Choose Controller > Mobility Management > Mobility Anchor Config to open the Mobility Anchor Config page.
            Step 2   The Symmetric Mobility Tunneling Mode text box shows Enabled.

            Verifying if Symmetric Mobility Tunneling is Enabled (CLI)

            Verify that symmetric mobility tunneling is enabled by entering this command:

            show mobility summary

            Running Mobility Ping Tests

            Information About Mobility Ping Tests

            Controllers in a mobility list communicate with each other by controlling information over a well-known UDP port and exchanging data traffic through an Ethernet-over-IP (EoIP) tunnel. Because UDP and EoIP are not reliable transport mechanisms, there is no guarantee that a mobility control packet or data packet will be delivered to a mobility peer. Mobility packets may be lost in transit due to a firewall filtering the UDP port or EoIP packets or due to routing issues.

            Guidelines and Limitations

            Controller software release 4.0 or later releases enable you to test the mobility communication environment by performing mobility ping tests. These tests may be used to validate connectivity between members of a mobility group (including guest controllers). Two ping tests are available:

            • Mobility ping over UDP—This test runs over mobility UDP port 16666. It tests whether the mobility control packet can be reached over the management interface.

            • Mobility ping over EoIP—This test runs over EoIP. It tests the mobility data traffic over the management interface.

            Only one mobility ping test per controller can be run at a given time.


            Note

            These ping tests are not Internet Control Message Protocol (ICMP) based. The term “ping” is used to indicate an echo request and an echo reply message.


            Note

            Any ICMP packet greater than 1280 bytes will always be responded with a packet that is truncated to 1280 bytes. For example, a ping with a packet that is greater than 1280 bytes from a host to the management interface is always responded with a packet that is truncated to 1280 bytes.

            Running Mobility Ping Tests (CLI)

            • To test the mobility UDP control packet communication between two controllers, enter this command:

              mping mobility_peer_IP_address

              The mobility_peer_IP_address parameter must be the IP address of a controller that belongs to the mobility list.

            • To test the mobility EoIP data packet communication between two controllers, enter this command:

              eping mobility_peer_IP_address

              The mobility_peer_IP_address parameter must be the IP address of a controller that belongs to the mobility list.

            • To troubleshoot your controller for mobility ping, enter these commands:

              config logging buffered debugging

              show logging

              To troubleshoot your controller for mobility ping over UDP, enter this command to display the mobility control packet:

              debug mobility handoff enable


              Note

              We recommend using an ethereal trace capture when troubleshooting.

            Configuring Dynamic Anchoring for Clients with Static IP Addresses

            Information About Dynamic Anchoring for Clients with Static IP

            At times you may want to configure static IP addresses for wireless clients. When these wireless clients move about in a network, they could try associating with other controllers. If the clients try to associate with a controller that does not support the same subnet as the static IP, the clients fail to connect to the network. You can now enable dynamic tunneling of clients with static IP addresses.

            Dynamic anchoring of static IP clients with static IP addresses can be associated with other controllers where the client’s subnet is supported by tunneling the traffic to another controller in the same mobility group. This feature enables you to configure your WLAN so that the network is serviced even though the clients use static IP addresses.

            How Dynamic Anchoring of Static IP Clients Works

            The following sequence of steps occur when a client with a static IP address tries to associate with a controller:

            1. When a client associates with a controller, for example, WLC-1, it performs a mobility announcement. If a controller in the mobility group responds (for example WLC-2), the client traffic is tunneled to the controller WLC-2. As a result, the controller WLC 1 becomes the foreign controller and WLC-2 becomes the anchor controller.

            2. If none of the controllers responds, the client is treated as a local client and authentication is performed. The IP address for the client is updated either through an orphan packet handling or an ARP request processing. If the IP subnet of the client is not supported in the controller (WLC-1), WLC-1 sends another static IP mobile announce and if a controller (for example WLC-3) that supports the client's subnet responds to that announcement, the client traffic is tunneled to that controller, that is WLC-3. As a result, the controller WLC 1 becomes the export foreign controller and WLC-3 becomes the export anchor controller.

            3. Once the acknowledgment is received, the client traffic is tunneled between the anchor and the controller (WLC-1).


              Note

              If you configure WLAN with an interface group and any of the interfaces in the interface group supports the static IP client subnet, the client is assigned to that interface. This situation occurs in local or remote (static IP Anchor) controller.

              When AAA override is used along with the interface group that is mapped to WLAN, the source interface that is used for DHCP transactions is the Management interface.

              If the interface group that you add to a WLAN has RADIUS Server Overwrite interface enabled and a client requests for authentication, the controller selects the first IP address from the interface group as the RADIUS server.


              Note

              A security level 2 authentication is performed only in the local (static IP foreign) controller, which is also known as the exported foreign controller.

            Restrictions on Dynamic Anchoring for Clients With Static IP Addresses

            • Do not configure overridden interfaces when you perform AAA for static IP tunneling, this is because traffic can get blocked for the client if the overridden interface does not support the client’s subnet. This can be possible in extreme cases where the overriding interface group supports the client’s subnet.

            • The local controller must be configured with the correct AAA server where this client entry is present.

            The following restrictions apply when configuring static IP tunneling with other features on the same WLAN:

            • Auto anchoring mobility (guest tunneling) cannot be configured for the same WLAN.

            • FlexConnect local authentication cannot be configured for the same WLAN.

            • The DHCP required option cannot be configured for the same WLAN.

            • You cannot configure dynamic anchoring of static IP clients with FlexConnect local switching.

            • We recommend that you configure the same NTP/SNTP servers on the Cisco WLCs. If the NTP/SNTP servers are different, ensure that the system time on all Cisco WLCs is the same when NTP/SNTP is enabled. If the system time is not in sync, seamless mobility might fail in some scenarios. Also, a Cisco WLC that has the lagging time with NTP/SNTP enabled drops the mobile announce messages.

            Configuring Dynamic Anchoring of Static IP Clients (GUI)

              Step 1   Choose WLANs to open the WLANs page.
              Step 2   Click the ID number of the WLAN on which you want to enable dynamic anchoring of IP clients. The WLANs > Edit page is displayed.
              Step 3   Choose the Advanced tab to open the WLANs > Edit (Advanced) page.
              Step 4   Enable dynamic anchoring of static IP clients by selecting the Static IP Tunneling check box.
              Step 5   Click Apply to commit your changes.

              Configuring Dynamic Anchoring of Static IP Clients (CLI)

              config wlan static-ip tunneling {enable | disable} wlan_id— Enables or disables the dynamic anchoring of static IP clients on a given WLAN.

              To monitor and troubleshoot your controller for clients with static IP, use the following commands:

              • show wlan wlan_id—Enables you to see the status of the static IP clients feature.

                
…………..
Static IP client tunneling.............. Enabled
…………..

              • debug client client-mac

              • debug dot11 mobile enable

              • debug mobility handoff enable

              Configuring Foreign Mappings

              Information About Foreign Mappings

              Auto-Anchor mobility, also known as Foreign Mapping, allows you to configure users that are on different foreign controllers from different physical location to obtain IP addresses from a subnet or group of subnets based on their physical location.

              Configuring Foreign Controller MAC Mapping (GUI)

                Step 1   Choose the WLANs tab.

                The WLANs page appears listing the available WLANs.

                Step 2   Click the Blue drop down arrow for the desired WLAN and choose Foreign-Maps.

                The foreign mappings page appears. This page also lists the MAC addresses of the foreign controllers that are in the mobility group and interfaces/interface groups.

                Step 3   Choose the desired foreign controller MAC and the interface or interface group to which it must be mapped and click on Add Mapping.

                Configuring Foreign Controller MAC Mapping (CLI)

                • To add foreign controller mapping, enter this command:

                  config wlan mobility foreign-map add wlan-id foreign_ctlr_mac interface/interface_grp name

                Configuring Proxy Mobile IPv6

                Information About Proxy Mobile IPv6

                Proxy Mobile IPv6 (PMIPv6) is a network-based mobility management protocol that supports a mobile node by acting as the proxy for the mobile node in an IP mobility-related signaling scenario. The mobility entities in the network track the movements of the mobile node, initiate mobility signaling, and set up the required routing state.

                The main functional entities are the Local Mobility Anchor (LMA) and Mobile Access Gateway (MAG). The LMA maintains the reachability state of the mobile node and is the topological anchor point for the IP address of the mobile node. The MAG performs mobility management on behalf of a mobile node. The MAG resides on the access link where the mobile node is anchored. The Cisco Wireless LAN Controller (WLC) implements the MAG functionality.

                In the Cisco 5500 Series WLC, Cisco Wireless Services Module 2 (WiSM2), and Cisco 8500 Series WLCs, PMIPv6 MAG support for integration with LMA such as Cisco ASR 5000 Series in cellular data networks.

                For PMIPv6 clients, Cisco WLC supports both central web authentication and local web authentication.

                PMIPv6 is supported for clients with 802.1X authentication. After the 802.1X authentication is complete, a Cisco AP starts PMIPv6 signaling for the corresponding client.

                Dynamic AAA Attributes

                The dynamic AAA attributes that are supported are listed below:
                Type Attribute Value Description Cisco WLC Behavior
                89 Chargeable-User-Identity String Chargeable User Identity RFC-4372 If present, the attribute is copied into the MSCB and used in accounting reports; no other usage.
                26/104 15/13 3GPP-Charging-Characteristics String Rules for producing charging information If present, the attribute is copied to the MSCB and passed to the L2 attach triggers to the MAG. The attribute is used to send to the local mobility anchor (LMA) as an option in the proxy binding update (PBU).
                26/9/1 Cisco-Service-Selection String Service Identifier (APN) If present, the attribute overrides the locally configured APN.
                26/9/1 Cisco-Mobile-Node-Identifier String Mobile Node Identifier If present, the attribute is used for the network access identifier (NAI).
                26/9/1 Cisco-MSISDN String Mobile Subscriber ISDN Number If present, the attribute is used to pass to MAG code with a new parameter in the L2 attach trigger.
                26/9/1 Cisco-MPC-Protocol-Interface ENUM: "none" "PMIPv6" "GTPv1" "PMIPv4" Mobile Node Service Type Only IPv4 and simple IP clients are supported.
                26/9/1 Cisco-URL-REDIRECT String HTTP URL of the Captive Portal Existing attribute used for web authentication; no changes required.
                26/9/1 Cisco-URL-REDIRECT-ACL String Specific Redirect Rule Existing attribute used for web authentication; no changes required.
                26/9/1 Cisco-Home-LMA-IPv4-Address IP Address Mobile node's Home LMA IPv4 address If present, this attribute is used as the LMA for the client.
                Note    The GRE tunnel creation is still static.

                PMIPv6 AAA Attributes

                The PMIPv6 AAA attributes that are supported are listed below:
                Type Attribute Value Description Cisco WLC Behavior
                89 Chargeable-User-Identity String Chargeable User Identity RFC-4372 If present, the attribute is copied into the MSCB and used in accounting reports; no other usage.
                26/104 15/13 3GPP-Charging-Characteristics String Rules for producing charging information If present, the attribute is copied to the MSCB and passed to the L2 attach triggers to the MAG. The attribute is used to send to the local mobility anchor (LMA) as an option in the proxy binding update (PBU).
                26/9/1

                mn-network

                		String Service Identifier (APN) If present, the attribute overrides the locally configured APN (Mandatory)
                26/9/1 mn-nai String Mobile Node Identifier If present, the attribute is used for the network access identifier (NAI).
                26/9/1 cisco-msisdn String Mobile Subscriber ISDN Number If present, the attribute is used to pass to MAG code with a new parameter in the L2 attach trigger.
                26/9/1 cisco-mpc-protocol-interface ENUM: "None" "PMIPv6" Mobile Node Service Type Only PMIPv6 clients are supported. (Mandatory)
                26/9/1 home-lma-ipv4-address IPv4 Address Mobile node's Home LMA IPv4 address If present, this attribute is used as the LMA for the client. The LMA should also be configured in WLC (Mandatory).
                Note    The GRE tunnel creation is still static.

                26/9/1

                mn-service

                		ENUM: "IPv4" Type of client

                Only IPv4 is supported.

                Restrictions on Proxy Mobile IPv6

                • IPv6/dual stack clients are not supported. Only IPv4 is supported with PMIPv6.

                • You must enable DHCP Proxy before you can connect to a PMIPv6-enabled WLAN.

                • PMIPv6 is not supported on local switching WLANs with FlexConnect mode APs.

                Configuring Proxy Mobile IPv6 (GUI)

                  Step 1   Choose Controller > PMIPv6 > General. The PMIPv6 Generalwindow is displayed.
                  Step 2   Enter the values for the following parameters:

                  • Domain Name—Name of the PMIPv6 domain. The domain name can be up to 127 case-sensitive, alphanumeric characters.

                  • MAG Name—Name of the MAG.

                  • Maximum Bindings Allowed—Maximum number of binding updates that the Cisco WLC can send to the MAG. The valid range is between 0 and 40000.

                  • Binding Lifetime—Lifetime, in seconds, of the binding entries in the Cisco WLC. The valid range is between 10 and 65535. The default value is 3600. The binding lifetime should be a multiple of 4.

                  • Binding Refresh Time—Refresh time, in seconds, of the binding entries in the Cisco WLC. The valid range is between 4 and 65535 seconds. The default value is 300 seconds. The binding refresh time should be a multiple of 4.

                  • Binding Initial Retry Timeout—Initial timeout, in milliseconds, between the Proxy Binding Updates (PBUs) when the Cisco WLC does not receive the Proxy Binding Acknowledgments (PBAs). The valid range is between 100 and 65535. The default value is 1000.

                  • Binding Maximum Retry Timeout—Maximum timeout between the PBUs when the Cisco WLC does not receive the PBAs. The valid range is between 100 and 65535. The default value is 32000.

                  • Replay Protection Timestamp—Maximum amount of time, in milliseconds, difference between the timestamp in the received PBA and the current time of the day. The valid range is between 1 and 255. The default value is 7.

                  • Minimum BRI Retransmit Timeout—Minimum amount of time, in milliseconds, that the Cisco WLC waits for before retransmitting the BRI message. The valid range is between 500 and 65535. The default value is 1000.

                  • Maximum BRI Retransmit Timeout—Maximum amount of time, in milliseconds, that the Cisco WLC waits for before retransmitting the Binding Revocation Indication (BRI) message. The valid range is between 500 and 65535. The default value is 2000.

                  • BRI Retries—Maximum number of times that the Cisco WLC retransmits the BRI message before receiving the Binding Revocation Acknowledgment (BRA) message. The valid range is between 1 to 10. The default value is 1.

                  Step 3   Click Apply.
                  Note   

                  To clear your configuration, click Clear Domain.

                  Step 4   To create the LMA, follow these steps:
                  1. Choose Controller > PMIPv6 > LMA and click New.
                  2. Enter the values for the following parameters:

                    • Member Name—Name of the LMA connected to the Cisco WLC.

                    • Member IP Address—IP address of the LMA connected to the Cisco WLC.

                  3. Click Apply.
                  Step 5   To create a PMIPv6 profile, follow these steps:
                  1. Choose Controller > PMIPv6 > Profiles and click New.
                  2. In the PMIPv6 Profile > New window, enter the values for the following parameters:

                    • Profile Name—Name of the profile.

                    • Network Access Identifier—Name of the Network Access Identifier (NAI) associated with the profile.

                    • LMA Name—Name of the LMA to which the profile is associated.

                    • Access Point Node—Name of the access point node; APN identifies a particular routing domain for user traffic.

                  3. Click Apply.
                  Step 6   To configure PMIPv6 parameters for a WLAN, follow these steps:
                  1. Choose WLANs > WLAN ID. The WLANs > Edit window is displayed.
                  2. Click the Advanced tab.
                  3. Under PMIP, from the PMIP Mobility Type drop-down list, choose the mobility type from the following options:

                    • None—Configures the WLAN with simple IP

                    • PMIPv6—Configures the WLAN with only PMIPv6

                  4. From the PMIP Profile drop-down list, choose the PMIP profile for the WLAN.
                  5. In the PMIP Realm field, enter the default realm for the WLAN.
                  6. Click Apply.
                  Step 7   Click Save Configuration.

                  Configuring Proxy Mobile IPv6 (CLI)

                    Step 1   Configure a PMIPv6 domain name by entering this command:

                    config pmipv6 domain domain-name

                    Note   

                    This command also enables the MAG functionality on the Cisco Wireless Controller (WLC).

                    Step 2   Configure MAG by using these commands:

                    • Configure the maximum binding update entries that are allowed by entering this command:

                      config pmipv6 mag binding maximum units

                    • Configure the binding entry lifetime by entering this command:

                      config pmipv6 mag lifetime units

                    • Configure the binding refresh interval by entering this command:

                      config pmipv6 mag refresh-time units

                    • Configure the initial timeout between PBUs if PBA does not arrive by entering this command:

                      config pmipv6 mag init-retx-time units

                    • Configure the maximum initial timeout between PBUs if PBA does not arrive by entering this command:

                      config pmipv6 mag max-retx-time units

                    • Configure the replay protection mechanism by entering this command:

                      config pmipv6 mag replay-protection {timestamp window units | sequence-no | mobile-node-timestamp}

                    • Configure the minimum or maximum amount of time, in seconds, that the MAG should wait for before it retransmits the binding revocation indication (BRI) message by entering this command:

                      config pmipv6 mag bri delay {min | max} units

                    • Configure the maximum number of times the MAG should retransmit the BRI message before it receives the binding revocation acknowledgment (BRA) message by entering this command:

                      config pmipv6 mag bri retries units

                    • Configure the list of LMAs for the MAG by entering this command:

                      config pmipv6 mag lma lma-name ipv4-address ip-address

                    Step 3   Add a profile to a PMIPv6 domain by entering this command:

                    config pmipv6 add profile profile-name nai {user@realm | @realm | *} lma lma-name apn apn-name

                    Note   

                    nai stands for network access identifier, while apn stands for access point name.

                    Step 4   Delete a PMIPv6 entity by entering this command:

                    config pmipv6 delete {domain domain-name | lma lma-name | profile profile-name nai {user@realm | @realm | *}}

                    Step 5   Configure the PMIPv6 parameters for the WLAN by using these commands:

                    • Configure the default realm for the WLAN by entering this command:

                      config wlan pmipv6 default-realm {realm-name | none} wlan-id

                    • Configure the mobility type for a WLAN or for all WLANs by entering this command:

                      config wlan pmipv6 mobility-type {none | pmipv6} {wlan-id | all}

                    • Configure the profile name for a PMIPv6 WLAN by entering this command:

                    Step 6   Save your changes by entering this command: save config
                    Step 7   See the PMIPv6 configuration details by using the following show commands:

                    • See the details of a profile of a PMIPv6 domain by entering this command:

                      show pmipv6 domain domain-name profile profile-name

                    • See a summary of all the PMIPv6 profiles by entering this command:

                      show pmipv6 profile summary

                    • See global information about the PMIPv6 for a MAG by entering this command:

                      show pmipv6 mag globals

                    • See information about MAG bindings for LMA or NAI by entering this command:

                      show pmipv6 mag bindings {lma lma-name | nai nai-name}

                    • See statistical information about MAG by entering this command:

                      show pmipv6 mag stats domain domain-name peer peer-name

                    • See information about PMIPv6 for all clients by entering this command:

                      show client summary

                    • See information about PMIPv6 for a client by entering this command:

                      show client details client-mac-address

                    • See information about PMIPv6 for a WLAN by entering this command:

                      show wlan wlan-id