Informazioni sul controllo collegamento logico

Introduzione

Lo standard IEEE 802.2 definisce LLC (Logical Link Control) come un livello di controllo del collegamento dati utilizzato su reti 802.3, 802.5 e di altro tipo. IBM ha originariamente progettato LLC come un sottolivello nell'architettura IBM Token Ring.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• Conoscenza di base di LLC

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Convenzioni

Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.

Premesse

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

Il trasferimento di dati senza connessione viene comunemente indicato come LLC tipo 1 o LLC1. Il servizio senza connessione non richiede la creazione di collegamenti dati o stazioni di collegamento. Dopo l'attivazione di un punto di accesso al servizio (SAP), 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 dispone di comandi di impostazione della modalità (ad esempio SABME) e non richiede che le informazioni sullo stato vengano mantenute.

Il trasferimento dei dati orientato alle connessioni è noto come LLC tipo 2 o LLC2. Il servizio orientato alle connessioni richiede la creazione di stazioni di collegamento. Una volta stabilita la stazione di collegamento, è necessario un comando di impostazione della modalità. In seguito, ogni stazione di collegamento è responsabile della gestione delle informazioni sullo stato del collegamento.

Implementazioni di LLC

LLC2 è implementato ogni volta che l'architettura di rete (SNA) dei sistemi viene eseguita su una LAN o una LAN virtuale. LLC2 è anche incapsulato direttamente in Frame Relay. A volte il router passa semplicemente attraverso i frame LLC2 e a volte implementa una stazione di collegamento LLC2. NetBIOS utilizza anche LLC. NetBIOS utilizza LLC1 per individuare una risorsa. Vengono quindi stabilite le sessioni LLC2 orientate alla connessione.

Il router implementa uno stack LLC2 quando è abilitata una delle seguenti funzionalità:

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

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

• CIP (Channel Interface Processor)

• Reti peer-to-peer avanzate (SNASwitching)

• Conversione da SDLC (Synchronous Data Link Control) a SDLC (LCC)

Informazioni di base necessarie per la risoluzione dei problemi

Una conoscenza di base di LLC è sufficiente per isolare e risolvere la maggior parte dei problemi. Poiché non esistono 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 stabiliscono

2. Sessioni stabilite con errori intermittenti

Per risolvere questi problemi è necessario conoscere i seguenti argomenti:

• Formati frame LLC

• Modalità LLC2 e definizione della sessione

• Funzionamento modalità bilanciamento asincrono LLC2

• Condizioni di errore LLC2

Formati frame LLC

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

Un frame LLC è denominato LLC Protocol Data Unit (LPDU) ed è formattato come mostrato di seguito:

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

Campo DSAP

Il punto di accesso al servizio di destinazione (DSAP, Destination Service Access Point) identifica il SAP per cui è destinata la LPDU. Il DSAP è costituito da sei bit di indirizzo, un bit utente (U) e un bit utente/gruppo (I/G), organizzati come mostrato di seguito:

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

Il bit U indica se l'indirizzo è definito da IEEE (1) o definito dall'utente (0). Il bit I/G indica se l'indirizzo SAP è un indirizzo di gruppo (1) o un indirizzo individuale (0). Per i nostri scopi, nessuno di questi bit è troppo importante. Tutto ciò che occorre sapere è che il DSAP è la destinazione della LPDU. Alcune comuni appaiono ripetutamente.

Campo SSAP

Il punto di accesso al servizio di origine (SSAP) identifica il SAP da cui ha avuto origine l'LPDU. Il protocollo SSAP è costituito da sei bit di indirizzo, un bit utente (U) e un bit di comando/risposta (C/R), organizzati come mostrato di seguito:

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

Il bit U indica se l'indirizzo è definito da IEEE (1) o definito dall'utente (0). Il bit C/R indica se la LPDU è un comando o una risposta. Quando si ricevono i frame LPDU, il bit C/R non è considerato parte del punto di accesso condiviso. Pertanto, il protocollo SSAP è in genere considerato solo ai sette bit più a sinistra.

Campo di controllo

