Ce document décrit les différents mécanismes de keepalive de Cisco IOS®.
Les messages Keepalive sont envoyés par un périphérique réseau via un circuit physique ou virtuel afin d'informer un autre périphérique réseau que le circuit entre eux fonctionne toujours. Pour que les keepalives fonctionnent, deux facteurs sont essentiels :
Sur les supports de diffusion tels qu'Ethernet, les keepalives sont légèrement uniques. Puisqu'il y a beaucoup de voisins possibles sur Ethernet, le keepalive n'est pas conçu pour déterminer si le chemin à un voisin quelconque sur le câble est disponible. Il est conçu uniquement pour vérifier que le système local a un accès en lecture et en écriture au câble Ethernet lui-même. Le routeur produit un paquet Ethernet avec lui-même comme adresse MAC source et de destination et un code de type Ethernet spécial de 0x9000. Le matériel Ethernet envoie ce paquet sur le câble Ethernet, puis reçoit immédiatement ce paquet. Cela permet de vérifier le matériel d'envoi et de réception sur la carte Ethernet et l'intégrité de base du câble.
Les interfaces série peuvent avoir différents types d’encapsulation et chaque type d’encapsulation détermine le type de keepalives qui sera utilisé.
Entrez la commande keepalive en mode de configuration d'interface afin de définir la fréquence à laquelle un routeur envoie des paquets ECHOREQ à son homologue :
Un autre mécanisme de keepalive bien connu est les keepalives série pour HDLC. Les keepalives séquentiels sont envoyés entre deux routeurs et font l'objet d'un accusé de réception. Avec l'utilisation de numéros de séquence pour suivre chaque keepalive, chaque périphérique peut confirmer si son homologue HDLC a reçu le keepalive qu'il a envoyé. Pour l’encapsulation HDLC, trois keepalives ignorés provoquent la désactivation de l’interface.
Activez la commande debug serial interface pour une connexion HDLC afin de permettre à l'utilisateur de voir les messages de veille générés et envoyés :
Sample Output:
17:21:09.685: Serial0/0: HDLC myseq 0, mineseen 0*, yourseen 1, line up
Les keepalives HDLC contiennent trois éléments afin de déterminer qu'ils fonctionnent :
Puisque les keepalives HDLC sont des keepalives de type ECHOREQ, la fréquence keepalive est importante et il est recommandé qu'ils correspondent exactement des deux côtés. Si les compteurs ne sont pas synchronisés, les numéros de séquence commencent à être désordonnés. Par exemple, si vous réglez un côté sur 10 secondes et l'autre sur 25 secondes, l'interface restera active tant que la différence de fréquence n'est pas suffisante pour que les numéros de séquence soient désactivés par une différence de trois.
Pour illustrer le fonctionnement des keepalives HDLC, les routeurs 1 et 2 sont directement connectés via Serial0/0 et Serial2/0, respectivement. Afin d'illustrer comment les keepalives HDCL échoués sont utilisés pour suivre les états d'interface, Serial 0/0 sera arrêté sur le routeur 1.
Routeur 1
Router1#show interfaces serial 0/0/0
Serial0/0/0 is up, line protocol is up (connected)
Hardware is HD64570
Internet address is 10.0.0.1/8
MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255
Encapsulation HDLC, loopback not set, keepalive set (10 sec)
[output is omited]
17:21:09.685: Serial0/0: HDLC myseq 0, mineseen 0*, yourseen 1, line up
17:21:19.725: Serial0/0: HDLC myseq 1, mineseen 1*, yourseen 2, line up
17:21:29.753: Serial0/0: HDLC myseq 2, mineseen 2*, yourseen 3, line up
17:21:39.773: Serial0/0: HDLC myseq 3, mineseen 3*, yourseen 4, line up
17:21:49.805: Serial0/0: HDLC myseq 4, mineseen 4*, yourseen 5, line up
17:21:59.837: Serial0/0: HDLC myseq 5, mineseen 5*, yourseen 6, line up
17:22:09.865: Serial0/0: HDLC myseq 6, mineseen 6*, yourseen 7, line up
17:22:19.905: Serial0/0: HDLC myseq 7, mineseen 7*, yourseen 8, line up
17:22:29.945: Serial0/0: HDLC myseq 8, mineseen 8*, yourseen 9, line up
Router1 (config-if)#shut
17:22:39.965: Serial0/0: HDLC myseq 9, mineseen 9*, yourseen 10, line up
17:22:42.225: %LINK-5-CHANGED: Interface Serial0/0, changed state
to administratively down
17:22:43.245: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0,
changed state to down
Routeur 2
Router2#show interfaces serial 0/0/0
Serial0/0/0 is up, line protocol is up (connected)
Hardware is HD64570
Internet address is 10.0.0.2/8
MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255
Encapsulation HDLC, loopback not set, keepalive set (10 sec)
[output is omited]
17:21:04.929: Serial2/0: HDLC myseq 0, mineseen 0, yourseen 0, line up
17:21:14.941: Serial2/0: HDLC myseq 1, mineseen 1*, yourseen 1, line up
17:21:24.961: Serial2/0: HDLC myseq 2, mineseen 2*, yourseen 2, line up
17:21:34.981: Serial2/0: HDLC myseq 3, mineseen 3*, yourseen 3, line up
17:21:45.001: Serial2/0: HDLC myseq 4, mineseen 4*, yourseen 4, line up
17:21:55.021: Serial2/0: HDLC myseq 5, mineseen 5*, yourseen 5, line up
17:22:05.041: Serial2/0: HDLC myseq 6, mineseen 6*, yourseen 6, line up
17:22:15.061: Serial2/0: HDLC myseq 7, mineseen 7*, yourseen 7, line up
17:22:25.081: Serial2/0: HDLC myseq 8, mineseen 8*, yourseen 8, line up
17:22:35.101: Serial2/0: HDLC myseq 9, mineseen 9*, yourseen 9, line up
17:22:45.113: Serial2/0: HDLC myseq 10, mineseen 10*, yourseen 10, line up
17:22:55.133: Serial2/0: HDLC myseq 11, mineseen 10, yourseen 10, line up
17:23:05.153: HD(0): Reset from 0x203758
17:23:05.153: HD(0): Asserting DTR
17:23:05.153: HD(0): Asserting DTR and RTS
17:23:05.153: Serial2/0: HDLC myseq 12, mineseen 10, yourseen 10, line up
17:23:15.173: HD(0): Reset from 0x203758
17:23:15.173: HD(0): Asserting DTR
17:23:15.173: HD(0): Asserting DTR and RTS
17:23:15.173: Serial2/0: HDLC myseq 13, mineseen 10, yourseen 10, line down
17:23:16.201: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial2/0,
changed state to down
Router2#
17:23:25.193: Serial2/0: HDLC myseq 14, mineseen 10, yourseen 10, line down
Les keepalives PPP sont légèrement différents des keepalives HDLC. Contrairement au protocole HDLC, les keepalives PPP sont plutôt des requêtes ping. Les deux parties peuvent s'envoyer des requêtes ping à leur guise. Le bon mouvement négocié est de TOUJOURS répondre à ce « ping ». Ainsi, pour les keepalives PPP, la fréquence ou la valeur du compteur ne sont pertinentes que localement et n'ont aucun impact de l'autre côté. Même si un côté désactive les messages de veille, il RÉPOND toujours aux requêtes d'écho du côté qui a un compteur de veille. Cependant, elle ne lancera jamais aucune des siennes.
Activez la commande debug ppp packet pour une connexion PPP afin de permettre à l'utilisateur de voir les keepalives PPP envoyés :
17:00:11.412: Se0/0/0 LCP-FS: I ECHOREQ [Open] id 32 len 12 magic 0x4234E325
et réponses reçues :
17:00:11.412: Se0/0/0 LCP-FS: O ECHOREP [Open] id 32 len 12 magic 0x42345A4D
Les keepalives PPP contiennent trois éléments :
Pour l’encapsulation PPP, cinq keepalives ignorés provoquent la désactivation de l’interface
Le mécanisme keepalive de tunnel GRE diffère légèrement de celui des interfaces Ethernet ou série. Il permet à une extrémité d'envoyer et de recevoir des paquets keepalives vers et en provenance d'un routeur distant même si ce dernier ne prend pas en charge les keepalives GRE. Puisque GRE est un mécanisme de transmission tunnel de paquet pour la transmission tunnel IP à l'intérieur d'IP, un paquet de tunnel IP GRE peut être construit à l'intérieur d'un autre paquet de tunnel IP GRE. Pour les keepalives GRE, l'expéditeur préconstruit le paquet de réponse keepalive à l'intérieur du paquet de requête keepalive initial de sorte que l'extrémité distante ait uniquement besoin d'effectuer une désencapsulation GRE standard de l'en-tête IP GRE externe puis de transférer le paquet IP GRE interne. Ce mécanisme fait en sorte que la réponse keepalive transfère l'interface physique plutôt que l'interface du tunnel. Pour plus d'informations sur le fonctionnement des keepalives de tunnel GRE, consultez Comment fonctionnent les keepalives GRE.
Les keepalives Internet Key Exchange (IKE) sont un mécanisme utilisé pour déterminer si un homologue VPN est actif et capable de recevoir du trafic chiffré. Des keepalives de chiffrement distincts sont nécessaires en plus des keepalives d'interface, car les homologues VPN ne sont généralement jamais connectés dos à dos, de sorte que les keepalives d'interface ne fournissent pas suffisamment d'informations sur l'état de l'homologue VPN.
Sur les périphériques Cisco IOS, les keepalives IKE sont activés par l'utilisation d'une méthode propriétaire appelée Dead Peer Detection (DPD). Afin de permettre à la passerelle d'envoyer des DPD à l'homologue, entrez cette commande en mode de configuration globale :
crypto isakmp keepalive seconds [retry-seconds] [ periodic | on-demand ]
Afin de désactiver les keepalives, utilisez la forme « no » de cette commande. Pour plus d'informations sur ce que fait chaque mot clé dans cette commande, consultez crypto isakmp keepalive. Pour plus de granularité, les keepalives peuvent également être configurés sous le profil ISAKMP. Pour plus d'informations, consultez Vue d'ensemble du profil ISAKMP [Cisco IOS IPsec].
Dans les scénarios où un homologue VPN se trouve derrière une traduction d'adresses de réseau (NAT), NAT-Traversal est utilisé pour le chiffrement. Cependant, pendant les périodes d'inactivité, il est possible que l'entrée NAT sur le périphérique en amont expire. Cela peut causer des problèmes lorsque vous ouvrez le tunnel et que NAT n'est pas bidirectionnel. Les keepalives NAT sont activés afin de maintenir le mappage NAT dynamique actif pendant une connexion entre deux homologues. Les keepalives NAT sont des paquets UDP avec une charge utile non chiffrée d'un octet. Bien que l'implémentation DPD actuelle soit similaire aux keepalives NAT, il y a une légère différence - DPD est utilisé pour détecter l'état homologue tandis que les keepalives NAT sont envoyés si l'entité IPsec n'a pas envoyé ou reçu le paquet à une période spécifiée. La plage valide est comprise entre 5 et 3 600 secondes.
Pour plus d'informations sur cette fonctionnalité, consultez Transparence NAT IPsec.