Observabilidad

Zonas

NorthStar es una controladora de subyacente de MPLS y una superposición selectiva. Su Genesis está arraigada en el auge de la centralización de la política y el control de tráfico. En lugar de tener que destinarse a ser un único panel de cristal, se illusory a tierra mediante la implementación de una funcionalidad de ingeniería de tráfico bien definida.

Esta concentración de este capítulo no estará administrando NorthStar, pero permitir que una implementación existente agregue valor a una red de SR.

A su vez, también nos centraremos en tierra. En primer lugar’, se va a ver la red creada hasta ese momento. Nueva familia de direcciones BGP– link-state –estará habilitado entre los enrutadores de borde de área (ABR’) y Northstar Junos máquina virtual. Esto exporta la topología para cada nodo de – área, vínculos, atributos de vínculo y prefijos. Tanto Junos como NorthStar se han mejorado para admitir la exportación de capacidades específicas de SR, como los SID rango de SRGB, nodo y adyacencia.

Aplique la siguiente configuración a los abr en Nueva York y Washington – P1. NYC, P2. NYC, P1. IAD y P2. IAD, sustituyendo los valores específicos de los enrutadores según corresponda. Esto proporciona redundancia, ya que configura todos los Abr de una región para exportar la topología específica de área; también garantiza la cobertura de toda la red de múltiples niveles:

Echemos’un vistazo a lo que P1. NYC exporta de sus dos áreas. ’Revisamos un ejemplo de cada uno de los nodos, enlaces y prefijos, y cómo esa información se ha enriquecido con atributos de Sr.

Control plane: p1.nyc exporting pe2.nyc as a node, as well as its SR attributes

Control Plane: p1.nyc exporting the link between itself and pe1.nyc, and its local adjacency SID

Control plane: p1.nyc exporting pe2.iad’s prefix and associated SID index

La suma total del BGP-LS de Exchange permite a NorthStar construir un gráfico de la red tal y como Figure 1 se Figure 2muestra en el y el.

Figure 1: Vista topológica con ASNs descubierto tras el análisis de la configuración del dispositivo

Figure 2: Colección de dispositivos NorthStar

Además de deshacer la serialización ‘de las’ rutas BGP-LS, Northstar puede recopilar, a través de NETCONF, y analizar la configuración del dispositivo. Para ello, puede recorrer el menú de’ti s en la parte superior derecha (administración > programador de tareas > agregar > colección de dispositivos). Asegúrese de especificar credenciales de usuario’que no sean raíz.

La recopilación de la configuración del dispositivo es opcional, pero mejora la experiencia del usuario. Por ejemplo, los ASNs a los que se adjunta nuestra red se hacen visibles en la IU. Puede profundizar en los VRFs VPN de capa 3 para descubrir sus PEs, los circuitos de conexión y los destinos de ruta. ’Estas no son las indicaciones exportadas por BGP-LS. El análisis de la configuración presenta a los operadores varios aspectos de su red.

Pero se trata de un libro sobre el enrutamiento segmentado. NorthStar tiene varias visualizaciones valiosas y específicas de SR. Cada vínculo puede mostrar no solo una dirección IP, sino también su SID de adyacencia asignado localmente. Puede seleccionar esto haciendo clic en el icono de engranaje del espacio de trabajo (debajo de los botones de Figure 3+/-zoom). Desde ahí, elija vínculos > Mostrar etiqueta > IP, SID A:: Z.

Figure 3: Vista topológica de Northstar con SID adyacentes seleccionado

Otra característica muy útil es hacer clic con el botón secundario del mouse (ratón) en un enrutador y seleccionar los SID del nodo seleccionado. Las etiquetas del otro enrutador cambian para mostrar el SID del nodo junto a su nombre de host. Esto se produce agregando el’índice de cada nodo (solo IPv4 en el momento) al sRGB anunciado de los vecinos del’enrutador.

