Control path to mobility member flaps

[cisconell]

Here is the problem  I have 2 controllers as below one with 6.0 version and other with 5.2 version

AIR-WLC4404-100-K9  6.0.202.0 
AIR-WLC4402-12-K9   5.2.178.0  GUEST

Control path between controller flaps

All mobility anchors on wlan index 7 are down.
All mobility anchors on wlan index 3 are down.
Control path to mobility member x.x.x.x is down.

No problem observed when i have software 5.2.178.0 on both the controler

Did some one experience this problem , or any thoughts on this please

[cisconell]

Weterry , could you guide me how to get this verified

is LAG enabled on 1-2-guest but not enabled on 3? (or vice versa)?  - commads please

Yes the next option is only packet capture or TAC.

Debug need to enable again and see when it goes down again , may be I can update on that by Monday.

[weterry]

As far as the debug keepalive goes, you will see a UDP 16666 sent from one like WLC 1 to WLC 2 every 30 seconds (and WLC 2 would then send a reply back followng it).  The EOIP packets would be every 10 seconds in the same fashion.

As far as interpeting the debug, you're basically looking for where there are longer than 10/30 second intervals between the keepalives.

In 7.0.116.0 you can debug "debug mobility keepalive enable "  so you can see just keepalives between two WLCs,  but I dont know if that is available in 6.0.202.0.....

As for LAG in the WLC GUI > Controller tab, you should see a drop down for LAG. Its either enabled or disabled.

In the CLI, I dont know command off top of my head, but something like a show interface summary  might show you the port number assigned to interfaces. If it says port 29 or port 13  (instead of port 1/2/3/4.etc.....)  then you have LAG enabled.

[cisconell]

Let me check on the LAG and update all

[cisconell]

LAG is enabled on both

Now here is something interesting

I saw the mobility peer between wlc3 and guest was up more that 24 hrs.

and now when a give a mping the 1st one i received a reply and 2nd time when I pinged the controller path went down

And again after certain time.it came up and after 30 minutes when I gave mping again it made controller path went down again

so for some reason my mping making the control path down.

Debug out put from wlc3
------------------------

when control path is down

*Jan 14 18:15:58.124: UDP Keepalive sent to ::
*Jan 14 18:15:58.124:   10.21.1.11, port 16666
*Jan 14 18:15:58.124:   type: 20(MobilityPingRequest)  subtype: 0  version: 1  xid: 18721  seq: 28216  len 41 flags 0
*Jan 14 18:15:58.125:   group id: 2a1a1c7e 259012ce 61cfa2a 52e3635d
*Jan 14 18:15:58.125:  Highest Mobility Version supported  2
*Jan 14 18:15:58.125: Mobility Member 10.21.1.11 detected DOWN status 2, cleaning up client entries

when control path is up

*Jan 14 18:35:58.149: UDP Keepalive sent to ::
*Jan 14 18:35:58.149:   10.21.1.11, port 16666
*Jan 14 18:35:58.150:   type: 20(MobilityPingRequest)  subtype: 0  version: 1  xid: 18801  seq: 28338  len 41 flags 1
*Jan 14 18:35:58.150:   group id: 2a1a1c7e 259012ce 61cfa2a 52e3635d
*Jan 14 18:35:58.150:  Highest Mobility Version supported  2
*Jan 14 18:35:58.153: UDP Keepalive received from::
*Jan 14 18:35:58.153:   10.21.1.11, port 16666

[cisconell]

Hi all

Does any one have any more suggestion  why the mping fails ?

mping works fine from wlc 1 to guest but fails between wlc 3 to guest

[cisconell]

Hi All,

Just want to close this thread . As I was new to the company I missed the compelete network Architecture . There was a  Paloalto sitting between the firewall and WLC and which was denying the protocol reguired for the mobilty handshake. We need to open a bidrectional rule in paloalto to make it work

Thanks for all your inputs

[Bilal Nawaz]

Could you kindly share the rule please. I cannot seem to get it to work.