Understanding Logical Link Control

Introduzione

Lo standard EIEEE 802.2 definisce Logical Link Control (LLC) come un livello di controllo del collegamento dati usato su 802.3, 802.5 e altre reti. IBM ha originariamente progettato LLC come sottolivello nell’architettura IBM Token Ring.

Prerequisiti

Requisiti

Cisco raccomanda di conoscere questi argomenti:

• Una conoscenza di base di LLC

Componenti utilizzati

Questo documento non è limitato a specifiche versioni software e hardware.

Le informazioni in questo documento sono state create dai dispositivi in uno specifico ambiente di laboratorio. Tutti i dispositivi usati in questo documento sono partiti con una configurazione azzerata (predefinita). Se la vostra rete è attiva, assicuratevi di capire il potenziale impatto di ogni comando.

Convenzioni

Riferitevi alle convenzioni dei suggerimenti tecnici Cisco per ulteriori informazioni sulle convenzioni dei documenti.

Informazioni di base

Il livello LLC fornisce un trasferimento dati senza connessione e orientato alla connessione.

Il trasferimento dati senza connessione è comunemente indicato come LLC tipo 1, o LLC1. Il servizio senza connessione non richiede di stabilire collegamenti dati o stazioni di collegamento. Dopo che un Service Access Point (SAP) è stato abilitato, il SAP può inviare e ricevere informazioni da e verso un SAP remoto che utilizza anche il servizio senza connessione. Il servizio senza connessione non ha alcun comando di impostazione della modalità (come SABME) e non richiede il mantenimento delle informazioni di stato.

Il trasferimento dati orientato alla connessione è indicato come LLC tipo 2, o LLC2. Il servizio orientato alla connessione richiede la creazione di stazioni di collegamento. Quando la stazione di collegamento è stabilita, è necessario un comando di impostazione della modalità. In seguito, ogni stazione di collegamento è responsabile del mantenimento delle informazioni sullo stato del collegamento.

Implementazioni di LLC

LLC2 è implementato ogni volta che Systems Network Architecture (SNA) gira su una LAN o una LAN virtuale. LLC2 è anche direttamente incapsulato in Frame Relay. A volte il router passa semplicemente i frame LLC2 e a volte il router implementa una linkstation LLC2. Anche NetBIOS usa LLC. NetBIOS usa LLC1 per localizzare una risorsa. Le sessioni orientate alla connessione LLC2 sono quindi stabilite.

Il router implementa uno stack LLC2 quando una di queste caratteristiche è abilitata:

• Data-Link Switching (DLSw) (connessione alla LAN)

• Remote Source-Route Bridging (RSRB) con ACK locale

• Channel Interface Processor (CIP)

• Advanced Peer-to-Peer (SNASwitching (SNASw))

• Synchronous Data Link Control (SDLC) to LCC Conversion (SDLLC)

Informazioni di base che dovete conoscere per risolvere i problemi

Una conoscenza di base di LLC è sufficiente per isolare e risolvere la maggior parte dei problemi. Poiché non ci sono stati di collegamento o sessioni da mantenere, i problemi sono rari in LLC1.

In LLC2, possono verificarsi due categorie di problemi:

1. Sessioni che non si stabiliscono

2. Sessioni stabilite che falliscono ad intermittenza

Per risolvere questi problemi è necessario conoscere questi argomenti:

• Formati di frame LLC

• Modalità LLC2 e creazione della sessione

• Modalità bilanciata asincrona LLC2 Funzionamento

• Condizioni di errore LLC2

Formati di frame LLC

Questa sezione fornisce informazioni sui formati di frame 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

Un frame LLC è chiamato LLC Protocol Data Unit (LPDU), ed è formattato come mostrato qui:

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

Campo DSAP

Il Destination Service Access Point (DSAP) identifica il SAP a cui è destinata la LPDU. Il DSAP consiste di sei bit di indirizzo, un bit utente (U) e un bit individuo/gruppo (I/G), organizzati come mostrato qui:

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

Il bit U indica se l’indirizzo è definito dall’IEEE (1) o definito dall’utente (0). Il bit I/G indica se il SAP è un indirizzo di gruppo (1) o individuale (0). Per i nostri scopi, nessuno di questi bit è troppo importante. Tutto quello che dovete sapere è che il DSAP è la destinazione della LPDU. Alcuni comuni appaiono più volte.

Campo SSAP

Il Source Service Access Point (SSAP) identifica il SAP che ha originato la LPDU. Il SSAP consiste di sei bit di indirizzo, un bit utente (U) e un bit comando/risposta (C/R), organizzati come mostrato qui:

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

