Comprender el protocolo de medición activa bidireccional
RESUMEN 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.
Ventajas de TWAMP
-
La configuración de 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.
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)
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).
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:
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.
La Tabla 1 proporciona información sobre TWAMP y la compatibilidad con marcas de tiempo relacionadas en MPC, MS-MIC/MPC y en línea:
| Característica |
Papel |
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 |
- Soporte de TWAMP Light
- Compatibilidad con el Protocolo simple de medición activa bidireccional (STAMP)
Soporte de TWAMP Light
La Tabla 2 proporciona información sobre la compatibilidad con TWAMP Light, tal como se define en el Apéndice I de RFC 5357, que define una versión ligera del protocolo TWAMP, 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.
La compatibilidad con direcciones de destino IPv6 para sesiones de prueba de TWAMP Light se introdujo en Junos OS versión 21.3R1 y como se menciona en la tabla siguiente.
La compatibilidad con direcciones de destino locales de vínculo IPv6 se introdujo en Junos OS versión 21.4R1, para la serie MX y los enrutadores PTX1000, PTX3000 y PTX5000, y en Junos OS Evolved versión 22.3R1, para los enrutadores ACX7100, ACX7509, PTX10001-36MR, PTX10003, PTX10004, PTX10008 y PTX10016.
| Dispositivo | admitido en |
|---|---|
| ACX710 | Junos OS versión 22.3R1 |
| Serie ACX5448 | Junos OS versión 22.3R1 |
| Serie ACX7100 | Junos OS Evolved versión 21.2R1 |
| ACX7509 | Junos OS Evolved versión 22.3R1 |
| Serie MX, con LC480, LC2101, LC2103 y MPC hasta MPC9E inclusive | Junos OS versión 21.1R1 (IPv4), Junos OS versión 21.3R1 (IPv6) |
| Serie MX con las siguientes tarjetas de línea: LMIC16-BASE, LC9600, MPC10E y MPC11E |
|
| Serie PTX que ejecuta Junos OS, con MPC hasta MPC9E inclusive | Junos OS versión 21.1R1 (IPv4), Junos OS versión 21.3R1 (IPv6) |
| Serie PTX con Junos OS con tarjetas de línea MPC10E y MPC11E |
|
| PTX10001-36MR |
|
| PTX10003 |
|
| PTX10004 |
|
| PTX10008 y PTX10016 (con el JNP10008-SF3 y la tarjeta de línea JNP10K-LC1201 o JNP10K-LC1202-36MR) |
|
| QFX5130-32CD, QFX5220 y QFX5700 | Junos OS Evolved 22.4R1 (IPv4 e IPv6) |
| QFX10002, QFX10008 y QFX10016 | Junos OS versión 21.3R1 (IPv4) |
| EX9200 | Junos OS versión 21.4R1 |
Compatibilidad con el Protocolo simple de medición activa bidireccional (STAMP)
La Tabla 3 proporciona información sobre la compatibilidad con TWAMP Light, tal como se define en 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). 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. Ahora admitimos 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.
| Dispositivo |
Soportado en |
|---|---|
| ACX7024, ACX7024X, ACX7100-32C, ACX7100-48L, ACX7509 |
Junos OS Evolved versión 23.4R1 |
| PTX10001-36MR, PTX10003, PTX10004 y PTX10008 y PTX10016 (con la tarjeta de línea JNP10008-SF3 y la tarjeta de línea JNP10K-LC1201 o JNP10K-LC1202-36MR) |
Junos OS Evolved versión 23.4R1 |
TWAMP en enrutadores serie MX, conmutadores serie EX9200 y serie QFX10000
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.
TWAMP en enrutadores de la serie PTX
El protocolo TWAMP-Control se utiliza para configurar sesiones de medición del rendimiento entre un cliente TWAMP y un servidor TWAMP, y el protocolo TWAMP-Test se utiliza para enviar y recibir sondas de medición del rendimiento. 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] . En la tabla 4 se proporciona información sobre la compatibilidad con TWAMP.
| Dispositivo | admitido en |
|---|---|
| Serie PTX con Junos OS | Junos OS versión 19.2R1 |
| PTX10001-36MR |
|
| PTX10003 |
|
| PTX10004 |
|
| PTX10008 (con el JNP10008-SF3 y la tarjeta de línea JNP10K-LC1201 o JNP10K-LC1202-36MR) |
|
| PTX10016 (con el JNP10008-SF3 y la tarjeta de línea JNP10K-LC1201 o JNP10K-LC1202-36MR) | Junos OS Evolved versión 22.4R1 (IPv4 e IPv6) |
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-typeinstrucción en el nivel de[edit services monitoring twamp client control-connection name test-session name]jerarquía debía configurarse comonone. A partir de Junos OS Evolved 23.4R1 para servidores, el valor predeterminado de laoffload-typeinstrucción ahorapfe-timestampes en lugar deinline-timestamp. -
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).
-
Informes de errores solo a través de mensajes de registro del sistema y capturas SNMP
-
Solo modo no autenticado
TWAMP en conmutadores de la serie QFX5000
El protocolo TWAMP-Control se utiliza para configurar sesiones de medición del rendimiento entre un cliente TWAMP y un servidor TWAMP, y el protocolo TWAMP-Test se utiliza para enviar y recibir sondas de medición del rendimiento. Para Junos OS Evolved, TWAMP se configura en el nivel jerárquico [edit services monitoring twamp] .
| Dispositivo | admitido en |
|---|---|
| QFX5130-32CD | Junos OS Evolved versión 22.4R1 |
| QFX5220 | Junos OS Evolved versión 22.4R1 |
| QFX5700 | Junos OS Evolved versión 22.4R1 |
La compatibilidad de Junos OS Evolved con TWAMP se limita a lo siguiente:
-
Las direcciones de origen y destino IPv4 e IPv6 (incluidas las direcciones locales de vínculo) son compatibles con las listas de clientes, las conexiones de control y las 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 por el motor de reenvío de paquetes para el tráfico IPv4 e IPv6.
-
Informes de errores solo a través de mensajes de registro del sistema y capturas SNMP
-
Solo modo no autenticado
TWAMP en firewalls de la serie SRX
Los dispositivos SRX300, SRX320, SRX340, SRX345, SRX550M, SRX1500, SRX4100 y SRX4200 y las instancias de vSRX Virtual Firewall tienen las siguientes limitaciones para la compatibilidad con TWAMP:
-
TWAMP para IPv6 no es compatible.
-
No se admite la autenticación de servidor TWAMP ni de cliente TWAMP.
-
TWAMP Light no es compatible.
TWAMP en enrutadores de la serie ACX
En Junos OS, TWAMP es compatible con enrutadores ACX. Los enrutadores de las series 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. Para Junos OS, TWAMP se configura en el nivel jerárquico [edit services rpm twamp] .
En Junos OS Evolved, TWAMP es compatible con enrutadores ACX, tanto para reflexión como para generación. A partir de Junos OS Evolved 21.2R1, TWAMP (incluido TWAMP Light) es compatible con los enrutadores de la serie ACX7100. Para Junos OS Evolved, TWAMP se configura en el nivel jerárquico [edit services monitoring twamp] . La compatibilidad de Junos OS Evolved con TWAMP se limita a lo siguiente:
-
tráfico IPv4 solo para sesiones de control y sesiones de prueba; Compatibilidad con tráfico IPv6 (excepto para direcciones locales de vínculo) a partir de Junos OS Evolved versión 21.4R1. Compatibilidad con direcciones locales de vínculo IPv6 para sesiones de prueba de TWAMP Light solo a partir de Junos OS Evolved 22.3R1.
-
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
A partir de Junos OS Evolved 23.4R1, el valor predeterminado de laoffload-typeinstrucción en el nivel de[edit services monitoring twamp client control-connection name test-session name]jerarquía debía configurarse comonone. A partir de Junos OS Evolved 22.4R1 para enrutadores ACX, puede configurar la opción de la instrucción para habilitar lasinline-timestampingoffload-typemarcas de tiempo establecidas en línea por el hardware.offload-typeinstrucción ahorapfe-timestampes en lugar deinline-timestamp.-
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).
-
Informes de errores solo a través de mensajes de registro del sistema
-
Solo modo no autenticado