Como práctica recomendada, la base y tamaño SRGB se han mantenido coherentes en nuestra red. En las redes en las’que no se’puede seguir este caso, esta característica solo puede ser Lifesaver.

Hacemos’una pausa en nuestra exploración de Northstar como herramienta de visualización. Siempre’nos devolvemos en su trabajo diario como un controlador de la ingeniería de tráfico. En este punto, a’partir de este ejercicio de sólo vista, realizamos el cálculo y el aprovisionamiento de las directivas de Sr-te (el nombre apropiado del LSP de Sr-t).

Figure 4: Northstar muestra los SID del nodo basándose en’el único punto de vista de un enrutador

Telemetría

A partir de su propia naturaleza,’ Junos implementación de Sr renuncia a la exportación de estadísticas a través de SNMP. Conocido que es de, SNMP está siendo sustituido por protocolos y marcos ampliamente más eficaces que organizan la información.

En la parte frontal del Protocolo, gRPC obsoletos de SNMP. Hereda las ventajas de HTTP/2, como:

• Binario: A diferencia de Text, la serialización y la anulación de la serialización de los protocolos binarios es más eficiente, compacta y menos propensa a errores en comparación con aspectos tales como el tratamiento de los espacios en blanco. gRPC utiliza búferes de protocolo para codificar y descodificar datos. SNMP utiliza ASN. 1.

• Multiplexaciónde: Esto permite varias solicitudes activas a través de una sola conexión TCP, a la vez que allow to parallelism. En la práctica, SNMP se basa en UDP y hereda su naturaleza no garantizada.

• Bidireccional: A diferencia de su antecesor, HTTP/2 permite al servidor insertar al cliente datos potencialmente útiles, sin necesidad de solicitarlos de forma explícita.

gRPC admite autenticación mutua basada en certificados; la rara vez usada SNMPv3 solo admite la autenticación de claves compartidas. gRPC también ofrece enfoques de publicación y suscripción periódicos e impulsados por eventos. Esto es parecido al sondeo de estadísticas de SNMP’s y se basa en interrupciones no solicitadas para transmitir cambios de estado. Lo que hace gRPC más eficaz es que permite que un cliente exprese su interés en subconjuntos del árbol de información de estado; a medida que el estado cambia, el servidor publica la actualización a – los clientes, lo que’podría incluir un ARP de enrutador o una tabla ND, estado LSP, et al.

A partir de este mejor, el transporte es OpenConfig, una iniciativa para modelar redes de manera neutral con respecto a los proveedores. Se trata de un intento de mejorar el’método de SNMP s de – organizar la información que base de información de administración – (BIA), lo que dio como resultado una escasa compatibilidad con proveedores neutros. Tanto los modelos de datos de configuración como los de funcionamiento se han definido por OpenConfig para – las características más utilizadas BGP, LLDP y, por supuesto, Sr. Otras se quedan en el trabajo.

El protocolo de transporte sólido y la representación intuitiva del modelo de datos facilita la telemetría moderna para el operador.

Por ejemplo, así es cómo se llevaría a cabo tradicionalmente’una encuesta SNMP para el estado operativo de una interfaz. En primer lugar,’tendría que detectarse la interfaz s. Se trata de un valor entero arbitrario que el dispositivo asigna a una interfaz. Todos los contadores y el estado específico de la interfaz se codifican utilizando ese índice. Durante mucho tiempo, el valor de tipo sería el de almacenamiento en caché, posiblemente reasignado y, por lo tanto, el reaprendizaje en el reinicio del dispositivo. Entonces, el estado y los contadores asociados con dicha interfaz tendrían que ser sondeados:

IF-MIB::ifDescr es una abreviatura de uso humano para el OID – subyacente. 1.3.6.1.2.1.2. No todas las ramas del BIA tienen una representación fácil de enseres humanos. Por el contrario, la ruta de acceso del subárbol equivalente con OpenConfig es /interfaces/interface[name=’ge-0/0/0’]/state/oper-status/. No funciona’bien en la lógica para comprender la intención, incluso si el operador no está desconocido inicialmente con esta sintaxis de ruta de acceso X.

