EN ESTA PÁGINA
Descripción del reinicio automático de TWAMP
Después de una interrupción de la red o un cambio de configuración, cuando el cliente del Protocolo de administración activa bidireccional (TWAMP) cae, debe iniciar manualmente la sesión TWAMP mediante request services rpm twamp start client el comando. A partir de Junos OS versión 19.1R1, el cliente TWAMP se reinicia automáticamente sin ninguna intervención manual.
El reinicio automático de la sesión de TWAMP permite que el cliente TWAMP inicie automáticamente la conexión de control TCP y las sesiones de prueba UDP durante los siguientes escenarios:
Inmediatamente después de que se confirma la configuración del cliente TWAMP.
Después de iniciar el demonio de operación remota (rmopd) con la presencia válida de configuración del cliente TWAMP.
Después de activar la configuración del cliente TWAMP.
Inmediatamente después de que se pueda comunicar con el servidor TWAMP desde el cliente TWAMP, según el
test-interval.
Cuando la red falla o el servidor TWAMP se vuelve inalcanzable por cualquier motivo, el cliente TWAMP intenta volver a conectar al servidor TWAMP después de cada test-interval valor hasta que se haya correcto. Sin embargo, para que el cliente vuelva a conectarse automáticamente al servidor TWAMP, el test-count valor del set rpm twamp client control-connection comando debe ser 0. En el lado del servidor TWAMP, el valor predeterminado de test-count max-connection-duration en el set rpm twamp server max-connection-duration también debe ser 0. Por lo tanto, puede conservar la conexión hasta que esté despejada.
A partir de Junos OS versión 19.1R1, el valor predeterminado de test-count en el cliente TWAMP y max-connection-duration en el servidor TWAMP es 0.
Después de configurar y confirmar una prueba de TWAMP, el cliente ejecuta pruebas de forma indeterminada, es decir, continúa enviando sondeos después del intervalo de prueba configurado incluso después de completar una prueba e incluso si hay un error de red o servidor. Puede detener la ejecución automática de pruebas cambiando el valor de la test-count opción a un valor distinto de cero. Si hace eso, la función de reinicio automático está deshabilitada y debe iniciar manualmente el cliente TWAMP para que establezca la conexión con el servidor e inicie sesiones de prueba.
Puede mantener y ver las estadísticas relacionadas con las pruebas anteriores enviadas durante la falta de disponibilidad del servidor. Puede Usar el set services rpm twamp client control-connection c1 persistent-results comando para conservar y mostrar los resultados de la prueba después de que se recupere la red o cuando se pueda llegar de nuevo al servidor TWAMP.
Ventajas
No es necesario reiniciar la sesión de TWAMP manualmente después de que el cliente se cae como resultado de una interrupción de la red o un cambio de configuración.
No es necesario ejecutar una secuencia de comandos de evento para reiniciar la sesión de TWAMP desde el lado del cliente.
Soporte keepalive TCP para clientes y servidores TWAMP
Las pruebas de keepalive pueden afirmar el cliente (pares) cuando otro par se vuelve inalcanzable. Si el problema se encuentra en la red entre dos pares, la acción de keepalive es esperar un tiempo y, luego, volver a intentar enviar el paquete keepalive antes de marcar la conexión como rota.
Cuando el temporizador de keepalive para una conexión TCP llega a cero, el cliente TCP envía a su par un paquete de sondeo keepalive sin datos en él y con el indicador ACK activado. El cliente recibe una respuesta del host remoto sin datos y con la marca ACK establecida. Si el cliente recibe una respuesta a su prueba de mantenimiento, el cliente puede afirmar que la conexión sigue funcionando. Si el par no responde al sondeo de mantenimiento, puede afirmar que la conexión no se puede considerar válida y, luego, tomar medidas correctivas.
En Junos OS, para detectar los errores de conexión de control TWAMP en el cliente TWAMP y los servidores TWAMP, debe configurar los siguientes parámetros:
tcp-keepcnt— Número de pruebas no reconocidas que se enviarán antes de considerar que la conexión está muerta y notificar a la capa de aplicación.tcp-keepidle— Intervalo de tiempo entre el último paquete de datos enviado y el primer sondeo de mantenimiento enviado.tcp-keepintvl— Intervalo de tiempo entre sondeos de mantenimiento sucesivos.