Data path down control path up issue

Unanswered Question
May 6th, 2010

have just set up a WLC 4402 as a Guest WLan controler on the DMZ of our network.

i have sucsessfully managed to get our internal controllers to connect to it, with the exception of 1. it says the control path is up but the data path is down. the other 14 controllers worked fine, and in testing the last one was ok but it is now not working properly. the 2 controllers can ping each other but just won't create the data tunnel. there is a firewall in the middle but that has been set up to allow traffic between the 2 groups of controllers to be unrestricted.

the internal controllers are 4404's and all controllers are running the same version of code.

any ideas would be great.


I have this problem too.
2 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (5 ratings)
christopher.hod... Sat, 01/29/2011 - 05:40

I'm having the same problem.  Why is the responder pointing you to documentation when you have clearly removed the issue as a config problem?

As in my scenario, I have active EoIP tunnels it's just one that's not playing nice.


George Stefanick Sat, 01/29/2011 - 08:26

What code are you using?

Is there a FW in the middle of your anchor and foreign controller?

Did you anchor your WLAN on the foreign controller to the anchor controller?

christopher.hod... Sat, 01/29/2011 - 09:28

George, thanks for the response.

Code level 7.0.98

Yes, anchor resides behind FW and verified port traffic 16,666-16,667 including UDP 97.

I have two active remote branch site tunneled back to the anchor now and working fine.  This is a third WLC and the data/path are down state.

Verified Symetric tunnel and mirroring active working configurations.  Can't go wrong as it's a cut-paste config.

Powered cycled the new WLC and NOGO.  Read in the forum to cycle the anchor next.

Pretty scary as there appears to be numerous threads noting similiar issues and we plan to expand the guest user access across the enterprise.

Obvious ICMP works and rebuilt configs already.  Becoming exhausted and frustrated as this deployment is only going to grow across our enterprise.

We have a NAC in the DMZ which doesn't come into play.

George Stefanick Sat, 01/29/2011 - 13:37

What is the name of the mobility group on the anchor and the name of the mobility group on your foreign controller?

christopher.hod... Sat, 01/29/2011 - 13:50

Hey george,

Thanks for the question,

Group name - same for all WLC's

Virtual IP - same for all WLC's

Symetric tunnel enbled - same for all WLC's

Anchor IP - same for all WLC's

Guest VLAN name - same for all WLC's

FW open ports - same for all WLC's

End points ICMP response testing - same for all WLC's

Did I miss anything...I don't think I did...

There are other threads which address similiar issue and recommend resetting the anchor....(reboot)

George Stefanick Sat, 01/29/2011 - 13:54

Lets get back to basics... From your WLC CLI can you mping and eping the anchor controller?

christopher.hod... Sat, 01/29/2011 - 15:32

Just researched and not familiar with mping and eping.  I do have ping response from the WLC.

Googled the mping and eping...appears to be a MS utility.  Is that built into the WLC IOS?

Please provide input as to completing ping type response.  How is that accomplished?

christopher.hod... Sat, 01/29/2011 - 16:02

Well, I'll be darned...they FAIL..

I reviewed the FW ACL and ran a trace between the two WLC's.  They both check open for defined ports 97 and 16,666-16,667.  I think it's going to be the requirement to (reboot) the anchor WLC.  Internet forums address this as a (known) problem.  But, I'm still listening...

(Cisco Controller) >mping

Send count=3, Receive count=0 from

(Cisco Controller) >eping ?

Enter a mobility peer IP addr.

(Cisco Controller) >eping

Send count=3, Receive count=0 from

(Cisco Controller) >

George Stefanick Sat, 01/29/2011 - 16:40

I cant say Ive ever had to reboot a anchor to make mobility work. Is there a route back from the firewall?I mean if the ports are listing then they should respond .. Is there any other ACLs you may have over looked ?

Did you say you can ping the management ip address of the anchor ?

nickeoannidis Fri, 08/26/2016 - 07:56

Hey guys,

Just wanted to reply to this thread so if someone else has this issue my experience may be useful.

The issue for my instance of this problem was IP routing. Our WAN provider uses iBGP as the routing protocol. What was happening was out of business hours the single WAN link at campus locations was dropping (due to ISP maintenance or what not). This was causing a routing convergence issued with the data path and WLC anchor. EoIP wouldn't be able to recover from this. What i had the WAN provider do was create static routes on the WAN routers for when the link dropped and the iBGP peer was down. This would allow EoIP to continue to operate was it would have a route to the anchor.

Scott Fella Sun, 01/30/2011 - 08:33

If you look at your output, it seems like you forgot to add the other WLC in the mobility group. When you do an eping, the wlc response tells you it doesn't know if that ip address.

Sent from Cisco Technical Support iPhone App

christopher.hod... Sun, 01/30/2011 - 13:11