Il campo di controllo LPDU contiene informazioni su comandi, risposte e numeri di sequenza. È necessario sapere come decodificare il campo di controllo per determinare cosa accade in una particolare sessione LLC2. Tuttavia, le informazioni di decodifica sono subito disponibili.

Esistono tre tipi di frame:

• I frame

• Frame di supervisione

• Frame non numerati

Sebbene ogni tipo abbia un formato diverso per il campo di controllo, è possibile distinguerlo facilmente esaminando due bit nel campo di controllo.

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

Nelle sezioni seguenti vengono descritti i singoli tipi di campo di controllo.

I Cornice

I frame IP consentono di trasferire LPDU con numerazione sequenziale contenenti informazioni (orientate alla connessione) tra le stazioni di collegamento. Il formato del frame I contiene un numero NS e NR. Il conteggio NS è il numero di sequenza (modulo 128) della LPDU attualmente in trasmissione. Il conteggio NR è il numero di sequenza del frame LPDU I successivo che il mittente si aspetta di ricevere. Per aiutarti in un secondo momento, ricorda 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 viene chiamato bit P nelle LPDU di comando e bit F nelle LPDU di risposta. Il bit P/F è impostato nel comando LPDU per richiedere che la stazione del collegamento remoto invii una risposta con questo bit impostato. Deve essere ricevuta una sola risposta con il bit F impostato per ogni comando inviato con il bit P impostato. Ci sono altri dettagli sull'uso del bit P/F in relazione al recupero dell'errore, ma questa è la regola generale.

Struttura di supervisione

I quadri di supervisione svolgono funzioni di controllo di supervisione, ad esempio per riconoscere i frame (RR), richiedere la ritrasmissione dei frame I (REJ) e richiedere la sospensione temporanea (RNR) dei frame I. I frame di supervisione non contengono un campo di informazioni. Pertanto, i frame di supervisione non influiscono su NS nella stazione di invio e pertanto non contengono un campo NS. Di seguito è riportato 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 quadro di supervisione.

• B'00' = Ricevitore pronto

  Una stazione utilizza l'RR per indicare che è pronta per la ricezione e contiene il conteggio NR del frame I successivo che deve arrivare. Quando una stazione invia un frame RR, la stazione conferma la ricezione di frame I numerati dalla stazione remota fino a NR - 1.

• B'01'=Ricevitore non pronto

  Una stazione utilizza l'RNR per indicare che al momento non è pronta per la ricezione. RNR contiene anche il conteggio dei NR che segue le stesse regole RR. Periodi transitori di RNR non sempre sono indicativi di un problema di rete. Se gli RNR sono persistenti, cercare la congestione nella stazione terminale.

• B'10'=Rifiuta

  Una stazione utilizza il REJ per richiedere la ritrasmissione di LPDU con frame IP a partire dal numero indicato nel numero di NR. REJ non è indicativo di un problema grave (che significa che è recuperabile). Se vengono visualizzati molti comandi REJ, cercare i frame I mancanti (scartati) nella direzione opposta. Non confondere REJ con FRMR (Frame Refs). Un FRMR è un fotogramma senza numero ed è sempre indicativo di un problema grave.

Frame non numerati

I frame non numerati offrono funzioni di controllo dei collegamenti, ad esempio comandi e risposte per l'impostazione della modalità. In alcuni casi, è possibile inviare anche frame di informazioni senza numero. I frame senza numero hanno una lunghezza di un solo byte. Non contengono campi per i conteggi NR o NRS. Di seguito è riportato il formato di una cornice senza numero:

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

I bit "M" indicano il tipo di fotogramma senza numero.

• B'00011'=Risposta DM (0x1F)

  Una stazione di collegamento invia una risposta DM per segnalare che è in modalità di disconnessione asincrona. Ciò significa che il collegamento non è attivo. Se una stazione di collegamento era attiva e inizia improvvisamente a inviare i DM, è probabile che sia stata reimpostata.

• B'01000'=Comando DISCO (0x53)

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

