Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Ce document décrit le comportement d'anti-relecture IPsec dans SD-WAN IPsec pour les routeurs Edge et comment dépanner les problèmes d'anti-relecture.
Cisco vous recommande de prendre connaissance des rubriques suivantes :
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
L'authentification IPsec fournit une protection intégrée contre la relecture contre les paquets IPsec anciens ou dupliqués avec le numéro de séquence dans l'en-tête ESP vérifié sur le récepteur. Les abandons de paquets anti-relecture sont l'un des problèmes de plan de données les plus courants avec IPsec en raison des paquets livrés dans le désordre en dehors de la fenêtre anti-relecture. Une approche générale de dépannage pour les abandons de l'anti-relecture IPsec peut être trouvée dans les échecs de vérification de l'anti-relecture IPsec, et la technique générale s'applique également à SD-WAN. Cependant, certaines différences d'implémentation existent entre IPsec traditionnel et IPsec utilisé dans la solution Cisco SD-WAN. Cet article a pour but d'expliquer ces différences et l'approche des plates-formes cEdge avec Cisco IOS ®XE.
Contrairement à IPsec traditionnel, où les SA IPsec sont négociées entre deux homologues à l'aide du protocole IKE, SD-WAN utilise un concept de clé de groupe. Dans ce modèle, un périphérique de périphérie SD-WAN génère périodiquement des SA entrantes de plan de données par TLOC et envoie ces SA au contrôleur vSmart, qui à son tour propage la SA au reste des périphériques de périphérie dans le réseau SD-WAN. Pour une description plus détaillée des opérations du plan de données SD-WAN, consultez Vue d'ensemble de la sécurité du plan de données SD-WAN.
Remarque : depuis Cisco IOS ®XE. 6.12.1a/SD-WAN 19.2, les clés IPsec par paires sont prises en charge. Voir Présentation des clés IPsec par paire. Avec les touches Pairwise, la protection anti-relecture IPsec fonctionne exactement comme IPsec traditionnel. Cet article se concentre principalement sur la vérification de relecture avec l'utilisation du modèle de clé de groupe.
Dans l'en-tête ESP IPsec, le SPI (Security Parameter Index) est une valeur de 32 bits que le récepteur utilise pour identifier l'association de sécurité avec laquelle un paquet entrant est décrypté. Avec SD-WAN, ce SPI entrant peut être identifié avec show crypto ipsec sa :
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)
Remarque : même si le SPI entrant est le même pour tous les tunnels, le récepteur a un SA différent et l'objet de fenêtre de relecture correspondant associé au SA pour chaque périphérique de périphérie homologue puisque le SA est identifié par la source, l'adresse IP de destination, la source, les ports de destination 4-uplet et le numéro SPI. Donc essentiellement, chaque homologue a son propre objet fenêtre anti-replay.
Dans le paquet réel envoyé par le périphérique homologue, notez que la valeur SPI est différente de la sortie précédente. Voici un exemple du résultat de la commande packet-trace avec l'option de copie de paquet activée :
Packet Copy In 45000102 0cc64000 ff111c5e ac127cd0 ac127cd1 3062303a 00eea51b 04000123 00000138 78014444 f40d7445 3308bf7a e2c2d4a3 73f05304 546871af 8d4e6b9f
Le SPI réel dans l'en-tête ESP est 0x04000123. La raison en est que les premiers bits de l'interface SPI pour SD-WAN sont codés avec des informations supplémentaires, et seuls les bits bas du champ SPI sont alloués pour l'interface SPI réelle.
IPsec traditionnel :
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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:
Il est courant d'observer des échecs de relecture IPsec dans un environnement où les paquets sont livrés dans le désordre en raison de la QoS, par exemple, LLQ, car la QoS est toujours exécutée après le chiffrement et l'encapsulation IPsec. La solution Multiple Sequence Number Space résout ce problème en utilisant plusieurs espaces de numéros de séquence mappés à différentes classes de trafic QoS pour une association de sécurité donnée. L'espace des différents numéros de séquence est indexé par les bits MSNS codés dans le champ SPI du paquet ESP comme illustré. Pour une description plus détaillée, veuillez voir IPsec Anti Replay Mechanism for QoS.
Comme indiqué précédemment, cette implémentation de numéro de séquence multiple implique que la valeur SPI efficace qui peut être utilisée pour la sélection SA est la valeur réduite de 25 bits de poids faible. Une autre considération pratique lorsque la taille de fenêtre de relecture est configurée avec cette implémentation est que la taille de fenêtre de relecture configurée est pour la fenêtre de relecture agrégée, de sorte que la taille de fenêtre de relecture effective pour chaque espace de numéro de séquence est 1/8 de l'agrégat.
Exemple de configuration :
config-t
Security
IPsec
replay-window 1024
Commit
Remarque : la taille de fenêtre de relecture effective pour chaque espace de numéro de séquence est 1024/8 = 128 !
Remarque : depuis la plate-forme logicielle Cisco IOS ®XE. 17.2.1, la taille de la fenêtre de relecture agrégée a été augmentée à 8192 de sorte que chaque espace de numéros de séquence peut avoir une fenêtre de relecture maximale de 8192/8 = 1024 paquets.
Sur un périphérique cEdge, le dernier numéro de séquence reçu pour chaque espace de numéro de séquence peut être obtenu à partir de la sortie du plan de données show crypto ipsec sa peer x.x.x.x platform IPsec :
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>
Dans l'exemple, la fenêtre anti-relecture la plus élevée (bord droit de la fenêtre glissante anti-relecture) pour MSNS de 0 (0x00) est 3944, et celle pour MSNS de 2 (0x04) est 1335, et ces compteurs sont utilisés pour vérifier si le numéro de séquence est à l'intérieur de la fenêtre de relecture pour les paquets dans le même espace de numéro de séquence.
Remarque : il existe des différences de mise en oeuvre entre la plate-forme ASR1k et les autres plates-formes de routage Cisco IOS ®XE (ISR4k, ISR1k, CSR1kv). Par conséquent, il y a des différences en termes de commandes show et de leurs résultats pour ces plates-formes.
Il est possible de corréler les erreurs Anti-Replay et les sorties show pour trouver le SPI, et l'index de numéro de séquence comme indiqué dans l'image.
Avec les informations précédentes obtenues le bord droit (fenêtre supérieure) et la fenêtre glissante ressemble comme indiqué dans l'image.
Contrairement à l'IPsec normal (non SD-WAN), la commande rekey n'est pas appliquée à la fenêtre anti-replay.
request platform software sdwan security ipsec-rekey
Ces commandes déclenchent la prise d'effet de la fenêtre de relecture configurée :
Avertissement : assurez-vous que vous comprenez l'impact potentiel de toute commande, ils affectent les connexions de contrôle et le plan de données.
clear sdwan control connection
ou
request platform software sdwan port_hop <color>
ou
Interface Tunnelx
shutdown/ no shutdown
Pour les abandons anti-relecture IPsec, il est important de comprendre les conditions et les déclencheurs potentiels du problème. Au minimum, collectez l'ensemble d'informations pour fournir le contexte :
Une fois les informations précédentes collectées, poursuivez le workflow de dépannage.
L'approche générale de dépannage pour les problèmes de relecture IPsec est semblable à la façon dont elle est effectuée pour IPsec traditionnel, tenir compte de l'espace de séquence SA par homologue et de l'espace de numéros de séquence multiples comme expliqué. Ensuite, procédez comme suit :
Étape 1. Identifiez d'abord l'homologue pour l'abandon de la relecture à partir du syslog et le taux d'abandon. Pour les statistiques d'abandon, collectez toujours plusieurs instantanés horodatés de la sortie afin que le taux d'abandon puisse être quantifié :
*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
Remarque : il n'est pas rare de voir des pertes de relecture occasionnelles dues à la réorganisation de la livraison des paquets sur le réseau, mais les pertes de relecture persistantes ont un impact sur le service et peuvent être analysées.
Étape 2a. Pour un débit de trafic relativement faible, prenez une trace de paquet avec la condition définie pour être l'adresse ipv4 homologue avec l'option copy packet et examinez les numéros de séquence pour le paquet abandonné par rapport au bord droit de la fenêtre de relecture actuelle et les numéros de séquence dans les paquets adjacents pour confirmer s'ils sont effectivement dupliqués ou en dehors de la fenêtre de relecture.
Étape 2b. Pour un débit de trafic élevé sans déclencheur prévisible, configurez une capture EPC avec tampon circulaire et EEM pour arrêter la capture lorsque des erreurs de relecture sont détectées. EEM n'étant pas pris en charge sur vManage à partir de la version 19.3, cela signifie que le serveur cEdge doit être en mode CLI lorsque cette tâche de dépannage est effectuée.
Étape 3. Collectez la plate-forme show crypto ipsec sa peer x.x.x.x sur le récepteur idéalement au moment où la capture de paquets ou la trace de paquets est collectée. Cette commande inclut les informations de la fenêtre de relecture du plan de données en temps réel pour l'association de sécurité entrante et sortante.
Étape 4. Si le paquet abandonné est en effet dans le désordre, effectuez des captures simultanées de l’expéditeur et du destinataire pour déterminer si le problème provient de la source ou de la couche de livraison réseau sous-jacente.
Étape 5. Si les paquets sont abandonnés alors qu'ils ne sont ni dupliqués ni en dehors de la fenêtre de relecture, cela indique généralement un problème logiciel sur le récepteur.
Description du problème :
Matériel : ASR1001-X
Logiciel : 17.06.03a
Plusieurs erreurs d'anti-relecture sont reçues pour l'homologue de session 10.62.33.91. Par conséquent, la session BFD est constamment instable et le trafic entre ces deux sites est affecté.
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
Étape 1. Cochez la case Configured Anti Replay Window is 8192.
cEdge#sh 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"
Remarque : la taille de fenêtre de relecture effective pour chaque espace de numéro de séquence doit être 8192/8= 1024 dans cet exemple.
Étape2. Vérifiez la taille de la fenêtre de relecture effective pour l'homologue 10.62.33.91 pour comparer et confirmer la valeur configurée.
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
Les Taille de la fenêtre : 64 affiché dans le résultat ne correspond pas à la fenêtre de relecture configurée 8192 (8192/8=1024), ce qui signifie que même si elle a été configurée, la commande n'a pas pris effet.
Remarque : la fenêtre de relecture effective s'affiche uniquement sur les plates-formes ASR. Afin de s'assurer que la taille réelle de la fenêtre anti-relecture est la même que la taille configurée, appliquez l'une des commandes de la section pour mesurer l'efficacité de la fenêtre de relecture configurée.
Étape 3. Configurez et activez simultanément le suivi des paquets et la capture de surveillance (facultatif) pour le trafic entrant en provenance de la source de session : 10.62.33.91, destination : 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 plat cond start
Étape 4. Récapitulatif du suivi des paquets :
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)
820 Te0/0/0.972 Te0/0/0.972 DROP 56 (IpsecInput)
821 Te0/0/0.972 Te0/0/0.972 DROP 56 (IpsecInput)
822 Te0/0/0.972 Te0/0/0.972 DROP 56 (IpsecInput)
823 Te0/0/0.972 Te0/0/0.972 DROP 56 (IpsecInput)
824 Te0/0/0.972 Te0/0/0.972 DROP 56 (IpsecInput)
825 Te0/0/0.972 Te0/0/0.972 DROP 56 (IpsecInput)
826 Te0/0/0.972 Te0/0/0.972 DROP 56 (IpsecInput)
827 Te0/0/0.972 Te0/0/0.972 DROP 56 (IpsecInput)
828 Te0/0/0.972 Te0/0/0.972 DROP 56 (IpsecInput)
829 Te0/0/0.972 Te0/0/0.972 DROP 56 (IpsecInput)
830 Te0/0/0.972 Te0/0/0.972 DROP 56 (IpsecInput)
831 Te0/0/0.972 Te0/0/0.972 DROP 56 (IpsecInput)
832 Te0/0/0.972 Te0/0/0.972 DROP 56 (IpsecInput)
833 Te0/0/0.972 Te0/0/0.972 DROP 56 (IpsecInput)
834 Te0/0/0.972 Te0/0/0.972 DROP 56 (IpsecInput)
835 Te0/0/0.972 Te0/0/0.972 DROP 56 (IpsecInput)
836 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
Étape 5. Développez certains paquets abandonnés (IpsecInput) capturés.
(IpsecInput) Abandons de paquets :
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 utilise ESP encapsulé UDP :
Étape 6. Vérification de l'index MSNS
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
La fenêtre anti-relecture la plus élevée (bord droit de la fenêtre glissante anti-relecture) pour MSNS de 2 (0x04) est 0b65f00.
Étape 7. Développez certains paquets transférés (FWD) capturés.
Paquets transférés :
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
Paquet : 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
Étape 8. Collecter et obtenir les informations de numéro de séquence à partir de plusieurs paquets transférés (FWD) avant, après et les abandons.
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
Étape 9. Convertissez en décimal le numéro de série et réorganisez-les en calcul simple :
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
Remarque : si le numéro de séquence est supérieur au numéro de séquence le plus élevé dans la fenêtre, l'intégrité du paquet est vérifiée. Si le paquet réussit la vérification d'intégrité, la fenêtre glissante est déplacée vers la droite.
Étape 10. Convertissez en décimal le numéro de série et réorganisez-les en calcul simple :
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
Pour cet exemple, on peut visualiser la fenêtre glissante avec la taille de fenêtre 64 et le bord droit11984964 comme représenté sur l'image.
Le numéro de séquence reçu pour les paquets abandonnés se trouve bien en avant du bord droit de la fenêtre de relecture pour cet espace de séquence.
Comme la taille de fenêtre est toujours dans la valeur précédente 64 comme on le voit à l'étape 2, une des commandes de la section Commandes pour prendre effet de la fenêtre de relecture configurée doit être appliquée pour que la taille de fenêtre 1024 prenne effet.
Le logiciel Wireshark est un autre outil utile permettant de corréler l’interface SPI ESP et le numéro de séquence.
Remarque : il est important de collecter la capture de paquets lorsque le problème se produit et si cela est possible en même temps, la trace fia est collectée comme décrit précédemment
Configurez la capture de paquets pour la direction entrante et exportez-la vers le fichier pcap.
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
Lorsque la capture pcap est ouverte dans Wireshark, afin de pouvoir voir le SPI ESP et le numéro de séquence, développez un paquet, cliquez avec le bouton droit et sélectionnez les préférences de protocole, recherchez UDPENCAP et changez le port par défaut en port SD-WAN (port source) comme illustré dans l'image.
Une fois UDPENCAP en place avec le port droit, les informations ESP s'affichent comme illustré dans l'image.
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
08-Sep-2022 |
Première publication |