12-10-2013 08:50 AM - edited 07-04-2021 01:24 AM
Hi All
I'm using a Cisco 5760 with 3.3 code with a Cisco 2504 acting as an anchor. The 2504 is running 7.5 code and has 'New Mobility' (Converged Access) enabled.
I can't fine any reference to what ports are now used between the controllers. I'm assuming it's still UDP 5246/5247. I know EoIP isn't used with the new mobility.
Can anyone confirm the port requirements for new mobility please?
Regards
Roger
Solved! Go to Solution.
12-11-2013 10:13 AM
Hi Roger,
Thanks for that info. As per your observation what is the time delay when mobility tunnel is not coming up ? No documents talks about that kind of behaviour.
Regarding the mobility packet format, here is some snapshot of a slide from Ciscolive session I went.
HTH
Rasika
**** Pls rate all useful responses ****
12-10-2013 08:53 AM
Sorry - I meant ports UDP 16666/16667 are the normal ones. Can anyone confirm this is still the case for new mobility?
12-10-2013 10:01 AM
Per this document, it is only 5246/5247 CAPWAP ports in new-mobility
http://www.cisco.com/en/US/docs/wireless/controller/7.5/config_guide/b_cg75_chapter_010010101.html
"Interoperability between two types of mobility is not supported. When you downgrade the controller from Release 7.5 to a controller software release that does not support new mobility, such as Releases 7.4.100.0, 7.3.101.0, 7.2, 7.0, or earlier (all releases prior to 7.3.112.0), the controller automatically transits to flat mobility (old mobility). This is due to the difference in mobility architecture and noninteroperability between flat mobility (EOIP tunnels) and new mobility(CAPWAP tunnels). "
HTH,
Steve
------------------------------------------------------------------------------------------------
Please remember to rate useful posts, and mark questions as answered
12-10-2013 11:05 AM
Though it is CAPWAP instead of EoIP, UDP port numbers for inter-mobilty control is remains.
Here are the UDP ports:
• Control plane 16666 (always DTLS encrypted)
• Data plane 16667 (not encrypted and cannot be encrypted at FCS)
• MO listens on UDP port 16668
HTH
Rasika
**** Pls rate all useful responses ****
12-10-2013 11:28 AM
it sounds like it's all CAPWAP now, which I know was the goal.
but the difference is if you are using new-mobility or if you are using the 'old' method.
HTH,
Steve
------------------------------------------------------------------------------------------------
Please remember to rate useful posts, and mark questions as answered
12-10-2013 12:38 PM
Hi Steve,
I think bit of confusion here. Yes I agree everything is CAPWAP, but UDP port number is different depend on what type of communication it is.
As per my understanding UDP 5246 & 5247 used for WLC to AP communicaton. Not for WLC-WLC mobility communication. So still I belive UDP 16666/16667 uses for Control plane & data plane traffic between controllers.
Here is one of my 3850 mobility summary output confirming it is using 16666 as UDP port.
3850-1#show wireless mobility summary
Mobility Controller Summary:
Mobility Role : Mobility Controller
Mobility Protocol Port : 16666
Mobility Group Name : LTU-CA
Mobility Oracle IP Address : 0.0.0.0
DTLS Mode : Enabled
Mobility Domain ID for 802.11r : 0x34c9
Mobility Keepalive Interval : 10
Mobility Keepalive Count : 3
Mobility Control Message DSCP Value : 48
Mobility Domain Member Count : 1
HTH
Rasika
**** Pls rate all useful responses ****
12-10-2013 12:42 PM
Good to know!
I have been hearing that all the communication, even WLC - WLC is supposed to be moving to be all CAPWAP and getting rid of the 16666/166667 EOIP tunnel portions.
HTH,
Steve
------------------------------------------------------------------------------------------------
Please remember to rate useful posts, and mark questions as answered
12-11-2013 02:32 AM
For info guys I have monitored the mobility traffic between the 5760 and the 2504 using new mobility and its only using UDP 16666. Its definitely not using CAPWAP UDP 5246 and 5247 so the documentation is misleading in suggesting that mobility now uses CAPWAP tunnels.
A crucial element for the tunnel to be established is time. If the 2 controllers are too far apart in time the tunnel doesn't come up.
Regards
Roger
12-11-2013 10:13 AM
Hi Roger,
Thanks for that info. As per your observation what is the time delay when mobility tunnel is not coming up ? No documents talks about that kind of behaviour.
Regarding the mobility packet format, here is some snapshot of a slide from Ciscolive session I went.
HTH
Rasika
**** Pls rate all useful responses ****
12-13-2013 12:15 AM
Hi Rasika
Thanks for the scrren shot - exactly what I was looking for.
I don't know what time difference would cause the tunnel to fail.
I've seen this a few times now where the time on 1 of the controllers caused the tunnel to fail.
I normally just make sure both controllers are tied to an NTP server.
Regards
Roger
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide