Informe técnico sobre telemetría dirigida por modelo ASR9K
Contenido
Introducción
Destinatarios
Este informe técnico pretende ayudar a los clientes a comprender rápidamente la función de telemetría basada en modelos (MDT) en general y cómo se ha implementado en el router de servicios de agregación 9000 (ASR9K), incluidas algunas directrices de diseño y detalles de configuración. También incluye algunos aspectos relacionados con la implementación, que resultarán útiles a la hora de implementar esta función mediante ASR9K. En general, este informe técnico puede ser una guía de referencia rápida para cualquier usuario que trabaje con esta función.
Aunque la telemetría se introduce como una función genérica, el enfoque está en la implementación de ASR9K; es decir, no todas las funciones admitidas por otras plataformas de Cisco son compatibles con la plataforma ASR9K y algunas implementaciones de funciones pueden ser específicas de ASR9K.
Breve introducción a la telemetría
Para empezar, en términos sencillos, la telemetría es el proceso de recopilación de datos operativos útiles. Según Wikipedia, la telemetría es un proceso de comunicaciones automatizadas mediante el cual se recopilan mediciones y otros datos en puntos remotos o inaccesibles y se transmiten al equipo receptor para su supervisión. La palabra de telemetría en sí misma se deriva de las raíces griegas: tele = remoto, y metron = medida.
Para la administración de la red, los operadores de red cuentan con un largo historial de confianza en el protocolo simple de administración de red (SNMP). Aunque SNMP es ampliamente adoptado para el monitoreo de la red, nunca se utilizó para la configuración aunque la capacidad de configuración con snmp siempre estaba allí. Los operadores han escrito secuencias de comandos de automatización para gestionar las tareas de configuración diarias, pero las secuencias de comandos son complicadas para estas tareas y difíciles de gestionar.
Por lo tanto, los operadores se inclinaron por la gestión basada en modelos de datos. La configuración de red se basa en modelos de datos YANG impulsados por protocolos como netconf, por ejemplo. Ahora, simplemente enviar la configuración no implica que el servicio configurado se esté ejecutando; tiene que haber un mecanismo que pueda supervisar los datos operativos de los servicios al mismo tiempo que la configuración. Aquí es donde los modelos de datos de Oper, que Telemetry utiliza para sacar la información del dispositivo, ayudan. Por lo tanto, la configuración está impulsada por el modelo de datos YANG, por lo que debe ser la verificación del servicio también; como en el caso de la telemetría, para tener la misma semántica de objeto. Por lo tanto, el término se llama telemetría basada en modelos o telemetría de transmisión.
La telemetría dirigida por modelos (MDT) se introdujo en cXR (IOS XR de 32 bits) desde la versión 6.1.1 y permite la recopilación y medición de datos críticos casi en tiempo real, lo que proporciona una respuesta rápida a la mayoría de los problemas operativos de la red moderna.
Arquitectura de telemetría de alto nivel
MDT aprovecha los modelos de datos estructurados compatibles con el dispositivo de red y proporciona datos críticos definidos en esos modelos de datos. La telemetría ayuda a los clientes a gestionar su red de varios proveedores utilizando un sistema de gestión de redes, procesos y aplicaciones comunes, ya que los datos recopilados de la red se basan en estándares y son uniformes en la implementación de todos los proveedores.
En lugar de esperar a la recuperación de datos (extracción) desde una estación de gestión centralizada (normalmente SNMP NMS); con MDT, los dispositivos de red envían (pulsan) de forma proactiva datos de rendimiento pertenecientes a las funciones vitales de la red, como información de reenvío de paquetes, estadísticas de errores, estado del sistema, recursos de CPU y memoria, etc.
Por qué telemetría
La recopilación de datos con fines analíticos y de resolución de problemas siempre ha sido un aspecto importante en la supervisión del estado de una red. Hay varios mecanismos disponibles como SNMP, CLI y Syslog para recopilar datos de una red. Aunque estos métodos han servido a la red durante mucho tiempo, no son adecuados para las redes modernas en las que la demanda de automatización, los servicios a escala son fundamentales. La información de estado de la red, las estadísticas de tráfico y la información de infraestructura crítica se envían a una estación remota en NMS, donde se utilizan para mejorar el rendimiento operativo y reducir el tiempo de resolución de problemas. Un modelo pull como snmp, donde un cliente sondea todos los nodos de red, no es eficiente. La carga de procesamiento en los nodos de red aumenta cuando hay más número de clientes para sondear. Por el contrario, un modelo de inserción tiene la capacidad de transmitir continuamente datos fuera de la red y notificar al cliente. La telemetría habilita el modelo push, que proporciona acceso casi en tiempo real a los datos de supervisión.
La telemetría de transmisión proporciona un mecanismo para seleccionar los datos de interés de los routers y transmitirlos en un formato estándar a las estaciones de administración remota para su supervisión. Este mecanismo permite un ajuste preciso de la red basado en datos en tiempo real, lo que resulta crucial para su funcionamiento sin problemas. La granularidad más fina y la mayor frecuencia de los datos disponibles a través de la telemetría permiten una mejor supervisión del rendimiento, lo que se traduce en una mejor resolución de problemas.
Ayuda a optimizar el uso del ancho de banda en la red, la utilización de enlaces, la evaluación de riesgos y la escalabilidad. Con la telemetría de streaming, los operadores de red disponen de más datos casi en tiempo real, lo que ayuda a mejorar la toma de decisiones.
La necesidad de alejarse de SNMP
SNMP existe desde hace tres décadas y su funcionamiento no ha cambiado para satisfacer las necesidades de supervisión de las redes modernas. El verdadero problema es la velocidad de ejecución de SNMP.
Los tres retos principales planteados por SNMP son en realidad parte de su comportamiento operativo fundamental y, por lo tanto, SNMP ofrece poco o ningún margen de mejora y la telemetría aborda los tres de forma inherente.
- Velocidad de ejecución y necesidad de supervisión en tiempo real
SNMP utiliza las operaciones PULL Model - GetBulk / GetNext que funcionan de manera lineal recorriendo las tablas de una columna a otra hasta. Además, se requieren varias solicitudes en el caso de tablas grandes que no caben en un paquete. Este es el mayor cuello de botella que hace que SNMP se ralentice y los datos que se envían a menudo quedan obsoletos por un cierto factor de tiempo en minutos. Este retraso es sencillamente inaceptable para los requisitos de supervisión de red modernos.
MDT (Model Driven Telemetry) utiliza el modelo PUSH y está intrínsecamente libre de la limitación anterior, ya que sabe qué datos se deben enviar a quién y en qué intervalo. Solo necesita una búsqueda para recopilar datos y utiliza plantillas internas prediseñadas para acelerar las operaciones internas, lo que permite suministrar muchos más datos en un tiempo considerablemente menor.
- Gastos generales adicionales y falta de opciones de optimización
Los datos extraídos por SNMP se almacenan realmente como estructuras de datos internas y el nodo debe convertirlos internamente. Esto supone un trabajo adicional en segundo plano, ya que el nodo de red asigna las estructuras de datos internas al formato SNMP. Se realizan optimizaciones internas; sin embargo, aún no son suficientes.
Por otro lado, la telemetría extrae directamente las estructuras de datos internas y realiza un procesamiento mínimo antes de enviar estos datos, proporcionando así los datos más actualizados con el menor tiempo y esfuerzo posibles.
- Naturaleza lineal de la carga de trabajo
Cada centro de votación adicional generará una carga de trabajo adicional en el nodo, incluso si estamos consultando los mismos datos exactos al mismo tiempo exacto. El acceso paralelo de la misma MIB desde varias estaciones de sondeo puede conducir a una respuesta más lenta y a una mayor utilización de la CPU. Esto es evidente especialmente en el caso de las tablas grandes, donde varias estaciones acceden a diferentes partes de la misma tabla MIB.
Por otra parte, la telemetría necesita extraer los datos una vez y replicar los paquetes si se necesitan los mismos datos para varios destinos. El modelo push supera a SNMP Pull en cuanto a velocidad y escalabilidad.
Con MDT, el enfoque de la recolección de datos cambia radicalmente y sus principios fundamentales se enumeran en la tabla a continuación y se comparan con los puntos clave de la tecnología SNMP.
| ‘Protocolo de administración de red simple (SNMP) | Telemetría basada en modelos (MDT) |
| Información no en tiempo real |
Información en tiempo real |
| Poco escalable |
Muy escalable |
| Modelo Pull |
Push-Model |
| No automatizado |
Preparado para la automatización/Impulsado por el modelo de datos |
Ventajas de la telemetría de streaming
La transmisión de datos de telemetría en tiempo real resulta útil en:
Planificación de capacidad/optimización del tráfico: cuando se supervisa con frecuencia la utilización del ancho de banda y las caídas de paquetes en una red, es más fácil agregar o eliminar enlaces, redirigir el tráfico, modificar la regulación, etc. Con tecnologías como fast reroute, la red puede cambiar a una nueva trayectoria y re-rutear más rápido que el mecanismo de intervalo de sondeo SNMP. La transmisión de datos de telemetría ayuda a proporcionar un tiempo de respuesta rápido para un tráfico más rápido.
Mejor visibilidad: ayuda a detectar y evitar rápidamente las situaciones de fallo que se producen después de una condición problemática en la red.
Especificaciones técnicas de la telemetría basada en modelos
La siguiente sección trata sobre las funciones técnicas y los principales componentes de la telemetría impulsada por modelos IOS XR, también conocida como MDT.
Funciones de telemetría
El marco de telemetría se organiza en tres bloques funcionales separados e interconectados.
El primer bloque se refiere a la representación de datos, que es cómo se organiza a bordo la información que hace referencia al análisis o las mediciones.
El segundo bloque se trata de la codificación. Cada intervalo de muestra, Telemetry traduce los datos de medición anteriores a un formato que se puede serializar a través del cable. Por supuesto, el controlador en el otro extremo debe ser capaz de decodificar los datos para tener una copia idéntica de los datos originales enviados por el dispositivo.
El último bloque es sobre el transporte. Esta es la pila de protocolos que se utiliza para transferir datos entre dispositivos.
En la tabla siguiente se resume la estructura principal de los bloques de creación de la telemetría basada en modelos:
| Función | Componentes |
| Representación de datos |
Modelos de datos YANG |
| Codificación |
Autodescripción de GPB/GPB |
| Transporte |
TCP/gRPC |
Tabla 3 Bloques de creación de telemetría
Componentes de telemetría
Antes de comprender cómo funcionan la telemetría y los componentes de configuración subyacentes, es importante comprender los diferentes componentes de la telemetría para evaluar una configuración óptima. La telemetría se basa en la pila de programación IOS XR, donde un nuevo marco de infraestructura proporciona las capacidades esenciales para la automatización de la red.
YANG se ha convertido recientemente en un estándar para el modelado de datos, y Cisco lo utiliza para formar conjuntos de datos estructurados que se pueden codificar y transportar lo más rápido posible a través de la red. La flexibilidad de YANG ofrece la gran ventaja de ser utilizada también como herramienta de configuración para procesos de automatización. Estos modelos de datos se combinan con formatos de codificación y protocolos de transporte específicos para hacer de MDT una solución completa para Network Analytics.
Para la configuración de la telemetría basada en modelos, el modelo de datos YANG se convierte en un componente crucial para permitir la transmisión de datos necesaria para la recopilación y el análisis.
Pila de programación IOS XR
YANG
Yang se define como "lenguaje de modelado de datos utilizado para modelar datos de configuración, datos de estado y notificaciones para protocolos de administración de redes". Debido a su naturaleza disociada de una arquitectura típica de lenguaje de programación, YANG se puede implementar para interactuar con una gran variedad de herramientas.
La estructura de datos de modelado de YANG se construye en torno al concepto de módulos y submódulos, que define una jerarquía de datos en forma de árbol, que se puede utilizar para varias operaciones, incluidas las acciones de configuración y la gestión de notificaciones.
Existen múltiples fuentes de modelos YANG disponibles para su uso, de las cuales las tres siguientes se consideran principales :
- Modelos nativos/específicos de Cisco
- OpenConfig
- IETF
Modelos específicos de Cisco: también se denominan modelos nativos y los publican varios proveedores de dispositivos, incluido Cisco. Por ejemplo, Cisco-IOS-XR-ptp-oper.yang
Modelos OpenConfig: OpenConfig es un grupo de trabajo informal formado por operadores de red. OpenConfig define modelos YANG comunes que todos los proveedores deben admitir para configurar las funciones críticas. p. ej. openconfig-interfaces.yang
Modelos IETF: IETF también define pocos módulos YANG comunes que describan la configuración básica para interfaces, QOS y definan otros tipos de datos comunes (como Ipv4, IPv6, etc.). p. ej. ietf-syslog-types.yang
Cisco no admite los modelos Openconfig disponibles. Los proveedores convergen en una forma estandarizada de modelar los datos para admitir un entorno de varios proveedores.
Existen tres tipos de modelos Yang:
- Operativo
- Configuración
- Acción
La telemetría solo se preocupa por los modelos Yang operativos que pueden identificarse como *-oper-*.yang.
YANG se define en RFC 7950: https://tools.ietf.org/html/rfc7950.
Codificación
La codificación (o "serialización") traduce los datos (objetos, estado) a un formato que se puede transmitir a través de la red. Cuando el receptor decodifica ("deserializa") los datos, tiene una copia semánticamente idéntica de los datos originales.
Durante las primeras etapas de desarrollo de la telemetría, XML se consideró inicialmente como un formato de codificación de primera elección debido a su estructura basada en etiquetas. Sin embargo, el problema con XML era su estructura de codificación no compacta. Cisco finalmente adoptó GPB (Google Protocol Buffers) porque mejora la eficiencia y la velocidad en las operaciones de codificación.
Existen dos tipos de GPB como opciones de codificación para la transmisión de telemetría:
- GPB compacta
- GPB autodescriptivo
La diferencia principal entre los dos formatos de telemetría GPB es cómo representan y codifican las claves dentro de un flujo de datos de telemetría.
JSON es otro esquema de codificación amigable para humanos disponible que es muy fácil de entender y casi cualquier aplicación será capaz de decodificar.
Desde el punto de vista de la implementación, hay pocos pros y contras de un esquema de codificación. En la sección Directrices de diseño de telemetría se ofrece una comparación de los distintos esquemas de codificación.
Transporte
La telemetría ofrece tres opciones posibles para los protocolos de transporte:
- TCP
- gRPC
- UDP
La telemetría define también dos modos de iniciación diferentes para iniciar una sesión entre el nodo y el colector:
- Marcado de salida
- Marcado de entrada
La diferencia entre los dos modos consiste únicamente en cómo se establece la sesión de transporte.
Durante las sesiones de marcado de salida, el dispositivo inicia la conexión enviando un paquete de sincronización hacia el puerto de servidor preconfigurado. Una vez establecida la conexión, los flujos de datos se alejan inmediatamente del dispositivo.
Para las sesiones de marcado, el router escucha pasivamente un puerto TCP que espera una conexión del servidor.
Sin embargo, una vez que se establece la sesión, el router no es sondeado por el propio servidor porque el dispositivo sigue siendo responsable de las operaciones de envío de datos. En MDT, de hecho, el concepto de sondeo de datos ni siquiera existe.
TCP es, de forma predeterminada, el método de transporte predefinido para la telemetría, ya que es fiable y muy fácil de configurar como opción.
gRPC es un marco de código abierto moderno diseñado para ejecutarse en cualquier entorno. Se basa en HTTP/2 y proporciona un conjunto mejorado y completo de funciones.
Telemetría basada en la cadencia frente a telemetría basada en eventos
Los datos del conjunto de datos suscrito se transmiten al destino en un intervalo periódico configurado o solo cuando se produce un evento. Este comportamiento se basa en si MDT está configurado para la telemetría basada en cadencia o la telemetría basada en eventos.
La configuración de la telemetría basada en eventos es similar a la de la telemetría basada en cadencia, con solo el intervalo de muestra como diferenciador. Si se configura el valor del intervalo de ejemplo en cero, se establece la suscripción para la telemetría basada en eventos; si se configura el intervalo en cualquier valor distinto de cero, se establece la suscripción para la telemetría basada en cadencia.
Se recomienda utilizar la telemetría orientada a eventos para eventos relacionados con cambios.
Directrices de diseño de telemetría
Como se ha explicado, hay muchos componentes en la pila de telemetría; a continuación se ofrecen un par de directrices que se deben tener en cuenta al implementar la telemetría en los dispositivos XR.
Cómo seleccionar un esquema de codificación
Como se ha indicado, la codificación o serialización convierte los datos (objetos, estado) en un formato que se puede transmitir a través de la red. Cuando el receptor decodifica o deserializa los datos, tiene una copia semánticamente idéntica de los datos originales.
Diversas opciones de codificación varían en eficacia de cable y facilidad de uso.
| Codificación | Breve Descripción | Eficacia en el cableado | Otras consideraciones |
| GPB (compacto) | Todo binario (Excepto los valores que son cadenas) 2 veces más rápido, operativamente más complejo (pero no en relación con SNMP) |
Alto | Archivo Proto por modelo |
| GPB - KV (par clave-valor) | Claves de cadena y valores binarios (excepto los valores que son cadenas) 3 veces más grande, Modelos nativos: aún se necesita heurística para los nombres de clave |
Medio a bajo | Archivo .proto único para descodificación |
| JSON | Cadenas de Todo: Claves y Valores | Bajo | Amable. Fácil de leer, fácil de analizar y fácil de usar |
GPB-KV proporciona un punto medio de equilibrio adecuado para el esquema de codificación.
Con respecto a la longitud del mensaje para el esquema de codificación elegido, a continuación se muestra la comparación en el cable.
Comparación de codificación: longitud del mensaje en bytes
Consideración del diseño de red de transporte
Las diferentes opciones de codificación plantean diferentes requisitos de ancho de banda. Al considerar la telemetría, el operador de red debe encargarse del aprovisionamiento de ancho de banda suficiente de acuerdo con el esquema de codificación elegido. Para tener una idea justa, por debajo del consumo de ancho de banda por comparación de esquema de codificación.
Comparación de ancho de banda de red
Cisco recomienda utilizar KV-GPB. Actúa como un buen punto medio entre la eficiencia y la comodidad.
Evaluación de opciones de configuración de telemetría
Al configurar la telemetría basada en modelos, el operador debe conocer todos los componentes implicados en la telemetría. Según las opciones disponibles para transporte, codificación y la dirección de transmisión como se detalla anteriormente, se puede elegir la combinación que mejor se adapte a un entorno.
Los cuatro componentes clave son
- Transporte
- Codificación
- Dirección de sesión
- Modelos de datos YANG
Transporte: Como se ha indicado, el nodo puede enviar datos de telemetría a través de TCP, UDP o gRPC a través de HTTP/2.
Mientras que TCP es la opción preferida por la simplicidad, gRPC ofrece la capacidad opcional de TLS que puede considerarse como una ventaja adicional desde el punto de vista de la seguridad.
Codificación: El router puede proporcionar datos de telemetría en dos tipos diferentes de búferes de protocolo de Google: compactos y autodescriptivos GPB.
Compact GPB es la codificación más eficiente pero requiere un .proto único para cada modelo YANG que se transmite. La GPB autodescriptiva es menos eficiente, pero utiliza un único archivo .proto para descodificar todos los modelos YANG porque las claves se pasan como cadenas en el .proto.
Dirección de la sesión: Hay dos opciones para iniciar la sesión en la implementación de telemetría. El router puede "marcar" hacia el colector o el colector puede "marcar" hacia el router.
YANG es el estándar aceptado en el sector para el modelado de datos y Cisco Programmability Stack también lo utiliza para formar conjuntos de datos estructurados que se pueden codificar y transportar lo más rápido posible a través de la red.
Estos modelos de datos, junto con los formatos de codificación y protocolos de transporte específicos descritos anteriormente, convierten a la telemetría dirigida por modelos (MDT) en una solución completa para el análisis.
Ejemplos de Configuración de Telemetría
IOS-XR
División de la configuración de marcación de salida
En el modo Dial-Out, el router es responsable de iniciar una sesión TCP al colector y envía datos que son especificados por el grupo de sensores en la suscripción.
Marcación de salida de telemetríaDesde el punto de vista de la configuración, la configuración de telemetría es un proceso de tres pasos. En primer lugar, identificamos la información que queremos transmitir y capturar en la configuración del Grupo de sensores. En segundo lugar, identificamos el destino al que debe transmitirse la información y lo capturamos en la configuración del grupo de destino. En tercer lugar, utilizamos la información identificada en los dos pasos anteriores para configurar la suscripción real.
- Definir grupos de sensores
- Definir grupos de destino
- Definir suscripción
Definir grupos de sensores
La configuración del grupo de sensores identifica la información que se va a transmitir. La siguiente plantilla de configuración proporciona la configuración necesaria para configurar grupos de sensores.
RP/0/RP0/CPU0:XR# RP/0/RP0/CPU0:XR#config RP/0/RP0/CPU0:XR(config)#telemetry model-driven RP/0/RP0/CPU0:XR(config-model-driven)#sensor-group <Sensor-Group-Name> RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# sensor-path <Sensor-Path> RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# commit RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# end RP/0/RP0/CPU0:XR#
El siguiente ejemplo muestra un ejemplo real de la CLI del router, donde un ejemplo real de la configuración del Grupo de Sensores:
RP/0/RP0/CPU0:XR# RP/0/RP0/CPU0:XR#config RP/0/RP0/CPU0:XR(config)#telemetry model-driven RP/0/RP0/CPU0:XR(config-model-driven)#sensor-group SensorGroup101 RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# sensor-path Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# commit RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# end RP/0/RP0/CPU0:XR#
Podemos tener varias trayectorias de sensor como parte de la misma definición de grupo de sensor:
RP/0/RP0/CPU0:XR# RP/0/RP0/CPU0:XR#config RP/0/RP0/CPU0:XR(config)#telemetry model-driven RP/0/RP0/CPU0:XR(config-model-driven)#sensor-group SensorGroup101 RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# sensor-path sensor-path Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/data-rate RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# sensor-path Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# commit RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# end RP/0/RP0/CPU0:XR#
Definir grupos de destino
La configuración del grupo de destino identifica el destino en el que se transmitirá la información.
Tiene tres parámetros clave
- Dirección de sesión
- Codificación a utilizar
- Protocolo de transporte que se utilizará
Debajo tiene un ejemplo:
RP/0/RP0/CPU0:XR# RP/0/RP0/CPU0:XR#config RP/0/RP0/CPU0:XR(config)# telemetry model-driven RP/0/RP0/CPU0:XR(config-model-driven)# destination-group DestGroup101 RP/0/RP0/CPU0:XR(config-model-driven-dest)# address family ipv4 10.1.1.1 port 5432 RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)# encoding self-describing-gpb RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)# protocol tcp RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)# commit RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# end RP/0/RP0/CPU0:XR#
Definición de la suscripción
La suscripción enlaza la información del Grupo de sensores y del Grupo de destino como la parte final de la configuración. El intervalo de muestra se define como parte de la suscripción.
Debajo tiene un ejemplo:
RP/0/RP0/CPU0:XR# RP/0/RP0/CPU0:XR#config RP/0/RP0/CPU0:XR(config)telemetry model-driven RP/0/RP0/CPU0:XR(config-model-driven)#subscription Subscription101 RP/0/RP0/CPU0:XR(config-model-driven-subs)#sensor-group-id SensorGroup101 sample-interval 30000 RP/0/RP0/CPU0:XR(config-model-driven-subs)#destination-id DestGroup101 RP/0/RP0/CPU0:XR(config-model-driven-subs)# commit RP/0/RP0/CPU0:XR(config-model-driven-subs)# end RP/0/RP0/CPU0:XR#
Ejemplo de configuración completa
RP/0/RP0/CPU0:XR# RP/0/RP0/CPU0:XR#conf RP/0/RP0/CPU0:XR(config)# RP/0/RP0/CPU0:XR(config)#telemetry model-driven RP/0/RP0/CPU0:XR(config-model-driven)#sensor-group SensorGroup101 RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# sensor-path Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)#destination-group DestGroup101 RP/0/RP0/CPU0:XR(config-model-driven-dest)#address family ipv4 10.1.1.2 port 5432 RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#encoding self-describing-gpb RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#protocol tcp RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#subscription Subscription101 RP/0/RP0/CPU0:XR(config-model-driven-subs)#sensor-group-id SensorGroup101 sample-interval 30000 RP/0/RP0/CPU0:XR(config-model-driven-subs)#destination-id DestGroup101 RP/0/RP0/CPU0:XR(config-model-driven-subs)#commit RP/0/RP0/CPU0:XR(config-model-driven-subs)#end RP/0/RP0/CPU0:XR#
Ventajas de la marcación de salida
- Mayor flexibilidad para las opciones de transporte.
- No es necesario abrir puertos para el tráfico de gestión entrante.
- Anycast y equilibrio de carga.
Distribución de la configuración de marcación
En el modo Dial-In, un colector/receptor/orquestador MDT marca al router y se suscribe dinámicamente a una o más trayectorias o suscripciones del sensor. El router actúa como el servidor y el cliente como el receptor.
Solo se forma una única sesión y el router transmite datos de telemetría a través de la misma sesión. Esta suscripción dinámica finaliza cuando el receptor cancela la suscripción o cuando finaliza la sesión.
Marcado de entrada de telemetría
Dado que el recopilador "marca" al router, no es necesario especificar cada destino MDT en la configuración. Simplemente habilite el servicio gRPC en el router, conecte su cliente y habilite dinámicamente la suscripción de telemetría que desee.
Desde el punto de vista de la configuración, la configuración de telemetría es un proceso de tres pasos similar al descrito anteriormente. En primer lugar, necesitamos habilitar gRPC. En segundo lugar, identificamos el destino al que debe transmitirse la información y la capturamos en la configuración del grupo de sensores. En tercer lugar, utilizamos la información identificada en los dos pasos anteriores para configurar la suscripción real.
- Habilitar gRPC
- Definir grupos de sensores
- Definir suscripción
Habilitar gRPC
En primer lugar, necesitamos habilitar el servidor gRPC en el router para aceptar las conexiones entrantes del colector.
- El intervalo <port-number> va de 57344 a 57999. Si un número de puerto no está disponible, se muestra un error.
RP/0/RP0/CPU0:XR#config RP/0/RP0/CPU0:XR(config)# grpc RP/0/RP0/CPU0:XR(config-grpc)#port 57890 RP/0/RP0/CPU0:XR(config-grpc)#commit RP/0/RP0/CPU0:XR(config-grpc)#end RP/0/RP0/CPU0:XR#
Definir grupos de sensores
La configuración del grupo de sensores identifica la información que se va a transmitir. La siguiente plantilla de configuración proporciona la configuración necesaria para configurar grupos de sensores.
El siguiente ejemplo muestra un ejemplo real de la CLI del router, donde un ejemplo real de la configuración del Grupo de sensores
RP/0/RP0/CPU0:XR# RP/0/RP0/CPU0:XR#config RP/0/RP0/CPU0:XR(config)#telemetry model-driven RP/0/RP0/CPU0:XR(config-model-driven)#sensor-group SensorGroup101 RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# sensor-path openconfig-interfaces:interfaces/interface RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# commit RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# end RP/0/RP0/CPU0:XR#
Definición de la suscripción
La suscripción enlaza el Grupo de sensores y gRPC como la pieza final de la configuración. El intervalo de muestra se define como parte de la suscripción.
La siguiente plantilla de configuración proporciona la configuración necesaria para configurar la suscripción.
El siguiente ejemplo muestra un ejemplo real de la CLI del router en el que se crea una suscripción y se enlazan el grupo de sensores y el grupo de destino, y también se define la velocidad de muestreo.
RP/0/RP0/CPU0:XR# RP/0/RP0/CPU0:XR#config RP/0/RP0/CPU0:XR(config)telemetry model-driven RP/0/RP0/CPU0:XR(config-model-driven)#subscription Subscription101 RP/0/RP0/CPU0:XR(config-model-driven-subs)#sensor-group-id SensorGroup101 sample-interval 30000 RP/0/RP0/CPU0:XR(config-model-driven-subs)# commit RP/0/RP0/CPU0:XR(config-model-driven-subs)# end RP/0/RP0/CPU0:XR#
Plantilla de configuración completa y ejemplo
RP/0/RP0/CPU0:XR# RP/0/RP0/CPU0:XR#config RP/0/RP0/CPU0:XR(config)# grpc RP/0/RP0/CPU0:XR(config-grpc)#port 57890 RP/0/RP0/CPU0:XR(config-grpc)telemetry model-driven RP/0/RP0/CPU0:XR(config-model-driven)#subscription Subscription101 RP/0/RP0/CPU0:XR(config-model-driven-subs)#sensor-group-id SensorGroup101 sample-interval 30000 RP/0/RP0/CPU0:XR(config-model-driven-subs)# commit RP/0/RP0/CPU0:XR(config-model-driven-subs)# end RP/0/RP0/CPU0:XR#
Ventajas de la marcación entrante
- Un único canal para la configuración y la transmisión
- Puerto de escucha en el router/dispositivo
- Conexión transitoria
- Actualmente sólo gRPC/gNMI disponible
Telemetría basada en eventos
En la telemetría controlada por eventos, los datos del conjunto de datos suscrito se transmiten sólo cuando se produce un evento.
Configuración de telemetría basada en eventos
La configuración de la telemetría basada en eventos es similar a la de la telemetría basada en cadencia, con la única diferencia en la configuración de la telemetría basada en eventos es la del intervalo de ejemplo. Si se configura el valor del intervalo de ejemplo en cero, se establece la suscripción para la telemetría basada en eventos.
Plantilla de configuración completa y ejemplo de DIAL-OUT
RP/0/RP0/CPU0:XR# RP/0/RP0/CPU0:XR#conf RP/0/RP0/CPU0:XR(config)# RP/0/RP0/CPU0:XR(config)#telemetry model-driven RP/0/RP0/CPU0:XR(config-model-driven)#sensor-group <Sensor-Group-Name> RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# sensor-path <Sensor-Path> RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)#destination-group <Destination-Group-Name> RP/0/RP0/CPU0:XR(config-model-driven-dest)#address family ipv4 <Destination-IP> port <Destination-Port> RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#encoding <Encoding-Type> RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#protocol <Transport-Protocol> RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#subscription <Subscription-Name> RP/0/RP0/CPU0:XR(config-model-driven-subs)#sensor-group-id <Sensor-Group-Name> sample-interval <0> RP/0/RP0/CPU0:XR(config-model-driven-subs)#destination-id <Destination-Group-Name> RP/0/RP0/CPU0:XR(config-model-driven-subs)#commit RP/0/RP0/CPU0:XR(config-model-driven-subs)#end RP/0/RP0/CPU0:XR#
El siguiente ejemplo muestra un ejemplo real de la CLI del router.
RP/0/RP0/CPU0:XR# RP/0/RP0/CPU0:XR#conf RP/0/RP0/CPU0:XR(config)# RP/0/RP0/CPU0:XR(config)#telemetry model-driven RP/0/RP0/CPU0:XR(config-model-driven)#sensor-group SensorGroup101 RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# sensor-path Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)#destination-group DestGroup101 RP/0/RP0/CPU0:XR(config-model-driven-dest)#address family ipv4 10.1.1.2 port 5432 RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#encoding self-describing-gpb RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#protocol tcp RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#subscription Subscription101 RP/0/RP0/CPU0:XR(config-model-driven-subs)#sensor-group-id SensorGroup101 sample-interval 0 RP/0/RP0/CPU0:XR(config-model-driven-subs)#destination-id DestGroup101 RP/0/RP0/CPU0:XR(config-model-driven-subs)#commit RP/0/RP0/CPU0:XR(config-model-driven-subs)#end RP/0/RP0/CPU0:XR#
Plantilla de configuración completa y ejemplo de DIAL-IN
RP/0/RP0/CPU0:XR# RP/0/RP0/CPU0:XR#config RP/0/RP0/CPU0:XR(config)# grpc RP/0/RP0/CPU0:XR(config-grpc)#port <port-number> RP/0/RP0/CPU0:XR(config-grpc)telemetry model-driven RP/0/RP0/CPU0:XR(config-model-driven)#subscription <Subscription-Name> RP/0/RP0/CPU0:XR(config-model-driven-subs)#sensor-group-id <Sensor-Group-Name> sample-interval <0> RP/0/RP0/CPU0:XR(config-model-driven-subs)#commit RP/0/RP0/CPU0:XR(config-model-driven-subs)#end RP/0/RP0/CPU0:XR#
El siguiente ejemplo muestra un ejemplo real de la CLI del router.
RP/0/RP0/CPU0:XR# RP/0/RP0/CPU0:XR#config RP/0/RP0/CPU0:XR(config)# grpc RP/0/RP0/CPU0:XR(config-grpc)#port 57890 RP/0/RP0/CPU0:XR(config-grpc)telemetry model-driven RP/0/RP0/CPU0:XR(config-model-driven)#subscription Subscription101 RP/0/RP0/CPU0:XR(config-model-driven-subs)#sensor-group-id SensorGroup101 sample-interval 0 RP/0/RP0/CPU0:XR(config-model-driven-subs)# commit RP/0/RP0/CPU0:XR(config-model-driven-subs)# end RP/0/RP0/CPU0:XR#
Validación de Telemetría con Comandos SHOW
Desde el punto de vista del router, podemos verificar los parámetros configurados para cada grupo de sensores, grupo de destino y suscripción
// ALL CONFIGURED SUBSCRIPTIONS
RP/0/RP0/CPU0:XR#show telemetry model-driven subscription
Subscription: Subscription101 State: ACTIVE
-------------
Sensor groups:
Id Interval(ms) State
SensorGroup101 30000 Resolved
Destination Groups:
Id Encoding Transport State Port IP
DestGroup101 self-describing-gpb tcp Active 5432 172.16.128.3
// DETAILS ON A PARTICULAR SUBSCRIPTION
RP/0/RP0/CPU0:XR#show telemetry model-driven subscription Subscription101
Subscription: Subscription101
-------------
State: ACTIVE
Sensor groups:
Id: SensorGroup101
Sample Interval: 30000 ms
Sensor Path: Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters
Sensor Path State: Resolved
Destination Groups:
Group Id: DestGroup101
Destination IP: 172.16.128.3
Destination Port: 5432
Encoding: self-describing-gpb
Transport: tcp
State: Active
Total bytes sent: 4893
Total packets sent: 1
Last Sent time: 2019-11-01 10:04:11.2378949664 +0000
Collection Groups:
------------------
Id: 1
Sample Interval: 30000 ms
Encoding: self-describing-gpb
Num of collection: 5
Collection time: Min: 6 ms Max: 29 ms
Total time: Min: 6 ms Avg: 12 ms Max: 29 ms
Total Deferred: 0
Total Send Errors: 0
Total Send Drops: 0
Total Other Errors: 0
Last Collection Start:2019-11-01 10:06:11.2499000664 +0000
Last Collection End: 2019-11-01 10:06:11.2499006664 +0000
Sensor Path: Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters
RP/0/RP0/CPU0:XR#
// ALL CONFIGURED DESTINATIONS
RP/0/RP0/CPU0:XR#show telemetry model-driven destination
Group Id IP Port Encoding Transport State
-----------------------------------------------------------------------------
DestGroup101 172.16.128.3 5432 self-describing-gpb tcp Active
RP/0/RP0/CPU0:XR#
// PARTICULAR DESTINATION
RP/0/RP0/CPU0:XR#show telemetry model-driven destination DestGroup101
Destination Group: DestGroup101
-----------------
Destination IP: 172.16.128.3
Destination Port: 5432
State: Active
Encoding: self-describing-gpb
Transport: tcp
Total bytes sent: 83181
Total packets sent: 17
Last Sent time: 2019-11-01 10:12:11.2859133664 +0000
Collection Groups:
------------------
Id: 1
Sample Interval: 30000 ms
Encoding: self-describing-gpb
Num of collection: 17
Collection time: Min: 5 ms Max: 29 ms
Total time: Min: 6 ms Max: 29 ms Avg: 10 ms
Total Deferred: 0
Total Send Errors: 0
Total Send Drops: 0
Total Other Errors: 0
Last Collection Start:2019-11-01 10:12:11.2859128664 +0000
Last Collection End: 2019-11-01 10:12:11.2859134664 +0000
Sensor Path: Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters
RP/0/RP0/CPU0:XR#
// ALL CONFIGURED SENSOR GROUPS
RP/0/RP0/CPU0:XR#show telemetry model-driven sensor-group
Sensor Group Id:SensorGroup101
Sensor Path: Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters
Sensor Path State: Resolved
// PARTICULAR SENSOR GROUPS
RP/0/RP0/CPU0:XR#show telemetry model-driven sensor-group SensorGroup101
Sensor Group Id:SensorGroup101
Sensor Path: Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters
Sensor Path State: Resolved
RP/0/RP0/CPU0:XR#
Pila de recopilación de telemetría
Además de la configuración del router, una solución basada en telemetría requería varios componentes, como recopilador, base de datos y software de supervisión/análisis. Estos componentes se pueden configurar por separado o pueden formar parte de un único producto completo.
- Se debe instalar un decodificador para tomar los paquetes entrantes y pasarlos para su almacenamiento posterior.
- Se requiere una base de datos de series de tiempo (también denominada TSDB) para almacenar la información transmitida.
- También se necesita una herramienta gráfica para visualizar los datos tomados de la base de datos interna.
No es posible describir la pila de recopilación en detalle. Cisco Crossworks Health Insights permite la telemetría sin intervención del usuario, en la que los dispositivos se aprovisionan automáticamente con la configuración de telemetría y las tablas/esquemas se crean en una base de datos de series temporales (TSDB). Simplifica la sobrecarga operativa y de gestión de red de la recopilación y limpieza de datos, lo que permite a los operadores centrarse en sus objetivos empresariales. El uso de un recopilador común para recopilar datos de dispositivos de red a través de SNMP, CLI y la telemetría basada en modelos permite evitar la duplicación de datos y también reduce la carga en los dispositivos y la red.
Consideraciones sobre la implementación de la telemetría en una red
A continuación, se describen algunos aspectos que se deben tener en cuenta al analizar la implementación de la telemetría en una red.
Escalabilidad
La telemetría puede transmitir una cantidad considerable de datos y se recomienda considerar cuidadosamente los aspectos de escalabilidad.
Transmitir solo los datos necesarios
Cada modelo Yang tendrá múltiples nodos de hoja. Se aconseja ser específico sobre la información que se requiere y la información que no se requiere. Se recomienda explorar los modelos Yang e identificar la ruta de datos requerida por los casos prácticos de telemetría.
Consideración de la cantidad de datos de transmisión
La cantidad total de datos de telemetría que se transmiten debe tener en cuenta los siguientes puntos:
- Asignación del ancho de banda dentro de la red
- QoS
- Rendimiento de aplicaciones/software adicionales como
- Software recopilador
- Base de datos Time Series
- Software de análisis/visualización
- La eficacia de la codificación (descrita en la sección "Directrices de diseño de telemetría") afecta directamente a la cantidad de datos que se transmiten. Siempre que sea posible, se recomienda utilizar GPB compactas.
- El intervalo de recopilación afecta directamente a varios aspectos, entre los que se incluyen los siguientes.
- Utilización del ancho de banda en la red
- Requisitos de almacenamiento en la base de datos
- Rendimiento del dispositivo que transmite los datos
Se recomienda evaluar la frecuencia de la recolección en función de los requisitos de la aplicación.
En general, se recomienda considerar el filtrado de datos no deseados en el origen o el destino como factible. Tenemos la opción de filtrar datos no deseados. El filtrado se puede realizar en dos niveles:
- En el origen: los dispositivos que transmiten los datos.
- En el destino: el recopilador que recopila y normaliza los datos. (El filtrado en el recopilador está fuera del alcance de este documento)
En el siguiente ejemplo, se muestran los datos que se están filtrando sólo para las interfaces de Hundered Gig dentro de las rutas del sensor mediante la aplicación de caracteres comodín.
sensor-path Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface[interface-name='HundredGigE*']/latest/generic-counters
Referencias
https://blogs.cisco.com/sp/the-limits-of-snmp
https://blogs.cisco.com/sp/why-you-should-care-about-model-driven-telemetry
https://www.cisco.com/c/en/us/td/docs/iosxr/asr9000/telemetry/b-telemetry-cg-asr9000-61x.html
Historial de revisiones
| Revisión | Fecha de publicación | Comentarios |
|---|---|---|
1.0 |
04-Mar-2020 |
Versión inicial |
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)