Il bit U indica se l’indirizzo è definito dall’IEEE (1) o definito dall’utente (0). Il bit C/R indica se la LPDU è un comando o una risposta. Quando si ricevono frame LPDU, il bit C/R non è considerato parte dell’SSAP. Pertanto, l’SSAP è normalmente considerato solo i sette bit più a sinistra.

Campo di controllo

Il campo di controllo LPDU contiene informazioni su comando, risposta e numero di sequenza. Hai bisogno di sapere come decodificare il campo di controllo per determinare cosa succede in una particolare sessione LLC2. Tuttavia, le informazioni di decodifica sono facilmente disponibili.

Ci sono tre tipi di frame:

• I Frames

• Supervisory Frames

• Unnumbered Frames

Anche se ogni tipo ha un formato diverso per il campo di controllo, puoi facilmente distinguerli attraverso un esame di due bit nel campo di controllo.

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

Le prossime sezioni spiegano ogni tipo di campo di controllo.

I Frame

I frame permettono di trasferire LPDU numerate in sequenza che contengono informazioni (orientate alla connessione) tra stazioni di collegamento. Il formato del frame I contiene un conteggio NS e NR. Il conteggio NS è il numero di sequenza (modulo 128) della LPDU attualmente in trasmissione. Il conteggio NR è il numero di sequenza della prossima LPDU I frame che il mittente si aspetta di ricevere. Per aiutarvi in seguito, ricordate che NR significa “prossima ricezione”.

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

Il bit P/F è chiamato bit P nelle LPDU di comando e bit F nelle LPDU di risposta. Il bit P/F è impostato nelle LPDU di comando per richiedere che la stazione di collegamento remoto invii una risposta con questo bit impostato. Solo una risposta deve essere ricevuta con il bit F impostato per ogni comando inviato con il bit P impostato. Ci sono alcuni altri dettagli sull’uso del bit P/F in relazione al recupero degli errori, ma questa è la regola generale.

Frame di supervisione

I frame di supervisione svolgono funzioni di controllo di supervisione, per esempio, per riconoscere gli I Frame (RR), per richiedere la ritrasmissione degli I Frame (REJ), e per richiedere la sospensione temporanea (RNR) degli I Frame. I frame di supervisione non contengono un campo di informazione. Pertanto, i frame di supervisione non influenzano l’NS nella stazione di invio, e quindi non contengono un campo NS. Ecco il formato di un frame di supervisione:

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

I bit “S” indicano il tipo di supervisory frame.

• B’00’ = Receiver Ready

  Una stazione usa il RR per indicare che la stazione è pronta a ricevere, e contiene il conteggio NR del prossimo I frame che deve arrivare. Quando una stazione invia un frame RR, la stazione riconosce la ricezione di frame I numerati dalla stazione remota fino a NR – 1.

• B’01’=Receiver Not Ready

  Una stazione usa RNR per indicare che la stazione non è temporaneamente pronta a ricevere. RNR contiene anche il conteggio NR che segue le stesse regole RR. Periodi transitori di RNR non sono sempre indicativi di un problema di rete. Se gli RNR sono persistenti, cercate una congestione nella stazione finale.

• B’10’=Rifiuta

  Una stazione usa il REJ per richiedere la ritrasmissione di I frame LPDU a partire dal numero indicato nel conteggio NR. REJ non è indicativo di un problema serio (il che significa che è recuperabile). Se vedete molti comandi REJ, cercate dei frame I mancanti (abbandonati) nella direzione opposta. Non confondete un REJ con un Frame reject (FRMR). Un FRMR è un frame non numerato ed è sempre indicativo di un problema serio.

Frames non numerati

I frame non numerati forniscono funzioni di controllo del collegamento, per esempio, comandi e risposte di impostazione della modalità. In alcuni casi, possono essere inviati anche frame informativi non numerati. I frame non numerati sono lunghi solo un byte. Non contengono campi per i conteggi NR o NRS. Ecco il formato di un frame non numerato:

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

I bit “M” indicano il tipo di frame non numerato.

• B’00011’=DM Response (0x1F)

  Una stazione di collegamento invia una risposta DM per segnalare che è in modalità di disconnessione asincrona. Questo significa che il collegamento non è attivo. Se una stazione di collegamento era attiva e improvvisamente inizia a inviare DM, la stazione di collegamento è stata probabilmente resettata.

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

  Una stazione di collegamento invia un DISC per terminare la modalità bilanciata asincrona. Il comando DISC informa la stazione di collegamento remota che sospende il funzionamento. La risposta corretta a un comando DISC è un UA (se la stazione è in ABM), o un DM (se la stazione è in ADM).

