Best way to catch if a CAT-6 cable gets broken to an access point

[Anders Hedlund]

Operating in underground mines, we often face problems with the cables to the access points.
We have about 3000 access points in operation.
What’s the best way to check if a cable is cut so an AP loses connection to the WLC?

We mainly use the NETCONF interface for monitoring, but there I can only see the operating AP configuration (at least from what I’ve found out so far), I can’t find anything about APs losing connectivity.

In the best scenario, I get an event of some type from the WLC once it loses an AP.
How can this be done using NETCONF?
Can we use SNMP traps here? What OID should we use?

Polling (PING or SSH port check) can be done, but due to the large number of APs I would like to avoid this.

WLC 9800-L version 17.3.0.107
AP models C9120, C9124, CAP2802 and some older models also.

/Anders

[Haydn Andrews]

I monitor over 40k APs. We have the WLCs managed by Cisco Catalyst Centre (DNAC) and prior to that Prime.

We have Alerting trigged from DNAC for any AP that disassociates from the WLC. We also used to have ICMP poling to every AP but found a number of times the AP would respond to ICMP but be not registered to the WLC.

That will not tell u the cable has been cut, but basically if the cable was cut the AP will go down.

[Leo Laohoo]

An SNMP poller to ping-n-poll the APs. 

[marce1000]

  - Besides online polling solutions also consider overall AP monitoring using commands from  : https://www.cisco.com/c/en/us/support/docs/wireless/catalyst-9800-series-wireless-controllers/217738-monitor-catalyst-9800-kpis-key-performa.html#anc4

   - As 17.3 is getting older/EOL consider moving to https://software.cisco.com/download/home/286323158/type/282046477/release/Cupertino-17.9.5
                perhaps improving stability 

  - Always useful to do in all circumstances is having a checkup of the 9800-L configuration with the CLI command
    show tech wireless and feed the output from that into Wireless Config Analyzer

 M.

[RxTx]

As Leo pointed, SNMP it is your friend here;

I am using LibreNMS in a vbox and work as expected for my WLC and AP Up/Down events, got my notification on email/Telegram...

Device 2702-GD2 recovered from Devices up/down
Severity: warning
Time elapsed: 7m 19s Timestamp: 2024-05-01 11:42:21
Unique-ID: 4732
Rule:  Devices up/down  Faults:
...

[Rich R · Accepted solution]

If you have a trap receiver then the WLC will send a trap for AP down. 
We use bsnAPDisassociated
https://snmp.cloudapps.cisco.com/Support/SNMP/do/BrowseOID.do?objectInput=1.3.6.1.4.1.14179.2.6.3.8&translate=Translate&submitValue=SUBMIT
variable-bindings: 4 items
SNMPv2-MIB::sysUpTime.0 (1.3.6.1.2.1.1.3.0): <uptime value>
SNMPv2-MIB::snmpTrapOID.0 (1.3.6.1.6.3.1.1.4.1.0): 1.3.6.1.4.1.14179.2.6.3.8 (AIRESPACE-WIRELESS-MIB::bsnAPDisassociated)
AIRESPACE-WIRELESS-MIB::bsnAPMacAddrTrapVariable.0 (1.3.6.1.4.1.14179.2.6.2.20.0): <AP MAC>
AIRESPACE-WIRELESS-MIB::bsnAPName.0 (1.3.6.1.4.1.14179.2.2.1.1.3.0): <AP Name>

Note that the corresponding UP trap is in a completely different part of the MIB (don't even ask what must go through Cisco developer's minds) - ciscoLwappApAssociated
https://snmp.cloudapps.cisco.com/Support/SNMP/do/BrowseOID.do?objectInput=1.3.6.1.4.1.9.9.513.0.4&translate=Translate&submitValue=SUBMIT&submitClicked=true
variable-bindings: 5 items
SNMPv2-MIB::sysUpTime.0 (1.3.6.1.2.1.1.3.0): <uptimevalue>
SNMPv2-MIB::snmpTrapOID.0 (1.3.6.1.6.3.1.1.4.1.0): 1.3.6.1.4.1.9.9.513.0.4 (CISCO-LWAPP-AP-MIB::ciscoLwappApAssociated)
CISCO-LWAPP-AP-MIB::cLApName.<encoded AP MAC>: <AP Name>
CISCO-LWAPP-AP-MIB::cLApLastRebootReason.<encoded AP MAC>:
CISCO-LWAPP-AP-MIB::cLApDataEncryptionStatus.<encoded AP MAC>:

We ignore (don't alarm/ticket) down/up events shorter than 10 minutes to avoid ticketing every time an AP reloads.  If it's down for 10 minutes or more then we assume it's actually gone down.