Présentation du contrôle de la liaison logique

Introduction

La norme IEEE 802.2 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 d'autres réseaux. IBM a initialement conçu LLC comme une sous-couche dans l'architecture Token Ring d'IBM.

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Une compréhension de base de LLC

Components Used

Ce document n'est pas limité à des versions de matériel et 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.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Informations générales

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

Le transfert de données sans connexion est généralement appelé LLC de type 1 ou LLC1. Le service sans connexion ne nécessite pas l'établissement de liaisons de données ou de stations de liaison. Une fois qu'un point d'accès au service (SAP) a été activé, le SAP peut envoyer et recevoir des informations depuis et vers un SAP distant qui utilise également un service non orienté connexion. Le service sans connexion ne possède aucune commande de configuration de mode (telle que SABME) et ne nécessite pas la maintenance des informations d'état.

Le transfert de données orienté connexion est appelé LLC de 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 configuration de mode est nécessaire. Par la suite, chaque station de liaison est responsable de la maintenance des informations d’état de liaison.

Implémentations de LLC

LLC2 est mis en oeuvre chaque fois que SNA (Systems Network Architecture) s'exécute sur un LAN ou un LAN virtuel. LLC2 est également encapsulé directement dans Frame Relay. Parfois, le routeur transmet simplement des trames LLC2 et parfois il implémente une station de liaison LLC2. NetBIOS utilise également LLC. NetBIOS utilise LLC1 pour localiser une ressource. Des sessions orientées connexion LLC2 sont alors établies.

Le routeur implémente une pile LLC2 lorsque l'une de ces fonctions est activée :

• Commutation de liaison de données (DLSw) (connexion au LAN)

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

• Processeur d'interface de canal (CIP)

• Mise en réseau peer-to-peer avancée (SNASwitching (SNASw))

• Conversion SDLLC (Synchronous Data Link Control) en LCC

Informations de base que vous devez connaître pour résoudre les problèmes

Une connaissance de base de LLC suffit pour isoler et résoudre la plupart des problèmes. Comme il n’y a pas d’état de liaison ou de session à gérer, les problèmes sont rares dans LLC1.

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

1. Sessions qui ne sont pas établies

2. Sessions établies qui échouent de façon intermittente

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

• Formats de trame LLC

• Modes LLC2 et établissement de session

• Fonctionnement du mode équilibré asynchrone LLC2

• Conditions d'erreur LLC2

Formats de trame LLC

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

dddd ddxx
xxxx xx1x
xxxx xxx1

Dest. Addr.
IEEE Defined
Group Address

CCCC CC11
000F 1111
010P 0011
011F 0011
011P 1111
100F 0111
101z 1111
111z 0011

xx-xx
0F-1F
43-53
63-73
6F-7F
87-97
AF-BF
E3-F3

Unnumbered format
Disconnect Mode
Disconnect
Unnumbered Ack.
SABME
Frame Reject
XID
Test

ssss ssxx
xxxx xx1x
xxxx xxx1

Source Address
IEEE defined
Response LPDU

CCCC CC01
0000 0001
0000 0101
0000 1001

xx-xx
01-xx
05-xx
09-xx

Supervisory Format
Receiver Ready
Receiver Not Ready
Reject

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 DSAP (Destination Service Access Point) identifie le SAP auquel la LPDU est destinée. Le DSAP se compose de six bits d’adresse, un bit utilisateur (U) et un bit individuel/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 protocole SAP est une adresse de groupe (1) ou une adresse individuelle (0). Pour nous, aucun de ces bits n'est trop important. Tout ce que vous devez savoir est que le DSAP est la destination de la LPDU. Certaines d'entre elles apparaissent encore et encore.

Champ SSAP

Le point d'accès au service source (SSAP) identifie le SAP à l'origine de la LPDU. Le SSAP se compose de six bits d’adresse, un bit utilisateur (U) et un bit C/R (Command/Response), 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 la 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 généralement considéré comme étant seulement les sept bits les plus à gauche.

Champ de contrôle

Le champ de contrôle LPDU contient les informations de commande, de réponse et de 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 :

• Trames I