There is an active mobility group called GUEST,

There are two active controllers in a mobility group which are not experiencing any issues.  My new WLC is unable to establish a control/data patch.

Configuration parameters match existing mobility group configurations which makes the configuration pretty straight forward.  I can ping from the new WLC back to the anchor but NO mping or eping.

My suspect I may have a FW inline that I'm unaware of as I am new to the organization.  Then again, there is mention to rebooting the anchor WLC.

I read up on the mping and eping, not sure why they would fail but the standard ping (8) type would pass.  Ports 97 and 16,666/16,667 verified with the network traffic sniffer.

Mping and eping appear to be a glorified extended ping with added functionality/multi host response tool.

George Stefanick Sun, 01/30/2011 - 13:41

Are you positive that you anchored your WLAN on the foreign controller?

Is this Anchor controller used for guest anchoring with your other controllers?

christopher.hod... Sun, 01/30/2011 - 15:10

Are you positive that you anchored your WLAN on the foreign controller? YES

Is this Anchor controller used for guest anchoring with your other controllers? YES

I read the Cisco doc and confirm eping and mping test the required ports.

Still...NOGO.....have a good night and I plan to respond with findings.

In my case this was the firewall. I had end-end IP connectivity, managed to establish mping successfully, but eping wasn't working. I had Data down between the anchors and the foreign WLCs. I had the 16666-7 capwap ports allowed back, but turned out I needed a rule returning for the snmp & protocol 97 traffic, despite having in on egress from the foreign side, they are needed on the anchor side as well for initiation, ie: it's bi-directional.

chris.van.krieken Thu, 05/12/2011 - 07:34

Facing the same issue here. Control Path up, Datapath down when Checkpoint firewall policy is pushed with SecureXL enabled.

What kind of firewalls are in between achor and foreign controller ?

Dave Lewis Fri, 10/21/2011 - 07:18

I know this post is old but I came across it when I was really stuck with the same issue and thought I'd share what resolved it for me.

So controller in DMZ (anchor) would not respond to eping from foreign controller. mping and icmp were fine.

ASA was the firewall.

Much packet tracing and frustration followed as the rule to allow IP protocol 97 was in the ACL for both the DMZ interface and the inside interface.

In my case the problem was that I had added the UDP CAPWAP rule into the ACL's first, this allowed the control path to come up. Unfortunately, because the mobility group keep-alive is set to 10 seconds it kept the flow up between the two WLC's on the ASA. Therefore when I added the ACE for IP 97 it wasn't reflected because there was an existing flow between the two.

So, solution for me was this on the firewall..

clear conn add x.x.x.x add y.y.y.y

...where x.x.x.x equals the management IP of your DMZ controller and y.y.y.y is the management IP of the foreign controller.

Once this was done I could then eping succesfully. So frustraing seeing the correct ACL's in place and traffic still not passing, still - it's a lesson learned for me!

Hope this helps someone else in a similar situation in future.


Ilya.Puzyrin Thu, 12/01/2011 - 02:26

Hi Dave,

I can confirm that likely you have found the proper solution (or workaround) for this issue. Yesterday we had the same issue with the mobility anchors whereas control path was up and data path was down and that was only applicable for random very selective controllers (whilst the others were fine) which didn't make sense at all.

Clearing the EoIP session on the firewall (Juniper in our case) has resolved the issue and restored data path.

Perhaps Adam has resolved this since then as well, however this forum is still very good for those who may experience the same.



karthikeyansrin... Mon, 07/21/2014 - 11:31


Head Shot Dave, Your fix worked like a Charm.

Irrespective of ASA , Juniper or Checkpoint, clearing the connections always seemed to help.



Steven Housego Wed, 04/13/2016 - 03:21

I can confirm this still works, stuck with 'Data Path Down' until we cleared the connections. Similar scenario running 8.0 with an Anchor in a DMZ behind an ASA.  Saved potentially hours of troubleshooting.

Ryan Bachand Fri, 08/26/2016 - 07:06

Thanks Dave! Spent hours troubleshooting this issue before coming across your post.

jjheck Sun, 10/23/2011 - 21:29

Also check the MAC addresses of the guest and anchor controllers.  The tunnel is established by the lower of the two MAC addresses.  We had an issue where one of our internal controllers was lower than the anchor controller and we had to tweak our Palo Alto firewall to get the packets to pass and not get dropped by the FW. 

nickeoannidis Wed, 04/18/2012 - 09:37

Hi All,

Im having the same issue i have 10 controllers and 1 anchor mix of 4400 series and 5508's. All running and Anchor is on

Randomly data path goes down for x controller. If i reboot the anchor controller - all controllers data and control paths come up.

