I don't know if this is related or not:
I have been working with Cisco TAC and they indicate that the following false alarm: "Disassociation Flood" alarm is due to a software bug that is to be fixed in the November timeframe (aka Concannon release):
"IDS Signature attack detected. Signature Type: Standard, Name: Disassoc flood, Description: Disassociation flood, Track: per-signature, Detecting AP Name"
What caught my attention to relate this to what you are describing is that the error/trap indicates that the supposed disassociation flood is coming from the radio MAC addresses of our own trusted APs being controlled by the WLC.
Bug is identified as CSCse70641
Externally found severe defect: Assigned (A) Problems with signatures in 4.0.155.0 Symptom:High number of 'Disassoc flood' and 'Broadcast Probe floo' alarms. In3.2 this is not showing up, for controllers on the same area The shorter mask of 4.0 seems to match additional frames resulting infalse positives Conditions: Between 3.2 and 4.0 versions, there are several changes on the standardsignature database. For 3.2, for example, signature 7 (Disassoc flood)was 0:0x00A0:0x03FF, on 4.0 now is 0:0:0x00A0:0x00FF Additionally thisdoes not matches the information present on the header of the signaturefile. If the byte stream is compared, for a disasociation flood, theframe starts with 0xA000, after applying either of the twomasks, results in 0, failing the verification. For the signature to becorrect, it a double byte swapping is needed, which is not documented orpresent.
The current workaround is as follows:
Workaround:
Disable signatures
To disable the signature file -
In the controller, go to 'Security' --> 'Wireless Protection Policies'
--> 'Standard Signatures' and click 'detail' on the far right of the
signature you wish to disable. You will see a 'State' check box, simply
uncheck and
hit apply. The signature will now show in a disabled state.
Hope this helps
