Validate Mobility Messaging

In this lesson, we’ll be looking at how we can validate mobility messaging are being exchanged correctly between controllers. This follows on from our previous lesson, in which we learnt that controllers exchange mobility messages when clients roam.

3.0 Mobility
 3.3 Validate mobility tunnelling for data and control path.

To recap, let’s remind ourselves on how and why Cisco wireless controllers exchange mobility traffic with each other.

Within our wireless deployment, we might have a number of wireless controllers hosting a number of APs. As clients roam between these APs, all of the wireless controllers need to know the following:

Above, you can see that we have two APs; MN-AP01 and MN-AP02. MN-AP01 is associated to MN-WLC01 and MN-AP02 is associated to MN-WLC02.

Our client has roamed from MN-AP01 to MN-AP02. When this occurs, mobility messages are exchanged between the controllers.


Depending on the mobility event that occurs, will depend on if the controllers will communicate via either of the following.

You can learn more about each of the mobility events  here.

As such, when working with numerous wireless controllers within a single mobility domain, it’s important to verify that they can communicate correctly. It’s important to make sure that your controllers are configured correctly within a single mobility domain, you can learn more about that here.

Remember that when a wireless client performs a layer 3 roam, data is exchanged via a CAPWAP tunnel. The CAPWAP tunnel is established using UDP ports 5246 and 5247.

We can test that controllers within our mobility domain can communicate with each other using a CAPWAP validation test.

In order to test CAPWAP communication, we can use the cping command, followed by the management interface IP address of our remove mobility controller.
It’s worth noting that the command must be ran from the CLI of the wireless controllers.

In our example, we’ll be running the cping command from WLC01 to the management IP of WLC02.

(Cisco Controller) >cping 10.10.20.1

Send count=3, Receive count=3 from 10.10.20.1

In our example, MN-WLC01 can communicate to MN-WLC02 successfully using UDP ports 5246 and 5247.

If the CAPWAP validation test fails, it’s important to ensure that UDP ports 5246 and 5247 are allowed between the controllers. There may be a firewall or other device that is restricting the messages from being delivered.


That’s all that’s required in order to validate mobility messaging for CAPWAP.

Data traffic between our controllers using auto-anchor mobility is exchanged via EoIP tunnels. The communication exchange between the controller uses IP protocol 97.

We can test that controllers within our mobility domain can communicate with each other using EoIP via a mobility test.

In order to test EoIP communication, we can use the eping command, followed by the management interface IP address of our remote mobility controller.

In our example, we’ll be running the eping command from WLC01 to the management IP of WLC02.

(Cisco Controller) >eping 10.10.20.1

Send count=3, Receive count=3 from 10.10.20.1

In our example, MN-WLC01 can communicate to MN-WLC02 via IP protocol 97.

If the EoIP validation test fails, it’s important to ensure that IP protocol 97 is allowed between the controllers. There may be a firewall or other device that is restricting the messages from being delivered.

That’s all that’s required in order to validate mobility messaging for EoIP.

Controllers in the same mobility domain exchange control information with each other using UDP/16666.

We can test that controllers within our mobility domain can communicate with each other using UDP/16666 via a mobility test.

In order to test UDP communication, we can use the mping command, followed by the IP address of our remote controller.

In our example, we’ll be running the mping command from WLC01 to the management IP of WLC02.

(Cisco Controller) >mping 10.10.20.1

Send count=3, Receive count=3 from 10.10.20.1

In our example, MN-WLC01 can communicate to MN-WLC02 via UDP port 16666.

If the mobility control test fails, it’s important to ensure that UDP/16666 is allowed between the controllers. There may be a firewall or other device that is restricting the messages from being delivered.

That’s all that’s required in order to validate mobility messaging for mobility control.