Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
EN ESTA PÁGINA
 

Comprender el protocolo de medición activa bidireccional

Obtenga información sobre el uso del protocolo de medición activa bidireccional (TWAMP) para medir el rendimiento de la red entre dos dispositivos cualesquiera en una red.

El Protocolo de administración activa bidireccional (TWAMP), descrito en RFC 5357, es una extensión del Protocolo de administración activa unidireccional (OWAMP) que proporciona mediciones bidireccionales o de ida y vuelta en lugar de capacidades unidireccionales. Las mediciones bidireccionales son útiles porque los retrasos de ida y vuelta no requieren sincronización del reloj del host y el soporte remoto puede ser una función de eco simple. Sin embargo, el Protocolo de mensajes de control de Internet (ICMP) Echo Request/Reply (utilizado por ping) para este propósito tiene varias deficiencias. TWAMP define un protocolo abierto para medir métricas bidireccionales o de ida y vuelta con mayor precisión que otros métodos mediante el uso de marcas de tiempo (también se pueden tener en cuenta los retrasos de procesamiento).

Utilice el 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.

Revise la sección Comportamiento de TWAMP específico de la plataforma para obtener notas relacionadas con su plataforma.

Ventajas de TWAMP

  • La configuración de la sonda TWAMP le ayuda a activar, probar, supervisar y solucionar problemas de su red de extremo a extremo sin necesidad de utilizar un dispositivo de prueba dedicado.

  • Las marcas de tiempo de TWAMP proporcionan métricas bidireccionales o de ida y vuelta con mayor precisión que otros métodos (también se pueden tener en cuenta los retrasos de procesamiento).

  • TWAMP se utiliza a menudo para comprobar el cumplimiento del acuerdo de nivel de servicio (SLA), y la función TWAMP se utiliza a menudo en ese contexto.

  • Las mediciones bidireccionales son mejores que las mediciones unidireccionales porque los retrasos de ida y vuelta no requieren sincronización del reloj del host. Esto es posible porque el reflector coloca su propio número de secuencia en el paquete.

Nota:

Le recomendamos que no configure el cliente RPM ni un servidor TWAMP en el mismo dispositivo. Esto puede causar algunos problemas en los resultados de la sonda RPM.

Comprender el protocolo de medición activa bidireccional (TWAMP)

Por lo general, TWAMP opera entre interfaces en dos dispositivos que desempeñan funciones específicas. TWAMP se utiliza a menudo para comprobar el cumplimiento del Acuerdo de nivel de servicio (SLA), y la función TWAMP se presenta a menudo en ese contexto. TWAMP utiliza dos protocolos relacionados, que se ejecutan entre varios elementos definidos:

  • TWAMP-Control: inicia, inicia y finaliza sesiones de prueba. El protocolo TWAMP-Control se ejecuta entre un elemento Control-Client y un elemento Server.

  • TWAMP-Test: intercambia paquetes de prueba entre dos elementos TWAMP. El protocolo TWAMP-Test se ejecuta entre un elemento Session-Sender y un elemento Session-Reflector.

Los cuatro elementos se muestran en la Figura 1:

Figura 1: Cuatro elementos de TWAMP Four Elements of TWAMP

Aunque cuatro dispositivos TWAMP diferentes pueden desempeñar las cuatro funciones lógicas de cliente de control de TWAMP, servidor, remitente de sesión y reflector de sesión, diferentes dispositivos pueden desempeñar funciones diferentes. Una implementación común combina las funciones de Control-Cliente y Sesión-Remitente en un dispositivo (conocido como controlador TWAMP o cliente TWAMP) y las funciones de Servidor y Reflector de sesión en el otro dispositivo (conocido como respondedor TWAMP o servidor TWAMP). En este caso, cada dispositivo ejecuta los protocolos TWAMP-Control (entre Control-Client y Server) y TWAMP-Test (entre Session-Sender y Session-Reflector).

