Comprendre le contrôle de liaison logique

Introduction

La norme 802.2 de l’IEEE définit le contrôle de liaison logique (LLC) comme une couche de contrôle de liaison de données utilisée sur les réseaux 802.3, 802.5 et autres. IBM a initialement conçu le LLC comme une sous-couche dans l’architecture Token Ring d’IBM.

Conditions préalables

Exigences

Cisco recommande que vous ayez des connaissances sur ces sujets :

• Une compréhension de base du LLC

Composants utilisés

Ce document n’est pas limité à des versions logicielles et matérielles spécifiques.

Les informations contenues dans ce document ont été créées à partir des dispositifs dans un environnement de laboratoire spécifique. Tous les appareils utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est en direct, assurez-vous de comprendre l’impact potentiel de toute commande.

Conventions

Référez-vous aux conventions des conseils techniques de Cisco pour plus d’informations sur les conventions des documents.

Informations de base

La couche LLC fournit un transfert de données sans connexion et orienté conection.

Le transfert de données sans connexion est communément appelé LLC type 1, ou LLC1. Le service sans connexion ne nécessite pas d’établir des liaisons de données ou des stations de liaison. Après qu’un point d’accès au service (SAP) a été activé, le SAP peut envoyer et recevoir des informations vers et depuis un SAP distant qui utilise également le service sans connexion. Le service sans connexion ne dispose pas de commandes de paramétrage de mode (telles que SABME) et ne nécessite pas que les informations d’état soient maintenues.

Le transfert de données orienté connexion est appelé LLC type 2, ou LLC2. Le service orienté connexion nécessite l’établissement de stations de liaison. Lorsque la station de liaison est établie, une commande de réglage de mode est nécessaire. Par la suite, chaque station de liaison est chargée de maintenir les informations d’état de liaison.

Mise en œuvre de LLC

LLC2 est mis en œuvre chaque fois que l’architecture de réseau de systèmes (SNA) fonctionne sur un réseau local ou un réseau local virtuel. LLC2 est également directement encapsulé dans Frame Relay. Parfois, le routeur transmet simplement les trames LLC2 et parfois le routeur implémente une station de liaison LLC2. NetBIOS utilise également LLC. NetBIOS utilise LLC1 pour localiser une ressource. Les sessions LLC2 orientées connexion sont alors établies.

Le routeur implémente une pile LLC2 lorsque l’une de ces fonctionnalités est activée :

• Commutation de liaison de données (DLSw) (connexion au réseau local)

• Remote Source-Route Bridging (RSRB) avec ACK local

• Processeur d’interface de canal (CIP)

• Réseau avancé de pair à pair (SNASwitching).Peer (SNASwitching (SNASw))

• Commande de liaison de données synchrone (SDLC) à la conversion LCC (SDLLC)

Informations de base que vous devez connaître pour dépanner

Une connaissance de base du LLC est suffisante pour isoler et résoudre la plupart des problèmes. Comme il n’y a pas d’états de liaison ou de sessions à maintenir, les problèmes sont rares en LLC1.

En LLC2, deux catégories de problèmes peuvent survenir :

1. Sessions qui ne s’établissent pas

2. Sessions établies qui échouent par intermittence

Pour résoudre ces problèmes, vous devez connaître ces sujets :

• Formats de trameLLC

• ModesLLC2 et établissement de session

• LLC2 Mode asynchrone équilibré. Fonctionnement

• LLC2 Conditions d’erreur

Formats de trame LLC

Cette section fournit des informations sur les formats de trame LLC.

dddd ddxxxxxx xx1xxxxx xxx1

Dest. Addr.IEEE DefinedGroup Address

CCCC CC11000F 1111010P 0011011F 0011011P 1111100F 0111101z 1111111z 0011

xx-xx0F-1F43-5363-736F-7F87-97AF-BFE3-F3

Unnumbered formatDisconnect ModeDisconnectUnnumbered Ack.SABMEFrame RejectXIDTest

