Inleiding
Dit document beschrijft de kwestie IPsec wanneer Security Associations (SA’s) niet meer synchroon lopen tussen de peer-apparaten.
Probleem
Een van de meest voorkomende problemen met IPsec is dat SA's niet meer kunnen synchroniseren tussen de peer-apparaten. Dientengevolge, versleutelt het encryptie-endpoint verkeer met een SA waarvan de peer niet op de hoogte is. Deze pakketten worden door de peer laten vallen en dit bericht verschijnt in syslog:
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
Opmerking: op de Cisco IOS® XE-routerplatforms, bijvoorbeeld de routers uit de Cisco Aggregation Services Routers (ASR) en Cisco Catalyst 8000 Series, wordt deze bepaalde daling geregistreerd onder zowel de wereldwijde QFP-drop-teller (Quantum Flow Processor) als in de drop-teller van de IPsec-functie, zoals in de volgende voorbeelden wordt getoond.
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
Het is belangrijk om op te merken dat dit bepaalde bericht in Cisco IOS® aan een tarief van één per minuut is beperkt om de duidelijke veiligheidsredenen. Als dit bericht voor een bepaalde stroom (SRC, DST, of SPI) slechts eenmaal in syslog verschijnt, dan is het waarschijnlijk een voorbijgaande voorwaarde die op hetzelfde ogenblik als de sleutel van IPsec aanwezig is, waar één peer kan beginnen om nieuwe SA te gebruiken terwijl het peer apparaat niet vrij klaar is om zelfde SA te gebruiken. Normaal gesproken is dit geen probleem, omdat het slechts van tijdelijke aard is en slechts op een paar pakketten betrekking zou hebben.
Als echter hetzelfde bericht blijft bestaan voor hetzelfde stroom- en SPI-nummer, is het indicatief dat de IPsec SA's niet meer synchroon lopen tussen de peers. Voorbeeld:
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
Dit is een indicatie dat verkeer zwart is en niet kan herstellen tot de SA's verlopen op het verzendende apparaat of tot de Dead Peer Detection (DPD) is geactiveerd.
Oplossing
Dit gedeelte bevat informatie die u kunt gebruiken om het probleem op te lossen dat in het vorige gedeelte wordt beschreven.
Ongeldig SPI-herstel
Om dit probleem op te lossen, raadt Cisco u aan de ongeldige SPI-herstelfunctie in te schakelen. Voer bijvoorbeeld de opdracht crypto isakmp Invalid-spi-recovery in. Hier zijn enkele belangrijke opmerkingen die het gebruik van deze opdracht beschrijven:
- Ten eerste, ongeldig SPI-herstel fungeert alleen als een herstelmechanisme wanneer de SA's niet goed zijn gesynchroniseerd. Het helpt herstellen van deze conditie, maar het lost niet de wortelkwestie op die de SAs veroorzaakte om uit synchronisatie in de eerste plaats te worden. Om de basisoorzaak beter te begrijpen, moet u de debuggen van ISAKMP en IPsec op beide tunneleindpunten inschakelen. Als het probleem vaak voorkomt, dan verkrijg debugs en probeer om de worteloorzaak (en niet alleen maskeren het probleem) aan te pakken.
- Er is een algemene misvatting over het doel en de functionaliteit van de crypto isakmp ongeldige-spi-recovery opdracht. Zelfs zonder deze opdracht voert Cisco IOS al een type ongeldige SPI-herstelfunctionaliteit uit wanneer er een Delete-melding wordt verzonden naar de verzendende peer voor de SA die wordt ontvangen als er al een IKE SA met die peer is. Opnieuw, komt dit ongeacht voor of de crypto isakmp ongeldig-spi-recovery opdracht wordt geactiveerd.
- De opdracht crypto isakmp Invalid-spi-recovery probeert de voorwaarde aan te pakken waar een router IPsec-verkeer ontvangt met ongeldige SPI, en het heeft geen IKE SA met die peer. In dit geval, probeert het om een nieuwe IKE-sessie met de peer op te zetten en verstuurt een Delete-melding via de nieuw gemaakte IKE SA. Deze opdracht werkt echter niet voor alle cryptoconfiguraties. De enige configuraties waarvoor dit commando werkt zijn statische crypto-kaarten waar de peer expliciet is gedefinieerd en statische peers die zijn afgeleid van geconcretiseerde crypto-kaarten, zoals VTI. Hier is een samenvatting van de algemeen gebruikte crypto-configuraties en of de ongeldige terugwinning van SPI met die configuratie werkt:
Crypto-configuratie |
Ongeldig SPI-herstel |
Statische cryptokaart |
Ja |
Dynamische crypto-kaart |
Nee |
P2P GRE met tunnelbescherming |
Ja |
mGRE Tunnelbescherming die gebruik maakt van statische NHRP-mapping |
Ja |
mGRE Tunnelbescherming die gebruik maakt van w/dynamic NHRP mapping |
Nee |
sVTI |
Ja |
EzVPN-client |
N.v.t. |
Intermitterende ongeldige SPI-foutmeldingen oplossen
Vaak komt de ongeldige SPI-foutmelding met tussenpozen voor. Dit maakt het moeilijk om problemen op te lossen, aangezien het erg moeilijk wordt om de relevante debugs te verzamelen. Embedded Event Manager (EEM) scripts kunnen in dit geval erg nuttig zijn.
Bekende Bugs
Deze lijst toont bugs die of IPsec SAs kunnen veroorzaken om uit synchronisatie te gaan of met de Ongeldige terugwinning van SPI verwant zijn:
- Cisco bug-id CSCvn31824 Cisco IOS XE ISAKMP verwijdert nieuwe SPI als rx nieuw SPI-pakket voordat de installatie is voltooid
- Cisco bug-id CSC40554 IKEv2: Cisco IOS kan INV_SPI-melding niet parseren met SPI-grootte 0 - verstuurt INGELDIGE_SYNTAX
- Cisco bug-id CSCvp16730 inkomende ESP-pakketten met SPI-waarde die begint met 0xFF worden verwijderd vanwege ongeldige SPI-fout