Forståelse af Logical Link Control

Introduktion

IEEE-standard 802.2 definerer Logical Link Control (LLC) som et datalink-kontrollag, der anvendes på 802.3, 802.5 og andre netværk. IBM designede oprindeligt LLC som et underlag i IBM’s Token Ring-arkitektur.

Forudsætninger

Krav

Cisco anbefaler, at du har kendskab til disse emner:

• En grundlæggende forståelse af LLC

Anvendte komponenter

Dette dokument er ikke begrænset til bestemte software- og hardwareversioner.

Informationerne i dette dokument blev oprettet ud fra enhederne i et specifikt laboratoriemiljø. Alle de enheder, der er anvendt i dette dokument, startede med en renset (standard)konfiguration. Hvis dit netværk er live, skal du sikre dig, at du forstår den potentielle virkning af enhver kommando.

Konventioner

Referer til Cisco Technical Tips Conventions for at få flere oplysninger om dokumentkonventioner.

Baggrundsoplysninger

LLC-laget giver forbindelsesløs og konnektionsorienteret dataoverførsel.

Den forbindelsesløse dataoverførsel betegnes almindeligvis som LLC type 1 eller LLC1. Forbindelsesløs tjeneste kræver ikke, at du etablerer dataforbindelser eller forbindelsesstationer. Når et serviceadgangspunkt (SAP) er blevet aktiveret, kan SAP’en sende og modtage oplysninger til og fra en fjern-SAP, der også bruger forbindelsesløs tjeneste. Forbindelsesløs tjeneste har ingen kommandoer til indstilling af tilstand (f.eks. SABME) og kræver ikke, at der vedligeholdes tilstandsinformationer.

Forbindelsesorienteret dataoverførsel omtales som LLC type 2 eller LLC2. Forbindelsesorienteret tjeneste kræver etablering af forbindelsesstationer. Når forbindelsesstationen er etableret, er det nødvendigt med en kommando til indstilling af tilstand. Derefter er hver enkelt forbindelsesstation ansvarlig for at vedligeholde oplysninger om forbindelsestilstand.

Implementeringer af LLC

LLC2 implementeres, når Systems Network Architecture (SNA) kører over et LAN eller et virtuelt LAN. LLC2 er også direkte indkapslet i Frame Relay. Nogle gange videregiver routeren blot LLC2-rammer, og nogle gange implementerer routeren en LLC2-linkstation. NetBIOS anvender også LLC. NetBIOS anvender LLC1 til at lokalisere en ressource. LLC2-forbindelsesorienterede sessioner etableres derefter.

Routeren implementerer en LLC2-stack, når en af disse funktioner er aktiveret:

• Data-Link Switching (DLSw) (forbindelse til LAN)

• Remote Source-Route Bridging (RSRB) med lokal ACK

• Channel Interface Processor (CIP)

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

• Synchronous Data Link Control (SDLC) til LCC-konvertering (SDLLC)

Grundlæggende oplysninger, som du skal kende for at kunne foretage fejlfinding

Et grundlæggende kendskab til LLC er nok til at isolere og løse de fleste problemer. Da der ikke er nogen linktilstande eller sessioner, der skal vedligeholdes, er problemer sjældne i LLC1.

I LLC2 kan der opstå to kategorier af problemer:

1. Sessioner, der ikke etableres

2. Etablerede sessioner, der med mellemrum mislykkes

For at kunne løse disse problemer skal du kende til disse emner:

• LLC-rammeformater

• LLC2 Modes and Session Establishment

• LLC2 Asynchronous Balanced Mode (Asynkron balanceret tilstand) Drift

• LLC2-fejlbetingelser

LLC-rammeformater

Dette afsnit indeholder oplysninger om LLC-rammeformater.

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

En LLC-ramme kaldes en LLC-protokol dataenhed (LLC Protocol Data Unit (LPDU)), og er formateret som vist her:

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

DSAP-feltet

Destination Service Access Point (DSAP) identificerer den SAP, som LPDU’en er beregnet til. DSAP består af seks adressebits, en brugerbit (U) og en individuel/gruppebit (I/G), der er organiseret som vist her:

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

U-bitten angiver, om adressen er defineret af IEEE (1) eller brugerdefineret (0). I/G-bitten angiver, om SAP er en gruppeadresse (1) eller en individuel adresse (0). For vores formål er ingen af disse bits særlig vigtige. Det eneste, man behøver at vide, er, at DSAP er destinationen for LPDU’en. Nogle almindelige optræder igen og igen.

SSAP-felt

