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) deja de funcionar, debe iniciar manualmente la sesión de 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 al cliente de TWAMP iniciar la conexión de control TCP y las sesiones de prueba UDP automáticamente durante los siguientes escenarios:
Inmediatamente después de confirmar 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 de cliente TWAMP.
Después de activar la configuración del cliente TWAMP.
Inmediatamente después de que se pueda acceder al servidor TWAMP desde el cliente de TWAMP, según el
test-intervalarchivo .
Cuando se produce un error en la red o el servidor TWAMP se vuelve inaccesible por cualquier motivo, el cliente de TWAMP intenta volver a conectarse al servidor de TWAMP después de cada test-interval valor hasta que se realice correctamente. Sin embargo, para que el cliente vuelva a conectarse al servidor TWAMP automáticamente, 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. De este modo, puede conservar la conexión hasta que se borre.
A partir de Junos OS versión 19.1R1, el valor predeterminado de en el cliente TWAMP y max-connection-duration en el servidor TWAMP test-count es 0.
Después de configurar y confirmar una prueba TWAMP, el cliente ejecuta pruebas indefinidamente, 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 lo hace, 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 los sondeos anteriores enviados durante la indisponibilidad del servidor. Puede utilizar el set services rpm twamp client control-connection c1 persistent-results comando para conservar y mostrar los resultados de las pruebas después de que la red se recupere o cuando se pueda volver a acceder al servidor TWAMP.
Beneficios
No es necesario reiniciar la sesión de TWAMP manualmente después de que el cliente deje de funcionar como resultado de una interrupción de la red o un cambio de configuración.
No es necesario ejecutar un script de eventos para reiniciar la sesión de TWAMP desde el lado del cliente.
Soporte TCP Keepalive para cliente y servidor TWAMP
Las sondas Keepalive pueden afirmar cliente (pares) cuando otro par se vuelve inalcanzable. Si el problema está en la red entre dos pares, la acción keepalive es esperar un tiempo y, a continuación, volver a intentar enviar el paquete keepalive antes de marcar la conexión como rota.
Cuando el temporizador keepalive para una conexión TCP llega a cero, el cliente TCP envía a su par un paquete de sondeo keepalive sin datos y con el indicador ACK activado. El cliente recibe una respuesta del host remoto sin datos y con el indicador ACK establecido. Si el cliente recibe una respuesta a su sonda keepalive, puede afirmar que la conexión sigue en funcionamiento. Si el par no responde a la sonda keepalive, puede afirmar que la conexión no puede considerarse válida y, a continuación, tomar medidas correctivas.
En Junos OS, para detectar los errores de conexión de control de TWAMP en el cliente de TWAMP y en los servidores de TWAMP, debe configurar los siguientes parámetros:
tcp-keepcnt: número de sondeos no reconocidos que se deben enviar antes de considerar la conexión muerta y notificar a la capa de aplicación.tcp-keepidle: intervalo de tiempo entre el último paquete de datos enviado y la primera sonda keepalive enviada.tcp-keepintvl—Intervalo de tiempo entre sondas keepalive sucesivas.
Tabla de historial de cambios
La compatibilidad con las funciones viene determinada por la plataforma y la versión que esté utilizando. Utilice el Explorador de características para determinar si una característica es compatible con su plataforma.