Buy or Renew
Buy or Renew
Cisco Virtual Engineer generative AI bot now active in Wireless Discussion Forum. Learn more.
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
8012
Views
0
Helpful
2
Replies

Control Path Down

Go to solution
scottwilliamson
Level 2
Level 2

‎10-23-2009 06:00 AM - edited ‎07-03-2021 06:11 PM

Hi,

The control path between our Guest Anchor WLC4402 and one of our foreign controllers is down all other control paths are up as are all of the data paths. The Anchor is behind a firewall the configuration of which must be ok due to the other WLCs data and control paths being up. Can anyone tell me how I check that the WLCs are reciving each others mobility packets e.g. via debug.

Many Thanks

Scott

Labels:
0 Helpful
1 Accepted Solution

Accepted Solutions

Go to solution
weterry
Level 4
Level 4

‎10-23-2009 07:54 PM

debug mobility keepalive

you should see a "data path" keepalive every 10 seconds and a "control path" keepalive every 30 seconds.

I believe the Control Path will be a message about port 16666.

Run this from all controllers and verify who is sending the keepalive (I believe it is lowest mac address).

Bottom line is that if you see one controller send it, and the other doesn't recieve it, that sounds like it is getting lost along the way.

I've seen configuration before where if the DMZ Controller is the initiator of the keepalive (high mac address?), then the path may be down. It had to do with the firewall allowing the session from Trust to DMZ (and the return traffic), but not allowing the DMZ to initiate the session.

You could try an mping from both controllers and see if you can get a response....?

View solution in original post

0 Helpful
2 Replies 2

Go to solution
weterry
Level 4
Level 4

‎10-23-2009 07:54 PM

debug mobility keepalive

you should see a "data path" keepalive every 10 seconds and a "control path" keepalive every 30 seconds.

I believe the Control Path will be a message about port 16666.

Run this from all controllers and verify who is sending the keepalive (I believe it is lowest mac address).

Bottom line is that if you see one controller send it, and the other doesn't recieve it, that sounds like it is getting lost along the way.

I've seen configuration before where if the DMZ Controller is the initiator of the keepalive (high mac address?), then the path may be down. It had to do with the firewall allowing the session from Trust to DMZ (and the return traffic), but not allowing the DMZ to initiate the session.

You could try an mping from both controllers and see if you can get a response....?

0 Helpful

Go to solution
scottwilliamson
Level 2
Level 2
In response to weterry

‎10-26-2009 06:52 AM

Hi Wesley,

Thanks for that you've helped me realise what the problem is: The Anchor was not sending udp port 16666 to the problem controller, it occured to me that the Service Port address of the Anchor was on the same subnet as the Manager interfaces of the controller it could not establish the EoIP tunnel with - I've changed the Service Port address and everything now works.

Thank you,

Scott

0 Helpful
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Customers Also Viewed These Support Documents
Review Cisco Networking products for a $25 gift card