Source Service Access Point (SSAP) identificerer den SAP, som er ophavsmand til LPDU’en. SSAP består af seks adressebits, en brugerbit (U) og en Command/Response-bit (C/R), organiseret som vist her:

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

U-bitten angiver, om adressen er defineret af IEEE (1) eller brugerdefineret (0). C/R-bitten angiver, om LPDU’en er en kommando eller et svar. Når der modtages LPDU-rammer, betragtes C/R-bitten ikke som en del af SSAP’en. Derfor anses SSAP normalt kun for at være de syv bits længst til venstre.

Kontrolfelt

LPDU-kontrolfeltet indeholder oplysninger om kommando, svar og sekvensnummer. Du skal vide, hvordan du afkoder kontrolfeltet for at kunne bestemme, hvad der sker på en bestemt LLC2-session. Afkodningsoplysninger er dog let tilgængelige.

Der er tre typer af rammer:

• I Frames

• Supervisor Frames

• Unummererede Frames

Og selv om hver type har et andet format for kontrolfeltet, kan du let skelne dem fra hinanden ved at undersøge to bits i kontrolfeltet.

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

De næste par afsnit forklarer hver type kontrolfelt.

I-ramme

I-rammer gør det muligt at overføre sekventielt nummererede LPDU’er, der indeholder oplysninger (forbindelsesorienteret) mellem forbindelsesstationer. Formatet for I-rammen indeholder en NS og NR-tælling. NS-tællingen er sekvensnummeret (modulo 128) for den LPDU, der er under overførsel i øjeblikket. NR-tallet er sekvensnummeret for den næste LPDU I-ramme, som afsenderen forventer at modtage. For at hjælpe dig senere skal du huske, at NR betyder “næste modtagelse”.

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

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

P/F-bitten kaldes P-bitten i kommando-LPDU’er og F-bitten i svar-LPDU’er. P/F-bitten er sat i kommando-LPDU’er for at anmode om, at fjernforbindelsesstationen sender et svar med denne bit sat. Der må kun modtages ét svar med F-bitten indstillet for hver kommando, der sendes med P-bitten indstillet. Der er nogle andre detaljer om brugen af P/F-bitten i forbindelse med fejlgenoprettelse, men det er den generelle regel.

Supervisory Frame

Supervisory frames udfører tilsynsstyringsfunktioner, f.eks. for at kvittere for I Frames (RR), for at anmode om retransmission af I frames (REJ) og for at anmode om midlertidig suspension (RNR) af I frames. Overvågningsrammer indeholder ikke et informationsfelt. Derfor påvirker tilsynsrammer ikke NS i den afsendende station og indeholder derfor ikke et NS-felt. Her er formatet for en supervisionsramme:

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

S-bitsne “S” angiver typen af supervisionsramme.

• B’00’ = Receiver Ready

  En station bruger RR til at angive, at stationen er klar til at modtage, og indeholder NR-tallet for den næste I-ramme, som skal ankomme. Når en station sender en RR-ramme, bekræfter stationen modtagelse af nummererede I-rammer fra fjernstationen på op til NR – 1.

• B’01’=Receiver Not Ready

  En station bruger RNR til at angive, at stationen midlertidigt ikke er klar til at modtage. RNR indeholder også NR-tællingen, som følger de samme regler RR. Forbigående perioder med RNR’er er ikke altid tegn på et netværksproblem. Hvis RNR’er er vedvarende, skal man kigge efter overbelastning i slutstationen.

• B’10’=Reject

  En station bruger REJ til at anmode om retransmission af I frame LPDU’er, der begynder med det antal, der er angivet i NR-tællingen. REJ er ikke et tegn på et alvorligt problem (hvilket betyder, at det kan genoprettes). Hvis du ser mange REJ-kommandoer, skal du kigge efter manglende (tabte) I-rammer i den modsatte retning. Du må ikke forveksle en REJ med en Frame reject (FRMR). En FRMR er en unummereret frame og er altid et tegn på et alvorligt problem.

Unummererede rammer

Unummererede rammer giver link-kontrolfunktioner, f.eks. mode-indstillingskommandoer og -svar. I nogle tilfælde kan der også sendes unummererede informationsrammer. Unummererede rammer er kun én byte lange. De indeholder ikke felter for NR- eller NRS-tællinger. Her er formatet for en unummereret ramme:

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

Den “M”-bits angiver typen af unummereret ramme.

• B’00011’=DM-svar (0x1F)

  En linkstation sender et DM-svar for at rapportere, at den er i asynkron frakoblingstilstand. Dette betyder, at forbindelsen ikke er aktiv. Hvis en linkstation var aktiv og pludselig begynder at sende DM’er, er linkstationen sandsynligvis blevet nulstillet.

