Summary

  • Un borrador individual de IETF propone diez estadísticas BMP para contar, en ambos sentidos, UPDATE, KEEPALIVE, NOTIFICATION, ROUTE-REFRESH y todos los mensajes BGP. Cuenta PDU, no prefijos ni entradas de la tabla.
  • Peer Down por sí solo no debe borrar los acumulados. El reinicio del proceso, la eliminación del vecino, el borrado manual o la conmutación del procesador de rutas sí pueden iniciar una época nueva del contador.

Una tabla de rutas estable puede ocultar un intercambio febril. Retirar un prefijo y anunciarlo otra vez deja el mismo número final de rutas, después de consumir mensajes UPDATE y trabajo de control. RFC 7854 ya permite enviar por BMP vistas de rutas, avisos de subida y caída del vecino e informes estadísticos. Sus tipos estadísticos muestran ocupación de tablas y determinados resultados de UPDATE; no ofrecen un total por cada clase de mensaje de la sesión.

El registro del 29 de octubre presenta el nuevo texto como Internet-Draft individual. Los autores piden cinco pares de contadores de entrada y salida. UPDATE y total de PDU usarían 64 bits; KEEPALIVE, NOTIFICATION y ROUTE-REFRESH, 32. La estación de vigilancia podría ver actividad de control y estado de rutas en la misma alimentación BMP. No son magnitudes intercambiables: un UPDATE puede transportar varios NLRI y un mensaje Route Monitoring puede depender de la vista exportada.

El criterio que importa aparece cuando el vecino cae. El borrador dice que generar Peer Down no debe reiniciar los contadores. Si la sesión vuelve, el acumulado de NOTIFICATION sigue informando de mensajes anteriores incluso cuando el colector perdió el aviso individual de cierre. El aviso describe una terminación concreta y su causa; la cifra acumulada mide otra cosa. Reiniciar el gráfico en cada Peer Up borraría justo la historia que se quiere conservar.

Un reinicio auténtico exige el movimiento opuesto. El proceso puede reiniciarse, un operador puede limpiar contadores, puede eliminarse el vecino o cambiar el procesador de rutas. El colector debe considerar una nueva Initiation BMP como discontinuidad, pero no una secuencia ordinaria Peer Down/Peer Up. Tampoco basta buscar números menores: después de volver a cero, un vecino activo puede superar el valor anterior antes del siguiente informe. El borrador no define una marca temporal de discontinuidad. Si un tipo no aparece en un informe, está ausente; no vale cero.

El registro BMP de IANA contiene los tipos asignados hoy; los diez del borrador aún se llaman TBD. No hay aquí un código de tipo oficial ni una implantación demostrada. Una prueba con un equipo identificado, caída de sesión, reinicio del equipo, informes sucesivos y registro del borrado mostraría si una estación puede reconstruir la cuenta sin inventar tráfico.