Überprüfen von IPsec %RECVD_PKT_INV_SPI-Fehlern und ungültigen Informationen zu SPI-Wiederherstellungsfunktionen

Einleitung

In diesem Dokument wird das IPsec-Problem beschrieben, wenn Sicherheitszuordnungen (SAs) zwischen den Peer-Geräten nicht mehr synchronisiert sind.

Problem

Eines der häufigsten IPsec-Probleme ist, dass SAs zwischen den Peer-Geräten nicht mehr synchronisiert sind. Daher verschlüsselt der Verschlüsselungsendpunkt den Datenverkehr mit einer SA, die der Peer nicht kennt. Diese Pakete werden vom Peer verworfen, und die folgende Meldung wird im Syslog angezeigt:

Sep  2 13:27:57.707: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for 
destaddr=10.10.1.2, prot=50, spi=0xB761863E(3076621886), srcaddr=10.1.1.1

Hinweis: Auf den Cisco IOS® XE Routing-Plattformen, z. B. den Cisco Aggregation Services Routern (ASR) und den Cisco Catalyst Routern der Serie 8000, wird dieser spezielle Tropfen sowohl unter dem globalen Quantum Flow Processor (QFP)-Tropfenzähler als auch unter dem IPsec-Feature-Tropfenzähler registriert, wie in den folgenden Beispielen gezeigt.

Router# show platform hardware qfp active statistics drop | inc Ipsec
  IpsecDenyDrop                              0               0
  IpsecIkeIndicate                           0               0
  IpsecInput                                 0               0     <======
  IpsecInvalidSa                             0               0
  IpsecOutput                                0               0
  IpsecTailDrop                              0               0
  IpsecTedIndicate                           0               0

Router# show platform hardware qfp active feature ipsec datapath drops all | in SPI
        4  IN_US_V4_PKT_SA_NOT_FOUND_SPI                           64574    <======
        7  IN_TRANS_V4_IPSEC_PKT_NOT_FOUND_SPI                         0
       12  IN_US_V6_PKT_SA_NOT_FOUND_SPI                               0

Es ist wichtig zu beachten, dass diese spezielle Nachricht in Cisco IOS® aus offensichtlichen Sicherheitsgründen mit einer Rate von einer pro Minute begrenzt ist. Wenn diese Meldung für einen bestimmten Datenfluss (SRC, DST oder SPI) nur einmal im Syslog auftritt, handelt es sich wahrscheinlich um eine vorübergehende Bedingung, die gleichzeitig mit dem IPsec-Schlüssel vorliegt, bei dem ein Peer die neue SA verwenden kann, während das Peer-Gerät nicht ganz bereit ist, dieselbe SA zu verwenden. Dies ist normalerweise kein Problem, da es nur vorübergehend ist und sich nur auf einige wenige Pakete auswirken würde.

Wenn jedoch dieselbe Nachricht für denselben Datenstrom und dieselbe SPI-Nummer beibehalten wird, weist dies darauf hin, dass die IPsec-SAs zwischen den Peers nicht mehr synchronisiert sind. Beispiele:

Sep  2 13:36:47.287: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for 
destaddr=10.10.1.2, prot=50, spi=0x1DB73BBB(498547643), srcaddr=10.1.1.1
Sep  2 13:37:48.039: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for 
destaddr=10.10.1.2, prot=50, spi=0x1DB73BBB(498547643), srcaddr=10.1.1.1

Dies ist ein Hinweis darauf, dass der Datenverkehr durch einen Black-Holing unterbrochen wird und sich nicht erholen kann, bis die SAs auf dem sendenden Gerät ablaufen oder bis die Dead Peer Detection (DPD) aktiviert ist.

Lösung

Dieser Abschnitt enthält Informationen, die Sie zur Behebung des im vorherigen Abschnitt beschriebenen Problems verwenden können.

Ungültige SPI-Wiederherstellung

