Understanding TWAMP Auto-Restart
After a network outage or a configuration change, when the Two-Way
Active Management Protocol (TWAMP) client goes down, you have to manually
start the TWAMP session by using request services rpm twamp start
client command. Starting
in Junos OS Release 19.1R1, the TWAMP client restarts automatically
without any manual intervention.
The automatic restart of the TWAMP session enables the TWAMP client to initiate the TCP control connection and UDP test sessions automatically during the following scenarios:
Immediately after the TWAMP client configuration is committed.
After the remote operation daemon (rmopd) is started with the valid TWAMP client configuration presence.
After the TWAMP client configuration is activated.
Immediately after the TWAMP server is reachable from the TWAMP client, based on the
test-interval.
When the network fails or the TWAMP server becomes unreachable
for any reason, the, TWAMP client tries to reconnect to the TWAMP
server after every test-interval value until it is successful.
However, for the client to reconnect to the TWAMP server automatically,
the test-count value in the set rpm twamp
client control-connection command must be 0. At the TWAMP server side, the default
value of test-count max-connection-duration in
the set rpm twamp server max-connection-duration must also
be 0. Thereby, you can retain the connection until it is cleared.
Starting in Junos OS Release 19.1R1, the default value of test-count at the TWAMP client and max-connection-duration at the TWAMP server is 0.
After you configure and commit a TWAMP test, the client runs
tests indefinitely—that is, it continues to send probes after
the configured test interval even after a test is completed, and even
if there is a network or server failure. You can stop the automatic
running of tests by changing the value of the test-count option to a nonzero value. If you do that, the automatic restart
feature is disabled, and you need to manually start the TWAMP client
for it to establish connection with the server and start test sessions.
You can maintain and view the statistics related to the previous
probes sent during server unavailability. You can Use the set
services rpm twamp client control-connection c1 persistent-results command to preserve and display the test results after the network
recovers or when the TWAMP server is again reachable.
Benefits
You do not need to restart the TWAMP session manually after the client goes down as a result of a network outage or configuration change.
You do not need to run an event script to restart TWAMP session from client side.
TCP Keepalive Support for TWAMP Client and Server
Keepalive probes can assert client (peers) when another peer becomes unreachable. If the problem is in the network between two peers, the keepalive action is to wait for some time and then retry sending the keepalive packet before marking the connection as broken.
When the keepalive timer for a TCP connection reaches zero, TCP client sends its peer a keepalive probe packet with no data in it and with the ACK flag turned on. The client receives a reply from the remote host with no data and with the ACK flag set. If the client receives a reply to its keepalive probe, the client can assert that the connection is still up and running. If the peer does not reply to the keepalive probe, you can assert that the connection cannot be considered valid and then take corrective action.
In Junos OS, to detect the TWAMP control connection failures at TWAMP client and TWAMP servers, you need to configure the following parameters:
tcp-keepcnt—Number of unacknowledged probes to send before considering the connection dead and notifying the application layer.tcp-keepidle—Time interval between the last data packet sent and the first keepalive probe sent.tcp-keepintvl—Time interval between successive keepalive probes.
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.