La arquitectura cliente-servidor de TWAMP, tal como se implementó, tiene el siguiente aspecto:

  • Cliente de TWAMP

    • Control-Client configura, inicia y detiene las sesiones de prueba de TWAMP.

    • Session-Sender crea paquetes de prueba de TWAMP que se envían al reflector de sesión en el servidor de TWAMP.

  • Servidor TWAMP

    • El reflector de sesión devuelve un paquete de medición cuando se recibe un paquete de prueba, pero no mantiene un registro de dicha información.

    • El servidor administra una o más sesiones con el cliente TWAMP y escucha los mensajes de control en un puerto TCP.

El empaquetado de estos elementos en los procesos de cliente y servidor de TWAMP se muestra en la figura 2.

Figura 2: Los elementos de TWAMP implementados como cliente (izquierda) y servidor (derecha). The Elements of TWAMP Implemented as Client (Left) and Server (Right).

Soporte de TWAMP Light

TWAMP Light, tal 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 se predefinen en lugar de negociarse. 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 los admitan, también puede configurar direcciones de destino IPv6, incluidas las direcciones de destino locales de vínculo IPv6.

Utilice el 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.

Compatibilidad con el Protocolo simple 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 compatibles con 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 en la carga reflejada se copia desde la trama del cliente o se genera de forma independiente. Un reflector con estado puede detectar en qué dirección se han producido caídas. En versiones anteriores, admitíamos cargas simétricas y reflexión sin estado. Apoyamos la reflexión de 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 por TWAMP. Para Junos OS Evolved, STAMP se configura en el nivel jerárquico [edit services monitoring twamp server light] . La reflexión con estado se configura con la stateful-sequence instrucción. Para los servidores, el nuevo valor predeterminado para offload-type es ahora pfe-timestamp en lugar de inline-timestamp.

Use el Explorador de características: Protocolo simple de medición activa bidireccional (STAMP) para confirmar la compatibilidad con la plataforma y la versión.

Seguimiento de rutas estáticas

A partir de la versión 24.4R1 de Junos OS Evolved, ampliamos la compatibilidad con el seguimiento de rutas estáticas a Junos OS Evolved e incluimos la compatibilidad con pruebas del protocolo de medición activa bidireccional (TWAMP). Los sondeos TWAMP se utilizan para detectar el estado del vínculo y cambiar el estado de la ruta preferida en función de los resultados del sondeo. Las rutas estáticas rastreadas 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 los dispositivos Junos OS evolucionado; La instrucción se configura sla-tracking en el nivel jerárquico [edit routing-options] . También puede utilizar 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 Junos OS Evolved versión 24.4R1, para aquellos enrutadores PTX que lo admiten, agregamos compatibilidad con el protocolo de medición activa bidireccional (TWAMP) para el enrutamiento de segmentos (SR), tal como se define en RFC 8402, que especifica en términos generales la arquitectura de SR. Admitimos dos tipos de SR para sondas TWAMP:

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

  • SRv6: Utiliza un encabezado de enrutamiento IPv6 de 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 al cliente. Esta información de ruta de retorno se incrusta en la propia sonda mediante las extensiones propuestas en Simple TWAMP (STAMP) Extensions for Segment Routing Networks, draft-ietf-ippm-stamp-srpm, es decir, la ruta de retorno TLV y sus subTLV de lista de segmentos de retorno, según corresponda según el tipo de enrutamiento de segmento. Los sondeos TWAMP tienen una marca de tiempo en el motor de enrutamiento o en el motor de reenvío de paquetes.