Habilitando OpenConfig con transporte gRPC

La habilitación del transporte de gRPC es trivial para fines de pruebas. La habilitación de la TI para la producción implica una sobrecarga en la autenticación basada en certificados. Como resultado, requiere una infraestructura de clave pública (PKI) funcional, concretamente una entidad emisora de certificados (CA), que pueda emitir certificados digitales.

Hay seis pasos necesarios para activar y proteger el gRPC:

1. Crear una instancia de una entidad emisora raíz. Esto se debe hacer en un host x86. El siguiente ejemplo utiliza OpenSSL para crear una clave privada (. Key Extension) y un certificado con firma personal (extensión. CRT).

2. A continuación, generará una clave privada y una solicitud de firma de certificado (CSR, .csr extensión) del cliente gRPC. En nuestro ejemplo, jtimon es el cliente gRPC. El host x86 en el que se ejecuta necesita presentar su identidad a los servidores gRPC (enrutadores) para la autenticación mutua. La entidad emisora creada anteriormente puede aprobar el uso del CSR, lo que genera un certificado para jtimon.

3. Cada enrutador debe generar una clave privada y un CSR. A continuación, la entidad emisora cumplirá cada CSR, como en el paso anterior, generando un certificado para el enrutador respectivo. Tanto el certificado como la clave privada se agrupan (.pem extensión). El ejemplo siguiente corresponde a PE1. NYC:

4. Las tres identidades – , la entidad’emisora raíz y los’jtimon de host s, así como el’paquete – propio de enrutador, deben copiarse en el /var/tmp Ubicación en cada enrutador. Como ejemplo, esto es lo que resulta de PE1. NYC:

5. Los certificados deben activarse a través de la configuración. El ejemplo siguiente corresponde a PE1. NYC:

6. Por último, gRPC puede habilitarse para escuchar en un puerto seguro y requiere autenticación mutua. Es necesario proporcionar un nombre de usuario y una contraseña jtimon – el usuario debe estar presente en la[system login] jerarquía de configuración del enrutador:

Estrictamente para fines de prueba, puede que desee utilizar gRPC de forma no segura. Hágalo fuera de un entorno de laboratorio bajo su propia responsabilidad. Omita los pasos 1-5 anteriores y reemplace Stanza en el paso 6 por:

SR telemetría

Con este telón de fondo’, explore las estadísticas de Sr que se pueden transmitir por secuencias. El más fundamental es el volumen de tráfico enrutado de segmento que se transmite en tránsito a una interfaz. Durante una migración de otros protocolos de transporte MPLS, este sensor puede distinguir qué parte del plano de envío se ha desplazado a SR.

Puede configurarlo de la siguiente manera:

Esto instala sensores para cada interfaz que tenga un salto siguiente de SR.

Management plane: Verify the OpenConfig sensors have been installed

Ahora puede suscribirse a la ruta de acceso de OpenConfig que exporta estas estadísticas (/MPLS/Signaling-Protocols/Segment-Routing/interfaces/). Configure jtimon mediante un archivo similar al siguiente, sustituyendo las credenciales de autenticación y rutas de la clave privada y los certificados según sea necesario:

La configuración se explica por sí misma. Se solicita al enrutador que publique las estadísticas de la interfaz SR cada 10 segundos. Inicie jtimon y observe qué PE1. NYC informes:

Como un PE de entrada, puede ver que el tráfico IP entrante de CEs se ha enviado con una etiqueta SR a través de la interfaz conectada con P1. nyc. No’se explica que el destino del tráfico es la etiqueta impuesta’t comunicada. Observe que el nombre del contador (oc-84) utiliza un número arbitrario, que no está relacionado con las etiquetas que se utilizan.

