AUF DIESER SEITE
Grundlegendes zum automatischen Neustart von TWAMP
Wenn nach einem Netzwerkausfall oder einer Konfigurationsänderung der TWAMP-Client (Two-Way Active Management Protocol) ausfällt, müssen Sie die TWAMP-Sitzung manuell per request services rpm twamp start client Befehl starten. Ab Junos OS Version 19.1R1 wird der TWAMP-Client automatisch und ohne manuelle Eingriffe neu gestartet.
Der automatische Neustart der TWAMP-Sitzung ermöglicht es dem TWAMP-Client, die TCP-Kontrollverbindung und UDP-Testsitzungen in den folgenden Szenarien automatisch zu initiieren:
Unmittelbar nachdem die TWAMP-Clientkonfiguration festgeschrieben wurde.
Nachdem der Remote Operation Daemon (rmopd) mit der gültigen TWAMP-Clientkonfiguration gestartet wurde.
Nach der Aktivierung der TWAMP-Client-Konfiguration.
Unmittelbar nachdem der TWAMP-Server vom TWAMP-Client aus erreichbar ist, basierend auf .
test-interval
Wenn das Netzwerk ausfällt oder der TWAMP-Server aus irgendeinem Grund nicht mehr erreichbar ist, versucht der TWAMP-Client nach jedem test-interval Wert, sich erneut mit dem TWAMP-Server zu verbinden, bis er erfolgreich ist. Damit sich der Client jedoch automatisch wieder mit dem TWAMP-Server verbindet, muss der test-count Wert im set rpm twamp client control-connection Befehl 0 sein. Auf der TWAMP-Serverseite muss der Standardwert von test-count max-connection-duration in ebenfalls set rpm twamp server max-connection-duration 0 sein. Auf diese Weise können Sie die Verbindung aufrechterhalten, bis sie gelöscht wird.
Ab Junos OS Version 19.1R1 ist der Standardwert für test-count auf dem TWAMP-Client und max-connection-duration auf dem TWAMP-Server 0.
Nachdem Sie einen TWAMP-Test konfiguriert und einen Commit ausgeführt haben, führt der Client Tests auf unbestimmte Zeit aus, d. h., er sendet auch nach Abschluss eines Tests und selbst bei einem Netzwerk- oder Serverausfall weiterhin Prüfpunkte nach dem konfigurierten Testintervall. Sie können die automatische Ausführung von Tests beenden, indem Sie den Wert der test-count Option in einen Wert ungleich Null ändern. Wenn Sie dies tun, ist die automatische Neustartfunktion deaktiviert, und Sie müssen den TWAMP-Client manuell starten, damit er eine Verbindung mit dem Server herstellen und Testsitzungen starten kann.
Sie können die Statistiken im Zusammenhang mit den vorherigen Tests verwalten und anzeigen, die während der Nichtverfügbarkeit des Servers gesendet wurden. Sie können den set services rpm twamp client control-connection c1 persistent-results Befehl verwenden, um die Testergebnisse nach der Wiederherstellung des Netzwerks oder wenn der TWAMP-Server wieder erreichbar ist, beizubehalten und anzuzeigen.
Nützt
Sie müssen die TWAMP-Sitzung nicht manuell neu starten, nachdem der Client aufgrund eines Netzwerkausfalls oder einer Konfigurationsänderung ausgefallen ist.
Sie müssen kein Ereignisskript ausführen, um die TWAMP-Sitzung clientseitig neu zu starten.
TCP-Keepalive-Unterstützung für TWAMP-Client und -Server
Keepalive-Tests können Client(Peers) bestätigen, wenn ein anderer Peer nicht mehr erreichbar ist. Wenn das Problem im Netzwerk zwischen zwei Peers auftritt, besteht die Keepalive-Aktion darin, einige Zeit zu warten und dann erneut zu versuchen, das Keepalive-Paket zu senden, bevor die Verbindung als unterbrochen markiert wird.
Wenn der Keepalive-Timer für eine TCP-Verbindung Null erreicht, sendet der TCP-Client seinem Peer ein Keepalive-Testpaket ohne Daten und mit aktiviertem ACK-Flag. Der Client erhält eine Antwort vom Remotehost ohne Daten und mit gesetztem ACK-Flag. Wenn der Client eine Antwort auf seinen Keepalive-Test erhält, kann der Client bestätigen, dass die Verbindung noch verfügbar ist. Wenn der Peer nicht auf den Keepalive-Test antwortet, können Sie bestätigen, 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 Verbindungsfehler der TWAMP-Steuerung auf TWAMP-Client- und TWAMP-Servern zu erkennen:
tcp-keepcnt– Anzahl der nicht bestätigten Sondierungen, die gesendet werden sollen, bevor die Verbindung als tot betrachtet und die Anwendungsschicht benachrichtigt wird.tcp-keepidle– Zeitintervall zwischen dem letzten gesendeten Datenpaket und der ersten gesendeten Keepalive-Sonde.tcp-keepintvl– Zeitintervall zwischen aufeinanderfolgenden Keepalive-Sondierungen.
Tabellarischer Änderungsverlauf
Die Unterstützung der Funktion hängt von der Plattform und der Version ab, die Sie benutzen. Verwenden Sie Funktionen entdecken , um festzustellen, ob eine Funktion auf Ihrer Plattform unterstützt wird.