Data Path Down for Mobility Group

[tedmonson-hhsc]

After setting up a Mobility Group the control channel appears to be up but the data path shows to be down so I know the two WLCs see each other. There are firewalls on each side of the WLCs the only issue that I have with that is at this point I cannot ping the Anchor WLC from the remote unit but I can ping the remote unit from the anchor.

Question: is icmp required for the mobility group to setup? 

I also turned on debug and received the following from each 

Anchor WLC

*mmListen: Feb 22 14:34:08.571: UDP Keepalive received from::

*mmListen: Feb 22 14:34:08.571:   10.40.96.10, port 16666

*mmListen: Feb 22 14:34:08.571:   type: 21(MobilityPingReply)  subtype: 0  version: 1  xid: 101800             seq: 23014  len 41 flags 0

*mmListen: Feb 22 14:34:08.571:   group id: dbfa98c8 897986cc 22707721 c8ae9143

*mmListen: Feb 22 14:34:08.571:  Highest Mobility Version supported  2

*mmMobility: Feb 22 14:34:18.567: EOIP Keepalive sent to:10.40.96.10

*mmMobility: Feb 22 14:34:18.567:  version : 02, opcode : ETHOIP_OP_REQ sequence no. 68986 peerStatus: 0

*mmMobility: Feb 22 14:34:18.568: Mobility Member 10.40.96.10 detected DOWN status 1, cleaning up client entries

*mmMobility: Feb 22 14:34:28.567: EOIP Keepalive sent to: 10.40.96.10

*mmMobility: Feb 22 14:34:28.567:  version : 02, opcode : ETHOIP_OP_REQ sequence no. 68987 peerStatus: 0

*mmMobility: Feb 22 14:34:28.568: Mobility Member 10.40.96.10 detected DOWN status 1, cleaning up client entries

*mmMobility: Feb 22 14:34:38.567: EOIP Keepalive sent to: 10.40.96.10

*mmMobility: Feb 22 14:34:38.567:  version : 02, opcode : ETHOIP_OP_REQ sequence no. 68988 peerStatus: 0

*mmMobility: Feb 22 14:34:38.568: UDP Keepalive sent to ::

*mmMobility: Feb 22 14:34:38.568:   10.40.96.10, port 16666

*mmMobility: Feb 22 14:34:38.568:   type: 20(MobilityPingRequest)  subtype: 0  version: 1  xid: 101807  seq: 36271  len 41 flags 1

*mmMobility: Feb 22 14:34:38.568:   group id: dbfa98c8 897986cc 22707721 c8ae9143

*mmMobility: Feb 22 14:34:38.568:  Highest Mobility Version supported  2

*mmMobility: Feb 22 14:34:38.568: Mobility Member 10.40.96.10 detected DOWN status 1, cleaning up client entries

Remote WLC

*ethoipSocketTask: Feb 22 14:34:08.633: EOIP Keepalive received from: 10.41.107.238

*ethoipSocketTask: Feb 22 14:34:08.633:  version : 02, opcode : ETHOIP_OP_REQ sequence no.68985 peerStatus: 0

*ethoipSocketTask: Feb 22 14:34:08.633: EOIP Keepalive sent to: 10.41.107.238

*ethoipSocketTask: Feb 22 14:34:08.633:  version : 02, opcode : ETHOIP_OP_RESP sequence no. 68985 peerStatus: 0

*mmListen: Feb 22 14:34:08.633: UDP Keepalive received from::

*mmListen: Feb 22 14:34:08.633:   10.41.107.238, port 16666

*mmListen: Feb 22 14:34:08.633:   type: 20(MobilityPingRequest)  subtype: 0  version: 1  x id: 101800  seq: 36264  len 41 flags 1

*mmListen: Feb 22 14:34:08.633:   group id: dbfa98c8 897986cc 22707721 c8ae9143

*mmListen: Feb 22 14:34:08.633:  Highest Mobility Version supported  2

*mmListen: Feb 22 14:34:08.633: UDP Keepalive sent to::

*mmListen: Feb 22 14:34:08.633:   10.41.107.238, port 16666