• Trames de supervision

• Trames 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 Frame

X-X-X-X-X-X-0-1 = Supervisory Frame

X-X-X-X-X-X-1-1 = Unnumbered frame

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

Trame I

Les trames I vous permettent de transférer des LPDU numérotées séquentiellement qui contiennent des informations (orientées connexion) entre les stations de liaison. Le format de la trame I contient un nombre NS et NR. Le nombre NS correspond au numéro de séquence (modulo 128) de la LPDU actuellement en transmission. Le nombre NR est le numéro de séquence de la prochaine trame LPDU I 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 la commande LPDU et le bit F dans la réponse LPDU. Le bit P/F est défini dans la commande LPDU pour demander à la station de liaison distante d’envoyer une réponse avec ce jeu de bits. Une seule réponse doit être reçue avec le bit F défini pour chaque commande envoyée avec le bit P défini. Il y a d'autres détails sur l'utilisation du bit P/F en relation avec la récupération d'erreurs, mais c'est la règle générale.

Trame de supervision

Les trames de supervision remplissent 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'informations. Par conséquent, les trames de supervision n'affectent pas le NS de la station émettrice et ne contiennent pas de champ NS. Voici le format d'un cadre 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 le RR pour indiquer que la station est prête à recevoir et contient le nombre NR de la trame I suivante qui doit arriver. Lorsqu’une station envoie une trame RR, la station accuse réception des trames numérotées I de la station distante jusqu’à NR - 1.

• B'01'=Récepteur non prêt

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

• B'10'=Rejeter

  Une station utilise le REJ pour demander la retransmission des LPDU de trame I en commençant par le numéro indiqué dans le nombre NR. REJ n'indique pas un problème grave (ce qui signifie qu'il est récupérable). Si vous voyez de nombreuses commandes REJ, recherchez les 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 indique toujours un problème grave.

Trames non numérotées

Les trames non numérotées fournissent des fonctions de contrôle de liaison, par exemple, des commandes de configuration de mode et des réponses. Dans certains cas, des trames d'informations non numérotées peuvent également être envoyées. Les trames non numérotées ne comportent qu'un octet. Ils ne contiennent pas de champs pour les comptes 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 DISK (0x53)

  Une station de liaison envoie un DISK pour terminer le mode asynchrone équilibré. La commande DISK informe la station de liaison distante qu'elle suspend le fonctionnement. La réponse correcte à une commande DISK est un UA (si la station est dans ABM) ou un DM (si la station est dans ADM).

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

  Une station de liaison envoie un UA en réponse aux commandes SABME et DISK.

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

  Une station de liaison envoie un SABME pour lancer le 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, la station réinitialise le nombre NR et NS à zéro. 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 Frame Reject 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. Ce n'est pas la cause de l'erreur. Toutes les trames qui arrivent après l'erreur FRMR sont ignorées jusqu'à la réception d'un DISQUE ou d'un SABME.

  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 de la LPDU qui a provoqué le rejet de la trame. Les octets 2 et 3 contiennent respectivement les nombres NS et NR. 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 transporté par le champ de contrôle en octets 0 et 1 n'est pas valide. Un NS n'est pas valide 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 le champ de contrôle porte indiqué en octets 0 et 1 ne fait pas référence à la trame I suivante ou à une trame I qui a déjà été transmise mais qui n'a pas été reconnue.

  Note : Il est possible de recevoir le même nombre NR plusieurs fois.

  Le nombre NR n'est valide que si le nombre fait référence à une trame I déjà reconnue ou si le nombre passe à une trame qui n'a pas encore été transmise. Le premier est le cas le plus courant de 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 que vous devez rechercher le réseau qui fournit les trames dans le désordre. Il est possible que la station de liaison émettrice les ait transmis dans le désordre, mais très peu probable.

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

  Le bit X indique que la LPDU contenait un champ I lorsqu'elle ne doit pas avoir, ou qu'une réponse FRMR a été reçue qui ne contenait pas 5 octets. Il s'agit d'un problème de station d'extrémité et non de problème réseau.

  Le bit W indique qu’une LPDU non prise en charge a été reçue. Il s'agit d'un problème de station d'extrémité.

