CCIE Enterprise Wireless (v1.0) – 3.9 Controller Mobility – 3.9.e Mobility anchoring aka Mobility Tunnels

Posted on Posted in 3.9.e Mobility anchoring, Cisco 9800 Wireless, Mobility anchoring

Note:

CCIE Enterprise Wireless (v1.0) – 3.9 Controller Mobility – 3.9.e Mobility anchoring

On any firewall between the guest anchor controller and the remote controllers, these ports need to be open:

Legacy mobility: IP Protocol 97 for user data traffic, UDP Port 16666

New mobility: UDP Port 16666 and 16667

For optional management, these firewall ports need to be open:

SSH/Telnet - TCP Port 22/23

TFTP - UDP Port 69

NTP - UDP Port 123

SNMP - UDP Ports 161 (gets and sets) and 162 (traps)

HTTPS/HTTP - TCP Port 443/80

Syslog - TCP Port 514

RADIUS Auth/Account UDP Port 1812 and 1813

If your 9800 WLCs are set in a HA pair it is mandatory to configure a mobility MAC address. The default mobility group name is “default” but can customize to a desired value. Remember that you must configure the same Mobility Group Name on 9800 WLCs where roams between them is
expected.

Foreign Controller – 10.0.0.40

Collect mobility configuration of both 9800 WLCs.

Foreign – 10.0.0.40

Anchor – 10.0.66.3

Configure the mobility peer on the foreign (internal ) 10.0.4.140

Configure the mobility peer on the anchor (DMZ) 10.0.0.66

verify the status of the mobility tunnels – the data/control path should be in an UP/UP status

Foreign – 10.0.0.4

DMZ anchor – 10.0.66.3

the data/control path are down – if both WLCs are configured correctly look at the firewall to see if mobility traffic is allowed between the two devices. Remember that the ports are as follows:

Legacy mobility: IP Protocol 97 for user data traffic, UDP Port 16666

New mobility: UDP Port 16666 and 16667

Log into ASA

First i will take a look at the ASA Firewal logs. The log shows that traffic originating from the DMZ (anchor controller – 10.0.66.3) is being denied to the foreign (internal controller – 10.0.4.140) on UDP ports 16666 and 16667.

BTW 10.0.4.140 is defined as the wireless management interface.


TIP: verify that the correct MAC addresses are defined when configuring the mobility master peer. After fixing the firewall rules below..

The tunnels were in a down state. The logs on the DMZ controller revealed that it could not process the packet that came from the foreign controller. In this case internal traffic to the DMZ is allowed so it was NOT a firewall issue.

The log did reveal an interesting mis-configuration on my end.

DMZ (anchor controller) log.

I also grabbed a wireshark capture from the controller

Once i updated the MAC the tunnels came up

no wireless mobility group member mac-address 000c.29d9.53e ip 10.0.4.140 public-ip 10.0.4.140 group 9800Cloud
wireless mobility group member mac-address 001e.14d9.d3ff ip 10.0.4.140 public-ip 10.0.4.140 group 9800Cloud
wr mem

Foreign tunnels UP

DMZ Anchor tunnels up


The next blog post – here – will cover sending traffic from the foreign to the anchor controller in the DMZ via the mobility tunnel.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.