Descripción del protocolo de medición activa bidireccional

Soporte de luz TWAMP

TWAMP Light, como se define en el Apéndice I de RFC 5357, es una versión sin estado de TWAMP donde los parámetros de prueba están predefinidos en lugar de negociados. Todos los paquetes de prueba recibidos por el servidor en un puerto de prueba se reflejan y se olvidan de inmediato. Para aquellos dispositivos que las admitan, también puede configurar direcciones de destino IPv6, incluidas las direcciones de destino locales de vínculo IPv6.

Utilice Explorador de características: protocolo de medición activa bidireccional para confirmar la compatibilidad de la plataforma y la versión para funciones específicas.

Soporte simple de protocolo de medición activa bidireccional (STAMP)

Como se define en RFC 8762, Protocolo simple de medición activa bidireccional, STAMP estandariza y amplía el modo operativo TWAMP Light, que se definió en el Apéndice I de RFC 5357, Protocolo de medición activa bidireccional (TWAMP). Para aquellos dispositivos que admiten STAMP, un reflector compatible con STAMP garantiza un tamaño de carga simétrico (de acuerdo con RFC 6038) y funciona en modo sin estado o con estado, dependiendo de si el número de secuencia de la carga reflejada se copia del marco de cliente o se genera de forma independiente. Un reflector de estado puede detectar en qué dirección se han producido las caídas. En versiones anteriores, admitíamos cargas simétricas y reflexión sin estado. Apoyamos la reflexión con estado, el cumplimiento total del estándar STAMP y los valores de caída unidireccionales para los clientes. Admitimos valores de caída unidireccionales no solo para clientes STAMP, sino también para clientes en modo administrado TWAMP. Para Junos OS Evolved, STAMP se configura en el [edit services monitoring twamp server light] nivel de jerarquía. La reflexión de estado se configura con la stateful-sequence instrucción. Para los servidores, el nuevo valor predeterminado para offload-type ahora es en pfe-timestamp lugar de inline-timestamp.

Utilice el Explorador de funciones: Protocolo simple de medición activa bidireccional (STAMP) para confirmar la compatibilidad con la plataforma y la versión.

Rastreo de rutas estáticas

A partir de la versión 24.4R1 de Junos OS evolucionado, extendimos el soporte para el seguimiento de rutas estáticas a Junos OS evolucionado e incluimos soporte para pruebas de protocolo de medición activa bidireccional (TWAMP). Los sondeos TWAMP se utilizan para detectar el estado de los vínculos y cambiar el estado de la ruta preferida en función de los resultados del sondeo. Las rutas estáticas con seguimiento pueden ser IPv4 o IPv6, y cada ruta estática con seguimiento IPv4 e IPv6 admite hasta 16 saltos siguientes. También puede configurar la métrica, la preferencia de ruta y los valores de etiqueta para cada prefijo de destino IPv4 o IPv6. Sin embargo, esta función se configura de forma diferente en dispositivos Junos OS evolucionados; La instrucción se configura sla-tracking en el nivel de [edit routing-options] jerarquía. También utilice un comando diferente, show route sla-tracking, para ver información sobre estas rutas.

Soporte de enrutamiento por segmentos para configurar rutas

A partir de la versión 24.4R1 de Junos OS evolucionado para los enrutadores PTX que lo admiten y en la versión 25.4R1 de Junos OS para los enrutadores MX que lo admiten, agregamos soporte en el protocolo de medición activa bidireccional (TWAMP) para el enrutamiento por segmentos (SR) como se define en RFC 8402, que especifica ampliamente la arquitectura de SR. Admitimos dos tipos de SR para sondas TWAMP:

• SR-MPLS: Usa una lista de etiquetas, cada una de las cuales representa un nodo final de segmento.

• SRv6: Utiliza un encabezado de enrutamiento IPv6 tipo 4 introducido en RFC 8754, con cada nodo final de segmento representado como una dirección IPv6 o un identificador de segmento IPv6 (SID).

