Cisco Mobility Group – Anchor : Data Path Down

The path of the mobility group EtherIP tunnel between WLCs passes through a single CheckPoint firewall (R77.20), requiring that rules be defined to allow UDP/16666 and TCP/97 traffic to and from the WLCs.

I created rules in the usual manner:

With this policy installed I was not seeing any EtherIP traffic reach the inside WLC. Running ‘fw ctl zdebug drop | grep I could see:

;[cpu_3];[fw4_0];fw_log_drop_ex: Packet proto=97 10.1.1.1:16384 -> 10.10.1.1:7391 dropped by fw_handle_first_packet Reason: fwconn_key_init_links (INBOUND) failed;
;[cpu_3];[fw4_0];fw_log_drop_ex: Packet proto=97 10.1.1.1:16384 -> 10.10.1.1:7391 dropped by fw_handle_first_packet Reason: fwconn_key_init_links (INBOUND) failed;
;[cpu_3];[fw4_0];fw_log_drop_ex: Packet proto=97 10.1.1.1:16384 -> 10.10.1.1:7391 dropped by fw_handle_first_packet Reason: fwconn_key_init_links (INBOUND) failed;
;[cpu_3];[fw4_0];fw_log_drop_ex: Packet proto=97 10.1.1.1:16384 -> 10.10.1.16:7391 dropped by fw_handle_first_packet Reason: fwconn_key_init_links (INBOUND) failed;
;[cpu_3];[fw4_0];fw_log_drop_ex: Packet proto=97 10.1.1.1:16384 -> 10.10.1.1:7391 dropped by fw_handle_first_packet Reason: fwconn_key_init_links (INBOUND) failed;

This error lead me to CheckPoint sk86984. The final link of the solution “Create a special rule for returned traffic, or add a single rule with “All” sources and “All” destinations in both the Source and Destination columns”.
In this instance “All” isn’t to be confused with ‘any’, the source column must list both the source and destination WLC, likewise the same must be configured in the destination column.

Once configured you should see the Data Path come up.

Cisco Mobility Group – Anchor : Control Path Down

Whilst setting up a mobility anchor positioned in a DMZ I came across the issue of having both WLCs having a status of ‘Control Path Down’.

Running ‘debug mobility error enable’ (v8.0.11.0 command) I saw the following output:

*mmListen: May 01 07:16:32.936: Mobilty Packet Received from MAC: 00:07:7d:c0:22:80 which is not found in Mobility Database 

*mmListen: May 01 07:16:32.940: Mobilty Packet Received from MAC: 7c:ad:74:8d:4f:00 which is not found in Mobility Database 

*mmListen: May 01 07:16:32.954: Mobilty Packet Received from MAC: 88:1d:fc:21:5f:c0 which is not found in Mobility Database 

*mmListen: May 01 07:16:32.973: Mobilty Packet Received from MAC: a4:93:4c:b0:fa:60 which is not found in Mobility Database 

*mmListen: May 01 07:16:32.996: Mobilty Packet Received from MAC: 7c:ad:74:8d:4d:20 which is not found in Mobility Database 

*mmListen: May 01 07:16:33.140: Mobilty Packet Received from MAC: 7c:ad:74:8d:4f:00 which is not found in Mobility Database

Checking what had been configured under the Controller → Mobility Management → Mobility Groups the MAC addresses were correct apart from the last character.
The Cisco configuration guides state that the mobility group members must be able to reach each other via their management IP address for communication, and from this you can infer that you should also use its MAC address. Sadly this is wrong.
Use the MAC address from the ‘virtual’ interface and you should see a mobility group status of ‘up’.