ssss ssxxxxxx xx1xxxxx xxx1

Source AddressIEEE definedResponse LPDU

CCCC CC010000 00010000 01010000 1001

xx-xx01-xx05-xx09-xx

Supervisory FormatReceiver ReadyReceiver Not ReadyReject

ssss sss0

xxxx

Information format

Une trame LLC est appelée unité de données de protocole LLC (LPDU), et est formatée comme indiqué ici :

DSAP (1 byte)-SSAP (1 byte)-Control Field (1 or 2 bytes)-Information Field(0 or more bytes)

Champ DSAP

Le point d’accès au service de destination (DSAP) identifie le SAP auquel la LPDU est destinée. Le DSAP se compose de six bits d’adresse, d’un bit d’utilisateur (U) et d’un bit d’individu/groupe (I/G), organisés comme indiqué ici :

D-D-D-D-D-D-D-I/G

Le bit U indique si l’adresse est définie par l’IEEE (1) ou définie par l’utilisateur (0). Le bit I/G indique si le SAP est une adresse de groupe (1) ou une adresse individuelle (0). Pour nos besoins, aucun de ces bits n’est trop important. Tout ce que vous avez vraiment besoin de savoir, c’est que le DSAP est la destination du LPDU. Certains bits communs apparaissent à plusieurs reprises.

Champ SSAP

Le point d’accès au service source (SSAP) identifie le SAP à l’origine du LPDU. Le SSAP se compose de six bits d’adresse, d’un bit utilisateur (U) et d’un bit de commande/réponse (C/R), organisés comme indiqué ici :

S-S-S-S-S-S-U-C/R

Le bit U indique si l’adresse est définie par l’IEEE (1) ou définie par l’utilisateur (0). Le bit C/R indique si le LPDU est une commande ou une réponse. Lorsque des trames LPDU sont reçues, le bit C/R n’est pas considéré comme faisant partie du SSAP. Par conséquent, le SSAP est normalement considéré comme étant uniquement les sept bits les plus à gauche.

Champ de contrôle

Le champ de contrôle LPDU contient des informations sur la commande, la réponse et le numéro de séquence. Vous devez savoir comment décoder le champ de contrôle afin de déterminer ce qui se passe sur une session LLC2 particulière. Cependant, les informations de décodage sont facilement disponibles.

Il existe trois types de trames :

• I Frames

• Frames de supervision

• Frames non numérotées

Bien que chaque type ait un format différent pour le champ de contrôle, vous pouvez facilement les distinguer par un examen de deux bits dans le champ de contrôle.

X-X-X-X-X-X-X-0 = I FrameX-X-X-X-X-X-0-1 = Supervisory FrameX-X-X-X-X-X-1-1 = Unnumbered frame

Les quelques sections suivantes expliquent chaque type de champ de contrôle.

Trame I

Les trames I vous permettent de transférer des LPDU numérotés séquentiellement qui contiennent des informations (orientées connexion) entre les stations de liaison. Le format de la trame I contient un compte NS et NR. Le compte NS est le numéro de séquence (modulo 128) de la LPDU en cours de transmission. Le compte NR est le numéro de séquence de la prochaine trame I LPDU que l’expéditeur s’attend à recevoir. Pour vous aider plus tard, rappelez-vous que NR signifie « prochaine réception ».

NS-NS-NS-NS-NS-NS-NS-0-NR-NR-NR-NR-NR-NR-P/F

Le bit P/F est appelé le bit P dans les LPDU de commande et le bit F dans les LPDU de réponse. Le bit P/F est activé dans les LPDU de commande pour demander que la station de liaison distante envoie une réponse avec ce bit activé. Une seule réponse doit être reçue avec le bit F activé pour chaque commande envoyée avec le bit P activé. Il y a quelques autres détails sur l’utilisation du bit P/F en relation avec la récupération d’erreur, mais c’est la règle générale.