Um dieses Problem zu beheben, empfiehlt Cisco die Aktivierung der ungültigen SPI-Wiederherstellungsfunktion. Geben Sie beispielsweise den Befehl crypto isakmp invalid-spi-recovery ein. Im Folgenden finden Sie einige wichtige Hinweise zur Verwendung dieses Befehls:

• Erstens dient eine ungültige SPI-Wiederherstellung nur dann als Wiederherstellungsmechanismus, wenn die SAs nicht synchronisiert sind. Es hilft bei der Wiederherstellung nach diesem Zustand, geht jedoch nicht auf das Problem ein, das die SAs veranlasst hat, überhaupt nicht mehr synchronisiert zu sein. Um die Ursache besser zu verstehen, müssen Sie ISAKMP- und IPsec-Debugging-Dienste an beiden Tunnelendpunkten aktivieren. Wenn das Problem häufig auftritt, holen Sie die Fehlerbehebungsschritte ein, und versuchen Sie, die Ursache anzugehen (und nicht nur das Problem zu maskieren).
  
  
• Es gibt eine weit verbreitete Fehleinschätzung des Zwecks und der Funktionalität des Befehls crypto isakmp invalid-spi-recovery. Selbst ohne diesen Befehl führt Cisco IOS bereits eine Art ungültiger SPI-Wiederherstellungsfunktionalität aus, wenn es eine DELETE-Benachrichtigung an den sendenden Peer für die SA sendet, die empfangen wird, wenn bereits eine IKE SA mit diesem Peer vorhanden ist. Auch dies geschieht unabhängig davon, ob der Befehl crypto isakmp invalid-spi-recovery aktiviert ist.
  
  
• Der Befehl crypto isakmp invalid-spi-recovery versucht, die Bedingung zu beheben, in der ein Router IPsec-Datenverkehr mit einem ungültigen SPI empfängt, und weist keine IKE-SA mit diesem Peer auf. In diesem Fall versucht er, eine neue IKE-Sitzung mit dem Peer herzustellen, und sendet eine DELETE-Benachrichtigung über die neu erstellte IKE SA. Dieser Befehl funktioniert jedoch nicht für alle Krypto-Konfigurationen. Die einzigen Konfigurationen, für die dieser Befehl funktioniert, sind statische Crypto-Maps, bei denen der Peer explizit definiert ist, und statische Peers, die von instanziierten Crypto-Maps, z. B. VTI, abgeleitet sind. Nachfolgend finden Sie eine Zusammenfassung der häufig verwendeten Krypto-Konfigurationen und der Frage, ob eine ungültige SPI-Wiederherstellung mit dieser Konfiguration funktioniert:
  
  

Fehlerbehebung: Ungültige SPI-Fehlermeldungen mit Unterbrechungen

Häufig tritt die ungültige SPI-Fehlermeldung zeitweilig auf. Dies erschwert die Fehlerbehebung, da es sehr schwierig wird, die relevanten Debugs zu sammeln. Embedded Event Manager (EEM)-Skripts können in diesem Fall sehr nützlich sein.

Hinweis: Weitere Informationen finden Sie in den EEM-Skripten zur Fehlerbehebung bei Tunnel-Flaps, die durch ungültige Sicherheitsparameterindizes verursacht wurden.

Bekannte Fehler

Diese Liste zeigt Fehler, die dazu führen können, dass IPsec-SAs nicht mehr synchronisiert sind oder die mit der ungültigen SPI-Wiederherstellung in Zusammenhang stehen:

• Cisco Bug-ID CSCvn31824 Cisco IOS XE ISAKMP löscht neuen SPI, wenn rx neues SPI-Paket vor Abschluss der Installation
• Cisco Bug-ID CSCvd4054 IKEv2: Cisco IOS kann INV_SPI-Benachrichtigung mit SPI-Größe 0 nicht analysieren - sendet INVALID_SYNTAX
• Cisco Bug-ID CSCvp16730 Eingehende ESP-Pakete mit SPI-Wert, die mit 0xFF beginnen, werden aufgrund eines ungültigen SPI-Fehlers verworfen