Jtimon apuntando a P1. NYC muestra el flujo de tráfico bidireccional. El mismo número de paquetes de entrada y salida GE-0/0/2 y GE-0/0/3 – estas interfaces conectan con PE1. NYC y PE2. NYC, respectivamente:

Como paso final, instrumentando PE2. NYC muestra el tráfico de SR de salida GE-0/0/1, que es una interfaz’local de PE2. NYC s a P1. NYC:

El Eagle-Eyed habrá observado que P1. NYC informa de un tamaño promedio de paquete de 4 bytes mayor que el de – los enrutadores PE que confirman el establecimiento de un único SID de nodo derivado MPLS etiqueta.

Esto es un buen comienzo, por lo que solo podemos obtener más detalle. Las estadísticas por SID, especialmente con una SRGB uniforme a todo el dominio, pueden ser muy útiles para calcular matrices de tráfico. La configuración para permitir esto es:

Management plane: Verify additional OpenConfig sensors have been installed per-SID

Se ha creado una matriz de sensores adicionales. Los nombres de los sensores de entrada por SID corresponden a los nodos IPv4 e IPv6, así como a los SID de adyacencia. En la dirección de salida, se les asigna un nombre basado en el protocolo subyacente y el SID del prefijo anunciado.

Ahora, cambie la ruta de acceso a la que jtimon suscribe: /mpls/signaling-protocols/segment-routing/aggregate-sid-counters/. Los detalles se encuentran entre PE1. NYC, P1. NYC y PE2. NYC para incluir el volumen de tráfico por SID.

Management plane: Per-SID statistics at pe1.nyc

Management plane: Per-SID statistics at p1.nyc

Management plane: Per-SID statistics at pe2.nyc

Lo fantástico de esto es que muestra unerringly cuánto tráfico está destinado desde PE1. NYC a PE2. NYC, y viceversa. Observando P1. NYC’s contadores muestra la cantidad de tráfico destinado a PE1. NYC o PE2. NYC de otros PES. Con un SRGB universal, cada enrutador comparte una comprensión común de la etiqueta asociada con un SID de nodo. Mediante la suma de los contadores asociados al mismo MPLS etiqueta, el operador puede ver cuánto tráfico se envía al creador del SID del nodo a través de cada enrutador de tránsito. Contadores acumulados asociados con un prefijo el SID muestra la cantidad de tráfico que se envía a un enrutador remoto. Esto puede simplificar en gran medida la construcción de matrices de tráfico.

Telemetría de SR-TE

En ningún lugar, la telemetría es más importante que segmentar el tráfico de enrutamiento (SR-TE). Debido al volumen de tráfico dirigido a una directiva – Sr-me que se comunica de manera poco estricta, un LSP – de la Sr-te inicia el ciclo de comentarios que puede utilizar un mecanismo de control centralizado que puede redireccionar el LSP en función de la disponibilidad y las necesidades de ancho de banda.

Para centrarse en su aspecto de telemetría, se ha creado un LSP de SR-TE entre PE2. NYC y PE1. IAD. Se trata de un LSP en color , lo que significa que se le ha asignado un valor numérico arbitrario, significativo y local. Cuando una ruta de servicio se aprende a través de BGP y transporta una comunidad de color extendida con un valor’coincidente, el siguiente salto del protocolo Route s se señala automáticamente a este LSP de Sr-te.

El tráfico destinado a las rutas de servicio que se resuelven sobre el LSP en color se trata como estadísticas de SR-TE. Como antes, la telemetría de SR-TE se ha habilitado específicamente a través de:

Una configuración de LSP de la SR-TE de colores sencilla y en vigor es efectiva:

Management plane: confirm sensor is attached to SR-TE LSP

Control plane: confirm service route points at SR-TE LSP