• B'01100'=Risposta UA(0x73)

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

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

  Una stazione di collegamento invia un messaggio SABME per avviare il trasferimento dei dati in modalità asincrona bilanciata. La risposta corretta a un SABME è un UA. Quando una stazione riceve un comando SABME, reimposta i conteggi di NR e NS su zero. La stazione di invio esegue la stessa operazione quando riceve la risposta dell'agente utente.

• B'10001'=Risposta FRMR(0x87)

  Una stazione di collegamento invia una risposta di rifiuto frame per segnalare un errore in una LPDU in ingresso dall'altra stazione di collegamento. Quando viene visualizzato un FRMR, la stazione che lo invia ha rilevato un errore irreversibile. Non è la causa dell'errore. Tutti i frame che arrivano dopo il verificarsi dell'errore FRMR vengono ignorati finché non si riceve un messaggio DISK o SABME.

  Una risposta FRMR contiene informazioni sulla causa della condizione FRMR.

  I byte 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 di seguito:

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

  Il bit V indica che il numero NS trasportato dal campo di controllo in byte 0 e 1 non è valido. Un NS non è valido se maggiore o uguale all'ultimo NS più le dimensioni massime 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 il NR contenuto nel campo di controllo, indicato nei byte 0 e 1, non si riferisce né al frame I successivo né a un frame I già trasmesso ma non riconosciuto.

  Nota: è possibile ricevere lo stesso numero di NR più volte.

  Il conteggio NR non è valido solo se fa riferimento a un fotogramma I già riconosciuto o se il conteggio va avanti rispetto a uno non ancora trasmesso. Il primo è il caso più comune di questo tipo di errore. Quando si verifica questo tipo di errore, in genere i frame vengono ricevuti fuori sequenza e si consiglia di cercare la rete che restituisce i frame non in ordine. È possibile che la stazione di collegamento di invio li abbia trasmessi in modo non corretto, ma molto improbabile.

  Il bit Y indica che la lunghezza del campo I nella LPDU ricevuta supera la capacità del buffer disponibile. In questo caso, cercare i problemi nelle stazioni terminali, non nella rete.

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

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

• Comando o risposta XID B'1011'

  Una stazione di collegamento utilizza il comando XID per comunicare le caratteristiche del nodo di invio e per fare in modo che la stazione di collegamento remoto risponda con una risposta XID. Le stazioni di collegamento possono inviare e ricevere XID in vari formati, inclusi i formati SNA.

• Comando o risposta di TEST B'11100'

  Una stazione di collegamento invia il comando TEST per fare in modo che la stazione di collegamento remoto risponda il prima possibile con una risposta TEST. Il comando TEST viene in genere utilizzato per il rilevamento dei percorsi in un ambiente di bridging route di origine.

  

Riepilogo campo controllo LLC

Modalità LLC2 e definizione della sessione

Esistono due modalità di funzionamento LLC2:

• Modalità bilanciata asincrona estesa

• Modalità disconnessione asincrona

Modalità bilanciata asincrona estesa (ABME)

ABME è una modalità di funzionamento bilanciata tra due stazioni di collegamento. La modalità bilanciata si riferisce al fatto che ciascuna stazione può inviare comandi in qualsiasi momento, indipendentemente dall'altra stazione di collegamento. Contrastare con SDLC, che funziona in modalità non bilanciata. In modalità non bilanciata, la stazione secondaria deve attendere il polling della stazione primaria prima di poter inviare i dati. Come risultato del funzionamento in modalità bilanciata, il polling non si verifica sui circuiti LLC2 nel senso tradizionale. Una stazione invia pacchetti keepalive per mantenere la sessione, ma non è necessario inviarli frequentemente per prestazioni ottimali come in SDLC. Per questo motivo, il timer keepalive ha in genere 10 secondi o più. È importante notare che le stazioni terminali possono aumentare questo timer keepalive per ridurre il sovraccarico. Un aumento del timer keepalive non ha alcun effetto negativo sul throughput o sul tempo di risposta.

Una stazione entra in ABME dopo che la stazione invia o riceve un UA al comando SABME. In ABME, la stazione può inviare e ricevere frame di informazioni numerati.

Modalità disconnessione asincrona (ADM)