Frame de supervision

Les trames de supervision exécutent des fonctions de contrôle de supervision, par exemple, pour accuser réception des trames I (RR), pour demander la retransmission des trames I (REJ) et pour demander la suspension temporaire (RNR) des trames I. Les trames de supervision ne contiennent pas de champ d’information. Par conséquent, les trames de supervision n’affectent pas le NS de la station émettrice, et ne contiennent donc pas de champ NS. Voici le format d’une trame de supervision :

0-0-0-0-S-S-0-1-NR-NR-NR-NR-NR-NR-NR-P/F

Les bits « S » indiquent le type de trame de supervision.

• B’00’ = Récepteur prêt

  Une station utilise la RR pour indiquer que la station est prête à recevoir, et contient le compte NR de la prochaine trame I qui doit arriver. Lorsqu’une station envoie une trame RR, la station accuse réception des trames I numérotées de la station distante jusqu’à NR – 1.

• B’01’=Receiver Not Ready

  Une station utilise le RNR pour indiquer que la station n’est temporairement pas prête à recevoir. RNR contient également le compte NR qui suit les mêmes règles RR. Les périodes transitoires de RNR ne sont pas toujours indicatives d’un problème de réseau. Si les RNR sont persistants, recherchez une congestion dans la station d’extrémité.

• B’10’=Reject

  Une station utilise le REJ pour demander la retransmission des LPDU de trame I en commençant par le nombre indiqué dans le compte NR. Le REJ n’est pas indicatif d’un problème grave (ce qui signifie qu’il est récupérable). Si vous voyez de nombreuses commandes REJ, recherchez des trames I manquantes (abandonnées) dans la direction opposée. Ne confondez pas un REJ avec un rejet de trame (FRMR). Un FRMR est une trame non numérotée et est toujours indicatif d’un problème sérieux.

Trames non numérotées

Les trames non numérotées fournissent des fonctions de contrôle de liaison, par exemple, des commandes de réglage de mode et des réponses. Dans certains cas, des trames d’information non numérotées peuvent également être envoyées. Les trames non numérotées ont une longueur d’un seul octet. Elles ne contiennent pas de champs pour les comptages NR ou NRS. Voici le format d’une trame non numérotée :

M-M-M-P/F-M-M-1-1

Les bits « M » indiquent le type de trame non numérotée.

• B’00011’=Réponse DM (0x1F)

  Une station de liaison envoie une réponse DM pour signaler qu’elle est en mode de déconnexion asynchrone. Cela signifie que la liaison n’est pas active. Si une station de liaison était active et commence soudainement à envoyer des DM, la station de liaison a probablement été réinitialisée.

• B’01000’=Commande DISC (0x53)

  Une station de liaison envoie un DISC pour mettre fin au mode asynchrone équilibré. La commande DISC informe la station de liaison distante qu’elle suspend le fonctionnement. La réponse correcte à une commande DISC est un UA (si la station est en ABM), ou un DM (si la station est en ADM).

• B’01100’=Réponse UA(0x73)

  Un poste de liaison envoie une UA en réponse aux commandes SABME et DISC.

• B’01111’=Commande SABME(0x7F)

  Un poste de liaison envoie une SABME pour initier un transfert de données en mode asynchrone équilibré. La réponse correcte à un SABME est un UA. Lorsqu’une station reçoit une commande SABME, elle remet à zéro les comptes NR et NS. La station émettrice fait de même lorsqu’elle reçoit la réponse UA.