De forma predeterminada, hay dos sensores conectados a un LSP de la actualización de la la era de la era. El sensor de entrada mide la cantidad de tráfico IP que se dirige a la política, mientras que el sensor de tránsito mide la cantidad de tráfico con etiqueta que se dirige de forma similar a la política. El sensor de tránsito es necesario si el SID de enlace (bSID), otro de forma local y separada del identificador numérico de color, asociado con la Directiva de Sr-te se utiliza para dirigir el tráfico MPLS etiquetado al LSP.

Como sucede con todos los sensores de enrutamiento de segmentos, nada se exporta hasta que se acumulen las estadísticas que no son cero. En cuanto llega el tráfico IP que coincide con la ruta de servicio de color, los contadores aumentan y se publican posteriormente según la frecuencia solicitada por el cliente gRPC.

Management plane: SR-TE IP statistics

El nombre de la Directiva IP, que es intuitivamente, contiene el punto de conexión del LSP, así como su color. Si MPLS el tráfico etiquetado que se había reenviado a este LSP mediante el SID de enlace, el nombre de la Directiva también contendría el identificador bSID. Además, inarguable es’el tratamiento de Sr-s de IPv6 como ciudadano de primera clase en – toda la gama, desde crear una política de Sr-te coloreada hacia un extremo de IPv6, hasta dirigir el tráfico IPv6 hacia ese LSP, terminando con la recepción de telemetría para el esfuerzo.

Telemetría de SR EPE

La última aplicación de la telemetría de SR es with peer out (EPE). En general, un enrutador de límite de sistema autónomo (ASBR) puede asociar una etiqueta a un par BGP, un vínculo específico a una par BGP determinada o un conjunto de BGP iguales del mismo nivel. Esta etiqueta sólo está instalada en el plano’de reenvío de la transmisión s y se exporta a un controlador a través de BGP-LS como un SID EPE. El controlador puede crear políticas de SR-TE que conducen más allá de un ASBR determinado a un interlocutor distintivo, un vínculo único a un igual o incluso a una colección de elementos del mismo nivel.

Tal y como se utilizaba anteriormente, se ha instalado un LSP de SR-TE en PE2. NYC para una par BGP concreta de PE1. IAD. Esto requiere que la etiqueta EPE configurada en PE1. IAD esté presente en la parte inferior de la lista de segmentos en la Directiva de SR-TE. La telemetría de SR-EPE debe estar habilitada explícitamente, tal y como habrá llegado a esperar:

Control plane: confirm sensor is installed for the EPE SID

Traffic matching the colored service route is transmitted, resulting in pe1.iad emitting telemetry for the EPE SID:

MANTENIMIENTO seguros (operaciones, administración, mantenimiento)

La verdad es que mantenimiento seguros suele ser una idea a los ingenieros de redes. La’ti s sólo cuando las cosas se inclinan de lado a producción que llegan mucho más para herramientas que no limitan la vida de la trayectoria de plano de planos, sino que también verifican la higiene del plano de datos.

Esto es aún más importante para SR-TE, ya que elimina la señalización de ruta. En su lugar, lo delega en sBFD (detección de reenvío bidireccional sin problemas). BFD ha sido un "separador" de la detección de errores de ruta de datos. Cada nodo de una relación punto a punto comienza por aprender el discriminador de’otros s, el nodo y el identificador de aplicación en el BFD. Después de esta detección, una sesión de BFD establece para comprobar la conectividad.

sBFD simplifica la BFD al eliminar el protocolo de enlace que se necesita para aprender los discriminadores. En su lugar, el operador asigna al menos un discriminador local a cada nodo de la red. Para establecer sBFD para una ruta de SR-TE, la Head-end se configura con el discriminador del’nodo remoto.

El jefe actúa como el iniciador e inserta la pila de etiqueta de SR-’te en la que se encontraban los paquetes de comprobación de la vida y garantiza que los paquetes atraviesan la misma ruta de acceso que encontrarán el tráfico del usuario; el statelessly de destino de la Directiva SR-TE responde a los paquetes sBFD. La ruta de acceso de SR-TE es viable siempre y cuando la sesión sBFD esté en el enrutador de entrada.