Prima e dopo che una stazione termina ABME, la stazione è in modalità di disconnessione asincrona. In ADM, il collegamento viene disconnesso logicamente; pertanto, non è possibile inviare frame I o frame di supervisione. Una stazione può accedere all'ADM nelle seguenti condizioni:

• Conferma di un comando DISK

• La stazione di collegamento è attivata

• Ricezione di una risposta DM

• Limite tentativi esaurito

Di seguito è riportato un esempio di sequenza di attivazione di una stazione di collegamento:

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

Funzionamento modalità bilanciamento asincrono LLC2

Le stazioni che operano in ASBM non hanno una percezione rigorosa delle stazioni primarie o secondarie. Non è necessario eseguire il polling o il polling delle stazioni per trasferire i dati. Le stazioni possono trasmettere dati a qualsiasi stazione in modo asincrono. Le stazioni hanno relazioni peer-to-peer.

Anche se non vi è un senso stretto di primario e secondario, una stazione mittente richiede una risposta a livello di collegamento chiamata conferma da parte della stazione ricevente per ogni frame di informazioni numerato inviato. Una stazione può continuare a trasmettere i frame a un'altra stazione fino a quando il numero di frame non riconosciuti raggiunge un limite. Questo numero è denominato "dimensione finestra" e in genere viene impostato automaticamente su 7. È possibile aumentare la dimensione della finestra nei circuiti in cui è presente una latenza elevata per evitare che la stazione di invio si arresti e attenda una risposta. Questo di solito non è necessario, specialmente in situazioni in cui LLC è localmente riconosciuto. Quando una stazione di invio raggiunge la finestra di invio, la stazione imposta il bit di polling per forzare la stazione ricevente a inviare una risposta. Nel router, le dimensioni della finestra sono denominate llc2 local-window.

Una stazione ricevente ha l'opzione di trattenere le conferme fino all'arrivo di un certo numero di frame IP o alla scadenza di un timer. Questi parametri sono denominati rispettivamente N3 e T2. In questo modo è possibile riconoscere più frame con un frame RR oppure inviare un riconoscimento in un frame I. Cisco chiama il contatore N3 llc2 ack-max. Il valore predefinito di tre indica che il router rifiuta una conferma finché non riceve tre frame IP o finché non scade il timer T2 o il tempo di ritardo ACK LLC2.

La modifica di questi parametri su una stazione senza considerare la stazione partner può influire sul tempo di risposta e sul throughput. Si consideri, ad esempio, cosa succede se la finestra locale della stazione di invio è impostata su 5 e la stazione ricevente ha valori pari a 7 per ack-max e 500 millisecondi per ack-delay-time.

In questo caso, la stazione di invio invia cinque fotogrammi, quindi attende la conferma prima di continuare. Poiché il ricevente rifiuta le conferme fino alla ricezione di sette frame, non invierà una conferma fino alla scadenza del ritardo di 500 millisecondi. È possibile migliorare notevolmente le prestazioni se si abbassa il valore ack-max sulla stazione ricevente.

Un altro parametro LLC2 comune è il timer Ti. Il router lo chiama tempo di inattività llc2. Lo scopo del timer Ti è mantenere attiva la sessione LLC2 durante i periodi in cui non vengono trasmessi frame I. Se si riduce questo valore, non è possibile migliorare il throughput e le prestazioni. Alla scadenza del timer per il Ti, viene inviato un frame RR con il bit di polling attivato per generare una risposta dal ricevitore. Se la stazione non risponde, viene eseguito un nuovo tentativo dopo il tempo tpf di llc2 fino alla scadenza del numero di tentativi definito da llc2 n2. In quel momento, la sessione è distrutta.

Aumentare il tempo di inattività per ridurre la quantità di sovraccarico su un circuito LLC2 e si può regolare questo come alternativa all'ack locale. Si consideri un esempio in cui 200 unità DSPU sono collegate a un NCP. Ciascuna delle unità di elaborazione mantiene una sessione LLC2 indipendente. Se ognuno invia un segnale keepalive ogni dieci secondi, si ottengono 20 frame di sovraccarico ogni secondo. Se aumentate 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 a scoprire che il loro partner è irraggiungibile. Ma a seconda della tua situazione, potrebbe essere una buona cosa.

