I've got 10.1.1 running in our lab, and one of the main things I'm testing is the WLC management capability.
I've hit a snag that a previously released PTF (10.01.017) doesn't seem to have fixed, although I may attempt a backup/re-install when time permits to prove this.
Main site has a WLC that controls all APs across the estate. By design, when you discover a WLC, all APs auto-discover as pingables in the same container. This is fine, as the app has no way of knowing what sites each AP or group therein applies to.
One then moves APs for site "B" into a site "B"'s container on the universe view. All is fine with the world until such time as the site has a power out or someone/something restarts the AP. As the AP gets it's address from DHCP, the original model goes red, and that AP then re-discovers back in the same container for site "A" alongside the WLC. PTF 10.01.017 should have fixed this but doesn't appear to have.
My query is this:
I need to deploy this monitoring solution for a customer that has around 180 or so sites, not all of them have APs but for the ones that do, they're all controlled by a WLC in the head office DC. When they have power outs etc. (which is frequent as they're construction material suppliers and there's a lot of brown-outs on some remote sites as they're quite off the beaten track) short of forcing our engineers to DHCP reserve every AP (and of course that only works on MAC address, so a like-for-like replacement should one fail will still have the problem of discovering in the wrong place with the old one still showing down) is there any other way that Spectrum can be told to check hostname/MAC etc. when it's "discovered" a new AP - which is essentially just an existing one on a different IP and to have it update the existing model WHATEVER the container, rather than just plopping it next to the WLC on the central site and marking the old one as down?
Did you raise a support ticket for the same?
I had a ticket 00358891 open to initial get and test the PTF but suspect it's been closed as the issue didn't crop up again for about a week.
I can re-submit but suspect it'll be "Fixed in 10.2"... :-)
Unfortunately I need to deploy it for the customer in the next 1-2 months.
Does this happen to AP that are modeled in the same container as the WLC? I didn’t think there was model correlation/relation requirement for the fix, but maybe this isn’t behaving the way it should be due to unexpected associations in the db by moving the AP. The PTF 10.01.017 does track mac address instead of just IP. We have other clients that have installed it and haven’t seen the issue again, however I’m not sure if they have moved the AP into another container. The only other caveat is that you MUST destroy both AP (the duplicate and the original) if you’ve already run into the problem and then install the patch. Sometimes it may be easier to destroy and remodel the WLC. If you’ve already done that, and can confirm that this only happens when moving the AP out of the container the WLC is in, then I would think we can look into that via your case.
DavidKGame it would be good idea to raise a support ticket so that team can investigate this further.
Unfortunately, the new Spectrum WLC Manager feature doesn't properly support management of access points which get management addresses by DHCP. New models are automatically created when an AP is discovered with a new IP address, which leads to alarmed model(s) with the previous IP addresses. It would be good if a solution becomes available.
And another thing. If there really is a PTF which fixes this issue, why are customers required to find this out later? I didn't see anything in the release notes related to this. If there was a fix, we could have installed it when we upgraded to r10.1.
PTF 10.01.017 is the patch which was released Post 10.1.
Rene has been posting the PTF patch information in the communities:
Spectrum 10.1.1 Patch List<https://communities.ca.com/docs/DOC-231165553>
Spectrum 10.1.0 Patch List<https://communities.ca.com/docs/DOC-231165309>
seeLet users subscribe to a "known issues" mailing list ;-)
We are currently reviewing this and will soon come out with a solution. Will keep the community posted.