Dieses Dokument beschreibt die verschiedenen Keepalive-Mechanismen auf Cisco IOS®.
Keepalive-Nachrichten werden von einem Netzwerkgerät über eine physische oder virtuelle Leitung gesendet, um einem anderen Netzwerkgerät mitzuteilen, dass die Verbindung zwischen ihnen weiterhin funktioniert. Für Keepalives gibt es zwei wesentliche Faktoren:
Bei Sendemedien wie Ethernet sind Keepalives etwas einzigartig. Da das Ethernet viele mögliche Nachbarn enthält, ist der Keepalive nicht darauf ausgelegt, festzustellen, ob der Pfad zu einem bestimmten Nachbarn des Kabels verfügbar ist. Es ist nur so konzipiert, dass das lokale System über Lese- und Schreibzugriff auf das Ethernet-Kabel selbst verfügt. Der Router erstellt ein Ethernet-Paket mit sich selbst als Quell- und Ziel-MAC-Adresse und einem speziellen Ethernet-Typcode von 0x9000. Die Ethernet-Hardware sendet dieses Paket an das Ethernet-Kabel und empfängt dieses Paket dann sofort wieder zurück. Dadurch wird die Sende- und Empfangshardware des Ethernet-Adapters und die grundlegende Integrität des Kabels überprüft.
Serielle Schnittstellen können verschiedene Arten von Kapselungen aufweisen, und jeder Kapselungstyp bestimmt die Art der zu verwendenden Keepalives.
Geben Sie den Keepalive-Befehl im Schnittstellenkonfigurationsmodus ein, um die Häufigkeit festzulegen, mit der ein Router ECHOREQ-Pakete an seinen Peer sendet:
Ein weiterer bekannter Keepalive-Mechanismus sind serielle Keepalives für HDLC. Serielle Keepalives werden zwischen zwei Routern hin und her gesendet, und die Keepalives werden bestätigt. Durch die Verwendung von Sequenznummern zur Verfolgung der Keepalive-Vorgänge kann jedes Gerät bestätigen, ob es den von ihm gesendeten Keepalive-Empfang empfangen hat. Bei der HDLC-Kapselung werden drei ignorierte Keepalives zum Herunterfahren der Schnittstelle führen.
Aktivieren Sie den Befehl für die serielle Debugschnittstelle für eine HDLC-Verbindung, damit der Benutzer Keepalives sehen kann, die generiert und gesendet werden:
Sample Output:
17:21:09.685: Serial0/0: HDLC myseq 0, mineseen 0*, yourseen 1, line up
HDLC-Keepalives enthalten drei Teile, um festzustellen, ob sie funktionieren:
Da es sich bei HDLC-Keepalives um Keepalives vom Typ ECHOREQ handelt, ist die Keepalive-Frequenz wichtig, und es wird empfohlen, dass sie genau auf beiden Seiten übereinstimmen. Wenn die Timer nicht synchronisiert sind, gehen die Sequenznummern aus der Reihenfolge. Wenn Sie beispielsweise eine Seite auf 10 Sekunden und die andere auf 25 Sekunden einstellen, bleibt die Schnittstelle so lange verfügbar, wie die Frequenzdifferenz nicht ausreicht, um die Sequenznummern um einen Unterschied von drei zu deaktivieren.
Zur Veranschaulichung der Funktionsweise von HDLC-Keepalives werden Router 1 und Router 2 direkt über Serial0/0 bzw. Serial2/0 verbunden. Um zu veranschaulichen, wie die Schnittstellenzustände mithilfe von ausgefallenen HDCL-Keepalives überwacht werden, wird die serielle 0/0 auf Router 1 deaktiviert.
Router 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
Router 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
PPP-Keepalives unterscheiden sich etwas von HDLC-Keepalives. Im Gegensatz zu HDLC sind PPP-Keepalives eher Pings. Beide Seiten können sich frei pingen. Der richtige ausgehandelte Schritt ist, IMMER auf diesen "Ping" zu antworten. Für PPP-Keepalives sind die Frequenz oder der Timer-Wert also nur lokal relevant und haben keine Auswirkungen auf die andere Seite. Selbst wenn eine Seite die Keepalives ausschaltet, reagiert sie weiterhin auf die Echo-Anfragen von der Seite, die über einen Keepalive-Timer verfügen. Sie wird jedoch niemals selbst eine Initiative einleiten.
Aktivieren Sie den Befehl debug ppp packet für eine PPP-Verbindung, damit der Benutzer die gesendeten PPP-Keepalives sehen kann:
17:00:11.412: Se0/0/0 LCP-FS: I ECHOREQ [Open] id 32 len 12 magic 0x4234E325
und eingegangenen Antworten:
17:00:11.412: Se0/0/0 LCP-FS: O ECHOREP [Open] id 32 len 12 magic 0x42345A4D
PPP-Keepalives enthalten drei Teile:
Bei der PPP-Kapselung werden fünf ignorierte Keepalives zum Herunterfahren der Schnittstelle führen.
Der GRE-Tunnel-Keepalive-Mechanismus unterscheidet sich geringfügig von Ethernet- oder seriellen Schnittstellen. Dadurch kann eine Seite Keepalive-Pakete an einen Remote-Router senden und von diesem empfangen, selbst wenn der Remote-Router keine GRE-Keepalives unterstützt. Da GRE ein Pakettunnelmechanismus für das Tunneling von IP innerhalb von IP ist, kann ein GRE-IP-Tunnelpaket in einem anderen GRE-IP-Tunnelpaket erstellt werden. Bei GRE-Keepalives erstellt der Sender das Keepalive-Antwortpaket im ursprünglichen Keepalive-Anforderungspaket vorab, sodass das Remote-Ende nur die standardmäßige GRE-Entkapselung des äußeren GRE-IP-Headers durchführen und anschließend das innere IP-GRE-Paket weiterleiten muss. Dieser Mechanismus bewirkt, dass die Keepalive-Reaktion die physische Schnittstelle und nicht die Tunnelschnittstelle weiterleitet. Weitere Informationen zum Arbeiten von GRE-Tunnel-Keepalives finden Sie unter Funktionsweise von GRE-Keepalives.
IKE-Keepalives (Internet Key Exchange) (IKE-Keepalives) dienen dazu, festzustellen, ob ein VPN-Peer aktiv ist und verschlüsselten Datenverkehr empfangen kann. Zusätzlich zu den Schnittstellenkepaliven sind separate Krypto-Keepalives erforderlich, da VPN-Peers in der Regel nie wieder zurück verbunden sind. Schnittstellenkeepalives liefern daher nicht genügend Informationen über den Zustand des VPN-Peers.
Auf Cisco IOS-Geräten werden IKE-Keepalives durch die Verwendung einer proprietären Methode namens Dead Peer Detection (DPD) aktiviert. Geben Sie den folgenden Befehl im globalen Konfigurationsmodus ein, damit das Gateway DPDs an den Peer senden kann:
crypto isakmp keepalive seconds [retry-seconds] [ periodic | on-demand ]
Um Keepalives zu deaktivieren, verwenden Sie die Form "no" dieses Befehls. Weitere Informationen darüber, was jedes Schlüsselwort in diesem Befehl tut, finden Sie unter crypto isakmp keepalive. Für mehr Detailgenauigkeit können die Keepalives auch unter dem ISAKMP-Profil konfiguriert werden. Weitere Informationen finden Sie unter ISAKMP Profile Overview [Cisco IOS IPsec].
In Szenarien, in denen ein VPN-Peer hinter einer Network Address Translation (NAT) steht, wird NAT-Traversal für die Verschlüsselung verwendet. Während Leerlaufzeiten ist es jedoch möglich, dass der NAT-Eintrag auf dem Upstream-Gerät das Timeout erreicht. Dies kann Probleme verursachen, wenn Sie den Tunnel öffnen, und NAT ist nicht bidirektional. NAT-Keepalives werden aktiviert, um die dynamische NAT-Zuordnung während einer Verbindung zwischen zwei Peers aufrecht zu erhalten. NAT-Keepalives sind UDP-Pakete mit einer unverschlüsselten Nutzlast von einem Byte. Obwohl die aktuelle DPD-Implementierung mit NAT-Keepalives vergleichbar ist, gibt es einen geringfügigen Unterschied: Mit DPD wird der Peer-Status erkannt, während NAT-Keepalives gesendet werden, wenn die IPsec-Einheit das Paket nicht zu einem bestimmten Zeitpunkt gesendet oder empfangen hat. Der gültige Bereich liegt zwischen 5 und 3600 Sekunden.
Weitere Informationen zu dieser Funktion finden Sie unter IPsec NAT Transparency.