Mobility Group Guidelines (5508 x 9800) | SSO and N+1 + VLAN

[joandwifi]

Hi Guys,
I have two questions and would like some help.
I currently have a WLC5508 Anchor in the DMZ for visiting users, which is part of the mobility group with an SSO-9800 (IRCM). That said, we have a project to add a Backup WLC, which would be part of N+1.
I would like to know if:
1 - For this configuration, would I really have to add the new WLC to the Mobility Group?
The current topology is:
WLC 5508 >> WLC9800_SSO (Mobility Group)

With the new configuration, it would be:
WLC 5508 >> WLC9800_SSO (Mobility Group)
WLC9800_SSO >> New_WLC9800 (Mobility Group)
WLC 5508 >> New_WLC9800 (Mobility Group)

In other words, the 3 WLCs would be in a group, but both would be talking to the 5508 that is in the WLC.

This configuration is standard, right?

2 - Another question is related to VLANs:
The customer wants to move the VLANs to the new WLC, and I have not found any recommendation from Cisco that points out the L2 problem that he will have in his environment (they are different locations).

Could you share your experience with this type of scenario? Or any link that makes a very clear observation of the risks of replicating the vlan on the WLC that is backed up in N+1?

[marce1000]

 - Because of the fact that the added controller is N+1 based it must be added to the mobility group. I have not yet studied the picture in detail but at least the Vlans from the defined WLANS must terninate on the  added controller too,

 M.

[joandwifi]

Perfect! Thank you very much @marce1000 !

My fear in this case would be to have some loop problem, with the VLANs in both locations.

Is there any documentation that informs me that I need to configure the AP, site, RF tags, etc.? The client's current configuration is default, without a group, without anything... I didn't want to change its production environment.

[marce1000 · Accepted solution]

 - In general I can only say that the configuration of  an N+1 controller must be identical, well mostly. For your concerns on RF , tags etc ; on each controller use the command :

  show tech wireless

 and feed the output from that into https://cway.cisco.com/wireless-config-analyzer/

 Note use the full command , it does not work with simple : show tech

 Keep using this procedure when making configuration changes on the 9800 controllers,

 M.

[joandwifi]

@marce1000 Sure! Very good, I believe that show tech wireless should be the same as show run commands, this makes it easier to build scripts, thank you very much!

[marce1000]

 Ok but WirelessAnalyzer only works with:

    show tech wireless

 M.

[Flavio Miranda]

Hi @joandwifi 

If I understood correctly your scenario you have an office in Sao Paulo with one pair of 9800 in SSO and one WLC 5800 in the DMZ for Guests.

Now, your customer have another office in Rio de Janeiro and they will have also a pair of 9800 in SSO and they will use the same 5500 in Sao Paulo for Guest? It that correct?

And both 9800 Cluster will be in N + 1 with each other.

I dont see the need to put all the WLC in the same groups although if you do it will have no impact. You may refer to the link below in order to check for the Mobility group function , requirements and limitations.

https://www.cisco.com/c/en/us/support/docs/wireless/4400-series-wireless-lan-controllers/107188-mobility-groups-faq.html#toc-hId-1363083985

About the Vlan question, it is unclear to me what it means to move the vlan. Does it means extend the vlan from one office to the other?  Do you have layer 2 connectivity between sites?

For Guest users in Rio, the users will connect to the Anchor in Sao Paulo and will get IP from there, supposing the DHCP for Guest is provided in the DMZ, which usually is.

[joandwifi]

Hey, Flavio, I apologize.

RJ x SP does not represent my reality.

In Rio de Janeiro, a real scenario, there would be a pair of 9800s (SSO) in downtown Rio de Janeiro, and a new 9800 WLC in Copacabana.

There is only one Anchor WLC (DMZ).

Regarding VLANs, yes, there is L2 communication between the sites, I really don't know if it is the best solution to load these VLANs, however, @marce1000  I said it would not be a problem. Thank you for your attention!

[Flavio Miranda]

About the Vlans, your customer could be looking to avoid work load like creating new rules on security tools like firewall or proxy. Using the same addressing could prevent this work loads.

The heads up you can give to you customer is related to vlans size, DHCP scope size, broadcast domain size, etc. It would be possible to accommodate all the users on those vlans in the event of the sites growth in the future?

[joandwifi]

Well scored! @Flavio Miranda 
I heard no in a meeting, but I will follow through with the recommendations, thank you very much!

[Leo Laohoo]

Mobility Tunnel + HA SSO.  No. Don't do it. 

The current quality of firmware situation with IOS-XE is really bad.  There are several memory leak/high CPU/CPU hog caused by the "wncd" &/or "wncmgrd" process.  Cisco TAC has "pin pointed" the cause to several combination such as:  

• Client roaming between AireOS to IOS-XE via the Mobility Tunnel (CSCwc22005)
• Number of APs exceed 50% of what the platform can do (example, more than 3000 APs on a 9800-80)
• Number of clients exceeding 50% of what the platform can do
• Web Authentication

And as an added bonus, because the two controllers are on HA SSO, please be aware of CSCwj73634.  The "Further Problem Description" information is incorrect:  The bug will hit regardless if/when the Redundancy Port (RP) is directly connected or otherwise.

[joandwifi]

Hello @Leo Laohoo  

Thank you master, however, we currently already have an SSO configuration. And we will have a hybrid HA, if the SSO goes down, all APs will be migrated to the WLC that is in another location. Unfortunately I can't change this.

[Leo Laohoo]

Understood.

At least, you've been "warned". 

Should some kind of "weirdness" happens, first thing to do is a "double-failover".  And if this stabilizes the WiFi then it is a sure sign HA SSO is causing the issue.  

We've done this workaround so many times that we tore apart all our HA SSO and turned them into N+1.