• B’01000’=DISC-kommando (0x53)

  En linkstation sender en DISC for at afslutte den asynkrone balancerede tilstand. DISC-kommandoen informerer den fjerne linkstation om, at den afbryder driften. Det korrekte svar på en DISC-kommando er en UA (hvis stationen er i ABM), eller en DM (hvis stationen er i ADM).

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

  En linkstation sender en UA som svar på SABME- og DISC-kommandoerne.

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

  En linkstation sender en SABME for at indlede dataoverførsel i asynkron balanceret tilstand. Det korrekte svar på en SABME er en UA. Når en station modtager en SABME-kommando, nulstiller stationen NR- og NS-tællingerne til nul. Den afsendende station gør det samme, når den modtager UA-svaret.

• B’10001’=FRMR-svar(0x87)

  En linkstation sender et Frame Reject-svar for at rapportere en fejl i en indgående LPDU fra den anden linkstation. Når du ser en FRMR, har den station, der sender FRMR, opdaget en fejl, der ikke kan genoprettes. Det er ikke årsagen til fejlen. Alle rammer, der ankommer, efter at FRMR-fejlen er opstået, ignoreres, indtil der modtages en DISC eller SABME.

  Et FRMR-svar indeholder oplysninger om årsagen til FRMR-tilstanden.

  Bytes 0 og 1 indeholder indholdet af kontrolfeltet i den LPDU, som forårsagede rammeafvisningen. Bytes 2 og 3 indeholder henholdsvis NS og NR tællingerne. Byte 4 indeholder flere bits, der identificerer fejltypen som vist her:

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

  V-bitten angiver, at det NS-nummer, der er indeholdt i kontrolfeltet i byte 0 og 1, er ugyldigt. Et NS er ugyldigt, hvis det er større end eller lig med det sidste NS plus den maksimale modtagervinduets størrelse. Når denne tilstand opstår, sender forbindelsesstationen en REJ LPDU, ikke et FRMR-svar.

  Z-bitten angiver, at den NR, som kontrolfeltet bærer angivet i byte 0 og 1, ikke henviser til hverken den næste I-ramme eller en I-ramme, der allerede er blevet transmitteret, men ikke er blevet kvitteret.

  Bemærk: Det er i orden at modtage den samme NR-tælling flere gange.

  NR-tællingen er kun ugyldig, hvis tællingen refererer til en I-ramme, der allerede er blevet kvitteret, eller hvis tællingen springer frem til en, der endnu ikke er blevet transmitteret. Førstnævnte er det mest almindelige tilfælde af denne type fejl. Når du ser denne type fejl, betyder det normalt, at rammene blev modtaget i forkert rækkefølge, og du bør lede efter det netværk, der leverer rammene i forkert rækkefølge. Det er muligt, at den afsendende linkstation har sendt dem i forkert rækkefølge, men det er meget usandsynligt.

  Y-bitten angiver, at længden af I-feltet i den modtagne LPDU har overskredet den tilgængelige bufferkapacitet. Hvis denne situation opstår, skal du lede efter problemer i slutstationerne, ikke i netværket.

  X-bitten angiver, at LPDU’en indeholdt et I-felt, når den ikke må have det, eller at der blev modtaget et FRMR-svar, som ikke indeholdt 5 bytes. Dette synes at være et slutstations- og ikke et netværksproblem.

  W-bitten angiver, at der er modtaget en LPDU, der ikke er understøttet. Dette er et slutstationsproblem.

• B’10111′ XID-kommando eller -svar

  En linkstation bruger XID-kommandoen til at formidle karakteristika for den afsendende knude og til at få den fjerne linkstation til at svare med et XID-svar. Linkstationer kan sende og modtage XID’er i forskellige formater, herunder SNA-formater.

• B’11100′ TEST-kommando eller -svar

  En linkstation sender TEST-kommandoen for at få den eksterne linkstation til at svare med et TEST-svar så hurtigt som muligt. TEST-kommandoen bruges generelt til stiopdagelse i et source-route bridging-miljø.

  

LLC-kontrolfeltoversigt

LLC2 Modes and Session Establishment

Der er to driftsformer for LLC2:

• Asynkron Balanced Mode Extended

• Asynkron Disconnect Mode

Asynchronous Balanced Mode Extended (ABME)