• B'10111' XID, commande ou réponse

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

• B'11100' TEST, commande ou réponse

  Une station de liaison envoie la commande TEST pour que la station de liaison distante réponde avec une réponse TEST dès que possible. La commande TEST est généralement utilisée pour la découverte de chemins dans un environnement de pontage source-route.

  

Récapitulatif des champs de contrôle LLC

Modes LLC2 et établissement de session

Il existe deux modes de fonctionnement LLC2 :

• Mode équilibré asynchrone étendu

• Mode de déconnexion asynchrone

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 ceci avec SDLC, qui fonctionne en mode déséquilibré. En mode désé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 des performances optimales comme dans SDLC. Pour cette raison, le compteur de test d'activité est généralement supérieur ou égal à 10 secondes. Il est important de noter que les stations d'extrémité peuvent augmenter ce compteur de test d'activité pour réduire la surcharge. Une augmentation du compteur keepalive n'a aucun effet négatif sur le débit ou le temps de réponse.

Une station entre dans ABME après que la station envoie ou reçoit une UA à la commande SABME. Lorsqu’elle est dans ABME, la station peut envoyer et recevoir des trames d’informations numérotées.

Mode de déconnexion asynchrone (ADM)

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

• Réception d'une commande DISK

• La station de liaison est activée

• Réception d'une réponse DM

• La limite de tentative est épuisée

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

To1 4000.0840.0001 8800.5a94.7d94 SABME F0F07F

To1 4000.0840.0001 8800.5a94.7d94 UA F0F173

To 1 4000.0840.00018800.5a94.7d94 RR nr=0 F0F001

To1 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 F0F101

To1 4000.0840.0001 8800.5a94.7d94 INFO nr=2 ns=2 F0F00000 ...

Fonctionnement du mode équilibré asynchrone LLC2

Les stations qui fonctionnent dans l'ASBM n'ont pas un sens strict des 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 peer-to-peer.

Même s’il n’existe pas de sens strict du primaire et du secondaire, une station émettrice nécessite une réponse de niveau liaison appelée accusé de réception 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 reconnues atteigne une limite. Ce numéro est appelé « taille de fenêtre » et est généralement défini sur 7 par défaut. Vous pouvez augmenter la taille de fenêtre sur les circuits où il y a beaucoup de latence pour éviter que la station émettrice ne s'arrête et attende une réponse. Cela n'est généralement pas nécessaire, en particulier dans les situations où la LLC est reconnue localement. Lorsqu'une station émettrice atteint la fenêtre émettrice, la station définit le bit d'interrogation pour forcer la station réceptrice à envoyer une réponse. Dans le routeur, la taille de fenêtre est appelée la fenêtre locale llc2.

Une station réceptrice peut refuser les accusés de réception jusqu’à ce qu’un certain nombre de trames I arrivent ou qu’un compteur expire. Ces paramètres sont respectivement appelés N3 et T2. De cette manière, plusieurs trames peuvent être reconnues 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 refuse un accusé de réception jusqu’à ce qu’il reçoive trois trames I, ou jusqu’à ce que le compteur T2, ou le délai de livraison llc2, 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 fenêtre locale de la station émettrice est définie sur 5 et que la station réceptrice a des valeurs de 7 pour ack-max et de 500 millisecondes pour ack-delay-time.

Dans ce cas, la station émettrice envoie cinq trames, puis attend un accusé de réception avant de continuer. Comme le récepteur refuse les accusés de réception jusqu’à ce que sept trames soient reçues, il n’envoie 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 réduisez la valeur ack-max sur la station de réception.

Un autre paramètre LLC2 courant est appelé le compteur Ti. Le routeur appelle cela le temps d’inactivité llc2. L'objectif du compteur 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. À l’expiration du compteur Ti, une trame RR est envoyée avec le bit d’interrogation activé pour obtenir une réponse du récepteur. Si la station ne répond pas, la station est retentée après lc2 tpf-time jusqu'à ce que le nombre de tentatives défini par llc2 n2 ait expiré. À ce moment-là, la session est désactivée.