*mmListen: Feb 22 14:34:08.633:   type: 21(MobilityPingReply)  subtype: 0  version: 1  xid  : 101800  seq: 23014  len 41 flags 0

*mmListen: Feb 22 14:34:08.633:   group id: dbfa98c8 897986cc 22707721 c8ae9143

*mmListen: Feb 22 14:34:08.633:  Highest Mobility Version supported  2

*mmMobility: Feb 22 14:34:18.129: Mobility Member 10.41.107.238 detected DOWN status 1, cleaning up client entries

[George Stefanick]

Hey there and welcome to CSC. I notice its your first post ..

I attached a topology I did  little bit ago. Note that 16666 and 166667 and 97 need to be opened or the EOIP tunnel and the control and data.

Are these open ?

[tedmonson-hhsc]

Thanks, I beleive we do

INSIDE ACL

access-list inside line 39 extended permit object-group GRP-PROTOCOL-CAPWAP any host 10.40.96.10 0x9245a567

  access-list inside line 39 extended permit esp any host 10.40.96.10 (hitcnt=0) 0xf7b4cd5e

  access-list inside line 39 extended permit 97 any host 10.40.96.10 (hitcnt=0) 0x2e873edc

access-list inside line 58 extended permit ip any any (hitcnt=50921316)

DMZ ACL

access-list guest-wlan line 1 extended permit object-group GRP-PROTOCOL-CAPWAP host 10.40.96.10 any 0xf5284c63

  access-list guest-wlan line 1 extended permit esp host 10.40.96.10 any (hitcnt=0) 0xd3c307e9

  access-list guest-wlan line 1 extended permit 97 host 10.40.96.10 any (hitcnt=0) 0xbfcb9db1

access-list guest-wlan line 2 extended permit object-group GRP-UDP-CAPWAP host 10.40.96.10 any 0x4a81f54f

  access-list guest-wlan line 2 extended permit udp host 10.40.96.10 any eq 12222 (hitcnt=0) 0xd4297d97

  access-list guest-wlan line 2 extended permit udp host 10.40.96.10 any eq 12223 (hitcnt=0) 0xfd456208

  access-list guest-wlan line 2 extended permit udp host 10.40.96.10 any eq 5247 (hitcnt=0) 0xd3349ebe

  access-list guest-wlan line 2 extended permit udp host 10.40.96.10 any eq 5246 (hitcnt=0) 0x907cd00a

  access-list guest-wlan line 2 extended permit udp host 10.40.96.10 any eq 16666 (hitcnt=0) 0x34e90f0c

  access-list guest-wlan line 2 extended permit udp host 10.40.96.10 any eq 16667 (hitcnt=0) 0x7eb24221

[George Stefanick]

Can you remove the ACLs and see if she comes up ? Then apply them and see where they break ?

Can you Mping and Eping across the Eoip ? Also, are the mob groups properly set up ?

[tedmonson-hhsc]

Eping fails on from both WLCs, the mob look configuration looks good, I have some one looking into the acl issue

Remote WLC

(Cisco Controller) >mping 10.40.96.10

Send count=3, Receive count=3 from 10.40.96.10

(Cisco Controller) >eping 10.40.96.10

Send count=3, Receive count=0 from 10.40.96.10

Anchor WLC

(Cisco Controller) >mping 10.41.107.238

Send count=3, Receive count=3 from 10.41.107.238

(Cisco Controller) >eping 10.41.107.238

Send count=3, Receive count=0 from 10.41.107.238

[dselfridge]

Hi,

I'm having the same issue. (MPings OK, EPings failing) did you manage to resolve this?

Couple of differences to your scenario,

ICMP Pings work both ways.

Protocol 97 and UDP 166666 allowed but 166667 wasn't requested as the Cisco Docs didn't say it was needed. Is it?

I'm also in the unhappy situation where the firewall is managed by a third party, so it's time consuming getting any changes done and debugging it? well....

[tedmonson-hhsc]

I understand, looking back I opened a TAC case and work with a couple of engineers and tried several things none of which worked, but what really got it to work was an old fashion reboot of the anchor controller, thats right after the reboot everything started to work and I haven't had any issues since.