ABME er en balanceret driftstilstand mellem to linkstationer. Balanceret tilstand henviser til, at begge stationer til enhver tid kan sende kommandoer uafhængigt af den anden linkstation. Sammenlign dette med SDLC, som opererer i ubalanceret tilstand. I ubalanceret tilstand skal den sekundære station vente på at blive spurgt af den primære, før den kan sende data. Som følge af den balancerede tilstand forekommer der ikke polling på LLC2-kredsløb i traditionel forstand. En station sender keepalives for at opretholde sessionen, men det er ikke nødvendigt at sende disse ofte for at opnå optimal ydelse som i SDLC. Af denne grund er keepalive-timeren typisk 10 sekunder eller mere. Det er vigtigt at bemærke, at slutstationerne kan øge denne keepalive-timer for at reducere overhead. En forøgelse af keepalive-timeren har ingen negativ effekt på gennemløb eller svartid.

En station går ind i ABME, efter at stationen har sendt eller modtaget en UA to to to SABME-kommando. Når stationen er i ABME, kan den sende og modtage nummererede informationsrammer.

Asynchronous Disconnect Mode (ADM)

Hvor og efter en station afslutter ABME, er stationen i Asynchronous Disconnect Mode. I ADM er forbindelsen logisk afbrudt; derfor kan der ikke sendes nogen I-rammer eller overvågningsrammer. En station kan gå ind i ADM under disse betingelser:

• Modtagelse af en DISC-kommando

• Linkstationen er aktiveret

• Modtagelse af et DM-svar

• Retry-grænse er er er udtømt

Her er et eksempel på en aktiveringssekvens for en linkstation:

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

Stationer, der opererer i ASBM, har ikke en streng fornemmelse af primære eller sekundære stationer. Stationer har ikke brug for at blive pollet eller blive pollet for at overføre data. Stationerne kan overføre data til enhver station asynkront. Stationerne har peer-to-peer-forhold.

Selv om der ikke er nogen streng betydning af primær og sekundær, kræver en afsendende station et svar på forbindelsesniveau, kaldet en kvittering, fra den modtagende station for hver nummereret informationsramme, der sendes. En station kan fortsætte med at sende I-rammer til en anden station, indtil antallet af ubekræftede rammer når en grænse. Dette antal kaldes “vinduesstørrelsen” og er typisk som standard 7. Du kan øge vinduesstørrelsen på kredsløb, hvor der er stor latenstid, for at undgå, at den afsendende station skal stoppe og vente på et svar. Dette er normalt ikke nødvendigt, især i situationer, hvor LLC er lokalt bekræftet. Når en afsenderstation når sendevinduet, sætter stationen poll-bitten for at tvinge modtagerstationen til at sende et svar. I routeren kaldes vinduets størrelse llc2 local-window.

En modtagende station har mulighed for at tilbageholde kvitteringer, indtil enten et bestemt antal I-rammer ankommer eller en timer udløber. Disse parametre kaldes henholdsvis N3 og T2. På denne måde kan der kvitteres for flere rammer med én RR-ramme, eller der kan sendes en kvittering oven på en I-ramme. Cisco kalder N3-tælleren llc2 ack-max. Standardværdien tre angiver, at routeren tilbageholder en kvittering, indtil routeren modtager tre I-rammer, eller indtil T2-timeren, eller llc2 ack-delay-time, udløber.

Modifikation af disse parametre på en station uden hensyntagen til partnerstationen kan påvirke svartiden og gennemstrømningen. Overvej f.eks. hvad der ville ske, hvis den afsendende stations local-window er indstillet til 5, og den modtagende station har værdier på 7 for ack-max og 500 millisekunder for ack-delay-time.

I dette tilfælde sender den afsendende station fem rammer og venter derefter på en kvittering, før den fortsætter. Da modtageren tilbageholder kvitteringer, indtil der er modtaget syv rammer, sender den ikke en kvittering, før forsinkelsestiden på 500 millisekunder udløber. Du kan forbedre ydeevnen betydeligt, hvis du sænker ack-max-værdien på den modtagende station.

En anden almindelig LLC2-parameter kaldes Ti timeren. Routeren kalder denne for llc2 idle-time. Formålet med Ti timeren er at holde LLC2-sessionen aktiv i perioder, hvor der ikke sendes nogen I-rammer. Du kan ikke forbedre gennemstrømning og ydeevne, hvis du sænker denne værdi. Når Ti timeren udløber, sendes en RR-ramme med poll-bitten slået til for at fremkalde et svar fra modtageren. Hvis stationen ikke svarer, forsøges stationen igen efter llc2 tpf-time, indtil det antal gentagelser, der er defineret af llc2 n2, er udløbet. På det tidspunkt rives sessionen ned.

