Cisco has introduced a new term called “new mobility” in their new “Converged Access” design for enterprise WLAN. Primarily this will change the protocol used for Mobility Tunnel between WLCs. In the current “Centralized Controller” design they used EoIP (Ethernet over IP) protocol for this and under latest “Converged Access” design they have changed this to CAPWAP.
CAPWAP has advantage as it can do fragmentation & re-assembly within protocol itself.
Why should I care about this today ? If your network have mixed of controllers models all of them need to talk to each other on same protocol (only option is CAPWAP as new controller only can do that). Unless your old controller configured for this “new mobility” you may encounter mobility issues if you are implementing new C3850 or CT5760 Wireless LAN controllers in your existing network (which consists of 5508, WiSM2, 2504).
Only option is you have to use WLC software code for existing controllers which support this new mobility feature. Sounds like not a big issue. But as at today this new mobility feature only supports on 7.3 MR1 release. So if you are operating any software code prior to that you can upgrade it to this & use this feature. But if you are already in 7.4 (like me 😦 ), yes you have to wait till Cisco release a new version to support this “new mobility” feature before bringing this 3850/5760 onto your network.
Another thing you need to understand is, this IOS based WLC software 8.x is only supports for new (Converged Access) CT5760 & 3850 controllers only. Cisco has no intention to bring these to existing controllers (5508, WiSM2, 2504). They will keep existing software train 7.x for these model until they retire these products.
Therefore interoperability between new WLC (3850/5760) & existing controller (5508/WiSM2/2504) will play a key role when designing wireless LAN solutions in coming days. If it is a green field deployment there should not be an issue of design it for “Converged Access” model.
Correction@27th July 2014
As you may already know AireOS 8.0 software code will be released in coming weeks. It is the next major software version for AireOS controllers (eg. 5508,2504, WiSM2,7500,8500). The information posted in my original post (dated 2013 March) was not accurate on this regard saying it will not suport AireOS controllers. In fact Cisco will not discontinue their CUWN product line for a foreseeable future. Converged Access products line (5760,3850,3650) will use IOS-XE releases where 3.6 is the latest as of today.
Thanks for @wirelessguru for highlighting this error.
mrn-cciew 
Hi Rasika,
I am regular follower of your posts and i love this blog so much i keep on waiting for your next post.
Thank you for this post.
I have a request for you, please create a post on what is converged access as i am very confused about what exactly is converged access and its benifits.
PLease show a configuration example on how to build new mobility between two 5508 running code 7.5.102.0 which supports new mobility.
Thank you in advance.
Hi Mander,
Thank you for the feedback.
I really like to do what you requested.. will post here when I do this..should not be taking too long for this
HTH
Rasika
Very interested to see how Cisco handles these interoperability issues. My DMZ anchor controllers are 5508 running 7.4.115.0 and I have a pair of new 5760s that I need to make mobility peers.
Hi Anthony,
At the moment your only choice is upgrade 5508 to 7.6.110.0 (as 7.4 is not supporting new mobility & other software codes are deffered by Cisco) & then enable new mobility on your 5508. Then you should be able to have peering between 5508 & 5760
HTH
Rasika
Hello Rasika;
Thank you very much for creating this blog which I found very useful and clear than other documents that I have found on the WEB including Cisco documentation.
I am working on a site that have already WISM and 5508 controllers installed but we are adding a new 5760. My understanding is the old architecture and the new converged architecture don’t mix. I am planning to use a 5760 and 5760HA, no 3850 controllers, I was wondering if you have any documentation on how to configured the 5760 including the WLANs.
Again, I want to thank you for your input and look forward to read your response.
Sincerely;
Juan
Hi Juan,
Here is a starting point
http://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/5700/software/release/ios_xe_33/5760_IOS_WLC_Configuration_Best_Practices.html#pgfId-44790
I have done couple of post on 5760 configuration (if you look for 5760 category you will find them) which may helpful to you as well.
HTH
Rasika
Hi Rasika;
I really, really appreciate your fast response and the information and service that you provide on this blog, the information that you have provided me will get me started on configuring the 5760 as Mobile centralize controller, at this time we don’t have 3850 switches so all APs will be associating to the 5760 controller.
Thanks again and have a wonderful day;
Juan
Hi Juan,
Below blog posts may help you as it does not include 3850 as MA
1. https://mrncciew.com/2013/12/12/getting-started-with-5760/
2. https://mrncciew.com/2013/12/16/5760-in-ca-cuwn/
3. https://mrncciew.com/2013/12/16/configuring-radius-on-5760/
HTH
Rasika
Thank you very much, you are truly a great help. you are correct the three blogs will get me started. One quick question, do you have a sample configuration that includes the dynamic “user” VLANs in the 5760? I was wondering if I need to configure an SVI and an IP address in the 5760 for each User VLAN and how will I group the different interfaces under one group, I am familiar how to do this in a 5508 running AirOs but I am not familiar with the CLI syntax in the 5760.
Thanks again Rasika;
Juan
Hi Juan,
You do not want to configure each user vlan SVI on 5760 (only management SVI is enough). You have to configure “dhcp snooping” for user vlans on your 5760 for them to get IP.
I will do a post on interface group (called vlan group in this new IOS configs) within 1-2 weeks time. Hope that would be useful to you
Regards
Rasika
Thank you Rasika and I’ll look forward to your new IOS config.
Hi Juan,
As promised here is how you can map multiple subnets to a WLAN on your 5760/3850
https://mrncciew.com/2014/07/30/vlan-groups-in-57603850/
HTH
Rasika
Thank you Rasika, as always your information is very valuable. One question on your configuration , if I am using only 5760 and no 3850 switches what interface or PO needs the trust configuration for dhcp snooping (i.e. ip dhcp snooping trust)?
Another question on connectivity between the 5760 and nexus switches, do you see any advantage of using VPc to the 5760?
Thanks;
Juan
In your case I would assume there would be one Port Channel from 5760 to your wired network. So you have to trust dhcp snooping on that port channel & its physical interfaces.
I am not so familiar with Nexus/vPC, so could not advice on that ;(
HTH
Rasika
Thank you Rasika. Have a great day.
Hi Rasika,
I am working on a wireless re-design project and would appreciate if you could give me some advice. I am having two sites (each site with 3 AP’s but expected to grow in near future) connected each other and have a single 2504 controller and 2 x 3850 switches. Its definite that I need to use 3850 for providing POE connectivity to AP’s. I know 3850 can act as the controller but just curious to know the difference in wireless capabilities between 3850 and 2504. Is it best to use 3850 as MA and leave the controller functions to 2504 or let the 3850 do all the controller functions and not to use 2504 at all? What do you reckon?
Thanks,
Devan
HI Devan,
I would suggest you to start 2504 use as WLC & 3850 initially use as a switch.
Once you familiar with that configuration & later on you can enable WLC functionality on a 3850.
3850 MA/MC deployment works ok (I have limited deployment in my production). but that is lack of validated design guides & compare to 2504/5508, it is bit hard to troubleshoot. So not many people doing it at the moment,
But if you want to learn, then you can go for it, but as I said earlier, first make sure you familiar with CUWN (2504/5508) architecture, before jump into 3850 as WLC.
HTH
Rasika
Thanks Rasika. I am already familiar with CUWN architecture and has deployed 5508 in 5 different countries. This is a small deployment and i have spare 2504 to use if needed. Also, have the luxury to use 3850 as a WLC too. So i was a little perplexed on to decide which one to use. I support your point of not having enough design/ deployment guides for 3850. Also, i have tried searching internet to see the feature comparison between 3850 and 2504/ 5508 but was unable to find any.
I will go with 2504 as the central controller and use Flex-connect for internet access.
Thanks & Regards,
devan
I have Exisitng 5508 Anchor WLC with 7.4 code, which is serving guest for multiple sites. One new site got 5760WLC with 3.6 code. This site also needs to use guest access via 5508 WLC in DMZ. Looks like EOIP option wont work, and need to go wtih New mobility option. For that need to Upgrade Anchor WLC code to 7.6 code, would like to know, if we upgrade to 7.6, still we can maintain peering with other remote sites?
New mobility between Anchor and New 5760 WLC is fine, what will happen to other connections with remote WLCs (Remote WLCs are 2504 and 5508)
Can you please suggest here.
Hi Rajesh,
If you upgrade to 7.6 & enable “new mobility” all existing tunnel will broken with 5508/2504 foreign WLC. So you have to upgrade all your foreign 5508/2504 & enable “new mobility”.
HTH
Rasika
Thanks a lot for your quick response Rasika..
Hi Rasika,
Thanks for your blog. it gives clear explanation about the new mobility.
I have one question regarding the configuration. i have two controller models. one 5508 and 0ne 7500.Both are running same 7.6 version. since 7500 wlc is not support new mobility, if i enable new mobility in 5508 and roam which protocol will take the action. EOIP or CAPWAP?
Thanks
Rama
Hi Rama
If you enable new mobility then that WLC will use CAPWAP for inter-controller mobility communication.
In your case if you want 7500 & 5508 to be in same mobility group, then leave them on “old mobility”. If you enable new mobility on 5508, you won’t able to peer it with 7500.
HTH
Rasika
Thanks for your information.Rasika
Hi, Currently my compay is running on 5508 (version 8.0.115.0) and is going to build a new building extension which is going to run on a 5520 (version 8.1) controller “new” AP. Is there a need to configure new mobility on the 5508 only for the roaming between the builing? Or the new mobility only apply to IOS XE controllers like 5760 and 3850? Many thanks.
Hi Jay,
You do not want to configure new mobility in this case. It is mandatory when you set up peering between AireOS controller with IOS-XE controller.
HTH
Rasika
Hi Rasika, I used your material to bring up one of the small office wlan on converged wireless with 3850 – successfully deployed but not very easy and quite difficult while TSHOOTing wireless. I hope to see great improvements over next years converged wireless solution deployment. Thanks a lot, your work is impeccable, helped me to learn new
Now I’m working on quite strange wireless setup.
The building is setup with 5508 wireless LAN controllers (3x) and also 4404 WLC (1x) presently all 4 are EoIP mobility group’d.
With in the building part of area has been rebuild and project proposal is to implement 5760 WLCs (2x) along with existing 5508 WLCs
The new 5760 WLCs are also implemented on separate L3 Cisco LAN environment
This means new 5760 WLCs fully work on same SSID’s as 5508 however, with new IP subnets
Roaming across the users is a requirement
My first steps are to replace 4404 with 5508 WLC & also
Upgrade 5508 WLC to support new mobility function
Question:
Same SSID with different IP subnet across 5508/5760 attaining roaming can this be feasible setup to achieve?
-Santhosh
My advise is not to mix AireOS & IOS based controllers. Stick with one design, 5520/8540 are there for AireOS, if you looking scalability.
What is the logic behind deploying 5760 ? Do you have any 3850/3650 acting as MAs ?
Rasika
Hi Rasika
I`m not really impressed with the converged access since it really complicates your management plane since all the configuration for SSID,Radius,APs,interface group are done on the MA and not the MC and with a deployement of over 100 MA ..well it will be hectic …trues Cisco PI is one solution but personally I`m not a big fan of it
Quick question: For Anchor Controller I can`t leverage the Oracle feature on my central MC and instead of pointing every single MA to the anchor controller I just leverage the tunnel between my exisiting MC and the anchor controller?
Thanks
I agree with you on CA capability issues you mentioned.
For Anchoring, it should be MC to Guest Anchor, not from MA to Guest Anchor.
So if you already have MC to Guest Anchor mobility tunnel establish, no additional peering required.
HTH
Rasika
Hi Rasika,
I really would like to know if EoIP tunnel is cryptografed for the data traffic between anchor and foreign controller using the old mobility feature.
I would like to know too if i change to the new mobility feature if is going to encrypt this traffic.
I am having some issues with one controller working with new mobility and all the traffic passing normally throught the firewall to the anchor with new mobility feature enabled too, and i have another environment with old mobility passing throught the same firewall andi am having issues with the fragmentation between anchor and foreign and it is not happening using the new mobility feature.
Thank You and sorry to extend my problem to this excelent forum.
Do you have some packet capture to see exactly what’s going on with EoIP (old mobility setup). I found below information from a old bug ID (CSCsm05607) , worth to check you see similar behavior
“When a WLC has a 1500 byte user IP packet to send into an EoIP
tunnel, it fragments it into two outer IP fragments, and sets the DF
bit on the first fragment. If the first fragment is too big to make it
to the other end of the EoIP tunnel without refragmenting, the
intermediate router will send back a “DF set but fragmentation needed”
ICMP error.
When the WLC receives this ICMP error, it is supposed to learn
the smaller path MTU and reduce its outbound MTU on subsequent
transmissions. This is called Path MTU Discovery and is
documented in RFC 1191.
However, the WLC does not actually support PMTUD. Therefore it fails
to reduce its outbound MTU. As a result, 1500 byte user data
packets can never get through the tunnel.”
HTH
Rasika