In diesem Dokument wird das IPsec-Anti-Replay-Verhalten in SD-WAN IPsec für Edge-Router und die Fehlerbehebung bei Anti-Replay-Problemen beschrieben.
Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:
Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
Die IPsec-Authentifizierung bietet integrierten Anti-Replay-Schutz gegen alte oder duplizierte IPsec-Pakete, wobei die Sequenznummer im ESP-Header auf dem Empfänger überprüft wird. Das Verwerfen von Anti-Replay-Paketen ist eines der häufigsten Probleme mit IPsec auf Datenebene, da Pakete nicht in der richtigen Reihenfolge oder außerhalb des Anti-Replay-Fensters übermittelt wurden. Eine allgemeine Vorgehensweise zur Fehlerbehebung bei IPsec-Anti-Replay-Drops finden Sie unter Fehlerbehebung bei IPsec-Anti-Replay-Überprüfungsfehlern. Die allgemeine Vorgehensweise gilt auch für SD-WAN. Zwischen den in der Cisco SD-WAN-Lösung verwendeten herkömmlichen IPsec und IPsec bestehen jedoch einige Implementierungsunterschiede. In diesem Artikel werden diese Unterschiede und der Ansatz für cEdge-Plattformen mit Cisco IOS ®XE erläutert.
Im Gegensatz zu herkömmlichen IPsec-Verbindungen, bei denen IPsec-SAs unter Verwendung des IKE-Protokolls zwischen zwei Peers ausgehandelt werden, verwendet das SD-WAN ein Gruppenschlüsselkonzept. Bei diesem Modell generiert ein SD-WAN-Edge-Gerät periodisch eine eingehende SA für die Datenebene pro TLOC (Transport Locator) und sendet diese SAs an den SD-WAN-Controller, der die SA wiederum an die übrigen Edge-Geräte in der SD-WAN-Fabric weitergibt.
Eine ausführlichere Beschreibung der Vorgänge auf SD-WAN-Datenebene finden Sie unter Übersicht über die Sicherheit auf SD-WAN-Datenebene.
Im IPsec-ESP-Header ist der SPI (Security Parameter Index, Sicherheitsparameterindex) ein 32-Bit-Wert, den der Empfänger verwendet, um die SA zu identifizieren, mit der ein eingehendes Paket entschlüsselt wird. Im SD-WAN kann dieser eingehende SPI mit show crypto ipsec sa identifiziert werden:
cedge-2#show crypto ipsec sa | se inbound
inbound esp sas:
spi: 0x123(291)
transform: esp-gcm 256 ,
in use settings ={Transport UDP-Encaps, esn}
conn id: 2083, flow_id: CSR:83, sibling_flags FFFFFFFF80000008, crypto map: Tunnel1-vesen-head-0
sa timing: remaining key lifetime 9410 days, 4 hours, 6 mins
Kilobyte Volume Rekey has been disabled
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
Beachten Sie, dass sich der SPI-Wert im vom Peer-Gerät gesendeten Paket von der vorherigen Ausgabe unterscheidet. Hier ist ein Beispiel aus der Paketverfolgungs-Ausgabe, bei der die Paketkopieoption aktiviert ist:
Packet Copy In 45000102 0cc64000 ff111c5e ac127cd0 ac127cd1 3062303a 00eea51b 04000123 00000138 78014444 f40d7445 3308bf7a e2c2d4a3 73f05304 546871af 8d4e6b9f
Der tatsächliche SPI im ESP-Header ist 0x04000123. Der Grund hierfür ist, dass die ersten Bits im SPI für SD-WAN mit zusätzlichen Informationen codiert werden und nur die niedrigen Bits des SPI-Felds dem tatsächlichen SPI zugewiesen werden.
Traditionelle IPsec:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SD-WAN:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CTR | MSNS| Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Dabei gilt:
Häufig werden IPsec-Wiedergabefehler in einer Umgebung beobachtet, in der Pakete aufgrund von QoS nicht in der richtigen Reihenfolge zugestellt werden, z. B. LLQ (Low Latency Queuing), da QoS immer nach IPsec-Verschlüsselung und -Kapselung ausgeführt wird. Die Multiple Sequence Number Space-Lösung löst dieses Problem durch die Verwendung mehrerer Sequenznummernräume, die unterschiedlichen QoS-Verkehrsklassen für eine bestimmte Sicherheitszuordnung zugeordnet sind. Der unterschiedliche Sequenznummernraum wird durch die MSNS-Bits indiziert, die im ESP-Paket-SPI-Feld wie dargestellt codiert sind. Eine ausführlichere Beschreibung finden Sie unter IPsec Anti Replay Mechanism for QoS.
Wie bereits erwähnt, impliziert diese Implementierung mit mehreren Sequenznummern, dass der effektive SPI-Wert für die SA-Auswahl die reduzierte niedrige Ordnung von 25 Bits ist. Eine weitere praktische Überlegung, wenn die Größe des Wiedergabefensters mit dieser Implementierung konfiguriert wird, ist die konfigurierte Größe des Wiedergabefensters für das aggregierte Wiedergabefenster, sodass die effektive Größe des Wiedergabefensters für jeden Sequenznummernraum 1/8 des aggregierten Fensters beträgt.
Konfigurationsbeispiel:
config-t
Security
IPsec
replay-window 1024
Commit
Anmerkung: Die effektive Größe des Wiedergabefensters für jeden Sequenznummernraum beträgt 1024/8 = 128!
Auf einem cEdge-Gerät kann die letzte für jeden Sequenznummernbereich empfangene Sequenznummer aus der Ausgabe des IPsec-Datenplans show crypto ipsec sa peer x.x.x.x abgerufen werden:
cedge-2#show crypto ipsec sa peer 172.18.124.208 platform <snip> ------------------ show platform hardware qfp active feature ipsec datapath crypto-sa 5 ------------------ Crypto Context Handle: ea54f530 peer sa handle: 0 anti-replay enabled esn enabled Inbound SA Total SNS: 8 Space highest ar number ---------------------------------------- 0 39444 1 0 2 1355 3 0 4 0 5 0 6 0 7 0 <snip>
Im Beispiel ist die höchste Nummer für die Sequenz des Anti-Replay-Fensters (rechter Rand des Anti-Replay-Gleitfensters) für MSNS von 0 (0x00) die Nummer 3944 und für MSNS von 2 (0x04) die Nummer 1335. Mit diesen Zählern wird überprüft, ob die Sequenznummer befindet sich innerhalb des Wiedergabefensters für Pakete im gleichen Sequenznummernbereich.
Es ist möglich, die Anti-Replay-Fehler und die Ausgänge zu korrelieren, um den SPI und den Sequenznummernindex zu finden, wie im Bild dargestellt.

