WCS Alarms - Disassociated AP's

I've just installed WCS for the first time and have been configuring the email alerts/alarms. I left the default settings of Critical alerts only but find I am getting spammed.
Now, I want to be alerted when an AP goes offline, but I've found that quite a few of the AP's seem to momentarily loose connectivity on one if not both radio interfaces - and then immediately come back up.
This results in 2 email alerts almost simultaneously - one telling me the AP interface has shut down and disassociated from the controller, and then immediately after another email telling me the previous message has been cleared and the AP has re-associated with the controller. It doesn't appear to be specific AP's but random ones throughout the day.
So 2 questions:
1 - Is this normal behavior for access points and if not, what could be causing it?
2 - Is there any way to set a threshold on the length of time an AP is down before receiving an email alert from WCS?
WCS - 5.2 (the latest build)
WLCs - 4404 with 5.1.151.0
APs - 1131AG
Thanks in advance.
Rob

I have TAC Case opened for very similar issue.
WCS 5.2.130
WiSM 5.2.178
APs 1252
1st part was that my WiSMs were not set up...the 1st Octet of the Service Port must be different than Manager and AP Manager interfaces. It is actually in a doc -- it ignores the subnet masks!
After I changed that (requires WLC reboot) my messages went down quite a bit. But there is a 2nd part ... not sure if it affects 1131s. I was told that there is a bug in the Marvell chipset. They have a fix in beta and it is going through regression testing. Hopefully out in next release by end of May. So my case is in "Release Pending" status waiting for the fix to be released.
Hope this helps...