Para configurar esta característica, incluya la source-routing instrucción en el nivel de [edit services monitoring twamp client control-connection name test-session session-name jerarquía.

Diferencias evolucionadas de Junos OS en la compatibilidad con TWAMP

La compatibilidad de Junos OS Evolved con TWAMP se limita a lo siguiente:

  • Tráfico IPv4 e IPv6 solo para sesiones de control y sesiones de prueba. A partir de Junos OS Evolved versión 21.4R1, las direcciones de origen y destino IPv6 (excepto las direcciones locales de vínculo) se admiten para listas de clientes, conexiones de control y sesiones de prueba.

  • Estadísticas e historial de la sonda

  • Controlar y probar el estado de la sesión

  • Generación y recepción de sondas en sesiones de prueba, así como reflexión

  • Marcas de tiempo establecidas por el motor de enrutamiento o el motor de reenvío de paquetes para el tráfico IPv4. Para el tráfico IPv6, marcas de tiempo establecidas solo por 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 debía configurarse como none. A partir de Junos OS Evolved versión 22.4R1 para dispositivos compatibles, puede configurar la opción de la instrucción para habilitar las inline-timestamping offload-type marcas de tiempo establecidas en línea por el hardware.

    A partir de Junos OS Evolved versión 23.4R1 para servidores, el valor predeterminado de la offload-type instrucción ahora pfe-timestamp es en lugar de inline-timestamp.

  • Informes de errores solo a través de mensajes de registro del sistema y capturas SNMP

  • Solo modo no autenticado

La compatibilidad de Junos OS Evolved con TWAMP también incluye algunas funciones que no se incluyen en Junos OS:

  • A partir de Junos OS Evolved versión 23.4R1, admitimos RFC 8762, Protocolo simple de medición activa bidireccional (STAMP). RFC 8762 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 obtener más información, consulte Compatibilidad con el Protocolo simple de medición activa bidireccional (STAMP).

  • A partir de Junos OS Evolved versión 24,4R1, admitimos el seguimiento de rutas estáticas mediante TWAMP para aquellos dispositivos que admiten esta función. Consulte Seguimiento de rutas estáticas para obtener más información.

  • A partir de Junos OS Evolved versión 24.4R1, para aquellos enrutadores PTX que lo admiten, hemos agregado compatibilidad con el protocolo de medición activa bidireccional (TWAMP) para el enrutamiento de segmentos (SR), tal como se define en RFC 8402. Consulte Compatibilidad con el enrutamiento por segmentos para configurar rutas para obtener más información.

Comportamiento de TWAMP específico de la plataforma

Utilice el 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.

Use la tabla siguiente para revisar los comportamientos específicos de la plataforma para su plataforma.

Tabla 1: Comportamiento de TWAMP específico de la plataforma
Diferencia de plataforma

Serie ACX

  • En Junos OS, los enrutadores serie ACX710 y ACX5448 admiten tanto la reflexión como la generación. Otros enrutadores de la serie ACX que ejecutan Junos OS solo admiten reflexión, no generación.

  • En Junos OS Evolved, TWAMP es compatible con enrutadores ACX, tanto para reflexión como para generación. Consulte Diferencias evolucionadas de Junos OS en la compatibilidad con TWAMP para obtener notas sobre las diferencias del sistema operativo en la compatibilidad con TWAMP.

  • Para Junos OS, TWAMP se configura en el nivel jerárquico [edit services rpm twamp] . Para Junos OS Evolved, TWAMP se configura en el nivel jerárquico [edit services monitoring twamp] .

  • El tráfico de conexión del control TWAMP siempre llega a los enrutadores ACX con el puerto de escucha establecido como 862. Dado que este número de puerto para sondeos de tráfico se puede modificar, los enrutadores ACX no reconocen ni procesan correctamente los sondeos que llegan con un número de puerto diferente. Como resultado, el tráfico TWAMP y los paquetes enlazados al host se descartan en tal escenario.

  • Para inline-timestamping el modo, el cliente y el servidor de TWAMP no se pueden configurar en el mismo enrutador ACX.

  • Para inline-timestamping el modo, TWAMP sobre VPN de capa 3 no es compatible.

  • Antes de Junos OS Evolved versión 23.4R1, si se configuraban tanto TWAMP como la administración de errores de conectividad (CFM), el cliente de TWAMP descarta los sondeos de TWAMP. Elimine la configuración de CFM para activar TWAMP. A partir de Junos OS Evolved versión 23.4R1, puede configurar CFM en el mismo dispositivo que TWAMP.

Serie EX

Tanto el cliente de control como el remitente de la sesión (el cliente TWAMP) residen en el mismo enrutador de Juniper Networks. Sin embargo, el cliente TWAMP no requiere que el servidor y el reflector de sesión estén en el mismo sistema. Por lo tanto, el cliente TWAMP de Juniper es capaz de trabajar con una implementación de servidor de terceros.

Serie MX

  • Tanto el cliente de control como el remitente de la sesión (el cliente TWAMP) residen en el mismo enrutador de Juniper Networks. Sin embargo, el cliente TWAMP no requiere que el servidor y el reflector de sesión estén en el mismo sistema. Por lo tanto, el cliente TWAMP de Juniper es capaz de trabajar con una implementación de servidor de terceros.

  • TWAMP no se admite cuando se habilitan los servicios de próxima generación en un enrutador de la serie MX.

Serie PTX

  • El atributo de interfaz si-x/y/z de destino, destinado a habilitar servicios en línea, no se admite en enrutadores de la serie PTX para configuraciones de cliente de TWAMP.

  • Para Junos OS, TWAMP se configura en el nivel jerárquico [edit services rpm twamp] . Para Junos OS Evolved, TWAMP se configura en el nivel jerárquico [edit services monitoring twamp] . Consulte Diferencias evolucionadas de Junos OS en la compatibilidad con TWAMP para obtener notas sobre las diferencias del sistema operativo en la compatibilidad con TWAMP.

Serie QFX 10000

Tanto el cliente de control como el remitente de la sesión (el cliente TWAMP) residen en el mismo enrutador de Juniper Networks. Sin embargo, el cliente TWAMP no requiere que el servidor y el reflector de sesión estén en el mismo sistema. Por lo tanto, el cliente TWAMP de Juniper es capaz de trabajar con una implementación de servidor de terceros.

Serie QFX5000 (Junos OS evolucionado)

Para Junos OS Evolved, TWAMP se configura en el nivel jerárquico [edit services monitoring twamp] . Consulte Diferencias evolucionadas de Junos OS en la compatibilidad con TWAMP para obtener notas sobre las diferencias del sistema operativo en la compatibilidad con TWAMP.

Serie SRX (dispositivos SRX300, SRX320, SRX340, SRX345, SRX550M, SRX1500, SRX4100 y SRX4200 e instancias de firewall virtual vSRX)

  • TWAMP para IPv6 no es compatible.

  • No se admite la autenticación de servidor TWAMP ni de cliente TWAMP.

  • TWAMP Light no es compatible.

Para la serie MX, la tabla siguiente muestra la relación entre la compatibilidad con el cliente RPM y el servidor, la compatibilidad con el cliente TWAMP (con el componente de control) y el servidor TWAMP (con el componente respondedor), y el hardware que realiza la marca de tiempo.

Tabla 2: Soporte y hardware de funciones de TWAMP para Junos OS, serie MX

Soporte de funciones de TWAMP

Marca de tiempo del motor de enrutamiento

Marca de tiempo MS-PIC/MS-DPC

Marca de tiempo MS-MIC/MS-MPC

Marca de tiempo del motor de reenvío de paquetes (microkernel)

Marca de tiempo del motor de reenvío de paquetes (LU) (si- interfaz)

Cliente RPM

Sí

Sí

Sí

Sí

No

Servidor RPM

Sí

Sí

Sí

Sí

No

Cliente de TWAMP

No

No

No

Sí

Sí

Servidor TWAMP

No

Sí

No

Sí (no se necesita configuración de respondedor)

Sí
Nota:

La compatibilidad con las interfaces de servicios (sp-, ms-, y si- las interfaces) son ligeramente diferentes.

La Tabla 3 proporciona información sobre TWAMP de la serie MX y la compatibilidad con marcas de tiempo relacionadas en MPC, MS-MIC/MPC y en línea:

Tabla 3: Compatibilidad con TWAMP y marcas de tiempo relacionadas, serie MX

Característica

Rol

Versión IP

Soporte (S/N)

Marca de tiempo en línea

Marca de tiempo en MPC (marca de tiempo de hardware)

Marca de tiempo en MPC (interfaz si)

Marca de tiempo en MS-MIC/MPC (sondas de delegado)

TWAMP

Cliente

IPv4

Y

N

Y (μsec)

500 sondas máximas

Y (μsec)

500 sondas máximas

N

IPv6

N

N

N

N

N

Servidor

IPv4

Y

N

Y (μsec)

500 sondas máximas

Y (μsec)

500 sondas máximas

N

IPv6

N

N

N

N

N

Documentación relacionada