Mit den vorherigen Informationen erhalten, die rechte Kante (oberes Fenster) und das Schiebefenster; wie im Bild dargestellt.

Anders als bei regulären IPsec (nicht SD-WAN) wird der Befehl rekey für das Anti-Replay-Fenster nicht wirksam.
request platform software sdwan security ipsec-rekey
Mit diesen Befehlen wird das konfigurierte Wiedergabefenster aktiviert:
Warnung: Stellen Sie sicher, dass Sie die potenziellen Auswirkungen von Befehlen verstehen, da diese die Steuerungsverbindungen und die Datenebene beeinflussen.
clear sdwan control connection
Oder
request platform software sdwan port_hop color <color>
Oder
interface Tunnelx
shutdown
no shutdown
Damit die IPsec-Anti-Replay-Funktion nicht ausgeführt wird, ist es wichtig, die Bedingungen und potenziellen Auslöser des Problems zu kennen. Sammeln Sie mindestens die Informationen für, um den Kontext bereitzustellen:
Fahren Sie mit dem Fehlerbehebungs-Workflow fort, nachdem Sie die vorherigen Informationen gesammelt haben.
Der allgemeine Ansatz zur Fehlerbehebung bei IPsec-Wiederholungsproblemen entspricht dem für herkömmliche IPsec-Anwendungen. Berücksichtigen Sie den pro-Peer-SA-Sequenzbereich und den Multiple Sequence Number Space wie erläutert. Gehen Sie dann wie folgt vor:
Schritt 1: Identifizieren Sie zuerst den Peer für die Wiederholungs-Verwerfung aus dem Syslog und die Verwerfungsrate. Sammeln Sie für Drop-Statistiken immer mehrere Zeitstempel-Snapshots der Ausgabe, sodass die Drop-Rate quantifiziert werden kann:
*Feb 19 21:28:25.006: %IOSXE-3-PLATFORM: R0/0: cpp_cp: QFP:0.0 Thread:000 TS:00001141238701410779 %IPSEC-3-REPLAY_ERROR: IPSec SA receives anti-replay error, DP Handle 6, src_addr 172.18.124.208, dest_addr 172.18.124.209, SPI 0x123
cedge-2#show platform hardware qfp active feature ipsec datapath drops
Load for five secs: 1%/0%; one minute: 1%; five minutes: 1%
No time source, *11:25:53.524 EDT Wed Feb 26 2020
------------------------------------------------------------------------
Drop Type Name Packets
------------------------------------------------------------------------
4 IN_US_V4_PKT_SA_NOT_FOUND_SPI 30
19 IN_CD_SW_IPSEC_ANTI_REPLAY_FAIL 41
Schritt 2a: Bei einer relativ geringen Datenverkehrsrate führen Sie eine Paketverfolgung durch, wobei die Bedingung mit der Option copy packet auf die IPv4-Adresse des Peers festgelegt wird. Überprüfen Sie die Sequenznummern für das verworfene Paket im Vergleich zum aktuellen Wiedergabefenster (rechter Rand) und den Sequenznummern in den benachbarten Paketen. Bestätigen Sie, ob es sich tatsächlich um Duplikate oder um Duplikate außerhalb des Wiedergabefensters handelt.
Schritt 2b: Konfigurieren Sie für eine hohe Datenverkehrsrate ohne vorhersehbare Auslöser eine EPC-Erfassung mit zirkulärem Puffer und EEM, um die Erfassung zu stoppen, wenn Wiedergabefehler erkannt werden. Da EEM ab Version 19.3 von vManage derzeit nicht unterstützt wird, impliziert dies, dass sich cEdge bei der Durchführung dieser Fehlerbehebungsaufgabe im CLI-Modus befinden muss.
Schritt 3. Sammeln Sie die Ausgabe von show crypto ipsec als Peer-x.x.x.x-Plattform auf dem Empfänger, idealerweise zur gleichen Zeit wie bei der Paketerfassung oder wenn die Paketverfolgung gesammelt wird. Dieser Befehl enthält die Echtzeitinformationen zum Replay-Fenster des Datenbereichs für die eingehende und ausgehende SA.
Schritt 4: Wenn das verworfene Paket nicht in der richtigen Reihenfolge gesendet wird, führen Sie gleichzeitige Erfassungen von Sender und Empfänger durch, um festzustellen, ob das Problem bei der Quelle oder der zugrunde liegenden Netzwerkzustellungsschicht liegt.
Schritt 5. Wenn die Pakete verworfen werden, obwohl sie weder doppelt vorhanden sind noch sich außerhalb des Wiedergabefensters befinden, dann ist dies in der Regel ein Hinweis auf ein Softwareproblem auf dem Empfänger.
Problembeschreibung:
HW: ASR 1001-X
SW: 17.06.03a
Mehrere Anti-Replay-Fehler werden für den Session-Peer 10.62.33.91 empfangen. Daher flattert die BFD-Sitzung ständig, und der Datenverkehr zwischen diesen beiden Standorten ist betroffen.
Jul 26 20:31:20.879: %IOSXE-3-PLATFORM: R0/0: cpp_cp: QFP:0.0 Thread:027 TS:00000093139972173042 %IPSEC-3-REPLAY_ERROR: IPSec SA receives anti-replay error, DP Handle 22, src_addr 10.62.33.91, dest_addr 10.62.63.251, SPI 0x106
Jul 26 20:32:23.567: %IOSXE-3-PLATFORM: R0/0: cpp_cp: QFP:0.0 Thread:009 TS:00000093202660128696 %IPSEC-3-REPLAY_ERROR: IPSec SA receives anti-replay error, DP Handle 22, src_addr 10.62.33.91, dest_addr 10.62.63.251, SPI 0x106
Jul 26 20:33:33.939: %IOSXE-3-PLATFORM: R0/0: cpp_cp: QFP:0.0 Thread:051 TS:00000093273031417384 %IPSEC-3-REPLAY_ERROR: IPSec SA receives anti-replay error, DP Handle 22, src_addr 10.62.33.91, dest_addr 10.62.63.251, SPI 0x106
Jul 26 20:34:34.407: %IOSXE-3-PLATFORM: R0/0: cpp_cp: QFP:0.0 Thread:020 TS:00000093333499638628 %IPSEC-3-REPLAY_ERROR: IPSec SA receives anti-replay error, DP Handle 22, src_addr 10.62.33.91, dest_addr 10.62.63.251, SPI 0x106
Schritt 1. Überprüfen Sie, ob das konfigurierte Anti-Replay-Fenster 8192 lautet.
cEdge#show sdwan security-info
security-info authentication-type deprecated
security-info rekey 86400
security-info replay-window 8192
security-info encryption-supported "AES_GCM_256 (and AES_256_CBC for multicast)"
security-info fips-mode Disabled
security-info pairwise-keying Disabled
security-info pwk-sym-rekey Enabled
security-info extended-ar-window Disabled
security-info integrity-type "ip-udp-esp esp"
Schritt 2: Überprüfen der tatsächlichen Größe des Wiedergabefensters für Peer 10.62.33.91 zum Vergleichen und Bestätigen des konfigurierten Werts
show crypto ipsec sa peer 10.62.33.91 platform
<snip>
------------------ show platform hardware qfp active feature ipsec sa 22 ------------------
<snip>
------------------ show platform software ipsec fp active encryption-processor 0 context c441ff4c ------------------
<snip>
window size: 64 <-- Effective Window Size
window base(ESN): 0
Multi-SNS window_top
-----------------------------------
index: 0, win_top: 0x00000000010dc0
index: 1, win_top: 0000000000000000
index: 2, win_top: 0x00000000b65f00
index: 3, win_top: 0000000000000000
index: 4, win_top: 0000000000000000
index: 5, win_top: 0000000000000000
index: 6, win_top: 0000000000000000
index: 7, win_top: 0000000000000000
traffic hard limit: 12876354284605669376
byte count: 0
packet count: 11378618
Die Fenstergröße: 64 entspricht nicht dem konfigurierten Wiedergabefenster von 8192 (8192/8=1024), d. h. der Befehl wurde trotz der Konfiguration nicht übernommen.
Schritt 3: Konfigurieren und aktivieren Sie gleichzeitig die Paketablaufverfolgung und die Überwachungserfassung (optional) für eingehenden Datenverkehr von der Sitzungsquelle: 10.62.33.91, Bestimmungsort: 10.62.63.251
cEdge#debug platform packet-trace packet 2048 circular fia-trace data-size 2048
cEdge#debug platform packet-trace copy packet both size 2048 L3
cEdge#debug platform condition ipv4 10.62.33.91/32 in
cEdge#debug platform condition start
Schritt 4: Zusammenfassung der Paketverfolgung sammeln:
cEdge#show platform packet summay
811 Te0/0/0.972 Te0/0/1.301 FWD
812 Te0/0/0.972 Te0/0/1.301 FWD
813 Te0/0/0.972 Te0/0/1.301 FWD
814 Te0/0/0.972 Te0/0/1.301 FWD
815 Te0/0/0.972 Te0/0/1.301 FWD
816 Te0/0/0.972 Te0/0/0.972 DROP 56 (IpsecInput)
817 Te0/0/0.972 Te0/0/0.972 DROP 56 (IpsecInput)
818 Te0/0/0.972 Te0/0/0.972 DROP 56 (IpsecInput)
819 Te0/0/0.972 Te0/0/0.972 DROP 56 (IpsecInput)
837 Te0/0/0.972 Te0/0/1.301 FWD
838 Te0/0/0.972 Te0/0/1.301 FWD
Schritt 5: Erweitern Sie einige gelöschte (IpsecInput) Pakete, die erfasst wurden.
(IPSecInput) Paketverluste:
cEdge#sh platform pack pack 816
Packet: 816 CBUG ID: 973582
Summary
Input : TenGigabitEthernet0/0/0.972
Output : TenGigabitEthernet0/0/0.972
State : DROP 56 (IpsecInput)
Timestamp
Start : 97495234494754 ns (07/26/2022 21:43:56.25110 UTC)
Stop : 97495234610186 ns (07/26/2022 21:43:56.25225 UTC)
Path Trace
Feature: IPV4(Input)
Input : TenGigabitEthernet0/0/0.972
Output : <unknown>
Source : 10.62.33.91
Destination : 10.62.63.251
Protocol : 17 (UDP)
SrcPort : 12367
DstPort : 12347
<snip>
Packet Copy In
45000072 ab314000 fd115c77 0a3e215b 0a3e3ffb 304f303b 005e0000 04000106
00b6dfed 00000000 d0a60d5b 6161b06e 453d0e3d 5ab694ce 5311bbb6 640ecd68
7ceb2726 80e39efd 70e5549e 57b24820 fb963be5 76d01ff8 273559b0 32382ab4
c601d886 da1b3b94 7a2826e2 ead8f308 c464
817 DROP:
-------------------------------
Packet: 817
<snip>
Packet Copy In
45000072 ab314000 fd115c77 0a3e215b 0a3e3ffb 304f303b 005e0000 04000106
00b6dfec 00000000 cc72d5dd ef73fe25 2440bed6 31378b78 3c506ee5 98e3dba4
bc9e6aa0 50ea98f6 7dee25c8 c1579ce0 1212290c 650f5947 57b9bc04 97c7996c
d4dbf3e6 25b33684 a7129b67 141a5e73 8736
SD-WAN nutzt UDP-gekapselten ESP:
Schritt 6: Überprüfen des MSNS-Index
show crypto ipsec sa peer 10.62.33.91 platform
<snip>
------------------ show platform hardware qfp active feature ipsec sa 22 ------------------
<snip>
------------------ show platform software ipsec fp active encryption-processor 0 context c441ff4c ------------------
<snip>
window size: 64
window base(ESN): 0
Multi-SNS window_top
-----------------------------------
index: 0, win_top: 0x00000000010dc0
index: 1, win_top: 0000000000000000
index: 2, win_top: 0x00000000b65f00
index: 3, win_top: 0000000000000000
index: 4, win_top: 0000000000000000
index: 5, win_top: 0000000000000000
index: 6, win_top: 0000000000000000
index: 7, win_top: 0000000000000000
traffic hard limit: 12876354284605669376
byte count: 0
packet count: 11378618
Die höchste Sequenznummer des Anti-Replay-Fensters (rechter Rand des Anti-Replay-Schiebereglers) für MSNS von 2 (0x04) ist 0b65f00.
Schritt 7: Erweitern Sie einige weitergeleitete (FWD) erfasste Pakete.
Weitergeleitete Pakete:
Packet: 838
<snip>
Packet Copy In
4564008e ab044000 fd115c24 0a3e215b 0a3e3ffb 304f303b 007a0000 04000106
00b6e015 00000000 088bbd6a f4e4b35f b131143f ef1f91eb 659149f7 dbe6b025
be7fbfd0 5fad1c71 014321f1 3e0d38f2 cc8d0e5f 1494e4fa 097c7723 dfc7ceef
4a14f444 abcc1777 0bb9337f cd70c1da 01fc5262 848b657c 3a834680 b07b7092
81f07310 4eacd656 ed36894a e468
Paket: 837
Packet: 837
<snip>
Packet Copy In
4564008e ab044000 fd115c24 0a3e215b 0a3e3ffb 304f303b 007a0000 04000106
00b6e014 00000000 76b2a256 8e835507 13d14430 ae16d62c c152cdfd 2657c20c
01d7ce1d b3dfa451 a2cbf6e9 32f267f9 e10e9dec 395a0f9e 38589adb aad8dfb8
a3b72c8d a96f2dce 2a1557ab 67959b6e 94bbbb0a cfc4fc9e 391888da af0e492c
80bebb0e 9d7365a4 153117a6 4089
Schritt 8: Sammeln Sie die Sequenznummerninformationen von mehreren weitergeleiteten Paketen (FWD) vor, nach und nach den Löschvorgängen, und rufen Sie sie ab.
FWD:
839 PKT: 00b6e003 FWD
838 PKT: 00b6e001 FWD
837 PKT: 00b6e000 FWD
815 PKT: 00b6e044 FWD
814 PKT: 00b6dfe8 FWD
813 PKT: 00b6e00d FWD
DROP:
816 PKT: 00b6dfed DROP
817 PKT: 00b6dfec DROP
818 PKT: 00b6dfeb DROP
819 PKT: 00b6dfe9 DROP
820 PKT: 00b6dfea DROP
Schritt 9: Wandeln Sie die Sequenznummer von Hexadezimalzahl in Dezimalzahl um, und ordnen Sie sie neu an, um die Berechnung zu vereinfachen:
REORDERED:
813 PKT: 00b6e00d FWD --- Decimal: 11984909
814 PKT: 00b6dfe8 FWD --- Decimal: 11984872
815 PKT: 00b6e044 FWD --- Decimal: 11984964 ***** Highest Value
816 PKT: 00b6dfed DROP--- Decimal: 11984877
817 PKT: 00b6dfec DROP--- Decimal: 11984876
818 PKT: 00b6dfeb DROP--- Decimal: 11984875
819 PKT: 00b6dfe9 DROP--- Decimal: 11984873
820 PKT: 00b6dfea DROP--- Decimal: 11984874
<snip>
837 PKT: 00b6e014 FWD --- Decimal: 11984916
838 PKT: 00b6e015 FWD --- Decimal: 11984917
839 PKT: 00b6e016 FWD --- Decimal: 11984918
Schritt 10: Berechnen Sie den Unterschied zwischen der höchsten Sequenznummer und der empfangenen Sequenznummer für jedes Paket:
Difference:
815 PKT: Decimal: 11984964 ***** Highest Value
--------------------------------------
815(Highest) - X PKT = Diff
--------------------------------------
816 PKT: 11984964 - 11984877 = 87 DROP
817 PKT: 11984964 - 11984876 = 88 DROP
818 PKT: 11984964 - 11984875 = 89 DROP
819 PKT: 11984964 - 11984873 = 91 DROP
820 PKT: 11984964 - 11984874 = 90 DROP
<snip>
837 PKT: 11984964 - 11984916 = 48 FWD
838 PKT: 11984964 - 11984917 = 47 FWD
839 PKT: 11984964 - 11984918 = 45 FWD
Für dieses Beispiel ist es möglich, das Schiebefenster mit der Fenstergröße 64 und dem rechten Rand 11984964 wie in der Abbildung dargestellt zu visualisieren:

