Comprendre le redémarrage automatique de TWAMP
Après une panne de réseau ou un changement de configuration, lorsque le client TWAMP (Two-Way Active Management Protocol) tombe en panne, vous devez démarrer manuellement la session TWAMP à l’aide d’une request services rpm twamp start client commande. À partir de Junos OS version 19.1R1, le client TWAMP redémarre automatiquement sans aucune intervention manuelle.
Le redémarrage automatique de la session TWAMP permet au client TWAMP d’initier automatiquement la connexion de contrôle TCP et les sessions de test UDP dans les scénarios suivants :
Immédiatement après la validation de la configuration du client TWAMP.
Une fois que le démon d’opération à distance (rmopd) est démarré avec la présence valide de la configuration du client TWAMP.
Une fois la configuration du client TWAMP activée.
Immédiatement après l’accès au serveur TWAMP à partir du client TWAMP, en fonction du
test-intervalfichier .
Lorsque le réseau tombe en panne ou que le serveur TWAMP devient inaccessible pour une raison quelconque, le client TWAMP tente de se reconnecter au serveur TWAMP après chaque test-interval valeur jusqu’à ce qu’il réussisse. Toutefois, pour que le client se reconnecte automatiquement au serveur TWAMP, la test-count valeur de la set rpm twamp client control-connection commande doit être 0. Côté serveur TWAMP, la valeur par défaut de test-count max-connection-duration dans le set rpm twamp server max-connection-duration doit également être 0. Ainsi, vous pouvez conserver la connexion jusqu’à ce qu’elle soit effacée.
À partir de Junos OS version 19.1R1, la valeur par défaut de au niveau du client TWAMP et max-connection-duration du test-count serveur TWAMP est 0.
Une fois que vous avez configuré et validé un test TWAMP, le client exécute les tests indéfiniment, c’est-à-dire qu’il continue d’envoyer des sondes après l’intervalle de test configuré, même après la fin d’un test et même en cas de défaillance du réseau ou du serveur. Vous pouvez arrêter l’exécution automatique des tests en remplaçant la valeur de l’option test-count par une valeur différente de zéro. Si vous faites cela, la fonction de redémarrage automatique est désactivée et vous devez démarrer manuellement le client TWAMP pour qu’il établisse la connexion avec le serveur et démarre les sessions de test.
Vous pouvez gérer et afficher les statistiques relatives aux sondes précédentes envoyées pendant l’indisponibilité du serveur. Vous pouvez utiliser la set services rpm twamp client control-connection c1 persistent-results commande pour conserver et afficher les résultats du test après la récupération du réseau ou lorsque le serveur TWAMP est à nouveau accessible.
Avantages
Vous n’avez pas besoin de redémarrer la session TWAMP manuellement après une panne du client à la suite d’une panne de réseau ou d’un changement de configuration.
Vous n’avez pas besoin d’exécuter un script d’événement pour redémarrer la session TWAMP à partir du côté client.
Prise en charge de TCP Keepalive pour le client et le serveur TWAMP
Les sondes Keepalive peuvent affirmer un ou plusieurs clients lorsqu’un autre pair devient inaccessible. Si le problème se situe dans le réseau entre deux homologues, l’action keepalive consiste à attendre un certain temps, puis à réessayer d’envoyer le paquet keepalive avant de marquer la connexion comme rompue.
Lorsque le temporisateur keepalive d’une connexion TCP atteint zéro, le client TCP envoie à son homologue un paquet de sonde keepalive contenant aucune donnée et avec l’indicateur ACK activé. Le client reçoit une réponse de l’hôte distant sans données et avec l’indicateur ACK défini. Si le client reçoit une réponse à sa sonde keepalive, il peut affirmer que la connexion est toujours en cours d’exécution. Si l’homologue ne répond pas à la sonde keepalive, vous pouvez affirmer que la connexion ne peut pas être considérée comme valide, puis prendre des mesures correctives.
Sous Junos OS, pour détecter les échecs de connexion de contrôle TWAMP au niveau du client TWAMP et des serveurs TWAMP, vous devez configurer les paramètres suivants :
tcp-keepcnt: nombre de sondes non acquittées à envoyer avant de considérer que la connexion est morte et d’en informer la couche d’application.tcp-keepidle: intervalle de temps entre le dernier paquet de données envoyé et la première sonde keepalive envoyée.tcp-keepintvl—Intervalle de temps entre les sondes keepalive successives.