• B’10001’=Réponse FRMR(0x87)

  Une station de liaison envoie une réponse de rejet de trame pour signaler une erreur dans une LPDU entrante de l’autre station de liaison. Lorsque vous voyez un FRMR, la station qui envoie le FRMR a détecté une erreur irrécupérable. Elle n’est pas la cause de l’erreur. Toutes les trames qui arrivent après que l’erreur FRMR se soit produite sont ignorées jusqu’à ce qu’un DISC ou un SABME soit reçu.

  Une réponse FRMR contient des informations sur la cause de la condition FRMR.

  Les octets 0 et 1 contiennent le contenu du champ de contrôle du LPDU qui a provoqué le rejet de la trame. Les octets 2 et 3 contiennent les comptes NS et NR, respectivement. L’octet 4 contient plusieurs bits qui identifient le type d’erreur comme indiqué ici :

  0-0-0-V-Z-Y-W-X

  Le bit V indique que le numéro NS porté par le champ de contrôle dans les octets 0 et 1 est invalide. Un NS est invalide s’il est supérieur ou égal au dernier NS plus la taille maximale de la fenêtre de réception. Lorsque cette condition se produit, la station de liaison envoie une LPDU REJ, et non une réponse FRMR.

  Le bit Z indique que le NR que porte le champ de contrôle indiqué dans les octets 0 et 1 ne fait référence ni à la trame I suivante ni à une trame I qui a déjà été transmise mais dont on n’a pas accusé réception.

  Note : Il n’y a pas de problème à recevoir le même compte NR plusieurs fois.

  Le compte NR n’est invalide que si le compte fait référence à une trame I qui a déjà été acquittée ou si le compte saute à une trame qui n’a pas encore été transmise. Le premier cas est le plus courant pour ce type d’erreur. Lorsque vous voyez ce type d’erreur, cela signifie généralement que les trames ont été reçues hors séquence, et vous devez rechercher le réseau qui délivre les trames dans le désordre. Il est possible que la station de liaison émettrice les ait transmises dans le désordre, mais c’est très peu probable.

  Le bit Y indique que la longueur du champ I dans le LPDU reçu a dépassé la capacité du tampon disponible. Si cette situation se produit, recherchez des problèmes dans les stations d’extrémité, pas dans le réseau.

  Le bit X indique que le LPDU contenait un champ I alors qu’il n’aurait pas dû, ou qu’une réponse FRMR a été reçue qui ne contenait pas 5 octets. Cela semble être un problème de station d’extrémité, et non un problème de réseau.

  Le bit W indique qu’une LPDU non supportée a été reçue. Il s’agit d’un problème de station terminale.

• B’10111′ Commande ou réponse XID

  Une station de liaison utilise la commande XID pour transmettre les caractéristiques du nœud émetteur et pour amener la station de liaison distante à répondre par une réponse XID. Les stations de liaison peuvent envoyer et recevoir des XID dans différents formats, y compris les formats SNA.

• B’11100′ Commande ou réponse TEST

  Un poste de liaison envoie la commande TEST pour amener le poste de liaison distant à répondre par une réponse TEST dès que possible. La commande TEST est généralement utilisée pour la découverte de chemin dans un environnement de pontage source-route.

  

Résumé des champs de contrôle LLC

Modes LLC2 et établissement de session

Il existe deux modes de fonctionnement LLC2 :

• Mode asynchrone équilibré étendu

• Mode asynchrone déconnecté

Mode asynchrone équilibré étendu (ABME)

ABME est un mode de fonctionnement équilibré entre deux stations de liaison. Le mode équilibré fait référence au fait que chaque station peut envoyer des commandes à tout moment, indépendamment de l’autre station de liaison. Comparez cela au SDLC, qui fonctionne en mode déséquilibré. En mode non équilibré, la station secondaire doit attendre d’être interrogée par la station primaire avant de pouvoir envoyer des données. En raison du fonctionnement en mode équilibré, l’interrogation ne se produit pas sur les circuits LLC2 au sens traditionnel du terme. Une station envoie des « keepalives » pour maintenir la session, mais il n’est pas nécessaire de les envoyer fréquemment pour obtenir des performances optimales comme dans le mode SDLC. Pour cette raison, la temporisation keepalive est généralement de 10 secondes ou plus. Il est important de noter que les stations d’extrémité peuvent augmenter ce délai afin de réduire les frais généraux. Une augmentation du délai keepalive n’a aucun effet négatif sur le débit ou le temps de réponse.