• B’01100’=UA Response(0x73)

  Una stazione di collegamento invia un UA in risposta ai comandi SABME e DISC.

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

  Una stazione di collegamento invia un SABME per iniziare il trasferimento dati in modalità bilanciata asincrona. La risposta corretta a un SABME è un UA. Quando una stazione riceve un comando SABME, la stazione azzera i conteggi NR e NS. La stazione mittente fa lo stesso quando riceve la risposta UA.

• B’10001’=FRMR Response(0x87)

  Una stazione di collegamento invia una risposta Frame Reject per segnalare un errore in una LPDU in arrivo dall’altra stazione di collegamento. Quando vedete una FRMR, la stazione che invia la FRMR ha rilevato un errore irrecuperabile. Non è la causa dell’errore. Qualsiasi frame che arriva dopo che l’errore FRMR si è verificato viene ignorato fino a quando non viene ricevuto un DISC o SABME.

  Una risposta FRMR contiene informazioni sulla causa della condizione FRMR.

  Bytes 0 e 1 contengono il contenuto del campo di controllo della LPDU che ha causato il rifiuto del frame. I byte 2 e 3 contengono rispettivamente i conteggi NS e NR. Il byte 4 contiene diversi bit che identificano il tipo di errore come mostrato qui:

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

  Il bit V indica che il numero NS portato dal campo di controllo nei byte 0 e 1 non è valido. Un NS non è valido se è maggiore o uguale all’ultimo NS più la dimensione massima della finestra di ricezione. Quando si verifica questa condizione, la stazione di collegamento invia una LPDU REJ, non una risposta FRMR.

  Il bit Z indica che l’NR che il campo di controllo porta indicato nei byte 0 e 1 non si riferisce né al prossimo I frame né a un I frame che è già stato trasmesso ma non riconosciuto.

  Nota: va bene ricevere lo stesso conteggio NR più volte.

  Il conteggio NR non è valido solo se il conteggio si riferisce a un I frame che è già stato riconosciuto o se il conteggio salta avanti a uno che non è stato ancora trasmesso. Il primo è il caso più comune di questo tipo di errore. Quando vedete questo tipo di errore, di solito significa che i frame sono stati ricevuti fuori sequenza, e dovreste cercare la rete che consegna i frame fuori ordine. È possibile che la stazione di collegamento mittente li abbia trasmessi fuori ordine, ma molto improbabile.

  Il bit Y indica che la lunghezza del campo I nella LPDU ricevuta ha superato la capacità del buffer disponibile. Se si verifica questa situazione, cercate problemi nelle stazioni finali, non nella rete.

  Il bit X indica che la LPDU conteneva un campo I quando non doveva, oppure è stata ricevuta una risposta FRMR che non conteneva 5 byte. Questo sembra essere un problema della stazione finale, non un problema di rete.

  Il bit W indica che è stata ricevuta una LPDU non supportata. Questo è un problema della stazione finale.

• B’10111′ Comando o risposta XID

  Una stazione di collegamento usa il comando XID per trasmettere caratteristiche del nodo mittente e per indurre la stazione di collegamento remota a rispondere con una risposta XID. Le stazioni di collegamento possono inviare e ricevere XID in vari formati, compresi i formati SNA.

• B’11100′ Comando o risposta TEST

  Una stazione di collegamento invia il comando TEST per indurre la stazione di collegamento remota a rispondere con una risposta TEST il più presto possibile. Il comando TEST è generalmente usato per la ricerca del percorso in un ambiente di bridging source-route.

  

Riassunto del campo di controllo LLC

Modalità LLC2 e Session Establishment

Ci sono due modalità di funzionamento LLC2:

• Asynchronous Balanced Mode Extended

• Asynchronous Disconnect Mode

Asynchronous Balanced Mode Extended (ABME)

ABME è una modalità di funzionamento bilanciata tra due stazioni di collegamento. La modalità bilanciata si riferisce al fatto che entrambe le stazioni possono inviare comandi in qualsiasi momento, indipendentemente dall’altra stazione di collegamento. Contrasta questo con SDLC, che opera in modalità non bilanciata. In modalità non bilanciata, la stazione secondaria deve aspettare di essere interrogata dalla primaria prima di poter inviare dati. Come risultato del funzionamento in modalità bilanciata, il polling non avviene sui circuiti LLC2 nel senso tradizionale. Una stazione invia keepalive per mantenere la sessione, ma non è necessario inviarli frequentemente per ottenere prestazioni ottimali come in SDLC. Per questo motivo, il keepalive timer è tipicamente 10 secondi o più. È importante notare che le stazioni finali possono aumentare questo timer di keepalive per ridurre l’overhead. Un aumento del keepalive timer non ha effetti negativi sul throughput o sul tempo di risposta.

