you're right but WLC starts to have this kind of problems last Sunday (without any network change). We've never encountered connectivity problems before. If the problem reside in switchport configuration I think that we would have encountered this kind of problems at the beginning of the deployment.
If your not having any issues with the wireless, then you know it's a false alert. If the alert is stating that the WLC is down, then it's an issue with snmp which can be related to the FW or something else dropping that. If your not having issues with your others WLC's, then you know it's either the FW or PI. Since you mentioned the anchor WLC, that would tell me that it's your FW since your foreign WLC's are not getting that alert.
We cannot check if wireless have problems because currently we haven't any user who are using Guest SSID tunneled to DMZ. We've tried to delete WLC from PI and then adding it again. Now we are waiting for The same alarm. If this workaround solves The issue it's probably a PI bug.
Well I would test this by connecting to the guest network and monitoring them. If your mobility isn't not bouncing between the foreign and the anchors, them I don't think the anchors is the issue or else you would see the mobility go down. If your PI can manage your foreign WLC's and have issue with the anchors, it seems like the FW is dropping the connection. If it was an issue with PI, you would see the alerts on your foreign WLC's also.
Transferring Crash file from standby: Login to the Active WLC in HA.
From CLI: (Cisco Controller) >transfer upload datatype crash (Cisco
Controller) >transfer upload filename (Cisco
Controller) >transfer upload mode tftp (Cisco Controller) >transfer
This is the start of a display filter cross reference between Wireshark
and OmniPeek. The 1st installment is a table of advanced filters. More
filters will be added as time allows. It is a living doc, so check back
for changes every so often Please feel f...