Contenido

Introducción

Destinatarios

Breve introducción a la telemetría

Por qué telemetría

La necesidad de alejarse de SNMP

Ventajas de la telemetría de streaming

Especificaciones técnicas de la telemetría basada en modelos

Funciones de telemetría

Componentes de telemetría

YANG

Codificación

Transporte

Telemetría basada en la cadencia frente a telemetría basada en eventos

Directrices de diseño de telemetría

Cómo seleccionar un esquema de codificación

Consideración del diseño de red de transporte

Evaluación de opciones de configuración de telemetría

Ejemplos de Configuración de Telemetría

IOS-XR

División de la configuración de marcación de salida

Definir grupos de sensores

Definir grupos de destino

Definición de la suscripción

Ejemplo de configuración completa

Ventajas de la marcación de salida

Distribución de la configuración de marcación

Habilitar gRPC

Definir grupos de sensores

Definición de la suscripción

Plantilla de configuración completa y ejemplo

Ventajas de la marcación entrante

Telemetría basada en eventos

Configuración de telemetría basada en eventos

Plantilla de configuración completa y ejemplo de DIAL-OUT

Plantilla de configuración completa y ejemplo de DIAL-IN

Validación de Telemetría con Comandos SHOW

Pila de recopilación de telemetría

Consideraciones sobre la implementación de la telemetría en una red

Escalabilidad

Transmitir solo los datos necesarios

Consideración de la cantidad de datos de transmisión

Referencias

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:

1. Operativo

2. Configuración

3. 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:

1. GPB compacta

2. 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

1. Transporte

2. Codificación

3. Dirección de sesión

4. 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.

1. Definir grupos de sensores

2. Definir grupos de destino

3. 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

1. Dirección de sesión

2. Codificación a utilizar

3. 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.

1. Habilitar gRPC

2. Definir grupos de sensores

3. Definir suscripción

Haga clic para expandir (Destaque para leer)

El modo de marcado sólo se admite con gRPC

El modo de marcado sólo se admite con gRPC

Habilitar gRPC

En primer lugar, necesitamos habilitar el servidor gRPC en el router para aceptar las conexiones entrantes del colector.

Haga clic para expandir (Destaque para leer)

- El intervalo <port-number> va de 57344 a 57999. Si un número de puerto no está disponible, se muestra un error.

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:

1. Asignación del ancho de banda dentro de la red

2. QoS

3. Rendimiento de aplicaciones/software adicionales como

- Software recopilador

- Base de datos Time Series

- Software de análisis/visualización

4. 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.

5. El intervalo de recopilación afecta directamente a varios aspectos, entre los que se incluyen los siguientes.

1. Utilización del ancho de banda en la red

2. Requisitos de almacenamiento en la base de datos

3. 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:

1. En el origen: los dispositivos que transmiten los datos.

2. 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