Resumen

  • El contador original de SNMP recorría 32 bits y, tras alcanzar el máximo, volvía a cero. Esa caída era aritmética prevista, no una prueba de avería ni de tráfico invertido.
  • Los enlaces rápidos redujeron el tiempo entre vueltas. Los contadores de alta capacidad de 64 bits alargaron la ventana, pero conservaron los 32 bits bajos para gestores antiguos.
  • Reiniciar no es desbordar. sysUpTime e ifCounterDiscontinuityTime delimitan la época de medida; si cambia entre dos lecturas, no se puede aceptar su diferencia como tráfico observado.

La línea no se detuvo, pero el número volvió atrás

Un sondeo recoge casi 4.300 millones de octetos. El siguiente devuelve unos pocos millones. La interfaz continuó activa y los paquetes siguieron circulando, pero una resta convencional ofrece un valor negativo. Un gráfico puede ocultar el conflicto con una corrección automática; el protocolo obliga a preguntar qué historia une las dos muestras.

Si toda caída se interpreta como reinicio, se pierde el tramo que cruzó el máximo. Si toda caída se interpreta como una vuelta, un reinicio puede convertirse en miles de millones de octetos inexistentes. Hacen falta el ancho, el tiempo transcurrido y una prueba de que el sistema contador no cambió de época.

La clave histórica no fue producir una cifra que jamás disminuyera. Fue conservar por separado las condiciones bajo las cuales dos cifras admiten comparación.

El primer Counter ya era circular

El RFC 1155 definió en 1990 un Counter no negativo que crece hasta 2^32-1 y después vuelve a cero. El desbordamiento forma parte de la sucesión legítima. No revoca los eventos contados ni diagnostica el estado físico del equipo.

El RFC 1213 llevó esa semántica a MIB-II. Cada interfaz ofrecía contadores como ifInOctets e ifOutOctets, junto con sysUpTime e ifLastChange. El contexto temporal estaba disponible, pero el número no incluía un origen absoluto ni decía cuántas vueltas había completado.

El RFC 2578 lo expresó con mayor precisión en SMIv2: ni Counter32 ni Counter64 tiene valor inicial definido. Una sola lectura carece, por regla general, de contenido informativo. Ambos son circulares; cambia la distancia hasta reutilizar una cifra.

Con dos muestras de una misma época y una sola vuelta posible, el cálculo modular recupera el incremento. Con un intervalo capaz de contener varias vueltas, los dos extremos no revelan cuántas faltan.

La velocidad convirtió los bits en plazo operativo

El crecimiento de las redes acortó ese margen. El RFC 1573 calculó que tráfico continuo de paquetes de tamaño máximo haría volver un contador de octetos de 32 bits en algo más de 57 minutos a 10 Mb/s, 5,7 minutos en FDDI y unos 34 segundos a 1 Gb/s. El RFC 2863 mantuvo la advertencia.

Sondear cada vez más rápido aumentaba carga y no reparaba una recogida perdida. También se estudió contar bloques de 1.024 octetos. Se descartó porque, a baja tasa, el valor tardaría en avanzar y un flujo uniforme parecería llegar en ráfagas.

La alternativa fue ampliar la capacidad. RFC 1573 añadió grupos de 64 bits. RFC 2863 exige contadores de bytes y paquetes de 32 bits hasta 20 Mb/s; por encima de esa velocidad exige octetos de 64 bits; y desde 650 Mb/s exige también paquetes de 64 bits.

Los umbrales equilibraban coste del agente, compatibilidad y probabilidad de perder una vuelta. No proclamaban que un tipo fuera exacto por sí solo.

La compatibilidad dejó dos ventanas sobre el mismo tráfico

Los objetos anteriores no desaparecieron. Cuando existen sus equivalentes de alta capacidad, los contadores de 32 bits siguen mostrando los 32 bits menos significativos del total de 64 bits. Un gestor legado conserva acceso; otro puede esperar mucho más entre lecturas sin perder una vuelta ordinaria.

Las dos cifras son coherentes módulo 2^32, pero no sostienen la misma historia tras un vacío largo. Cambiar un colector de ifInOctets a ifHCInOctets sin marcar la transición crea una serie que parece uniforme y no lo es.

Tampoco Counter64 es infinito. El RFC 2578 lo hace volver después de 2^64-1. Su amplitud reduce la frecuencia del ciclo; no evita reinicios, recreaciones del objeto ni cambios en lo que el objeto cuenta.

La misma interfaz podía estrenar historial

Quedaba un problema distinto. Una tarjeta puede retirarse y regresar, o su sistema de contadores reiniciarse sin que el agente entero caiga. Para la operación sigue siendo la misma interfaz y conservar ifIndex resulta útil. Para la medición, unir los valores anteriores y posteriores resulta falso.

La práctica antigua obligaba a retener todos los contadores durante la ausencia o asignar otro índice. El RFC 2233 abrió una tercera vía con ifCounterDiscontinuityTime: mantener la identidad de la fila y declarar que sus acumuladores comenzaron otra época.

El RFC 2863 define el objeto como el valor de sysUpTime cuando ocurrió la discontinuidad más reciente en alguno de los Counter32 o Counter64 asociados. Si no ha habido ninguna desde la última reinicialización del subsistema de gestión, contiene cero.

La separación evita pedir a un identificador estable una promesa que no puede cumplir. ifIndex señala la interfaz en un ámbito de gestión; el marcador señala desde cuándo se pueden comparar sus contadores.

El marcador decía cuándo, no por qué

La obligación del gestor es concreta. Si ifCounterDiscontinuityTime no coincide en ambos sondeos, debe descartar la diferencia calculada. Además debe comprobar sysUpTime, porque un reinicio del agente puede cambiar el contexto de índices, tiempo y valores.

Descartar no significa registrar cero. Significa que el total exacto del intervalo no está respaldado por las muestras normalizadas. Una estimación puede servir para planificación si permanece etiquetada como estimación.

El objeto tampoco explica la causa. No distingue recambio de hardware, actualización, recreación lógica o defecto. El RFC 3635 lleva la misma regla a los objetos de Ethernet y confirma esa frontera: el tiempo de discontinuidad acompaña al contador, pero no es un parte de avería autenticado.

Por eso una marca estable permite calcular dentro del modelo, pero no certifica al fabricante, el destino de los paquetes, una factura o el efecto de servicio.

Fuentes y límites de la evidencia

El conjunto histórico cerrado reúne los RFC 1155, RFC 1213, RFC 1573, RFC 2233, RFC 2578, RFC 2863 y RFC 3635. Demuestran tipos, evolución y obligaciones de lectura. No miden despliegue actual, conformidad de productos ni la causa de una discontinuidad real, y no convierten un contador en prueba de entrega o cobro.