Augmentez le temps d'inactivité pour réduire la surcharge sur un circuit LLC2 et vous pouvez l'ajuster comme alternative au rack local. Prenons un exemple où 200 DSPU sont connectés à un NCP. Chaque unité physique gère une session LLC2 indépendante. Si chacun envoie un keepalive toutes les dix secondes, il y a 20 trames de surcharge toutes les secondes. Si vous augmentez le temps d'inactivité à 30 secondes, la quantité de trames de surcharge passe à 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, ça pourrait être une bonne chose.

Paramètres de réglage LLC2

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

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

Exemples de configuration de paramètres LLC2

Dans un réseau DLSw+ classique avec un réseau LAN Token Ring à chaque extrémité, la configuration des paramètres LLC2 est effectuée sur l'interface Token Ring sortante.

Il existe deux sessions LLC2 distinctes. 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 0
source-bridge 10 1 100
llc2 tpf-timer 2000
llc2 n2 20

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

Remarque : Ces configurations abrégées n'affichent que les configurations de paramètres LLC2 pertinentes.

Les configurations des paramètres LLC2 doivent correspondre aux paramètres LLC2 au FEP (au routeur DLSw1) et au PC (au routeur DLSw2). Lorsque l'homologue DLSw+ du site central se trouve 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 se trouve entre le CIP et la pile LLC2 dans IOS. Le CIP représente le mainframe, et les paramètres LLC2 du mainframe vers IOS sont configurés sous les adaptateurs de la Token Ring LAN (sur le CIP). Les paramètres LLC2 de l’IOS vers le mainframe sont configurés sur l’interface sortante. Autrement dit, canal d'interface x/2 (pour CIP) et canal d'interface x/0 (pour xCPA).Par exemple :

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

Remarque : Ces configurations abrégées n'affichent que les configurations de paramètres LLC2 pertinentes.

Si le routeur CIP se connecte via le réseau local à une station locale, vous n'avez besoin que des paramètres LLC2 sous les cartes CIP. Les paramètres LLC2 sont ensuite mis en correspondance avec ceux du PC. Tous les paramètres LLC2 sous le canal d'interface 0/2 sont inefficaces.

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

Remarque : Ces configurations abrégées n'affichent que les configurations de paramètres LLC2 pertinentes.

Si des périphériques se connectent à DLSw+ via des groupes de ponts, les paramètres LLC2 sont configurés sur l'instruction DLSW+ bridge-group, comme indiqué ici :

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

Remarque : Ces configurations abrégées n'affichent que les configurations de paramètres LLC2 pertinentes.

Remarque : Bien que vous puissiez configurer LLC2 sous l'interface Ethernet 0, ces paramètres n'ont aucun effet. Le DLSw bridge-group LLC2 a été ajouté à la version 11.3 du logiciel Cisco IOS.

Lorsque le routeur est configuré en tant que 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. Exemple :

Remarque : Ces configurations abrégées n'affichent que les configurations de paramètres LLC2 pertinentes.

hostname snasw1
!
Interface fastethernet 0/0
llc2 tpf-timer 2000
llc2 n2 20
!
snasw cpname neta.snasw1
snasw 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 incorrectes. Celles-ci aboutissent généralement à un REJ et à des trames retransmises. Les retransmissions excessives ne sont pas normales et vous devez identifier la cause et résoudre le problème. Des retransmissions excessives peuvent se produire en raison de pertes, de chemins multiples, d’encombrement et de latence excessive.

Certaines erreurs dans LLC2 sont irrécupérables et entraînent toujours une panne 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 entraîner l’envoi d’une réponse FRMR par une station. La station qui envoie la réponse FRMR n'est probablement pas le contrevenant, mais simplement le messager. Le FRMR contient des informations qui indiquent pourquoi le FRMR est envoyé, ce qui est le plus souvent le cas lorsqu’une station demande à une autre station de renvoyer une trame I qu’elle a déjà reconnue. Comme la station ne peut pas retransmettre la trame (car elle l’a déjà supprimée), elle n’a 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 sont en panne.

Informations connexes

• Support et documentation techniques - Cisco Systems