Une station entre en ABME après que la station ait envoyé ou reçu une commande UA to to SABME. Lorsqu’elle est en ABME, la station peut envoyer et recevoir des trames d’information numérotées.

Mode de déconnexion asynchrone (ADM)

Avant et après qu’une station se termine en ABME, la station est en mode de déconnexion asynchrone. En ADM, la liaison est logiquement déconnectée ; par conséquent, aucune trame I ou trame de supervision ne peut être envoyée. Une station peut entrer en ADM dans les conditions suivantes :

• Réception d’une commande DISC

• La station de liaison est activée

• Réception d’une réponse DM

• La limite de réponse est est épuisée

Voici un exemple de séquence d’activation d’une station de liaison :

To1 4000.0840.0001 8800.5a94.7d94 SABME F0F07FTo1 4000.0840.0001 8800.5a94.7d94 UA F0F173To 1 4000.0840.00018800.5a94.7d94 RR nr=0 F0F001To1 4000.0840.0001 8800.5a94.7d94 INFO nr=0 ns=0 F0F00000 ...To1 4000.0840.0001 8800.5a94.7d94 RR nr=1 F0F101 To1 4000.0840.0001 8800.5a94.7d94 INFO nr=1 ns=1 F0F00202 ...To1 4000.0840.0001 8800.5a94.7d94 RR nr=2 F0F101To1 4000.0840.0001 8800.5a94.7d94 INFO nr=2 ns=2 F0F00000 ...

Fonctionnement en mode asynchrone équilibré LLC2

Les stations qui fonctionnent en ASBM n’ont pas un sens strict de stations primaires ou secondaires. Les stations n’ont pas besoin d’interroger ou d’être interrogées pour transférer des données. Les stations peuvent transmettre des données à n’importe quelle station de manière asynchrone. Les stations ont des relations d’égal à égal.

Même s’il n’y a pas de sens strict de primaire et secondaire, une station émettrice a besoin d’une réponse au niveau de la liaison appelée accusé de réception de la part de la station réceptrice pour chaque trame d’information numérotée envoyée. Une station peut continuer à transmettre des trames I à une autre station jusqu’à ce que le nombre de trames non acquittées atteigne une limite. Ce nombre est appelé « taille de la fenêtre » et est généralement fixé par défaut à 7. Vous pouvez augmenter la taille de la fenêtre sur les circuits où il y a beaucoup de latence afin d’éviter que la station émettrice ne doive s’arrêter et attendre une réponse. Cela n’est généralement pas nécessaire, notamment dans les situations où le LLC fait l’objet d’un accusé de réception local. Lorsqu’une station émettrice atteint la fenêtre d’envoi, elle active le bit poll pour obliger la station réceptrice à envoyer une réponse. Dans le routeur, la taille de la fenêtre est appelée llc2 local-window.

Une station de réception a la possibilité de retenir les accusés de réception jusqu’à ce qu’un certain nombre de trames I arrivent ou qu’un temporisateur expire. Ces paramètres sont appelés N3 et T2, respectivement. De cette façon, plusieurs trames peuvent être acquittées avec une trame RR, ou un accusé de réception peut être envoyé au-dessus d’une trame I. Cisco appelle le compteur N3 llc2 ack-max. La valeur par défaut de trois indique que le routeur retient un accusé de réception jusqu’à ce qu’il reçoive trois trames I, ou jusqu’à ce que le temporisateur T2, ou le llc2 ack-delay-time, expire.

La modification de ces paramètres sur une station sans tenir compte de la station partenaire peut affecter le temps de réponse et le débit. Par exemple, considérez ce qui se passerait si la station émettrice local-window est définie à 5 et que la station réceptrice a des valeurs de 7 pour ack-max et 500 millisecondes pour ack-delay-time.

