AUF DIESER SEITE
Grundlegendes zu TWAMP Auto-Restart
Wenn der TWAMP-Client (Two-Way Active Management Protocol) ausfällt, müssen Sie nach einem Netzwerkausfall oder einer Konfigurationsänderung die TWAMP-Sitzung manuell über request services rpm twamp start client einen Befehl starten. Ab Junos OS Version 19.1R1 wird der TWAMP-Client automatisch ohne manuelle Eingriffe neu gestartet.
Der automatische Neustart der TWAMP-Sitzung ermöglicht es dem TWAMP-Client, die TCP-Steuerungsverbindung und UDP-Testsitzungen in den folgenden Szenarien automatisch zu initiieren:
Unmittelbar nach der TwAMP-Clientkonfiguration.
Danach wird der Remote-Betriebs-Daemon (rmopd) mit der gültigen TWAMP-Client-Konfiguration gestartet.
Nachdem die TWAMP-Client-Konfiguration aktiviert wurde.
Unmittelbar nachdem der TWAMP-Server über den TWAMP-Client erreichbar ist, basiert auf dem
test-interval.
Wenn das Netzwerk ausfällt oder der TWAMP-Server aus irgendeinem Grund nicht erreichbar ist, versucht der TWAMP-Client nach jedem test-interval Wert wieder eine Verbindung mit dem TWAMP-Server herzustellen, bis er erfolgreich ist. Damit der Client jedoch automatisch wieder eine Verbindung mit dem TWAMP-Server herstellen kann, muss der test-count set rpm twamp client control-connection Wert im Befehl 0 sein. Auf der TWAMP-Serverseite ist der Standardwert von in test-count max-connection-duration ebenfalls set rpm twamp server max-connection-duration 0. Auf diese Weise können Sie die Verbindung beibehalten, bis sie freigegeben ist.
Ab Junos OS Version 19.1R1 ist der Standardwert für test-count den TWAMP-Client und max-connection-duration auf dem TWAMP-Server 0.
Nachdem Sie einen TWAMP-Test konfiguriert und festgelegt haben, führt der Client Tests auf unbestimmte Zeit aus, d. h. er sendet auch nach Abschluss eines Tests weiterhin Probes, auch wenn es zu einem Netzwerk- oder Serverausfall kommt. Sie können die automatische Ausführung von Tests beenden, indem Sie den Wert der test-count Option in einen nichtzero-Wert ändern. Wenn Sie dies tun, ist die Funktion für den automatischen Neustart deaktiviert, und Sie müssen den TWAMP-Client manuell starten, um eine Verbindung mit dem Server herzustellen und Testsitzungen zu starten.
Sie können die Statistiken zu den vorherigen Sondierungen pflegen und anzeigen, die während der Server-Nichtverfügbarkeit gesendet wurden. Sie können den set services rpm twamp client control-connection c1 persistent-results Befehl verwenden, um die Testergebnisse beizubehalten und anzuzeigen, nachdem das Netzwerk wiederhergestellt wurde oder wenn der TWAMP-Server wieder erreichbar ist.
Vorteile
Sie müssen die TWAMP-Sitzung nicht manuell neu starten, nachdem der Client infolge eines Netzwerkausfalls oder einer Konfigurationsänderung ausfällt.
Sie müssen kein Ereignisskript ausführen, um die TWAMP-Sitzung vom Client aus neu zu starten.
TCP Keepalive-Unterstützung für TWAMP-Client und -Server
Keepalive Probes können Client (Peers) behaupten, wenn ein anderer Peer nicht erreichbar ist. Wenn das Problem im Netzwerk zwischen zwei Peers liegt, besteht die Keepalive-Aktion darin, einige Zeit zu warten und dann erneut zu versuchen, das Keepalive-Paket zu senden, bevor die Verbindung als defekt markiert wird.
Wenn der Keepalive Timer für eine TCP-Verbindung null erreicht, sendet der TCP-Client seinem Peer ein Keepalive Probe-Paket ohne daten und mit eingeschalteter ACK-Flag. Der Client erhält eine Antwort vom Remote-Host ohne Daten und mit dem gesetzten ACK-Flag. Wenn der Client eine Antwort auf seine Keepalive Probe erhält, kann der Client behaupten, dass die Verbindung noch aktiv ist. Wenn der Peer nicht auf die Keepalive Probe antwortet, können Sie behaupten, dass die Verbindung nicht als gültig angesehen werden kann, und dann Korrekturmaßnahmen ergreifen.
In Junos OS müssen Sie die folgenden Parameter konfigurieren, um Ausfälle der TWAMP-Steuerungsverbindung am TWAMP-Client und den TWAMP-Servern zu erkennen:
tcp-keepcnt—Anzahl der nicht bekannten Sondierungen, die gesendet werden müssen, bevor die Verbindung für nicht erreichbar ist und die Anwendungsebene benachrichtigt wird.tcp-keepidle— Zeitintervall zwischen dem letzten gesendeten Datenpaket und der ersten gesendeten Keepalive Probe.tcp-keepintvl— Zeitintervall zwischen aufeinander folgenden Keepalive-Sondierungen