Die empfangene Sequenznummer für verworfene Pakete liegt weit vor dem rechten Rand des Wiedergabefensters für diesen Sequenzbereich.
Da die Fenstergröße noch im vorherigen Wert 64 liegt, wie in Schritt 2 zu sehen ist, muss einer der Befehle im Abschnitt Befehle, die das neu konfigurierte Wiedergabefenster zwingen, angewendet werden, damit die vergrößerte Fenstergröße 1024 wirksam wird.
Ein weiteres nützliches Tool zur Korrelation von ESP-SPI und Sequenznummer ist Wireshark.
Konfigurieren Sie die Paketerfassung für die eingehende Richtung, und exportieren Sie sie in die pcap-Datei.
monitor caputure CAP match ipv4 host 10.62.33.91 host 10.62.63.251 buffer size 20 inter TenGigabitEthernet0/0/0 in
monitor caputure CAP star
monitor caputure CAP stop
monitor caputure CAP export bootflash:Anti-replay.pca
Wenn die PCAP-Erfassung in Wireshark geöffnet wird, erweitern Sie ein Paket, um die ESP-SPI- und Sequenznummer anzuzeigen, indem Sie mit der rechten Maustaste klicken und die Protokolleinstellungen auswählen. Suchen Sie nach UDPENCAP, und ändern Sie den Standardport in den SD-WAN-Port (Quellport), wie im Bild gezeigt:

Nachdem UDPENCAP mit dem richtigen Port installiert wurde, werden nun die ESP-Informationen angezeigt, wie im Bild gezeigt:

| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
2.0 |
24-Jun-2026
|
Aktualisierte Rechtschreibung, Grammatik, Satzstruktur, Abstände und feste URL-Probleme sowie CCW-Warnungen. |
1.0 |
08-Sep-2022
|
Erstveröffentlichung |