Überblick über die Keepalive-Mechanismen in Cisco IOS

Einleitung

In diesem Dokument werden die verschiedenen Keepalive-Mechanismen unter Cisco IOS^{® beschrieben}.

Hintergrundinformationen

Keepalive-Nachrichten werden von einem Netzwerkgerät über einen physischen oder virtuellen Schaltkreis gesendet, um ein anderes Netzwerkgerät darüber zu informieren, dass der Schaltkreis zwischen ihnen noch funktioniert. Damit Keepalives funktionieren, gibt es zwei wesentliche Faktoren:

• Das Keepalive-Intervall ist der Zeitraum zwischen den einzelnen Keepalive-Nachrichten, die von einem Netzwerkgerät gesendet werden. Dies ist immer konfigurierbar.
• Bei den Keepalive-Wiederholungsversuchen handelt es sich um die Anzahl der Wiederholungsversuche, die das Gerät ohne Antwort an Keepalive-Pakete sendet, bevor der Status in "Down" geändert wird. Bei einigen Typen von Keepalives ist dies konfigurierbar, bei anderen gibt es einen Standardwert, der nicht geändert werden kann.

Schnittstellen-Keepalive-Mechanismen

Ethernet-Schnittstellen

Bei Broadcast-Medien wie einem Ethernet sind Keepalives ein wenig einzigartig. Da es viele mögliche Nachbarn auf dem Ethernet gibt, ist der Keepalive nicht darauf ausgelegt, festzustellen, ob der Pfad zu einem bestimmten Nachbarn auf dem Kabel verfügbar ist. Sie ist nur dafür konzipiert, zu überprüfen, ob das lokale System Lese- und Schreibzugriff auf die Ethernet-Leitung selbst hat. Der Router erzeugt ein Ethernet-Paket mit sich selbst als Quell- und Ziel-MAC-Adresse und einem speziellen Ethernet-Typ-Code von 0x9000. Die Ethernet-Hardware sendet dieses Paket an die Ethernet-Leitung und empfängt es dann sofort wieder. Dabei werden die Sende- und Empfangshardware des Ethernet-Adapters und die grundlegende Integrität des Kabels überprüft.

Serielle Schnittstellen

Serielle Schnittstellen können unterschiedliche Typen von Kapselungen haben, und jeder Kapselungstyp bestimmt die Art der verwendeten Keepalives.

Geben Sie den Befehl keepalive im Schnittstellenkonfigurationsmodus ein, um die Häufigkeit festzulegen, mit der ein Router ECHOREQ-Pakete an seinen Peer sendet:

• Um das System auf das standardmäßige Keepalive-Intervall von 10 Sekunden zurückzusetzen, geben Sie den Befehl keepalive mit dem Schlüsselwort no ein.
• Um Keepalives zu deaktivieren, geben Sie den Befehl keepalive disable ein.

Anmerkung: Der keepalive Befehl gilt für serielle Schnittstellen, die High-Level Data Link Control (HDLC) oder PPP-Kapselung verwenden. Sie gilt nicht für serielle Schnittstellen, die Frame Relay-Kapselung verwenden.

Anmerkung: Sowohl für PPP- als auch für HDLC-Kapselungstypen deaktiviert ein Keepalive von 0 Keepalives und wird in der Ausgabe des Befehls show running-config als Keepalive Disable gemeldet.

HDLC-Keepalive

Ein weiterer bekannter Keepalive-Mechanismus sind die seriellen Keepalives für HDLC. Serielle Keepalives werden zwischen zwei Routern hin- und hergeschickt und die Keepalives bestätigt. Durch die Verwendung von Sequenznummern zum Nachverfolgen jedes Keepalive kann jedes Gerät bestätigen, ob der HDLC-Peer den gesendeten Keepalive empfangen hat. Bei der HDLC-Kapselung wird die Schnittstelle durch drei ignorierte Keepalives deaktiviert.

Aktivieren Sie den Befehl debug serial interface 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 es funktioniert:

• Der "myseq" ist unsere eigene fortlaufende Zahl.
• Die "mineseen", die eigentlich eine Bestätigung von der anderen Seite ist (erhöht), die besagt, dass sie diese Zahl von uns erwarten.
• Das "Ihr gesehen", das ist unsere Anerkennung auf der anderen Seite.

Anmerkung: Wenn die Differenz zwischen den Werten in den Feldern myseq und mineseen auf Router 2 drei überschreitet, fällt die Leitung aus, und die Schnittstelle wird zurückgesetzt.

Da HDLC-Keepalives vom ECHOREQ-Typ sind, ist die Keepalive-Frequenz wichtig und es wird empfohlen, dass sie auf beiden Seiten genau übereinstimmen.  Wenn die Timer nicht synchronisiert sind, verlieren die Sequenznummern an Ordnung. Wenn Sie beispielsweise eine Seite auf 10 Sekunden und die andere auf 25 Sekunden einstellen, kann die Schnittstelle so lange aktiv bleiben, wie die Frequenzdifferenz nicht ausreicht, um zu bewirken, dass die Sequenznummern um eine Differenz von drei ausgeschaltet werden.