Parametri regolabili LLC2

È possibile utilizzare il comando show llc per visualizzare i valori di questi parametri:

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

Esempi di configurazioni di parametri LLC2

In una tipica rete DLSw+ con una LAN Token Ring su entrambe le estremità, la configurazione dei parametri LLC2 viene effettuata sull'interfaccia token ring in uscita.

Esistono due sessioni LLC2 separate. Pertanto, configurare i parametri LLC2 come indicato di seguito:

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

Nota: queste configurazioni di skimed mostrano solo le configurazioni di parametro LLC2 rilevanti.

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

La configurazione del router DLSw+ remoto rimane invariata. Tuttavia, la sessione LLC2 sul sito centrale si trova tra lo stack CIP e LLC2 in IOS. Il CIP rappresenta il mainframe, e i parametri LLC2 dal mainframe verso IOS sono configurati sotto le schede sul LAN Token Ring (sul CIP). I parametri LLC2 da IOS verso il mainframe sono configurati sull'interfaccia in uscita. ovvero il canale di interfaccia x/2 (per CIP) e il canale di interfaccia x/0 (per xCPA).Ad esempio:

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

Nota: queste configurazioni di skimed mostrano solo le configurazioni di parametro LLC2 rilevanti.

Se il router CIP si connette tramite la LAN a una stazione locale, saranno necessari solo i parametri LLC2 delle schede CIP. I parametri LLC2 vengono quindi associati a quelli del PC. Tutti i parametri LLC2 nel canale di interfaccia 0/2 sono inattivi.

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

Nota: queste configurazioni di skimed mostrano solo le configurazioni di parametro LLC2 rilevanti.

Se i dispositivi si connettono a DLSw+ tramite bridge-group, i parametri LLC2 sono configurati nell'istruzione DLSW+ bridge-group come mostrato di seguito:

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

Nota: queste configurazioni di skimed mostrano solo le configurazioni di parametro LLC2 rilevanti.

Nota: sebbene sia possibile configurare LLC2 nell'interfaccia Ethernet 0, questi parametri non hanno alcun effetto. DLSw bridge-group LLC2 è stato introdotto nel software Cisco IOS versione 11.3.

Quando il router è configurato come stazione terminale (ad esempio, SNASw e DSPU), è necessario configurare i parametri LLC2 sull'interfaccia in uscita. Si noti che non tutte le interfacce virtuali supportano la configurazione dei parametri LLC2. Ad esempio:

Nota: queste configurazioni di skimed mostrano solo le configurazioni di parametro LLC2 rilevanti.

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

Condizioni di errore LLC2

Alcuni errori nelle sessioni LLC2 sono normali e recuperabili, ad esempio, occasionali frame mancati o frame non ordinati. Questi in genere producono un REJ e frame ritrasmessi. Trasmissioni eccessive non sono normali ed è necessario identificare la causa e risolvere il problema. Ritrasmissioni eccessive possono verificarsi a causa di cadute, percorsi multipli, congestione e latenza eccessiva.

Alcuni errori in LLC2 sono irreversibili e determinano sempre un'interruzione della sessione. Questi errori sono esclusivamente violazioni di protocollo. Possono verificarsi quando le stazioni inviano campi di controllo non definiti o altre informazioni errate. A causa di queste violazioni del protocollo, una stazione può inviare una risposta FRMR. La stazione che invia la risposta FRMR molto probabilmente non è il violatore, ma semplicemente il messaggero. Il FRMR contiene informazioni che identificano il motivo per cui il FRMR viene inviato, in genere quando una stazione richiede a un'altra stazione di inviare nuovamente un frame I già riconosciuto. Poiché la stazione non può ritrasmettere il frame (poiché lo ha già scartato), non ha altra scelta se non quella di terminare la sessione LLC. Quando si verifica questo tipo di errore, la causa più probabile è che i frame non siano in ordine.

Informazioni correlate

• Documentazione e supporto tecnico – Cisco Systems