Una stazione entra in ABME dopo che la stazione invia o riceve un comando UA to SABME. Quando è in ABME, la stazione può inviare e ricevere frame di informazione numerati.

Modalità di disconnessione asincrona (ADM)

Prima e dopo che una stazione termina ABME, la stazione è in modalità di disconnessione asincrona. In ADM, il collegamento è logicamente disconnesso; pertanto, non possono essere inviati I frames o supervisory frames. Una stazione può entrare in ADM in queste condizioni:

• Ricezione di un comando DISC

• La stazione di collegamento è attivata

• Ricezione di una risposta DM

• Il limite di ripetizione è esaurito

Ecco un esempio di sequenza di attivazione della stazione di collegamento:

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 ...

LLC2 Asynchronous Balanced Mode Operation

Le stazioni che operano in ASBM non hanno un senso stretto di stazione primaria o secondaria. Le stazioni non hanno bisogno di fare o essere interrogate per trasferire dati. Le stazioni possono trasmettere dati a qualsiasi stazione in modo asincrono. Le stazioni hanno relazioni peer-to-peer.

Anche se non c’è un senso stretto di primario e secondario, una stazione che invia richiede una risposta a livello di collegamento chiamata acknowledgment dalla stazione ricevente per ogni frame informativo numerato inviato. Una stazione può continuare a trasmettere frame I a un’altra stazione finché il numero di frame non riconosciuti non raggiunge un limite. Questo numero è chiamato “dimensione della finestra”, e tipicamente il valore predefinito è 7. Potete aumentare la dimensione della finestra sui circuiti dove c’è molta latenza per evitare che la stazione inviante debba fermarsi e aspettare una risposta. Questo di solito non è necessario, specialmente in situazioni dove LLC è riconosciuto localmente. Quando una stazione di invio raggiunge la finestra di invio, la stazione imposta il bit di polling per forzare la stazione ricevente ad inviare una risposta. Nel router, la dimensione della finestra è chiamata llc2 local-window.

Una stazione ricevente ha l’opzione di trattenere le conferme finché non arriva un certo numero di frame I o finché non scade un timer. Questi parametri sono chiamati N3 e T2, rispettivamente. In questo modo, più frame possono essere riconosciuti con un solo frame RR, o un riconoscimento può essere inviato sopra un frame I. Cisco chiama il contatore N3 llc2 ack-max. Il valore predefinito di tre indica che il router trattiene un acknowledgment finché non riceve tre frame I, o finché il timer T2, o il llc2 ack-delay-time, non scade.

La modifica di questi parametri su una stazione senza considerare la stazione partner può influenzare il tempo di risposta e il throughput. Per esempio, considerate cosa accadrebbe se la local-window della stazione mittente è impostata su 5 e la stazione ricevente ha valori di 7 per ack-max e 500 millisecondi per ack-delay-time.

In questo caso, la stazione mittente invia cinque frame, poi aspetta una conferma prima di continuare. Poiché il ricevitore trattiene le conferme fino alla ricezione di sette frame, non invierà una conferma fino alla scadenza del tempo di ritardo di 500 millisecondi. Potete migliorare drasticamente le prestazioni se abbassate il valore ack-max sulla stazione ricevente.

Un altro parametro comune di LLC2 è chiamato Ti timer. Il router lo chiama llc2 idle-time. Lo scopo del Ti timer è di mantenere attiva la sessione LLC2 durante i periodi in cui non vengono trasmessi frame I. Non puoi migliorare il throughput e le prestazioni se abbassi questo valore. Quando il timer Ti scade, viene inviato un frame RR con il poll bit attivo per provocare una risposta dal ricevitore. Se la stazione non risponde, la stazione viene ritentata dopo llc2 tpf-time finché il numero di ritentativi definito da llc2 n2 è scaduto. A quel punto, la sessione viene interrotta.

