DX NetOps Manager

Expand all | Collapse all

Cisco WLC Access Point DisAssociate alarm issue

Jump to Best Answer
  • 1.  Cisco WLC Access Point DisAssociate alarm issue

    Posted 10-04-2017 10:47 AM

    Hi
    I have come across a problem with alarming on Cisco Wireless Lan Controllers (WLC) when an Access Point (AP) goes down and wondering if anyone can help.

     

    Out of the box Spectrum will alarm when an AP is Disassociated (bsnAPDisassociated trap, event 0x4b60007), however the corresponding clear event (trap bsnAPAssociated, event 0x4b60006) is deprecated so will never be seen. Put simply, Spectrum creates an alarm when an AP is disassociated, but doesn’t clear it when it’s back on again.

    The problem is the AP disassociate and associate traps are from different mibs. The Disassociate is from the Airespace mib, bsnAPDisassociated, and the Associate from the Cisco Lwapp AP mib, ciscoLwappApAssociated (event 0x210e0c). Don’t ask me why 

     

    I have captured the traps from the WLC when the AP goes down and back up and can confirm that bsnAPDisassociated is sent for the disassociate and ciscoLwappApAssociated is sent for the subsequent associate.

     

    Both traps send the mac address and AP name in the trap variables and I have tried to use both of these to discriminate the alarm and the clear, but without success .

     

    Has anyone come across this already? And more importantly, has anyone got a solution, or even suggest a solution?

     

    Thanks, John

     

    For info the trap definitions are as follows.

     

    bsnAPDisassociated NOTIFICATION-TYPE
    OBJECTS {
    bsnAPMacAddrTrapVariable,
    bsnAPName
    }
    STATUS current
    DESCRIPTION
    "When Airespace AP disassociates from Airespace Switch, AP
    disassociated notification will be sent with dot3 MAC address
    of Airespace AP management system to remove Airespace AP from
    this Airespace Switch"
    ::= { bsnTraps 8 }


    ciscoLwappApAssociated NOTIFICATION-TYPE
    OBJECTS {
    cLApName,
    cLApLastRebootReason,
    cLApDataEncryptionStatus
    }
    STATUS current
    DESCRIPTION
    "This notification is generated whenever an AP joins the
    controller successfully. This notification contains
    information about the last reboot reason and Data
    Encryption status of the AP."
    ::= { ciscoLwappApMIBNotifs 4 }



  • 2.  Re: Cisco WLC Access Point DisAssociate alarm issue

    Posted 10-04-2017 12:07 PM

    Hi John,

                    Spectrum’s WLC code does account for this, so please open a case as it sounds like it’s not working.

    Cheers

    Jay



  • 3.  Re: Cisco WLC Access Point DisAssociate alarm issue

    Posted 10-04-2017 12:20 PM

    Hi Jason

    Are you saying that the ciscoLwappApAssociated event should clear the alarm created by the bsnAPDisassociated event? If so I will create a support call.

     

    I should have added that a complication in our environment is that Spectrum cannot communicate directly with the APs, hence we are relying on the traps.

     

    For info we are on 10.2.0.0.244.

     

    John



  • 4.  Re: Cisco WLC Access Point DisAssociate alarm issue

    Posted 10-04-2017 01:47 PM

    Jason

    I have raised case number 00858990 for this.

     

    Regards, John



  • 5.  Re: Cisco WLC Access Point DisAssociate alarm issue

    Posted 10-04-2017 01:50 PM

    Cool, I’ll put some notes in it…If you have any debug (events, sniffer etc) that you can add, that would be appreciated.

    Cheers

    Jay



  • 6.  Re: Cisco WLC Access Point DisAssociate alarm issue
    Best Answer

    Posted 10-05-2017 04:52 AM

    Hello,

     

    The reason it doesn't clear is pretty simple if you ask me. When you use discriminators in Spectrum Events, they should be exactly the same. I see variables are not in the same order in both traps, so I think the right way to make them clear each other is to do a custom event handler for both, and the AlertMap for both traps should create an event with the variables in the same order (let's say 1. APName, 2. MAC, 3. and 4. for the rest) so you can then use events to clear each other. Having that into a case should help us to get this OOTB for next release!  In the meantime, I think this can be fixed in the field!



  • 7.  Re: Cisco WLC Access Point DisAssociate alarm issue

    Posted 10-05-2017 07:06 AM

    Hi Christophe

    I hadn't realised the discriminators needed to be in the same order. A bit weak if you ask me  ... mind you this was on my list of things to try but hadn't got there just yet 

     

    So I tried what you said and have now got it working, so thank you for that . I had to change the discriminator for both the Disassociate and Associate to the APName to get it working however. The mac address is available for both but seems to be in a different format and doesn't work. Not really sure why that is.

     

    Anyway onwards and upwards from here.

     

    Regards, John



  • 8.  Re: Cisco WLC Access Point DisAssociate alarm issue

    Posted 10-05-2017 07:53 AM

    Nice catch Christophe. I jumped right to the code to make sure we should generate the clear without even looking at the event config   Sounds like we can create a defect to get it fixed out of the box.

    Thanks!

    Jay



  • 9.  Re: Cisco WLC Access Point DisAssociate alarm issue

    Posted 06-22-2018 08:14 PM

    Has this been fixed.  I am being sweated about disassociation's from corp controller, and I dont even see the bsn event listed in the event list.



  • 10.  Re: Cisco WLC Access Point DisAssociate alarm issue

    Posted 06-26-2018 08:32 AM

    What are you getting for an event stream?  Are you getting 0x04b60007 and 0x04b60006 events?

     

    # bsnAPAssociated                                # bsnAPMacAddrTrapVariable
    1.3.6.1.4.1.14179.2.6.3.6.7 0x04b60006 1.3.6.1.4.1.14179.2.6.2.20(1,0)\
    # bsnAPPortNumberTrapVariable
    1.3.6.1.4.1.14179.2.6.2.32(2,0)\
    # bsnAPName
    1.3.6.1.4.1.14179.2.2.1.1.3(3,0)

     

     

    # bsnAPDisassociated                            # bsnAPMacAddrTrapVariable
    1.3.6.1.4.1.14179.2.6.3.6.8 0x04b60007 1.3.6.1.4.1.14179.2.6.2.20(1,0)\
    # bsnAPName
    1.3.6.1.4.1.14179.2.2.1.1.3(2,0)

     

    The event rule is triggering off of value 1 (the MAC):


    # bsnAPDisassociated
    0x4b60007 E 50 A 1,0x04b60007,U,1 R CA.EventCounter, "0x4b60006 -:-", 10, "0x6760002 -:-", "0x6760003 -:-"
    0x04b60006 E 50 C 0x04b60007, 1

     

    If you're still seeing the 0x04b60007 and 0x00210e0c then you'll need to copy the SS/CsVendor/AlertMap and EventDisp to /custom/Events/Cisco_Router.  Update the AlertMap to match the bsnAPName of 0x4b60007.  

     

    # ciscoLwappApAssociated              cLApLastRebootReason
    1.3.6.1.4.1.9.9.513.0.4 0x00210e0c 1.3.6.1.4.1.9.9.513.1.1.1.1.16(1,0)\
    #cLApName
    1.3.6.1.4.1.9.9.513.1.1.1.1.5(2,3)\
    # cLApDataEncryptionStatus
    1.3.6.1.4.1.9.9.513.1.1.1.1.36(4,0)

     

    You'll need to add 0x4b60007 to use the varbind 2 as a discriminator and generate the alarm:

     

    0x4b60007 E 50 A 1,0x04b60007,U,2

     

    0x210e0c generates a minor alarm, so if you don't want the minor alarm when the APAssociated happens, you'll probably want to change that to clear the 0x4b60007:

     

    0x00210e0c E 20 C 0x4b60007,2

     

    In Event configuration editor, edit 0x00210e0c so it has this in the event variables:

     

    cLApLastRebootReason = {T cLApLastRebootReason 1}

    cLApName = {S 2}
    cLApName.cLApSysMacAddress = {o 3}
    cLApDataEncryptionStatus = {T cLApDataEncryptionStatus 4}

     

    Be sure to press the Update Event Configuration on the VNM after.

     

    I think that looks right. Someone please spot check me as I get another coffee   

    Cheers

    Jay



  • 11.  Re: Cisco WLC Access Point DisAssociate alarm issue

    Posted 06-22-2018 08:17 PM

    were you able to get this to work? I need this solution like yesterday. I dont really understand creating custom events yet, so if you have a screenshot or 2 on how you did this....

    dick.baker@nttdata.com



  • 12.  Re: Cisco WLC Access Point DisAssociate alarm issue

    Posted 06-26-2018 08:45 AM

    Hi Dick,

     

    For time sensitive issues its probably best to log a support issue.  I just checked on my Spectrum 10.2.3 lab server and I can see that it is not fixed.

     

    If you look at the traps in how they are defined in the AlertMap, you can find the alertmap location from a grep

     

    shogl02-F3116%/d/win32app/Spectrum/SS/CsVendor
    > grep -r "1.3.6.1.4.1.9.9.513.0.4" .
    ./Cisco_Router/AlertMap:1.3.6.1.4.1.9.9.513.0.4 0x00210e0c 1.3.6.1.4.1.9.9.
    513.1.1.1.1.5(1,2)\
    shogl02-F3116%/d/win32app/Spectrum/SS/CsVendor
    > grep -r "bsnAPDisassociated" .
    ./Airespace/AlertMap:# bsnAPDisassociated #
    bsnAPMacAddrTrapVariable
    ./Airespace/EventDisp:# bsnAPDisassociated
    shogl02-F3116%/d/win32app/Spectrum/SS/CsVendor
    >

     

    So Spectrum/SS/CsVendor/Cisco_Router for Cisco Alertmap and Spectrum/SS/CsVendor/Airespace for the bsnAPDissociated Alertmap.


    # ciscoLwappApAssociatedNotify cLApName
    1.3.6.1.4.1.9.9.9998.0.1 0x00210e34 1.3.6.1.4.1.9.9.513.1.1.1.1.5(1,2)\
    # cLApSysMacAddress
    1.3.6.1.4.1.9.9.513.1.1.1.1.1(3,0)\
    # cLApLastRebootReason
    1.3.6.1.4.1.9.9.513.1.1.1.1.16(4,0)\
    # cLApDataEncryptionStatus
    1.3.6.1.4.1.9.9.513.1.1.1.1.36(5,0)

     

     

    # bsnAPDisassociated # bsnAPMacAddrTrapVariable
    1.3.6.1.4.1.14179.2.6.3.6.8 0x04b60007 1.3.6.1.4.1.14179.2.6.2.20(1,0)\
    # bsnAPName
    1.3.6.1.4.1.14179.2.2.1.1.3(2,0)

     

    If we check the Mac Address in both traps they have different discriminators  3 for Cisco and 1 for bsnAPDissociated.  So the suggestion by Christophe Sperandio was to make them match so that Cisco uses Discriminator of 1 instead of 3.

     

    So the fixed Cisco Alertmap should look like this:

     

    # ciscoLwappApAssociatedNotify cLApName
    1.3.6.1.4.1.9.9.9998.0.1 0x00210e34 1.3.6.1.4.1.9.9.513.1.1.1.1.5(3,2)\
    # cLApSysMacAddress
    1.3.6.1.4.1.9.9.513.1.1.1.1.1(1,0)\
    # cLApLastRebootReason
    1.3.6.1.4.1.9.9.513.1.1.1.1.16(4,0)\
    # cLApDataEncryptionStatus
    1.3.6.1.4.1.9.9.513.1.1.1.1.36(5,0)

     

    You will then need to fix the EventFormat File for the Cisco Event  0x00210e34

     

     

    Then save and reload the events from the VNM model in Spectrum and from the OneClick admin page for OneClick because we changed the event format files.

     

    Any doubts please open a support issue as we probably should have fixed this out of the box but it looks like it hasn´t been corrected yet.

     

    Best regards,

    Glenn