Dans ce cas, la station d’envoi envoie cinq trames, puis attend un accusé de réception avant de continuer. Comme le récepteur retient les accusés de réception jusqu’à ce que sept trames soient reçues, il n’enverra pas d’accusé de réception avant l’expiration du délai de 500 millisecondes. Vous pouvez améliorer considérablement les performances si vous abaissez la valeur ack-max sur la station de réception.

Un autre paramètre LLC2 commun est appelé le timer Ti. Le routeur appelle cela le temps d’inactivité de llc2. L’objectif du timer Ti est de maintenir la session LLC2 active pendant les périodes où aucune trame I n’est transmise. Vous ne pouvez pas améliorer le débit et les performances si vous diminuez cette valeur. Lorsque le timer Ti expire, une trame RR est envoyée avec le bit poll activé pour provoquer une réponse du récepteur. Si la station ne répond pas, elle est relancée après llc2 tpf-time jusqu’à ce que le nombre de relances défini par llc2 n2 ait expiré. À ce moment-là, la session est déchirée.

Augmenter le temps d’inactivité pour réduire la quantité de surcharge sur un circuit LLC2 et vous pouvez ajuster ceci comme une alternative à l’ack local. Considérons un exemple où 200 DSPU sont connectées à un NCP. Chacun des DSPUs maintient une session LLC2 indépendante. Si chacun envoie un keepalive toutes les dix secondes, il y a 20 trames de surcharge par seconde. Si vous augmentez le temps d’inactivité à 30 secondes, le nombre de trames de surcharge diminue à 6,67 trames par seconde. L’inconvénient de cette approche est que les stations mettent plus de temps à découvrir que leur partenaire est inaccessible. Mais en fonction de votre situation, cela pourrait être une bonne chose.

Paramètres accordables LLC2

Vous pouvez utiliser la commande show llc pour voir les valeurs de ces paramètres :

ibu-7206#sh llcLLC2 Connections: total of 1 connectionsTokenRing3/0 DTE: 4001.68ff.0000 4000.0000.0001 04 04 state NORMALV(S)=5, V(R)=5, Last N(R)=5, Local window=8, Remote Window=127akmax=3, n2=8, Next timer in 8076xid-retry timer 0/60000 ack timer 0/1000p timer 0/1000 idle timer 8076/10000rej timer 0/3200 busy timer 0/9600akdelay timer 0/100 txQ count 0/2000

Exemples de configurations des paramètres LLC2

Dans un réseau DLSw+ typique avec un LAN Token Ring à chaque extrémité, la configuration des paramètres LLC2 se fait sur l’interface Token Ring sortante.

Il y a deux sessions LLC2 séparées. Par conséquent, configurez les paramètres LLC2 comme indiqué ici :

hostname dlsw1!source-bridge ring-group 100!dlsw local-peer ...dlsw remote-peer ...!interface token-ring 0source-bridge 10 1 100llc2 tpf-timer 2000llc2 n2 20hostname dlsw2! source-bridge ring-group 100! dlsw local-peer ...dlsw remote-peer ...! interface token-ring 0source-bridge 20 1 100llc2 tpf-timer 2000llc2 n2 20

Note : Ces configurations écrémées ne montrent que les configurations de paramètres LLC2 pertinentes.

Les configurations de paramètres LLC2 doivent correspondre aux paramètres LLC2 au FEP (au routeur DLSw1) et au PC (au routeur DLSw2). Lorsque le pair DLSw+ du site central est sur un routeur CIP, la configuration est légèrement différente.

La configuration du routeur DLSw+ distant reste inchangée. Cependant, la session LLC2 sur le site central est entre le CIP et la pile LLC2 dans IOS. Le CIP représente l’ordinateur central, et les paramètres LLC2 de l’ordinateur central vers IOS sont configurés sous les adaptateurs du LAN Token Ring (sur le CIP). Les paramètres LLC2 de IOS vers l’ordinateur central sont configurés sur l’interface sortante. C’est-à-dire, le canal d’interface x/2 (pour le CIP) et le canal d’interface x/0 (pour le xCPA).Par exemple:

