Agente 2.30.1: el contador de 32 bits de los Xirrus daba la vuelta y "AP Bandwidth" pintaba un cero (v1.166.1)

Cuándo

28-09-2026. Lo vio Edu al usar el desplegable “Red” de Wireless (feature del mismo día, v1.166.0) en las salas P1-Sala111 y P1-Sala113. Medido en VictoriaMetrics sobre 4 horas en Sala 113: 24 lecturas a 0 Mbps aisladas entre valores normales de 40-60 Mbps — una cada vez que el contador de subida o el de bajada completaba una vuelta de 2^32 bytes (~23 vueltas esperadas en esas 4 h a ese caudal). El fallo llevaba activo desde que estos puntos de acceso empezaron a reportar tráfico real por el contador legacy; no hay forma de fechar el origen exacto porque no existía alarma que lo señalase.

Síntomas visibles

La gráfica “AP Bandwidth” de un punto de acceso, en la vista “All networks”, caía a 0 Mbps de forma recurrente (cada ~11 minutos a 50 Mbps de caudal) y se recuperaba sola en la lectura siguiente. La vista filtrada por una sola red WiFi no mostraba el fallo, porque esa serie la calcula VictoriaMetrics con rate() sobre las muestras ya escritas: el cero llegaba ya cocinado desde el Agente, antes de esa vista.

Causa raíz

En terminal/agent/sentinel/snmp_bandwidth.py, los Xirrus tienen los contadores HC (64 bits) casi quietos en las interfaces Ethernet — el tráfico real de estos puntos de acceso va por los contadores legacy de 32 bits (quirk ya documentado en [[crearack-tech—backend—multi-vendor-snmp-guide]]). Cuando ese contador de 32 bits llega a su máximo (2^32 bytes, ~4,29 GB) y vuelve a empezar, la resta entre dos lecturas consecutivas da un número negativo. El código descartaba esa familia al ver el negativo y usaba la familia HC como alternativa — que en estos aparatos apenas se mueve — así que la lectura salía en 0 Mbps en vez del tráfico real.

Fix aplicado

Commit b9ef67c4 (PR #628, Agente 2.30.1, v1.166.1). Si la familia legacy tiene datos y el hueco entre lecturas es de 180 segundos o menos, un delta negativo se interpreta como una vuelta del contador y se le suma 2^32 (COUNTER32_WRAP) antes de usarlo. El límite de 180 s es criterio, no medida (LEGACY_WRAP_MAX_DT_S, marcado UNVERIFIED en el propio código): a menos de ~190 Mbps sostenidos solo cabe una vuelta dentro de esa ventana; con un hueco mayor (por ejemplo, un reinicio del punto de acceso) no se corrige. Además, si una familia de contadores retrocede y la otra no tiene tráfico propio, la lectura se omite en vez de devolver ese 0 (evita que un 0 “quieto” tape una vuelta real de la otra familia). Test de regresión: tests/agent/test_snmp_bandwidth_vuelta_32bits.py.

Lecciones

• El mismo síntoma (0 Mbps intermitente en Bandwidth) ya tuvo otras dos causas raíz distintas en este proyecto: un timeout de walk SNMP que fabricaba ceros ([[incident—20260825—snmp-walk-timeout-fabricaba-cero]]) y una ventana de agregación demasiado corta frente a rondas de sondeo largas (RELEASE_NOTES v1.135.1, 16-09-2026). Un 0 en una gráfica de tráfico casi nunca significa “no hay dato”: suele ser una rama del código que se rinde demasiado pronto.
• El bug estaba invisible en la vista agregada porque nadie la comparaba desglosada por red; el desplegable “Red” (v1.166.0, el mismo día) lo hizo visible al contrastar la vista “All networks” contra una sola red.

Preventivos futuros

• No hay alarma dedicada a “cuántas lecturas de Bandwidth salen con reason=wrap por target”: el mecanismo state["reason"] (Agente 2.24.0, ver [[crearack-tech—architecture—sentinel-mode]]) ya registra el motivo, pero nadie agrega esa serie para detectar un punto de acceso con vueltas anómalamente frecuentes.
• El límite de 180 s de la ventana de corrección es criterio, no una medición del peor caso real de caudal de la flota; si aparece un punto de acceso con más de ~190 Mbps sostenidos, revisar LEGACY_WRAP_MAX_DT_S.
• Los ceros ya guardados en el histórico, de antes de esta versión, no se pueden corregir con retroactividad.

Véase también

• [[incident—20260825—snmp-walk-timeout-fabricaba-cero]]
• [[crearack-tech—architecture—sentinel-mode]]
• [[crearack-tech—backend—multi-vendor-snmp-guide]]
• [[crearack—monitoring—configurar-snmp]]
• [[feature—monitoring—bandwidth-snmp-por-interfaz]]