Ce document explique le processus de dépannage de la connectivité de circuit DLSw+ (Data-Link Switching Plus).
Aucune spécification déterminée n'est requise pour ce document.
Ce document n'est pas limité à des versions de matériel ou de logiciel spécifiques.
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. If your network is live, make sure that you understand the potential impact of any command.
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
Cette section explique l'état du circuit DLSw, les raisons possibles pour lesquelles un circuit DLSw est bloqué à un état particulier et quelques étapes de dépannage qui peuvent être prises pour établir la connectivité du circuit. Cette section explique également, au format graphique, les états d’établissement du circuit et la sortie de la commande show dlsw circuit. Enfin, cette section traite de certains des problèmes DLSw les plus courants, tels que :
Causes des messages d'erreur BADSSPHDR.
Pourquoi les circuits DLSw version 2 peuvent ne pas se connecter lorsqu'ils passent par un pare-feu ?
Problèmes survenant lorsque vous exécutez DLSw sur la carte MSFC (Multilayer Switch Feature Card) ou la carte MSFC2 (Multilayer Switch Feature Card 2).
Connexions LAN directes de liaisons 802.1q dans DLSw+.
Remarque : La cause la plus courante pour laquelle les circuits sont bloqués dans l'état CKT_ESTABLISHED est un noeud principal commuté VTAM (Virtual Telecommunications Access Method) hôte inactif.
Le démarrage du circuit est un état transitoire qui indique qu'il y a une réponse en attente à un message CANUREACH_CS (ID d'échange nul [XID]) résolu par un message ICANREACH_CS. Si vous rencontrez un problème avec un circuit bloqué à l'état CKT_START, cela indique un problème interne avec les routeurs homologues DLSw : une paire MAC ou SAP (Service Access Point) n'est pas nettoyée, ou les ressources disponibles sont insuffisantes pour terminer la transition d'état (par exemple, la mémoire).
Pour résoudre un problème CKT_START, vérifiez que le sondage de test et le XID nul ont tous deux atteint les partenaires homologues et vérifiez que les partenaires homologues ont répondu correctement. Vous devez comprendre la topologie du réseau à l’hôte ; il s'agit généralement du processeur frontal (FEP) ou d'un canal connecté via une carte CIP (Channel Interface Processor) d'un routeur 7xxx.
Pour les connexions FEP, vérifiez que l’interface du routeur ??s au FEP est active et fonctionne correctement. Demandez à l'opérateur réseau d'afficher (ou d'afficher par vous-même) les définitions de LIGNE et d'unité physique (PU) pertinentes sur le FEP et vérifiez qu'elles sont actives. Vérifiez que le noeud principal commuté, pour lequel le processeur agit comme espace réservé, est actif.
Si vous utilisez une carte CIP et que vous avez vérifié la connectivité à l'hôte, il peut y avoir un problème avec le noeud principal de l'adaptateur de communications externes VTAM (XCA). Voici les problèmes les plus courants :
Le noeud principal XCA n'est pas actif.
Le chemin vers l'extérieur de VTAM ? ? ? appelé Adresse de l'unité de canal ? ? n'est pas en ligne ou n'est pas placé dans le sous-système de canal.
Vérifiez que vous disposez de lignes logiques gratuites disponibles sous le noeud principal XCA, pour lequel VTAM CONNECT-IN peut allouer une unité physique. Dans les versions ultérieures du microcode CIP (CIP22.38, CIP24.15, CIP25.14, CIP26.10 et CIP27.4), la carte CIP ne répond pas aux sondages de test, s'il n'y a plus de lignes logiques disponibles.
Émettez la commande show extended channel x/2 max-llc2-sessions pour vérifier que le nombre maximal de sessions LLC (Logical Link Control) n'a pas été atteint. Il est défini par défaut à 256.
Il peut également y avoir un problème avec les valeurs SAP utilisées. La carte CIP écoute les SAP uniques. Toutes les cartes CIP internes doivent être définies sur VTAM dans les définitions de noeud principal XCA. La valeur ADAPNO (Adapter Number) du noeud principal XCA est utilisée par VTAM comme référence à une carte interne du routeur. Chaque carte interne configurée sur un CIP doit avoir une ADAPNO unique pour chaque type de support. La définition du noeud principal XCA vous permet de configurer les SAP à ouvrir pour chaque adaptateur interne.
Le sondage de test et la valeur Null XID vérifient que le noeud principal XCA et la carte CIP écoutent le SAP correct. Si l'adaptateur MAC CIP est ouvert et qu'au moins un SAP est ouvert, il répond aux tests sans les transmettre à VTAM. Les trames de test sont envoyées avec DSAP 04 et SSAP 00. Vérifiez les valeurs SAP utilisées entre la station d’extrémité, le routeur CIP et le noeud principal XCA à l’aide des commandes suivantes :
NCCF TME 10 NetView CNM01 OPER6 03/31/00 13:56:01 C CNM01 DISPLAY NET,ID=DKAPPN,SCOPE=ALL CNM01 IST097I DISPLAY ACCEPTED ' CNM01 IST075I NAME= DKAPPN , TYPE= XCA MAJOR NODE IST486I STATUS= ACTIV , DESIRED STATE= ACTIV IST1021I MEDIUM=RING , ADAPTNO=1 , CUA=0401 , SNA SAP=4 IST654I I/O TRACE= OFF, BUFFER TRACE= OFF IST1656I VTAMTOPO= REPORT, NODE REPORTED= YES IST170I LINES: IST232I L0401000 ACTIV IST232I L0401001 ACTIV IST232I L0401002 ACTIV IST232I L0401003 ACTIV IST232I L0401004 ACTIV IST232I L0401005 ACTIV IST232I L0401006 ACTIV IST232I L0401007 ACTIV IST232I L0401008 ACTIV IST232I L0401009 ACTIV IST232I L040100A ACTIV IST232I L040100B ACTIV IST232I L040100C ACTIV IST232I L040100D ACTIV IST232I L040100E ACTIV IST232I L040100F ACTIV IST314I END # show dlsw circuit details Index local addr (lsap) remote addr (dsap) state uptime 194 0800.5a9b.b3b2 (04) 0800.5ac1.302d (04) CONNECTED 00:00:13 PCEP: 995AA4 UCEP: A52274 Port: To0/0 peer 172.18.15.166 (2065) Flow-Control-Tx SQ CW: 20, permitted: 28; Rx CW: 22, Granted: 25 Op: IWO Congestion: LOW(02) , Flow OP: Half: 12/5 Reset 1/0 RIF = 0680.0011.0640
Utilisez ces exemples de résultats et ces notes pour vérifier les définitions de noeud principal XCA :
NCCF TME 10 NetView CNM01 OPER6 03/31/00 13:56:01 C CNM01 DISPLAY NET,ID=DKAPPN,SCOPE=ALL !--- NetView takes the DIS DKAPPN short form and converts !--- it into the full D NET,ID=DKAPPN,SCOPE=ALL command. CNM01 IST097I DISPLAY ACCEPTED ' CNM01 IST075I NAME= DKAPPN , TYPE= XCA MAJOR NODE !--- Check that the XCA Major Node name is correct and that !--- it is, in fact, an XCA MAJOR NODE. IST486I STATUS= ACTIV , DESIRED STATE= ACTIV !--- Verify that the XCA Major Node is in an ACTIV status. !--- Any other status is an error condition (see the comment after !--- the Local Line for information about how to correct this error). IST1021I MEDIUM=RING , ADAPTNO=1 , CUA=0401 , SNA SAP=4 !--- Verify that the Adapter Number is correct and matches the !--- number used in the CIP definitions on the router. !--- Also, verify that the Channel Unit Address (CUA) is correct. !--- Issue the next command (below) to verify that it is either !--- in status online (O) or, if in use, in status allocated (A). !--- Finally, verify that the SAP number that is configured on !--- the XCA Major Node matches the SAP number that is configured !--- in the ADAPTER statement in the CIP router definition. IST654I I/O TRACE= OFF, BUFFER TRACE= OFF IST1656I VTAMTOPO= REPORT, NODE REPORTED= YES IST170I LINES: IST232I L0401000 ACTIV !--- Verify that the Logical Line is in an ACTIV status. !--- Any other status is an error condition. !--- Contact either the System Programmer or Network Operator to !--- CYCLE, INACT then ACT, or take other action to get both the !--- Local Line and the XCA Major Node into ACTIV status. IST232I L0401001 ACTIV IST232I L0401002 ACTIV IST232I L0401003 ACTIV IST232I L0401004 ACTIV IST232I L0401005 ACTIV IST232I L0401006 ACTIV IST232I L0401007 ACTIV IST232I L0401008 ACTIV IST232I L0401009 ACTIV IST232I L040100A ACTIV IST232I L040100B ACTIV IST232I L040100C ACTIV IST232I L040100D ACTIV IST232I L040100E ACTIV IST232I L040100F ACTIV !--- Verify that you have free Logical Lines left for the VTAM !--- CONNECTIN to allocate a PU. IST314I END
À partir de l'invite NetView, exécutez la commande mvs d u,,, xxx,2, où xxx est l'adresse de l'unité de canal. Cela confirme que le CUA est soit en ligne (O), soit attribué (A) :
NCCF TME 10 NetView CNM01 OPER6 03/31/00 16:08:27 * CNM01 MVS D U,,,401,2 " CNM01 IEE457I 16.07.29 UNIT STATUS 076 UNIT TYPE STATUS VOLSER VOLSTATE 0401 CTC A 0402 CTC A-BSY
Il s'agit d'un exemple de configuration CIP qui montre l'interface virtuelle, le VLAN CIP, les instructions de pont source et le numéro de la carte interne qui correspond à ADAPNO sur le noeud principal XCA ; CIP suppose que LSAP=04 provient du noeud principal XCA :
!--- Sample CIP configuration. interface Channel4/2 lan TokenRing 0 source-bridge 88 1 100 adapter 1 4000.7507.ffff !--- Sample XCA Major Node configuration. VBUILD TYPE=XCA * APPNPRT PORT ADAPNO=1, CUADDR=401, DEFAULT TABLE ENTRY MEDIUM=RING, MODE TABLE FOR MODEL 3 SAPADDR=4, 3270 DISPLAY TERMINAL !--- This is the SAP number to which the XCA Major Node listens. !--- If this value does not match with your end stations, then !--- their XIDs will not receive responses. TIMER=20 * APPNGRP GROUP DIAL=YES, CU ADDRESS PORT A01 ANSWER=ON, DEFAULT TABLE ENTRY DYNPU=YES, MODE TABLE FOR MODEL 4 AUTOGEN=(16,L,P), INITIAL ACTIVE !--- This automatically generates 16 Logical Lines, starting !--- with the letter L, and generates 16 PUs, starting with !--- the letter P. !--- This can be seen in the previous DISPLAY NET output. CALL=INOUT 3270 DISPLAY TERMINAL
Un état CKT_ESTABLISHED indique que les routeurs ont configuré le circuit avec succès, mais que les stations d’extrémité n’ont pas encore initié leur session sur ce circuit. Examinez la session LLC2 (Logical Link Control) de type 2 qui a été établie pour vérifier que c'est le cas.
router# show llc2 LLC2 Connections: total of 3 connections Vitual-TokenRing0 DTE: 4000.7507.fff 4000.7507.0099 04 04 state NORMAL !--- Vitual-TokenRing0 is the name of the interface on which the session !--- is established. !--- 4000.7507.fff and 4000.7507.0099 are the source and destination MAC !--- addresses. This is the address of the interface on which the connection !--- is established. !--- NORMAL indicates that the current state of the LLC2 session is fully !--- established and that normal communication is occurring. V(S)=15, V(R)=15, Last N(R)=15, Local window=7, Remote Window=127 akmax=3, n2=10, xid-retry timer 0/0 ack timer 0/1000 p timer 0/1000 idle timer 1220/10000 rej timer 0/3200 busy timer 0/9600 akdelay timer 0/100 txQ count 0/200 RIF: 0830.0141.0641.0580
Les circuits dans cet état peuvent indiquer un certain nombre de problèmes, tels que des problèmes avec les échanges XID ou des périphériques qui ne sont pas modifiés dans VTAM. Dans les homologues FST (Fast Sequenced Transport) (ou les homologues d'encapsulation directe qui n'utilisent pas d'accusé de réception local), la session n'est pas terminée localement. Le champ RIF (Routing Information Field)??pour Token Ring???est terminé, mais la session est complètement directe. En tant que tel, vous ne voyez pas de circuits établis pour des sessions sur DLSw+ FST ou des homologues directs (autres que Frame Relay local-ack). Un autre problème courant avec l'échange XID est d'avoir les mauvaises valeurs IDBLK/IDNUM ou CPNAME.
NCCF TME 10 NetView CNM01 OPER6 03/31/00 13:59:43 C CNM01 DISPLAY NET,ID=DKTN3270,SCOPE=ALL !--- NetView takes the DIS DKTN3270 short form and converts !--- it into the full D NET,ID=DKTN3270,SCOPE=ALL command. CNM01 IST097I DISPLAY ACCEPTED ' CNM01 IST075I NAME = DKTN3270 , TYPE = SW SNA MAJOR NODE IST486I STATUS = ACTIV , DESIRED STATE = ACTIV IST1656I VTAMTOPO = REPORT , NODE REPORTED - YES IST084I NETWORK RESOURCES: IST089I DK3270DY TYPE = PU_T2.1 , ACTIV !--- Verify that the PU is in ACTIV state. !--- If the PU is in INACT or INOP status, then ask the System Programmer or !--- Network Operator to activate it. !--- If the PU is in CONNECT status, then you could have a definition error. !--- Ask the System Programmer to verify the Switched Major Node definition. !--- If the PU is in ACTIV status and you still can not establish a session, !--- then verify that another end station is not using the the same PU. IST089I DKDYLU0A TYPE = LOGICAL UNIT , ACTIV---X- IST089I DKDYLU0B TYPE = LOGICAL UNIT , ACT/S---X- IST089I DKDYLU1A TYPE = LOGICAL UNIT , ACTIV---X- IST089I DKDYLU19 TYPE = LOGICAL UNIT , ACT/S---X- IST089I DKDYLU18 TYPE = LOGICAL UNIT , ACT/S---X- IST089I DKDYLU17 TYPE = LOGICAL UNIT , ACT/S---X- IST089I DKDYLU16 TYPE = LOGICAL UNIT , ACT/S---X- IST089I DKDYLU15 TYPE = LOGICAL UNIT , ACT/S---X- IST089I DKDYLU09 TYPE = LOGICAL UNIT , ACTIV---X- IST089I DKDYLU08 TYPE = LOGICAL UNIT , ACTIV---X- IST089I DKDYLU07 TYPE = LOGICAL UNIT , ACTIV---X- IST089I DKDYLU06 TYPE = LOGICAL UNIT , ACTIV---X- IST089I DKDYLU05 TYPE = LOGICAL UNIT , ACTIV---X- IST089I DKDYLU04 TYPE = LOGICAL UNIT , ACTIV---X- IST089I DKDYLU03 TYPE = LOGICAL UNIT , ACTIV---X- IST089I DKDYLU02 TYPE = LOGICAL UNIT , ACTIV---X- IST089I DKDYLU01 TYPE = LOGICAL UNIT , ACTIV---X- IST089I DK3270ST TYPE = PU_T2 , CONCT IST089I DKSTLU01 TYPE = LOGICAL UNIT , CONCT IST089I DKSTLU02 TYPE = LOGICAL UNIT , CONCT IST089I DKSTLU03 TYPE = LOGICAL UNIT , CONCT IST089I DKSTLU04 TYPE = LOGICAL UNIT , CONCT IST089I DKSTLU05 TYPE = LOGICAL UNIT , CONCT IST089I DKSTLU06 TYPE = LOGICAL UNIT , CONCT IST089I DKSTLU07 TYPE = LOGICAL UNIT , CONCT IST089I DKSTLU08 TYPE = LOGICAL UNIT , CONCT IST089I DKSTLU09 TYPE = LOGICAL UNIT , CONCT IST089I DKDLUR32 TYPE = PU_T2.1 , ACTIV--L-- IST089I DKDLDYPU TYPE = PU_T2.1 , ACTIV IST089I DKDLSTPU TYPE = PU_T2.1 , ACTIV IST089I DKDLST01 TYPE = LOGICAL UNIT , ACTIV IST089I DKDLST02 TYPE = LOGICAL UNIT , ACTIV ??? ***
VBUILD TYPE=SWNET * * TN3270 DYNAMIC LU BUILD * DK3270DY PU ADDR=01, IDBLK=05D, IDNUM=03270, !--- Verify that the end station is using the correct IDBLK and IDNUM values. PUTYPE=2, LUGROUP=BXLLUGRP,LUSEED=DKDYLU## * LUGROUP=BXLLUGRP,LUSEED=DKDYLU## * * * TN3270 CP DEF FOR DLUR EN ON CIP * DKDLUR32 PU ADDR=01, CPNAME=DK3270CP, !--- Verify that the end station is using the correct CPNAME value. ISTATUS=ACTIVE, PUTYPE=2, CPCP=YES, NETID=NETA
L'état CONNECTED est normal lorsqu'un circuit DLSw est correctement connecté.
show dlsw circuit ???Lorsque vous dépannez des problèmes d’état des circuits DLSw, émettez la commande show dlsw circuits en mode d’exécution privilégié :
show dlsw circuits [detail] [mac-address address | sap-value value | circuit id]
detail??(Facultatif) Affiche les informations d'état du circuit au format développé.
mac-address address ? ? (Facultatif) Spécifie l'adresse MAC à utiliser dans la recherche de circuit.
sap-value value ? ? (Facultatif) Spécifie le SAP à utiliser dans la recherche de circuit.
ID de circuit ???(Facultatif) Spécifie l'ID de circuit de l'index de circuit.
Reportez-vous aux commandes de configuration DLSw+ et au diagramme suivant pour comprendre le résultat de cette commande.
Ce message d'erreur peut apparaître sur certains routeurs DLSw :
%DLSWC-3-BADSSPHDR: bad ssp hdr in proc ssp - received remote correlator from different peer = 0x200004B -Traceback= 606FCD68 606FD008 606ED364 606F2B2C 6026B118 601F6438 601CAA10 6020F6B0 6020E350 6020E484 601B3048 601B3034 Nov 23 06:10:33: %DLSWC-3-RECVSSP: SSP OP = 4( ICR ) received from peer x.x.x.x(2065) Nov 23 06:10:33: %DLSWC-3-RECVSSP: SSP OP = 4( ICR ) expected from peer y.y.y.y(2065) !--- Where x.x.x.x and y.y.y.y are two different remote DLSw peers.
Ces messages sont informatifs, et cette section explique pourquoi ils peuvent se produire.
Lors de la résolution d'adresse (CANUREACH_EX), un routeur peut récupérer plusieurs réponses (ICANREACH_EX). Le routeur qui a initié la résolution d’adresse met en cache toutes les réponses au moment de la mise en route du circuit. Le routeur d'origine envoie un message CANUREACH dirigé à l'un des routeurs distants qui a répondu lors de la résolution d'adresse. Le routeur d'origine exécute un minuteur pour attendre un ICANREACH. Si le protocole ICANREACH n'est pas reçu avant le délai d'attente, le routeur d'origine envoie un autre CANUREACH dirigé à l'un des autres routeurs distants qui ont répondu lors de la résolution d'adresse. Si ? ? ? pour une raison quelconque, comme la congestion, les liaisons lentes, etc ? ? ? ? ICANREACH du premier routeur distant arrive après l'ICANREACH du deuxième routeur distant, vous recevez les messages d'erreur mentionnés ci-dessus. Le routeur reçoit une adresse ICANREACH de l'adresse IP x.x.x.x, mais il attendait l'ICANREACH de l'adresse IP y.y.y.y. S'il n'y a aucun problème de connectivité, ces messages sont affichés à titre d'information uniquement ; DLSw est considéré comme fonctionnant comme conçu. Référez-vous à l'ID de bogue Cisco CSCdp50163 (clients enregistrés uniquement) pour plus d'informations.
Toutefois, si le réseau DLSw rencontre des problèmes de connectivité, les messages doivent être pris au sérieux et une enquête plus approfondie est nécessaire. Recherchez des retards WAN importants, des délais d'attente DLSw périodiques sur le réseau, ou les deux. En outre, déterminez si la traduction d'adresses de réseau (NAT) est utilisée entre les homologues, car cela peut provoquer un problème de connectivité. Il peut être utile de désactiver les explorateurs UDP (User Datagram Protocol) pour voir si ces messages d'erreur cessent : émettez la commande dlsw udp-disable, introduite pour la première fois dans Cisco IOS ? ? Version logicielle 11.2 F. Si ce n'est pas le cas, une trace WAN des flux TCP (Transmission Control Protocol) entre les homologues serait plus utile.
Remarque : Les messages d'erreur mentionnés ci-dessus ont également été signalés de manière incorrecte dans les versions du logiciel Cisco IOS antérieures à la version 11.2. Par conséquent, il est important d'exécuter une version ultérieure à 11.2.
Avec l'introduction de la fonctionnalité de monodiffusion UDP Cisco DLSw dans le logiciel Cisco IOS Version 11.2(6)F, les trames d'exploration et les trames d'informations non numérotées sont envoyées via la monodiffusion UDP plutôt que TCP. Avant DLSw version 2, cette fonctionnalité de monodiffusion exigeait qu'une connexion TCP existe avant l'envoi de paquets via UDP. DLSw version 2, cependant, envoie la multidiffusion UDP/IP et la monodiffusion avant l'existence de la connexion TCP. Les paquets de résolution d'adresse ? ? ? tels que CANUREACH_EX, NETBIOS_NQ_ex, etc ? ? ? ? utilisent le service de multidiffusion, mais les réponses ? ? ? ICANREACH_ex et NAME_RECOGNIZED_ex ? ? sont renvoyés par monodiffusion UDP.
Dans un scénario type, un pare-feu a été configuré entre les homologues DLSw. Par conséquent, les circuits DLSw doivent être établis via le pare-feu. RFC 2166 (améliorations DLSw v2.0) indique que le port source UDP peut être n'importe quelle valeur. Les routeurs Cisco DLSw utilisent le port source 0. Cela pose un problème lorsque les circuits DLSw passent par des pare-feu, qui sont généralement configurés pour filtrer le port 0. Cela entraîne des échecs de connexion des circuits DLSw. La solution de contournement consiste à activer la commande de configuration globale dlsw udp-disable. Si la commande dlsw udp-disable est configurée, alors DLSw n'envoie pas de paquets par monodiffusion UDP et n'annonce pas la prise en charge de monodiffusion UDP dans son message d'échange de fonctionnalités.
Pour plus d'informations, référez-vous à Service de multidiffusion UDP/IP et Présentation de l'introduction de la fonction de monodiffusion UDP DLSw+.
Il peut y avoir de nombreux problèmes lorsque vous exécutez DLSw sur une carte MSFC (Multilayer Switch Feature Card) ou une carte MSFC2 (Multilayer Switch Feature Card 2). Pour obtenir des informations complètes sur DLSw et MSFC, reportez-vous à la Foire aux questions DLSw+ et MSFC.
La LLC2 à partir de liaisons encapsulées 802.1q dans DLSw est d'abord prise en charge avec des homologues TCP DLSw et un pontage transparent au moyen de l'ID de bogue Cisco CSCdv26715 (clients enregistrés uniquement). Depuis la version 12.2(6) et ultérieure du logiciel Cisco IOS, 802.1q et DLSw fonctionnent.
En outre, grâce à la prise en charge de DDTS pour DLSw, la redondance Ethernet et l'encapsulation dot1Q avec le VLAN natif sont disponibles. Reportez-vous aux champs Release-notes et First Fixed-in Version de ces rapports DDTS :
ID de bogue Cisco CSCdv26715 (clients enregistrés uniquement) ? ??Apporte la prise en charge de 802.1q dans DLSw avec encapsulation TCP uniquement.
ID de bogue Cisco CSCdy09469 (clients enregistrés uniquement) ? ??Corrige le défaut où DLSw ne fonctionne pas lorsque l'interface LAN est une interface FastEthernet configurée pour l'encapsulation 802.1q et le VLAN natif :
interface FastEthernet0/0.500 encapsulation dot1Q 500 native bridge-group 1
ID de bogue Cisco CSCdw65810 (clients enregistrés uniquement) ? ??Corrige l'utilisation de la redondance Ethernet DLSw et des agrégations encapsulées 802.1q. Il n'y a toujours pas de prise en charge de DLSw FST avec 802.1q.
Si vous sélectionnez le logiciel Cisco IOS Version 12.2(13.4) et ultérieure, DLSw avec encapsulation TCP, alors la redondance Ethernet DLSw prend en charge LLC2 à partir de liaisons encapsulées 802.1q avec ou sans le mot clé natif.