Similar Messages

  • WCS Alarms - Configuring Thresholds

    I am using 6.0.181.0
    I want to understand what the thresholds are for WCS alarm severity levels. For example, I received an alarm indicating it was low on disk space "did not meet the requirements", but I want to know whether I can adjust these thresholds? I know I can adjust them from Critical to Major etc. but I can not see anything that enables me to quantify these severity levels.
    Can anyone help?
    Regards
    Andrew

    This is not a user customizable setting, and there is no control in any version of WCS to
    turn that alarm off.  The best you can do is lower the level of the alarm. 
    The free disk space alert an be deleted without issue.
    I believe the error message indicates the required available space such as:
    WCS 'x.x.x.x' does not meet the minimum hardware requirements for disk space.
    Available: '14'GB. Minimum requirement: '30'GB.
    E-mail will be suppressed up to 30 minutes for these alarms.

  • WCS Alarm Status shows green but LAP is unplugged ?! Oper Staus shows Down

    Hello,
    we are operating a Cisco WLAN environment with 1242 and 1131 LAP. Some of them have been converted from AP to LAP.
    Now we took some LAP off the wall.
    They are now packed in a box in our storage room.
    But the WCS is showing a green Alarm Status for these LAP and as Oper Status Down.
    How can that be ?
    Is there a way to fix this problem, because we want to see the Alarm Status in Red.
    Thx for all your input.
    Best Regards
    Christian

    This is very interesting. If I try to put myself in the WCS developer's shoes, I think:
    - if you get an alarm for missing AP, then acknowledge the alarm, WCS has no reason to re-display the same alarm. This is precisely what Acknowledge is for, to say "don't bother me with this issue anymore".
    - Even if you manually remove the AP from WCS, it clearly keeps some memory of it, at least for a while. This is something you can clearly see if you run a report of any kind, WCS has to keep track of objects even if you remove them.
    My suggestion would be:
    - Unacknowledge the alarm, then delete it... acknowledging an alarm is probably not the best way to deal with removing an AP. You would use Aknowledge for alarms such as "your neighbour AP keep being detected as rogue, you can't remove your neighbour AP but don't want to hear about this warning anymore." You acknowledge the alarm, WCS keeps it in its database and remembers NOT to bother you with it anymore (exactly what happens in your case).
    For an AP you remove, I would not acknowledge the alarm, but simply delete it after having removed the AP. This removes the alarm from the WCS database.
    If you ever re-plug this AP to the network, WCS may remember it, but any new alarm about it will display.
    Hope it helps
    Jerome

  • WCS Alarms

    Hi ,
    Iam getting continueous alarm message on my WCS Server..
    The messeges are "  IDS 'NetStumbler generic' Signature attack cleared on AP " and " AP Impersonation " both are says critical alarms.
    Please help me on how to resolve this alarms to stop generating.
    Thanks & Regds,
    Lalit

    Hello,
    Do a search in this document for netstumbler for an explanation of the IDS signature causing this alarm:
    http://www.cisco.com/en/US/docs/wireless/controller/5.0/configuration/guide/c5sol.html
    The AP impersonation alarm is triggered by an snmp trap sent by the WLC. The trap sent is:
    bsnAPImpersonationDetected.
    This happens when a radio of an authenticated access point has heard from another
    access point whose MAC address neither matches that of a rogue nor is it an authenticated
    neighbor of the detecting access point.
    On aggressive environments, a helpful feature is to enable access point authentication with
    a threshold of 2. This enables you to detect possible AP impersonation and minimize false
    positive detections.
    This is how to configure it from the CLI of the Wireless Lan Controller (WLC):
    config wps ap-authentication enable
    config wps ap-authentication threshold 2
    Finally, you can change the severity of the AP impersonation alarm in WCS from critical to
    lower so you are not alerted. This can be done from Administration > Settings > Severity Configuration.

  • WCS Report - Disassociated APs

    Is it possible to run a report containing all Disassociated APs? I tried all the Device reports in the report launch pad and they only report on associated APs. I can obviosly view them in Monitor/Access Points but I cannot report on them. Any help would be greatly appreciated! I wouldnt even mind if I had to run a report on ALL AP's and just filter out Disassociated APs in Excel.
    Thanks,
    Phil

    Never mind - I figured it out.
    Report Launch Pad - Device - Inventory
    Report Type - AP
    Customize - Custome Report name - Disassociated APs
    Thanks Phil!

  • Interference violation detected shown in WCS Alarm

    Hi Cisco Support,
    /* Style Definitions */
    table.MsoNormalTable
    {mso-style-name:"Table Normal";
    mso-tstyle-rowband-size:0;
    mso-tstyle-colband-size:0;
    mso-style-noshow:yes;
    mso-style-parent:"";
    mso-padding-alt:0in 5.4pt 0in 5.4pt;
    mso-para-margin:0in;
    mso-para-margin-bottom:.0001pt;
    mso-pagination:widow-orphan;
    font-size:10.0pt;
    font-family:"Times New Roman";
    mso-ansi-language:#0400;
    mso-fareast-language:#0400;
    mso-bidi-language:#0400;}
    Question 1: When we tried to set the Load threshold “Max Clients” from value 18 to 20, we receive this error:
    /* Style Definitions */
    table.MsoNormalTable
    {mso-style-name:"Table Normal";
    mso-tstyle-rowband-size:0;
    mso-tstyle-colband-size:0;
    mso-style-noshow:yes;
    mso-style-parent:"";
    mso-padding-alt:0in 5.4pt 0in 5.4pt;
    mso-para-margin:0in;
    mso-para-margin-bottom:.0001pt;
    mso-pagination:widow-orphan;
    font-size:10.0pt;
    font-family:"Times New Roman";
    mso-ansi-language:#0400;
    mso-fareast-language:#0400;
    mso-bidi-language:#0400;}
    Do we need to disable the wireless network 802.11b/g before we can set it? Will ALL the APs be rebooted?
    Question 2: For the interference threshold, we need to set it higher than the default value 10 in order for avoid interference violation messages from WCS?
    Question 3: When we receive the interference violation from WCS, it does not indicate any interference value, how can we determine it’s value in order for us to decide the interference threshold value we can set to avoid interference violation messages from WCS?
    v\:* {behavior:url(#default#VML);}
    o\:* {behavior:url(#default#VML);}
    w\:* {behavior:url(#default#VML);}
    .shape {behavior:url(#default#VML);}
    /* Style Definitions */
    table.MsoNormalTable
    {mso-style-name:"Table Normal";
    mso-tstyle-rowband-size:0;
    mso-tstyle-colband-size:0;
    mso-style-noshow:yes;
    mso-style-parent:"";
    mso-padding-alt:0in 5.4pt 0in 5.4pt;
    mso-para-margin:0in;
    mso-para-margin-bottom:.0001pt;
    mso-pagination:widow-orphan;
    font-size:10.0pt;
    font-family:"Times New Roman";
    mso-ansi-language:#0400;
    mso-fareast-language:#0400;
    mso-bidi-language:#0400;}
    /* Style Definitions */
    table.MsoNormalTable
    {mso-style-name:"Table Normal";
    mso-tstyle-rowband-size:0;
    mso-tstyle-colband-size:0;
    mso-style-noshow:yes;
    mso-style-parent:"";
    mso-padding-alt:0in 5.4pt 0in 5.4pt;
    mso-para-margin:0in;
    mso-para-margin-bottom:.0001pt;
    mso-pagination:widow-orphan;
    font-size:10.0pt;
    font-family:"Times New Roman";
    mso-ansi-language:#0400;
    mso-fareast-language:#0400;
    mso-bidi-language:#0400;}
    Please help to advice on this. Thank You.
    Junhan

    Hi,
    1) Yes you need to disable the network b/g. That does not reboot the APs  at all. It just brings the radios down (disconnect all clients) obviously. When you bring network up, network is up in a matter of seconds (maybe less)
    2) Yes. But it's just to lower the amount of messages you see. The level of interference you have on your network stays the same. You are just less alerted.
    3) Go on monitor-> AP and find out the AP who reported the alert. The interference level should be indicated.
    Hope this helps.
    Nicolas
    ===
    Don't forget to rate answers that you find useful

  • WCS Alarms reporting lost keepalive messages

    Starting a few days ago, two of my WISM-based controllers generated this message: "Keepalive messages are lost between Controller 'xx.xx.xxx.xx'and Master.Please check the controllers port configuration,any software or hardware
    incompatibility issues."
    My question is what is considered the "Master?", What it is referring to? The only Master I know of within the context of the WISM is when you set up a Master Controller for configuration purposes, but this is something that I have NOT done and it is in fact, disabled.

    got same problem, did you get a resolve?

  • Ambiguous WCS Critical Alert Message .... HELP!!!

    I have received this alert in WCS for a couple days now and I don't know what's triggering this ... especially because the reason says its unknown ... so I was wondering if anyone has seen this before and if you had any idea how this is triggered ... this is important to me because a radio keeps getting disabled which causes clients to drop which isn't a good thing in a hosptial environment.
    This is the email that I keep receiving ...
    Subject: WCS Alarm: AP, severity Critical
    WCS has detected one or more alarms of category AP and severity Critical in
    Virtual Domain root for the following items:
    802.11a interface of AP AP1-06 is down: Controller 10.0.10.3 Reason:
    Unknown.

    Hi there, did you manage to get a resolve?
    I have the same problem, and I read that I should upgrade the WiSM controller software to 6.0.188.
    Also getting similar anoying traps "
    /* Style Definitions */
    table.MsoNormalTable
    {mso-style-name:"Table Normal";
    mso-tstyle-rowband-size:0;
    mso-tstyle-colband-size:0;
    mso-style-noshow:yes;
    mso-style-priority:99;
    mso-style-qformat:yes;
    mso-style-parent:"";
    mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
    mso-para-margin:0cm;
    mso-para-margin-bottom:.0001pt;
    mso-pagination:widow-orphan;
    font-size:11.0pt;
    font-family:"Calibri","sans-serif";
    mso-ascii-font-family:Calibri;
    mso-ascii-theme-font:minor-latin;
    mso-fareast-font-family:"Times New Roman";
    mso-fareast-theme-font:minor-fareast;
    mso-hansi-font-family:Calibri;
    mso-hansi-theme-font:minor-latin;
    mso-bidi-font-family:"Times New Roman";
    mso-bidi-theme-font:minor-bidi;}
    802.11b/g interface of AP C4C4w26P4 is down: Controller 10.105.1.35 Reason: Unknown."
    Cheers

  • Disassoc flood - false alarms - IDS signature file needs adjustment

    Another interesting observation regarding Disassociation flood wireless IDS alarms:
    When a wireless client goes out of range of an AP, is that it is not uncommon for a burst of 64 disassociation frames to be sent in order to ensure that the client/AP are no longer associated.
    However, the threshold in the WLC's IDS signature file is 50. It is unclear why this value was chosen by the developers. However, at Cisco's recommendation, we have adjusted the signature file to a value of FREQ=80 (instead of 50) for the following alarms:
    Disassociation, Deauth Flood, and Bcast Deauth
    This has resulted in fewer false alarms (except for Bcast deaut which is the result of the WLC alarming on its own containment messages - see previous thread!).
    Additional Note: When making changes to the IDS signature file, it would appear that a REBOOT ended up being necessary in our case in order to get the WLCs to recognize the changes to the IDS signature file. When we merely upgraded the signature file, it did not make a difference.
    Also, it would appear that the name of the signature file is important (since the parsing of the file does not take place unless a specific file name is given).
    - John

    Hi,
    I'm getting a lot of false positive rogue APs (I've checked the MAC addresses and they are definitely ours), is it possible that a similar problem with signatures is causing this?
    Scott

  • LWAPP Rogue AP report

    Hi
    In my WCS, I see hundreds of rogue AP. Most of them are my AP also controled by my WiSMs. Wy does I get rogue report for them? The radio mac of the rogue report is usualy one digit higher then the base mac of the AP

    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

  • POE from 3524PWR Switch for 1130AG AP?

    We have a bunch of 1130AG LWAPP access points that we are installing in various locations. Those locations with newer 802.3af switches such as the 3750's and 3560's power the AP's without issue. However we have mixed results plugging them in to older Cisco POE only 3524PWR Switches.
    For the most part if we plug the 1130AG's into the 3524PWR's with short patch cords they power the radios up. However, if we connect them to a longer network line (80 to 100 feet) they disable the radios and WCS alarms tell me that the switch could not supply enough power for the radios.
    The Quick Start Guide (page 14) shows the 1130AG supporting both Cisco POE and 802.3af power. Is there any way to get these to reliable power up on 3524PWR switches or do I need to use power cords or power injectors?

    Hi Jim,
    We had this happen to us due to the same PoE problem. The 1130 requires either IEEE 802.3af power **or needs a setting on the WLC for using power injector or Cisco Pre-Standard PoE. Our older switches could only provide Cisco Pre-Standard PoE so we had to tweak the WLC Power setting for these AP's. Once we did that the Radios came right up. Here is a reference;
    You may have to enter the following info in the WLC;
    While the AP boots, with its Intelligent Power Management feature, it negotiates with the switch via Cisco Discovery Protocol messages in order to provide the necessary power to the AP. Even though the power injector is connected to the AP, the AP that uses this Intelligent Power Management feature gives priority to the Cisco Discovery Protocol information in order to identify whether or not the switch can provide the power. Therefore, after the Cisco Discovery Protocol message shows that the switch does not provide sufficient power (since it is not an inline power capable switch), the AP disables its radios. At this time, the status LED of the AP turns orange and this error message is recorded:
    [ERROR] : AP has not enough in-line power
    to enable radio slot 1 In order to overcome this problem, issue the
    config ap power injector enable installed
    command on the controller that is connected with this AP. This command is available from controller version 3.2.116.21. Ensure that you use the correct version in the controller.
    This command specifies that a power injector is used in order to supply sufficient power to the AP.
    From this doc;
    Cisco Aironet and WLAN Controller Product Power Options
    http://www.cisco.com/en/US/products/hw/wireless/ps430/products_tech_note09186a00800946e7.shtml
    Hope this helps!
    Rob

  • WCS IDS False Alarms - NetStumbler Generic Attack

    We have a particular installation where we are seeing four (4) types of IDS errors constantly reappearing:
    "IDS Signature attack detected. Signature Type: Standard"
    "Disassoc flood, Description: Disassociation flood
    "AP impersonation"
    "NetStumbler Generic Attack"
    In the first three alarms, Cisco has acknowledged that there are known issues with false IDS alarms that are supposed to be fixed in an upcoming "BE-MR2" in mid-December, and a new IDS signature in January.
    Is anyone else experiencing the NetStumbler Generic IDS alarm? We see them on a regular basis.
    If so, please reply - as I would like to forward this on to TAC to make sure they get this fixed in the next release.
    We are using WLC-4.x and WCS 4.x with LAP-1131AG access points.
    - John

    The Disassociation attack is a known bug acknowledged by Cisco TAC. (That is not a guarantee that it is a false alarm - that is what has been especially frustrating in troubleshooting these).
    Specifically, though, I am trying to confirm that others are experiencing the NetStumbler attack as we suspect this is another false alarm since it came from the MAC address of a trusted laptop that was confirmed to not be running NetStumbler - and, yes, I realize that the MAC address can be spoofed, but with the high number of false positives on the other types of alarms mentioned earlier, it would seem more likely that the WLC's IDS subsystem needs tweaking.
    I would really like to get this fixed within the next release, and am hoping that additional confirmation may help get Cisco to resolve it more quickly.
    - John

  • WCS displays Access Point as disassociated but WLC shows as associated

    Hi all,
    I have a WCS ver 7.0.172, a 5508 WLAN Controller with ver 7.0.116.0. At this WLC 21 Access Points (AIR-LAP1131AG-E-K9 ) were associated. As well I have one CleanAir Access Point (AIR-CAP3502E-E-K9) is associated.
    And now ... my problem:
    every time the WCS got a critical error and reports that the AP is disassociated from Controller. But if I take a look to the WLC the AP is associated and works at local mode and have two clients associated.
    I cleared the alarm - a few minutes later the alarm will be reported again. Same result if I delete the alarm.
    Could anybody give support for that issue.
    Thanks and regards
    Holger

    Hi Holgerseiler,
    Have you got any information/solution on this issue?
    I also have same kind of issue. I have a WCS with version 7.0.172.0, and around 25 WLCs (version7.0.116.0, in which i checked) and totally around 1000 APs are assiociated in wireless network.
    Some error messages are coming on my WCS device like
    "AP disassociated from Controller [ip]"
    Here AP name and WLC ip address will change randomly, but there is no impact on my network.
    Thanks in advance
    Sangeeth BS

  • WCS 4.1.83.0 alarm dashboard not updating security issues

    Hello,
    Not sure if the topic title made much sense but basically what is happening is this:
    I just finished getting 4.1.83.0 installed on a fresh server with no backup restorations. My 4404 WLC's (x2) are on version 4.1.171.0.
    I have been receiving an influx of WPA MIC errors on both controllers, that were previously showing up on the alarm dashboard of WCS (on an older version), but ever since the upgrade, they are not appearing on the dashboard at all.
    I have just added the controllers, some alarms are updating (rogue APs for one), and I have also tried refreshing the config through WCS.
    I can't seem to find anything on the 4.1 WCS config guide, so if anyone could point me in the right direction it would be appreciated.
    As a note: The controllers have both reported these WPA MIC errors since I added the controllers to WCS, but no info was updated on the alarm dashboard.
    Thanks,
    Jeff

    Hi,
    We don't have any chokepoints nor do we have a location server.
    Is that the reason why the security alarms aren't being flagged? If so then cisco should have documented that in the release notes.. on the previous version we weren't having this issue under the same conditions (security alarm was flagging).
    Just in case it's not clear where this is happening - I'm concerned about the panel on the bottom-left of the screen (java applet). Also when I go to monitor->security, there are no alarms (no previous/cleared either) when there should be.

  • WCS 4.1.83.0 alarm dashboard not flagging security issues

    Hello,
    Not sure if the topic title made much sense but basically what is happening is this:
    I just finished getting 4.1.83.0 installed on a fresh server with no backup restorations. My 4404 WLC's (x2) are on version 4.1.171.0.
    I have been receiving an influx of WPA MIC errors on both controllers, that were previously showing up on the alarm dashboard of WCS (on an older version), but ever since the upgrade, they are not appearing on the dashboard at all.
    I have just added the controllers, some alarms are updating (rogue APs for one), and I have also tried refreshing the config through WCS.
    I can't seem to find anything on the 4.1 WCS config guide, so if anyone could point me in the right direction it would be appreciated.
    As a note: The controllers have both reported these WPA MIC errors since I added the controllers to WCS, but no info was updated on the alarm dashboard.
    Thanks,
    Jeff

    Yes I see the logs and I looked through them.. though I have no idea what I'm really looking for as I have no direction in my troubleshooting.
    What does the alarm panel use for it's updating? tftp? snmp? ssh/telnet?
    Also I don't believe I mentioned it, but both controllers are pointing to WCS as a 'trap receiver'.
    I just don't see how an upgrade can suddenly prevent security logs from being updated on the WCS server. I have a feeling it might have to do with Linux itself as we upgraded that as well from RHEL3...
    I also did not see any caveats mentioned.. maybe it's time to open a TAC.
    Also; All I did to get WCS running once it was installed was add the two controllers, then refresh the config. Was there something else I was supposed to do other than that?

Maybe you are looking for