If Access Points AP are moved from one WLC to another, the old one remains in the database

If an AP (Access Point-basically an antenna) ist moved from one WLC  (Wireless lan Controller) to another, both remain in the inventory.

Thats not convenient, because the old location AP ist critical is in NNM, and cannot be removed manually in the NNM as well, only be set to unmanaged

there is the possibility in the discovery configuration to delete unresponsive objects after a certain time, Physical Components would be correct here.
However, APs that are actually defective are then also deleted.

The clean behavior for me would be if NNM would automatically delete the old controller in the event of an AP move to another controller - since the MAC address of the AP's
is unique, this shouldn't be a technical problem - i.e. in the case of duplicate Mac addresses, delete the AP from the DN with the older registration time.

Does anybody have a solution like this, maybe an ER is already created, although I could not find one?

Tags:

  • Suggested Answer

    Hi, 

    what is your NNMI version? Below is response from MF Support what I received some your ago. It describes mechanism of AP maintenance in the inventory. It seems automation you are looking for is implanted, but now works for some reason in your case. I'd suggest to rise support call.


    "The Wireless Access points are displayed within the Wireless controller's node view under the Chassis, Card, Radio Card and LightweightAP tabs.

    Normally the Wireless Controllers ( WLC ) will send a disassociate and associate traps as the AP moves from one to another. 
    These traps are intercepted by APA and a discovery poll is performed on the respective node in order to determine the change. 
    If these traps do not get sent then NNMi will eventually detect the movement but in the interim the following scenarios will be seen:

    On the device where the AP has been disassociated ( moved from ) a status poll result will not show the AP in the poll output. 
    The Chassis and the lightweight AP entries will show the respective entries as Oper Down with Critical Status and the Node will be minor with a conclusion of ChassisDownInNode. A config poll will not change anything.

    On the device where the AP has been associated ( moved to ) a status poll will not show the new AP and nor will the UI until the discovery/config poll takes place. 
    Once the discovery/config poll occurs and the new AP entry is processed then it is added to the WLC and removed from the old WLC.

    All of this is done much more quickly and in synch if the traps are sent by the WLCs and processed by NNMi, resulting in the two config polls and the AP movement in a much shorter time.

    Note, if an AP is removed from a WLC and is not then associated with another WLC then it will remain shown in a down state on the original WLC until the "Period (in Days) to Delete Physical Components that are Missing" expires. 
    This property is configured in the "Discovery Configuration" view, the default being "0" - don't delete."

    Please check the "Period (in Days) to Delete Physical Components that are Missing" inside the "Discovery Configuration" and if it shows 0, to change it to 1. 
    Then to wait for a day and to see, if the disassociated APs are still attached to the WLC. 

    best regards,
    Gedas

  • Hello Gedas,

    thank you for the explanation, I created a vendor case for the issue (02229287), I verified this behaviour independently at two customers.

    This is how it should work, anyway the AP is not removed after the move to another WLC and discovery hat taken place.

    Once the discovery/config poll occurs and the new AP entry is processed then it is added to the WLC and removed from the old WLC.