Forøg idle-tiden for at reducere mængden af overhead på et LLC2-kredsløb, og du kan justere dette som et alternativ til local ack. Overvej et eksempel, hvor 200 DSPU’er er forbundet til en NCP. Hver af PU’erne opretholder en uafhængig LLC2-session. Hvis hver enkelt sender en keepalive hvert tiende sekund, er der 20 rammer med overhead hvert sekund. Hvis man øger inaktivitetstiden til 30 sekunder, reduceres mængden af overheadrammer til 6,67 rammer pr. sekund. Ulempen ved denne fremgangsmåde er, at stationerne er længere tid om at opdage, at deres partner er utilgængelig. Men afhængigt af din situation kan dette være en god ting.

LLC2 Tunable Parameters

Du kan bruge kommandoen show llc til at se værdierne for disse parametre:

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

Eksempler på LLC2-parameterkonfigurationer

I et typisk DLSw+-netværk med et Token Ring LAN i begge ender foretages konfigurationen af LLC2-parametre på den udgående token ring-grænseflade.

Der er to separate LLC2-sessioner. Konfigurer derfor LLC2-parametre som vist her:

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

Bemærk: Disse skimtede konfigurationer viser kun relevante LLC2-parameterkonfigurationer.

LLC2-parameterkonfigurationer skal stemme overens med LLC2-parametrene til FEP’en (til DLSw1-routeren) og pc’en (til DLSw2-routeren). Når DLSw+-peeren på det centrale sted er på en CIP-router, er konfigurationen lidt anderledes.

Den eksterne DLSw+-routerkonfiguration forbliver uændret. LLC2-sessionen på det centrale sted er dog mellem CIP og LLC2-stakken i IOS. CIP’en repræsenterer mainframen, og LLC2-parametrene fra mainframen ud mod IOS er konfigureret under adapterne på LAN Token Ring (på CIP’en). LLC2-parametrene fra IOS til mainframen er konfigureret på den udgående grænseflade. Det vil sige grænsefladekanal x/2 (for CIP) og grænsefladekanal x/0 (for xCPA). f.eks.:

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

Bemærk: Disse skimtede konfigurationer viser kun relevante konfigurationer af LLC2-parametre.

Hvis CIP-routeren opretter forbindelse over LAN til en lokal station, har du kun brug for LLC2-parametrene under CIP-adapterne. LLC2-parametrene vil så blive afstemt med pc’ens parametre. Alle LLC2-parametre under grænsefladekanal 0/2 er ineffektive.

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

Bemærk: Disse skimtede konfigurationer viser kun relevante LLC2-parameterkonfigurationer.

Hvis enheder tilsluttes til DLSw+ via brogrupper, konfigureres LLC2-parametre på DLSWW+-brogruppe-erklæringen som vist her:

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

Bemærk: Disse skimmede konfigurationer viser kun relevante LLC2-parameterkonfigurationer.

Bemærk: Selv om du kan konfigurere LLC2 under ethernet 0-grænsefladen, har disse parametre ingen virkning. DLSw bridge-group LLC2 var ny i Cisco IOS Software Release 11.3.

Når routeren er konfigureret som en slutstation (f.eks. SNASw og DSPU), skal du konfigurere LLC2-parametrene på den udgående grænseflade. Bemærk, at ikke alle virtuelle grænseflader understøtter konfiguration af LLC2-parametre. F.eks:

Bemærk: Disse skimtede konfigurationer viser kun relevante konfigurationer af LLC2-parameterkonfigurationer.

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

LLC2-fejlbetingelser

Visse fejl på LLC2-sessioner er normale og kan genoprettes, f.eks. lejlighedsvis manglende rammer eller rammer i forkert rækkefølge. Disse resulterer normalt i en REJ og retransmitterede rammer. Overdrevne genudsendelser er ikke normale, og du skal identificere årsagen og løse problemet. Overdrevne retransmissioner kan forekomme på grund af tab, flere stier, overbelastning og for lang ventetid.

Nogle fejl i LLC2 kan ikke genoprettes og resulterer altid i et sessionssvigt. Disse fejl er udelukkende protokolbrud. De kan opstå, når stationer sender udefinerede kontrolfelter eller andre fejlagtige oplysninger. Disse protokolbrud kan få en station til at sende et FRMR-svar. Den station, der sender FRMR-svaret, er højst sandsynligt ikke krænkeren, men blot budbringeren. FRMR’en indeholder oplysninger, der identificerer, hvorfor FRMR’en sendes, hvilket oftest er, når en station anmoder en anden station om at sende en I-ramme igen, som den allerede har kvitteret for. Da stationen ikke kan sende rammen igen (fordi den allerede har kasseret den), har den intet andet valg end at afslutte LLC-sessionen. Når denne type fejl opstår, er den mest sandsynlige årsag, at rammene ikke er i den rigtige rækkefølge.