Anchor sits behind ASA 5520 on 8.4, i have ip any rule from the addresses of the foreigns to the anchor controller. Return traffic is permitted. Can't see any issue with ACL logic as the control and data path does work, at least for a time for some controllers. Should i change this to permit UDP CAPWAP first then IP Protocol 97 in a second rule?

I tried using the clear conn to see if it would come back when the data path is down for a specific controller, no cigar.

Scott Fella Mon, 03/04/2013 - 08:43

You need to be able to eping from the guest anchor to both internal.  That is Ethernet over ip 97 and it seems like the FW is blocking that.  I would open the FW rule to allow everything between the guest anchor and the two foreign WLC's for now.



Help out other by using the rating system and marking answered questions as "Answered"

powys Mon, 03/04/2013 - 08:40

We've discovered that we're having the same issue here. Three 5508 controllers, 2 internal (WLC-01 and WLC-02) and 1 anchor in the DMZ (WLC-03). If an access point runs from WLC-01 it's fine, but if on WLC-02 the guest wifi fails.

WLC-01 can see WLC-02 and WLC-03

WLC-02 can see WLC-01, link to the anchor (WLC-03) is "Data path down"

WLC-03 can see WLC-01, link to WLC-02 is "Data path down"

mping works from any WLC to any other.

eping does not work between WLC-02 and WLC-03 (anchor) in either direction.

The firewall (a WatchGuard Firebox X750e, firmware 11.3.4) is set to allow any IP traffic between the three controllers.

According to jjheck's post above the mobility links will be set up as follows, I don't know if that's a clue as to why it's misbehaving:-

Primary WLC-01 (MAC starting 50:3d:e5:ae) will establish the link to WLC-02 and WLC-03)

Secondary WLC-02 (MAC starting 64:00:f1:f6) will not try to establish any links

Anchor WLC-03 (MAC starting 64:00:f1:f1) will establish the link to WLC-01

All three are running

The only differences between the running configs on WLC-01 and WLC-02 (apart from the pile of APs on WLC-01) are:-

Maximum number of APs supported.................. 200 (on WLC-01, 175 on WLC-02)

Cisco AP Default Master..................... Enabled (on WLC-01, Disable on WLC-02)

The whole lot was rebooted the weekend before last as we needed to shut down the server room for electrical work, but that made no difference.

Does anyone have any suggestions? We're scratching our heads here!

powys Mon, 03/04/2013 - 09:04

The firewall already has a rule set up that allows any IP traffic between the three WLCs. Basically all three WLCs appear in both the "from" and "to" columns.

We've also tried splitting the rule in two, with one allowing any IP from the anchor to the two foreign WLCs and the other allowing any IP from the foreign WLCs to the anchor. This made no difference.

Scott Fella Mon, 03/04/2013 - 09:17

Try to delete all the mobility info and re-creating them again.  Sometime that helps.



Help out other by using the rating system and marking answered questions as "Answered"

grabonlee Mon, 03/04/2013 - 09:21

As Scott mentioned if protocol 97 isn't allowed then the Data path will not come up. I will suggest that you explicitly allow protocol 97 and not just any IP. Also on your firewall you can do a source or destination search only using your WLC IP address to find out what traffic is dropped between the Anchor and Foreign controller. For example your search string could specify the source as the Foreign controller IP.

Dave Lewis Mon, 03/04/2013 - 13:35

As others have mentioned, please try explicitly allowing protocol 97, I don't know about Watchguards but see this post which explains that, in Cisco's world, allowing ip any any doesn't also allow 97/47,50 etc...

And this watchguard kb...


powys Wed, 03/13/2013 - 08:08

We've tried that, exactly the same. We now have four firewall rules relating to it:-

From anchor to WCS and both internal WLCs: ports 16666 to 16667

From WCS and both internal WLCs to anchor: ports 16666 to 16667

From anchor to WCS and both internal WLCs: IP protocol 97

From WCS and both internal WLCs to anchor: IP protocol 97

The "Any IP" rule between the internal WLCs, WCS and anchor WLC has been deleted.

It's weird how one WLC can see the anchor but the other (which sits alongside it) cannot.

Everything works except the data path between controller 2 and the  anchor (which would be the only link established from the anchor side according to the lowest-MAC-address rule,  the others being established by controller 1 which has the lowest address of the three).

grabonlee Fri, 03/15/2013 - 04:33

Hi Powys,

Firstly, UDP port 16667 is no longer supported and was deprecated since controller version 5 as the secure mode never worked. Not that enabling affects your control traffic any way. To resolve the problem of the second WLC, I would suggest that you look at the firewall logs to see if Protocol 97 traffic is actually passed between the Foreign and Anchor WLC.


This Discussion

Related Content



Trending Topics: Other Wireless Mobility

client could not be authenticated
Network Analysis Module (NAM) Products
Cisco 6500 nam
reason 440 driver failure
Cisco password cracker
Cisco Wireless mode