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.

o

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?

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.

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

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)

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

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?

from the WLC CLI mping and eping your anchor. If this doesnt work you need to check your ports

http://www.cisco.com/en/US/products/ps6366/products_tech_note09186a0080b1a506.shtml

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 10.48.27.182

Send count=3, Receive count=0 from 10.48.27.182

(Cisco Controller) >eping ?

Enter a mobility peer IP addr.

(Cisco Controller) >eping 10.48.27.182

Send count=3, Receive count=0 from 10.48.27.182

(Cisco Controller) >

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 ?

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.

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

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.