EN ESTA PÁGINA
Descripción general de la interfaz de telemetría de Junos
A medida que ha crecido el número de objetos en la red y las métricas que generan, los modelos tradicionales, como SNMP, que se utilizan para recopilar estadísticas operativas para monitorear el estado de una red, han impuesto límites a la escala y la eficiencia de los elementos de red. El llamado modelo pull utilizado por SNMP y la CLI, que requiere un procesamiento adicional para sondear periódicamente el elemento de red, limita directamente el escalamiento.
La interfaz de telemetría de Junos (JTI) supera estos límites al confiar en un llamado modelo push para entregar datos de forma asincrónica, lo que elimina las encuestas. Una solicitud de envío de datos se envía una vez por una estación de administración para transmitir actualizaciones periódicas. Como resultado, JTI es altamente escalable y puede admitir el monitoreo de miles de objetos en una red.
La interfaz de telemetría de Junos se introdujo en la versión 15.1F3 de Junos OS, en enrutadores serie MX con interfaces configuradas en MPC1 a MPC6E y en enrutadores de la serie PTX con interfaces configuradas en FPC3. A partir de Junos OS versión 15.1F5, la interfaz de telemetría de Junos también se admite en MPC7E, MPC8E y MPC9E en enrutadores serie MX.
A partir de Junos OS versión 16.1R3, también se admiten motores de enrutamiento doble, FPC1, FPC2 y de enrutamiento dual en enrutadores de la serie PTX.
A partir de Junos OS versión 17.2R1, también se admiten conmutadores QFX10002, QFX10008 y QFX10016, QFX5200 y enrutadores PTX1000 y PTX10008. QFX5200 solo admiten sensores gRPC.
A partir de Junos OS versión 17.3R1, también se admiten conmutadores QFX5110, conmutadores EX4600, EX4600-VC y EX9200, y la tarjeta de enrutamiento y control (RCB) en enrutadores PTX3000. QFX5110 solo admiten sensores gRPC.
A partir de Junos OS versión 17.4R1, se admiten enrutadores PTX10016 y de la serie MX virtual (vMX).
A partir de Junos OS versión 18.2R1, también se admiten enrutadores PTX10002.
Sensores de telemetría y modelos de datos
La interfaz de telemetría de Junos le permite aprovisionar sensores para recopilar y exportar datos para diversos recursos del sistema, como interfaces físicas y filtros de firewall. Se admiten dos modelos de datos, cada uno de los cuales utiliza un modo de transporte diferente:
Un modelo de datos abierto y extensible definido por Juniper Networks. Los datos se generan como mensajes estructurados de memorias intermedias de protocolo (gpb) de Google. Los archivos que definen cada
.proto
mensaje se publican en el sitio web de Juniper Networks. Los sensores nativos exportan datos cercanos a la fuente, como la tarjeta de línea o la unidad de procesamiento de red (NPU), mediante el protocolo de datagramas de usuario (UDP). Dado que este modelo cuenta con una arquitectura distribuida, escala fácilmente.Un modelo de datos de OpenConfig que genera datos como mensajes gpb en un formato universal de clave/valor. OpenConfig para Junos OS, que debe descargar, admite los modelos de datos YANG. Las llamadas de procedimiento remoto gRPC (gRPC) se utilizan para aprovisionar sensores y para suscribirse y recibir datos de telemetría. gRPC está basado en TCP y admite el cifrado SSL, por lo que se considera seguro y confiable. Si su dispositivo Juniper Networks ejecuta una versión de Junos OS con el kernel FreeBSD actualizado, este modelo requiere que descargue el paquete Junos Network Agent, que se ejecuta en el motor de enrutamiento y proporciona interfaces para administrar suscripciones gRPC. Para otras versiones de Junos OS, la funcionalidad del agente de red está integrada en el software. A partir de Junos OS versión 18.2R1, los sensores de motor de enrutamiento (RE) basado en OpenConfig pueden transmitir datos como mensajes estructurados gpb a través de UDP.
Usos y beneficios
Una función principal de la interfaz de telemetría de Junos es la supervisión del rendimiento. La transmisión de datos a un sistema de gestión de rendimiento permite a los administradores de red medir las tendencias en la utilización de enlaces y nodos, y solucionar problemas como la congestión de la red en tiempo real.
En una implementación típica, el elemento de red o dispositivo transmite datos duplicados a dos servidores de destino que funcionan como recolectores del sistema de administración del rendimiento. La transmisión de datos a dos recolectores proporciona redundancia. Consulte la Figura 1 para ver una ilustración de cómo los recolectores del sistema de gestión de rendimiento solicitan datos y cómo el dispositivo transmite los datos. El dispositivo proporciona sensores para recopilar y exportar datos mediante la interfaz de línea de comandos (CLI), la configuración a través de NETCONF o llamadas de suscripción gRPC. Los recopiladores solicitan datos iniciando una suscripción de telemetría. Los datos se solicitan una sola vez y se transmiten periódicamente.
A partir de la versión 18.1R1 de Junos OS, está disponible un nuevo sensor que permite que los datos de syslog se transmitan a los sistemas de recolección de telemetría de red. Con el sensor /junos/events/ y un perfil de exportación con un reporting-rate
de 0, ahora puede transmitir datos de eventos junto con datos estadísticos a sus sistemas de recopilación de telemetría.
Otras aplicaciones de la interfaz de telemetría de Junos incluyen el suministro de datos en tiempo real para admitir la sincronización del estado operativo entre un elemento de red y un controlador externo, como el controlador Northstar, que automatiza la creación de rutas de ingeniería de tráfico en toda la red. El controlador NorthStar puede suscribirse a datos de telemetría sobre ciertos elementos de red, como estadísticas de ruta conmutada por etiquetas (LSP).