hostname dlsw1! source-bridge ring-group 100! dlsw local-peer ...dlsw remote-peer ...!interface channel 0/2llc2 tpf-timer 2000llc2 n2 20lan tokenring 0source-bridge 10 1 100adapter 0 4000.7513.0000llc2 tpf-timer 2000llc2 n2 20

Note : Ces configurations écrémées ne montrent que les configurations pertinentes des paramètres LLC2.

Si le routeur CIP se connecte par le réseau local à une station locale, vous n’avez besoin que des paramètres LLC2 sous les adaptateurs CIP. Les paramètres LLC2 seront alors adaptés à ceux du PC. Tout paramètre LLC2 sous le canal d’interface 0/2 est inefficace.

hostname rtr1! source-bridge ring-group 100! interface channel 0/2lan tokenring 0source-bridge 10 1 100adapter 0 4000.7513.0000llc2 tpf-timer 2000llc2 n2 20

Note : Ces configurations écrémées ne montrent que les configurations pertinentes des paramètres LLC2.

Si des périphériques se connectent à DLSw+ par l’intermédiaire de groupes-ponts, les paramètres LLC2 sont configurés sur l’énoncé du groupe-pont DLSW+ comme indiqué ici :

hostname dlsw2!dlsw local-peer ...dlsw remote-peer dlsw bridge-group 1 llc2 tpf-timer 2500 n2 20! interface ethernet 0bridge-group 1bridge 1 protocol ieee

Note : Ces configurations écrémées ne montrent que les configurations pertinentes des paramètres LLC2.

Note : Bien que vous puissiez configurer LLC2 sous l’interface ethernet 0, ces paramètres n’ont aucun effet. DLSw bridge-group LLC2 était nouveau dans la version 11.3 du logiciel Cisco IOS.

Lorsque le routeur est configuré comme une station d’extrémité (par exemple, SNASw et DSPU), vous devez configurer les paramètres LLC2 sur l’interface sortante. Notez que toutes les interfaces virtuelles ne prennent pas en charge la configuration des paramètres LLC2. Par exemple :

Remarque : Ces configurations écrémées ne montrent que les configurations pertinentes des paramètres LLC2.

hostname snasw1!Interface fastethernet 0/0llc2 tpf-timer 2000llc2 n2 20!snasw cpname neta.snasw1snasw port FASTETH0 FastEthernet0/0 conntype nohpr

Conditions d’erreur LLC2

Certaines erreurs sur les sessions LLC2 sont normales et récupérables, par exemple, des trames manquées occasionnelles ou des trames hors d’ordre. Celles-ci se traduisent généralement par un REJ et des trames retransmises. Des retransmissions excessives ne sont pas normales, et vous devez identifier la cause et résoudre le problème. Les retransmissions excessives peuvent se produire en raison de chutes, de chemins multiples, de congestion et de latence excessive.

Certaines erreurs dans LLC2 sont irrécupérables et entraînent toujours une interruption de session. Ces erreurs sont exclusivement des violations de protocole. Elles peuvent se produire lorsque les stations envoient des champs de contrôle non définis ou d’autres informations erronées. Ces violations de protocole peuvent amener une station à envoyer une réponse FRMR. La station qui envoie la réponse FRMR n’est très probablement pas le violateur, mais simplement le messager. La réponse FRMR contient des informations qui identifient la raison pour laquelle la réponse FRMR est envoyée, le plus souvent lorsqu’une station demande à une autre station de renvoyer une trame I dont elle a déjà accusé réception. Comme la station ne peut pas retransmettre la trame (car elle l’a déjà rejetée), elle n’a pas d’autre choix que de mettre fin à la session LLC. Lorsque ce type d’erreur se produit, la cause la plus probable est que les trames ne sont pas dans l’ordre.