Hello All,
Opened a TAC case for the above issue. This is specific for customers who are using mobility anchoring solutions with their customers or partners.
Cisco created a bug ID for this issue and are currently investigating. Kindly note this is not specific to guest anchoring.
Why enable new Mobility ?
New mobility (CAPWAP) is required when Native wireless controllers have to establish a mobility tunnel to Cisco IOS controllers (5760, 3850 or 3650)
Background: We were using old mobility (EOIP) tunnels to offer wireless service at 3rd party sites that has foreign controllers.
There is no isse on old mobility.
Issue:
When new mobility is enabled (CAPWAP) we have to enter the public and private IP address for mobility tunnels to come up.
At the foreign controller end (both end NAT'ed IP not tested) , if the IP address is Nat'ed to public IP address, when the client try to connect the clients do not receive the IP address as they get stuck in DHCP_REQD state.
Work around:
1)This issue is not noticed if controllers at both ends are using Public IP address or only private IP address. The clients receive an IP address and works as desired.
2)Enable Old mobility (EOIP) if CAPWAP mobility is not mandatory.
Recommendation to Cisco wireless BU :
- It will be prudent to have an option in GUI to create an anchor tunnel for individual session/tunnel and have CAPWAP/EOIP option check box individually.
- Instead of enabling the New Mobility feature globally, it would be prudent to have an option to select (CAPWAP/EOIP) type based on the requirement.
Cheers,
Devaiah N K
