Checkpoint · Firewalls · Wireless

Cisco WLC Mobility Groups

Cisco WLC Mobility Groups – Data Path down/ Control Path down

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:

SRC DST Service
outside_wlc inside_wlc TCP/97
outside_wlc inside_wlc UDP/16666

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’.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s