Puede especificar la lista de segmentos SR-MPLS o SRv6 para que una sonda TWAMP llegue al reflector. Además, puede especificar la misma información para la ruta de retorno desde el reflector hasta el cliente. Esta información de ruta de retorno se incrusta en la propia sonda mediante el uso de las extensiones propuestas en Extensiones TWAMP simple (STAMP) para redes de enrutamiento por segmentos, draft-ietf-ippm-stamp-srpm, es decir, el TLV de ruta de retorno y sus subTLV de lista de segmentos de retorno, según corresponda según el tipo de enrutamiento de segmentos. Los sondeos TWAMP tienen marca de tiempo en el motor de enrutamiento o en el motor de reenvío de paquetes.

Para configurar esta función para Junos OS Evolved, incluya la source-routing instrucción en el nivel de [edit services monitoring twamp client control-connection name test-session session-name] jerarquía. Para configurar esta función para Junos OS, incluya la source-routing instrucción en el nivel de [edit services rpm twamp client control-connection name test-session session-name] jerarquía.

Marcas de tiempo

De forma predeterminada, para la mayoría de las plataformas, las marcas de hora se establecen en el procesador host del motor de reenvío de paquetes. Para tener en cuenta la latencia en la comunicación de mensajes de sondeo, puede descargar la marca de tiempo de los paquetes de sondeo en el hardware del motor de reenvío de paquetes. Este tipo de marca de tiempo se denomina marca de tiempo en línea, donde la marca de tiempo se realiza en el hardware en el generador o reflector, justo antes de que el paquete abandone el dispositivo. La compatibilidad con esta descarga y la marca de tiempo en línea varía según la versión, la plataforma y la compatibilidad con la tarjeta de línea:

• Junos OS: Antes de Junos OS versión 25.4R1, podía habilitar la marca de tiempo en línea mediante la configuración de una si- interfaz OR sp- . A partir de la versión 25.4R1 de Junos OS, para las tarjetas de línea MX que lo admitan, puede descargar la marca de tiempo en el hardware del motor de reenvío de paquetes mediante la offload-type inline-timestamp opción. Esta función de marca de tiempo en línea también es compatible con Flex Algo y SR-MPLS.

  Si si- las interfaces están configuradas en un enrutador MX para TWAMP, esta opción es la predeterminada para la marca de tiempo. Para depurar la implementación de la si- interfaz, debe configurar la none opción o la pfe-timestamp opción.

  Configure la offload-type (inline-timestamp | none | pfe-timestamp) instrucción en uno de estos niveles de jerarquía: [edit services rpm twamp client control-connection name test-session name], [edit services rpm twamp server], o [edit services rpm twamp server light].

• Junos OS evolucionado: Las marcas de tiempo las establece el motor de enrutamiento o el motor de reenvío de paquetes para el tráfico IPv4. Para el tráfico IPv6, las marcas de tiempo se establecen únicamente mediante el motor de enrutamiento. Para el tráfico IPv6, a partir de Junos OS Evolved 22.3R1, admitimos marcas de tiempo del motor de reenvío de paquetes. Antes de Junos OS Evolved versión 22.3R1, para el tráfico IPv6, la offload-type instrucción en el nivel de [edit services monitoring twamp client control-connection name test-session name] jerarquía se debe configurar como none. A partir de la versión 22.4R1 de Junos OS evolucionado para dispositivos compatibles, puede configurar la opción de la offload-type instrucción para habilitar las inline-timestamping marcas de hora establecidas en línea por el hardware. A partir de la versión 23.4R1 de Junos OS Evolved para servidores, el valor predeterminado de la offload-type instrucción ahora pfe-timestamp es en lugar de inline-timestamp. A partir de Junos OS evolucionado, versión 25.4R1, la función de marca de tiempo en línea también es compatible con Flex Algo y SR-MPLS.