Aumenta il tempo di inattività per ridurre la quantità di overhead su un circuito LLC2 e puoi regolare questo come alternativa al local ack. Consideriamo un esempio in cui 200 DSPU sono collegate a un NCP. Ogni PU mantiene una sessione LLC2 indipendente. Se ognuna invia un keepalive ogni dieci secondi, ci sono 20 frame di overhead ogni secondo. Se si aumenta il tempo di inattività a 30 secondi, la quantità di frame di overhead si riduce a 6,67 frame al secondo. Lo svantaggio di questo approccio è che le stazioni impiegano più tempo per scoprire che il loro partner non è raggiungibile. Ma a seconda della vostra situazione, questa potrebbe essere una buona cosa.

Parametri regolabili LLC2

Puoi usare il comando show llc per vedere i valori di questi parametri:

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

Esempi di configurazione dei parametri LLC2

In una tipica rete DLSw+ con una LAN Token Ring ad entrambe le estremità, la configurazione dei parametri LLC2 è fatta sull’interfaccia Token Ring in uscita.

Ci sono due sessioni LLC2 separate. Pertanto, configurare i parametri LLC2 come mostrato qui:

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

Nota: Queste configurazioni scremate mostrano solo le configurazioni rilevanti dei parametri LLC2.

Le configurazioni dei parametri LLC2 devono corrispondere ai parametri LLC2 al FEP (al router DLSw1) e al PC (al router DLSw2). Quando il peer DLSw+ del sito centrale è su un router CIP, la configurazione è leggermente diversa.

La configurazione del router DLSw+ remoto rimane invariata. Tuttavia, la sessione LLC2 al sito centrale è tra il CIP e lo stack LLC2 in IOS. Il CIP rappresenta il Mainframe, e i parametri LLC2 dal Mainframe verso IOS sono configurati sotto gli adattatori sulla LAN Token Ring (sul CIP). I parametri LLC2 da IOS verso il Mainframe sono configurati sull’interfaccia in uscita. Cioè, il canale di interfaccia x/2 (per CIP) e il canale di interfaccia x/0 (per xCPA).Per esempio:

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

Nota: Queste configurazioni scremate mostrano solo le configurazioni dei parametri LLC2 rilevanti.

Se il router CIP si connette via LAN a una stazione locale, hai bisogno solo dei parametri LLC2 sotto gli adattatori CIP. I parametri LLC2 sarebbero poi abbinati a quelli del PC. Qualsiasi parametro LLC2 sotto il canale di interfaccia 0/2 è 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

Nota: Queste configurazioni scremate mostrano solo le configurazioni dei parametri LLC2 rilevanti.

Se i dispositivi si connettono in DLSw+ attraverso i gruppi ponte, i parametri LLC2 sono configurati sulla dichiarazione del gruppo ponte DLSW+ come mostrato qui:

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

Nota: Queste configurazioni scremate mostrano solo le configurazioni dei parametri LLC2 rilevanti.

Nota: Anche se puoi configurare LLC2 sotto l’interfaccia ethernet 0, questi parametri non hanno effetto. DLSw bridge-group LLC2 era nuovo in Cisco IOS Software Release 11.3.

Quando il router è configurato come end-station (per esempio, SNASw e DSPU), è necessario configurare i parametri LLC2 sull’interfaccia in uscita. Nota che non tutte le interfacce virtuali supportano la configurazione dei parametri LLC2. Per esempio:

Nota: Queste configurazioni scremate mostrano solo le configurazioni dei parametri LLC2 rilevanti.

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

Condizioni di errore LLC2

Alcuni errori sulle sessioni LLC2 sono normali e recuperabili, per esempio, occasionali frame mancanti o frame fuori ordine. Questi di solito risultano in un REJ e frame ritrasmessi. Ritrasmissioni eccessive non sono normali, e dovete identificare la causa e risolvere il problema. Le ritrasmissioni eccessive possono verificarsi a causa di cadute, percorsi multipli, congestione ed eccessiva latenza.

Alcuni errori in LLC2 sono irrecuperabili e provocano sempre un’interruzione della sessione. Questi errori sono esclusivamente violazioni del protocollo. Possono verificarsi quando le stazioni inviano campi di controllo non definiti o altre informazioni errate. Queste violazioni di protocollo possono far sì che una stazione invii una risposta FRMR. La stazione che invia la risposta FRMR molto probabilmente non è il trasgressore, ma semplicemente il messaggero. La FRMR contiene informazioni che identificano il motivo per cui la FRMR viene inviata, che è più comunemente quando una stazione richiede ad un’altra stazione di reinviare un frame I che ha già riconosciuto. Poiché la stazione non può ritrasmettere il frame (perché lo ha già scartato), non ha altra scelta che terminare la sessione LLC. Quando si verifica questo tipo di errore, la causa più probabile è che i frame siano fuori ordine.