Router 1 und Router 2 sind über Serial0/0 bzw. Serial2/0 direkt verbunden, um zu veranschaulichen, wie HDLC-Keepalives funktionieren. Um zu veranschaulichen, wie ausgefallene HDCL-Keepalives verwendet werden, um die Schnittstellenzustände zu verfolgen, wird Serial 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-Keepalive

PPP-Keepalives unterscheiden sich ein wenig von HDLC-Keepalives. Im Gegensatz zu HDLC sind PPP-Keepalives eher Pings. Beide Seiten können einander in Ruhe pingen. Der richtige ausgehandelte Schritt besteht darin, IMMER auf diesen "Ping" zu reagieren. Bei PPP Keepalives sind also die Frequenz oder der Timer-Wert nur lokal relevant und haben keine Auswirkung auf die andere Seite. Selbst wenn eine Seite die Keepalives ausschaltet, wird sie dennoch auf die Echo-Anfragen der Seite REAGIEREN, die über einen Keepalive-Timer verfügt. Es wird jedoch niemals eine eigene Initiative ergreifen.

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 erhaltene Antworten:

17:00:11.412: Se0/0/0 LCP-FS: O ECHOREP [Open] id 32 len 12 magic 0x42345A4D

PPP-Keepalives bestehen aus drei Teilen:

• ID-Nummer - wird verwendet, um festzustellen, auf welche ECHOREQ der Peer reagiert.
• Keepalive-Typ - ECHOREQ sind Keepalives, die vom ursprünglichen Gerät gesendet werden, und ECHOREP sind Antworten, die vom Peer gesendet werden.
• Magische Zahlen: Die Benachrichtigungen enthalten die magischen Zahlen des Servers und des Remote-Clients. Der Peer validiert die magische Nummer im LCP-Echo-Request-Paket und überträgt das entsprechende LCP-Echo-Reply-Paket, das die vom Router ausgehandelte magische Nummer enthält.

Bei der PPP-Kapselung wird die Schnittstelle durch fünf ignorierte Keepalives deaktiviert.

GRE-Tunnelschnittstellen

Der GRE-Tunnel-Keepalive-Mechanismus unterscheidet sich geringfügig von den Mechanismen für Ethernet- oder serielle Schnittstellen. Dadurch kann eine Seite Keepalive-Pakete von und zu einem Remote-Router generieren und empfangen, auch wenn der Remote-Router keine GRE-Keepalives unterstützt. Da GRE ein Paket-Tunneling-Mechanismus 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 das innere IP-GRE-Paket weiterleiten muss. Dieser Mechanismus veranlasst die Keepalive-Antwort, die physische Schnittstelle und nicht die Tunnelschnittstelle weiterzuleiten. Weitere Informationen zur Funktionsweise von GRE-Tunnel-Keepalives finden Sie unter How GRE Keepalives Work (Wie GRE-Keepalives funktionieren).

Krypto-Keepalives

IKE-Keepalive

Internet Key Exchange (IKE)-Keepalives dienen dazu, festzustellen, ob ein VPN-Peer aktiv ist und verschlüsselten Datenverkehr empfangen kann. Zusätzlich zu den Schnittstellen-Keepalives sind separate Krypto-Keepalives erforderlich, da VPN-Peers im Allgemeinen nie mit Back-to-Back-Verbindungen verbunden sind, sodass die Schnittstellen-Keepalives nicht genügend Informationen über den Status des VPN-Peers liefern.

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 "no"-Form dieses Befehls. Weitere Informationen zu den einzelnen Schlüsselwörtern in diesem Befehl finden Sie unter crypto isakmp keepalive. Um die Genauigkeit zu erhöhen, können die Keepalives auch unter dem ISAKMP-Profil konfiguriert werden. Weitere Informationen finden Sie unter ISAKMP-Profilübersicht [Cisco IOS IPsec].

NAT-Keepalive

Bei Szenarien, bei denen sich ein VPN-Peer hinter einer Network Address Translation (NAT) befindet, wird NAT-Traversal für die Verschlüsselung verwendet. In Zeiten geringer Auslastung kann es jedoch vorkommen, dass die NAT-Eingabe auf dem Upstream-Gerät abgelaufen ist. Dies kann zu Problemen führen, wenn Sie den Tunnel hochfahren und NAT nicht bidirektional ist. NAT-Keepalives werden aktiviert, um die dynamische NAT-Zuordnung während einer Verbindung zwischen zwei Peers aufrechtzuerhalten. NAT-Keepalives sind UDP-Pakete mit einer unverschlüsselten Nutzlast von einem Byte. Obwohl die aktuelle DPD-Implementierung NAT-Keepalives ähnelt, gibt es einen kleinen Unterschied: DPD wird verwendet, um den Peer-Status zu erkennen, während NAT-Keepalives gesendet werden, wenn die IPsec-Entität das Paket nicht zu einem bestimmten Zeitpunkt gesendet oder empfangen hat. Der gültige Bereich liegt zwischen 5 und 3600 Sekunden.