Puede configurar sBFD agregando un discriminador en cada nodo de la red. Supongamos’que s agregue sBFD comprobación de la vida en la ruta IPv4 de Sr-te que hemos definido desde PE2. NYC a PE1. IAD:

Después de agregar esta configuración, la ruta de SR-TE permanecerá activa siempre que sBFD el reenvío entre los dos enrutadores, utilizando la misma pila de etiquetas.

Control plane: Verify pe2.nyc’s sBFD session to pe1.iad is Up

Control plane: Verify pe2.nyc’s SR-TE policy has a valid path

El primer salto utiliza el SID de adyacencia con P1. NYC (21). Si la adyacencia entre PE2. NYC y P1. NYC falters, se dejará de usar esta directiva de SR-TE.

Control plane: Verify the SR-TE policy goes Down if the label stack is rendered unusable

No hay ninguna lista de SID alternativos, lo que se conoce también como ruta, para que la Directiva la utilice. El tráfico de usuario resolverá a través de una ruta que no sea SR-TE, si hay alguna disponible. Por el contrario, las rutas de SR-TE configuradas estáticamente que’no se aprovechan de sBFD siguen siendo engañosas.

Depurabilidad

La telemetría es, pero una parte de la de observación. La solución de problemas de rendimiento y disponibilidad de la red depende tanto de la claridad de los protocolos subyacentes como del diagnóstico y el registro de las implementaciones disponibles.

Minimización de la revisión’s en los enrutadores de tránsito y en el uso de un sRGB uniforme, es más fácil para el usuario analizar las acciones de reenvío de las – etiquetas de SID de nodo, hay menos Grok. Junos se basa en esta simplicidad con una funcionalidad de registro enriquecida para detectar errores humanos.

La sección SRMS dio un ejemplo de cómo se marcaron los SID de nodo configurados incorrectamente. Hay dos tipos distintos de conflictos que SR. de revisión identifica:

1. Conflicto de SID: Esto se detecta si se asignan SID diferentes al mismo prefijo.

2. Conflicto de prefijo: Esto ocurre si hay prefijos distintos asignados al mismo SID.

El ejemplo anterior mostró un conflicto de SID. ’Es posible forzar temporalmente un conflicto de prefijo y usar gRPC para transmitirlo como un evento. Syslog tradicional está todavía disponible por supuesto, pero al igual que ocurre con éxito de gRPC para la telemetría, los eventos ahora se pueden transmitir también a través de gRPC.

Deje’que s configure jtimon para suscribirse a /junos/events/. Para provocar un conflicto de prefijo, PE1. IAD está configurado temporalmente con una dirección de bucle de retroceso adicional que, en realidad, pertenece a P1. IAD (128.49.106.9/32). Esto sería adecuado si estas direcciones se utilizaron para generar un SID común de difusión por proximidad. En su lugar, PE1. IAD se configuró incorrectamente para anunciar un índice de prefijo diferente (99) a P1. IAD (9) con una política de exportación IS-IS.

Control plane: pe1.iad misconfiguration to cause a prefix conflict

Management plane: streamed system event about the prefix conflict

La atención es beckoned y la recitifed de configuración no es la más importante. SR especifica una serie de reglas de ruptura de las empates para abordar el conflicto hasta que tenga lugar una intervención humana. Las reglas evolucionan. En este punto, son:

1. Preferir entradas IPv6 a través de IPv4

2. Preferir longitud de prefijo más larga

3. Preferir la dirección del prefijo más baja numérica

4. Preferir el índice de segmento más bajo numérico

Los conflictos de prefijo se resuelven primero; La resolución de conflictos de SID se muestra a continuación en las entradas pendientes. Con esto, deje’pasar la cara de nuestro análisis a labilidad de observación y avance a la optimización.