Network Management

Wireless Controllers show stale LastUpdate timestamps in SolarWinds Platform

This article provides information about an issue in the SolarWinds Platform where Wireless Controllers (WLCs) and their associated Access Points (APs) show stale LastUpdate timestamps, leading to missed or inaccurate alerting.

First published date

8/29/2025 9:38 PM

Last published date

8/29/2025 9:38 PM

Overview

In some environments, Wireless Controllers (WLCs) and their Access Points (APs) may stop receiving updates in the database, while node-level polling continues normally.

Symptoms:

  • WLCs show LastUpdate timestamps stuck in the past.
  • APs managed by these WLCs are not updated in the database.
  • Alerts for APs may trigger inaccurately due to outdated polling data.
  • Restarting Collector Services or moving the WLC to a different polling engine temporarily restores updates, but the issue reoccurs.

  • The SolarWinds.Node.Wireless.Snmp collector queue file size increases abnormally on the affected Polling Engine.

    • Normally, this queue temporarily stores polled values before they are written to the SQL database.
    • When the database connection fails or stalls, values cannot be flushed, causing the queue to accumulate/backlog until service is restarted.

Product section

Network Performance Monitor

Cause

The issue is caused by network latency between the database server and a specific polling engine.

Evidence from debug collector logs shows that:

 

On a healthy polling engine, committing results for a WLC with ~5,700 wireless entities takes less than a minute (~50 seconds):

  • [12:01:10.123] [STP DatabaseProcessing Thread #12345] INFO WirelessPollingPlanBase - Importing WL poller result for NodeID <####>
[12:02:00.789] [STP DatabaseProcessing Thread #12345] INFO WirelessPollingPlanBase - Importing WL poller result for NodeID <####> was successful

On the affected polling engine, committing results for a WLC with ~8,100 wireless entities can take more than 30 minutes (~36 minutes):

  • [13:15:22.456] [STP DatabaseProcessing Thread #23456] INFO WirelessPollingPlanBase - Importing WL poller result for NodeID <####>
[13:51:45.987] [STP DatabaseProcessing Thread #23456] INFO WirelessPollingPlanBase - Importing WL poller result for NodeID <####> was successful

During this process, single wireless DB operations exceed 200ms on the affected engine, while similar operations on a healthy engine complete almost instantly:

  • [13:20:01.321] [STP DatabaseProcessing Thread #23456] DEBUG WirelessPollerResultImporter - Synchronizing WL Interface <#####>
[13:20:01.543] [STP DatabaseProcessing Thread #23456] DEBUG WirelessPollerResultImporter - Synchronizing WL Interface <#####>

 On a healthy engine, synchronization occurs rapidly for wireless clients:

  • [12:05:10.111] [STP DatabaseProcessing Thread #34567] DEBUG WirelessPollerResultImporter - Synchronizing WL Client <#####>
[12:05:10.114] [STP DatabaseProcessing Thread #34567] DEBUG WirelessPollerResultImporter - Synchronizing WL Client <#####>

 

This performance gap demonstrates that the database itself is healthy, but the network path between the DB server and the affected polling engine introduces significant latency.

 

This latency leads to:

  • Jammed processing queues on the affected polling engine
  • Outdated LastUpdate timestamps in the database for WLCs and their associated APs

Resolution

To resolve the issue:

  1. Investigate network latency between the database server and the affected polling engine.
    • Ensure sufficient bandwidth and low latency on the link.
  2. Workaround: Move Wireless Controllers from the affected polling engine to a healthy polling engine.
    • After migration, WLCs and APs should begin updating LastUpdate timestamps normally.
  3. Continue monitoring the environment to confirm whether the latency issue is resolved.