Understanding Logical Link Control

Introduction

IEEE standard 802.2 defines Logical Link Control (LLC) as a data link control layer used on 802.3, 802.5, and other networks. IBM ontwierp LLC oorspronkelijk als een sublayer in de IBM Token Ring architectuur.

Vereisten

Vereisten

Cisco beveelt aan dat u kennis heeft van deze onderwerpen:

• Een basiskennis van LLC

Gebruikte componenten

Dit document is niet beperkt tot specifieke software- en hardwareversies.

De informatie in dit document is gemaakt op basis van de apparaten in een specifieke lab-omgeving. Alle apparaten die in dit document zijn gebruikt, zijn gestart met een gewiste (standaard) configuratie.

Conventies

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Background Information

De LLC-laag biedt verbindingsloze en conectiegeoriënteerde gegevensoverdracht.

De verbindingsloze gegevensoverdracht wordt gewoonlijk aangeduid als LLC type 1, of LLC1. Bij verbindingsloze dienstverlening is het niet nodig dat er datalinks of verbindingsstations tot stand worden gebracht. Nadat een Service Access Point (SAP) is ingeschakeld, kan het SAP informatie verzenden naar en ontvangen van een SAP op afstand die ook verbindingsloze service gebruikt. Verbindingsloze service kent geen commando’s voor het instellen van modi (zoals SABME) en vereist niet dat statusinformatie wordt bijgehouden.

Connectiegeoriënteerde dataoverdracht wordt LLC type 2, of LLC2 genoemd. Verbindingsgeoriënteerde dienst vereist de totstandbrenging van verbindingsstations. Wanneer het verbindingsstation is opgericht, is een commando voor het instellen van de modus noodzakelijk. Daarna is elk linkstation verantwoordelijk voor het bijhouden van link-statusinformatie.

Implementaties van LLC

LLC2 wordt geïmplementeerd wanneer Systems Network Architecture (SNA) over een LAN of virtueel LAN loopt. LLC2 wordt ook rechtstreeks in Frame Relay ingekapseld. Soms geeft de router gewoon LLC2 frames door en soms implementeert de router een LLC2 linkstation. NetBIOS maakt ook gebruik van LLC. NetBIOS gebruikt LLC1 om een bron te lokaliseren. LLC2 connection-oriented sessions are then established.

The router implements an LLC2 stack when any of these features are enabled:

• Data-Link Switching (DLSw) (verbinding met LAN)

• Remote Source-Route Bridging (RSRB) met lokale ACK

• Channel Interface Processor (CIP)

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

• Synchrone Data Link Control (SDLC) naar LCC Conversie (SDLLC)

Basisinformatie die u moet weten om problemen op te lossen

Een basiskennis van LLC is voldoende om de meeste problemen te isoleren en op te lossen. Omdat er geen verbindingstoestanden of sessies zijn om te onderhouden, zijn problemen zeldzaam in LLC1.

In LLC2 kunnen zich twee categorieën problemen voordoen:

1. Sessies die niet tot stand komen

2. Gebruikte sessies die met tussenpozen mislukken

Om deze problemen op te lossen moet u deze onderwerpen kennen:

• LLC Frame Formats

• LLC2 Modes en Session Establishment

• LLC2 Asynchronous Balanced Mode Werking

• LLC2 Foutcondities

LLC Frame Formaten

Dit gedeelte geeft informatie over LLC frame formaten.

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

Een LLC frame wordt een LLC Protocol Data Unit (LPDU) genoemd, en is geformatteerd zoals hier getoond:

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

DSAP-veld

De Destination Service Access Point (DSAP) identificeert het SAP waarvoor de LPDU is bestemd. De DSAP bestaat uit zes adresbits, een gebruikersbit (U) en een individueel/groepsbit (I/G), georganiseerd zoals hier afgebeeld:

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

De U bit geeft aan of het adres is gedefinieerd door de IEEE (1) of door de gebruiker is gedefinieerd (0). De I/G bit geeft aan of het SAP een groepsadres (1) of een individueel adres (0) is. Voor onze doeleinden zijn geen van deze bits van groot belang. Het enige dat u echt hoeft te weten is dat de DSAP de bestemming van de LPDU is. Enkele veel voorkomende komen steeds weer terug.

SSAP Field

Het Source Service Access Point (SSAP) identificeert het SAP dat de LPDU heeft geïnitieerd. De SSAP bestaat uit zes adresbits, een gebruikersbit (U) en een commandoresponsbit (C/R), georganiseerd zoals hier afgebeeld:

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

De U bit geeft aan of het adres is gedefinieerd door de IEEE (1) of door de gebruiker is gedefinieerd (0). Het C/R-bit geeft aan of de LPDU een opdracht of een antwoord is. Wanneer LPDU-frames worden ontvangen, wordt het C/R-bit niet beschouwd als onderdeel van de SSAP. Daarom wordt de SSAP normaal gesproken beschouwd als alleen de meest linkse zeven bits.

Controleveld

Het LPDU-besturingsveld bevat informatie over commando’s, antwoorden en sequentienummers. U moet weten hoe u het besturingsveld moet decoderen om te bepalen wat er gebeurt op een bepaalde LLC2-sessie. Informatie over het decoderen is echter gemakkelijk beschikbaar.

Er zijn drie soorten frames:

• I Frames

• Supervisory Frames

• Unnumbered Frames

Hoewel elk type een ander formaat heeft voor het besturingsveld, kunt u ze gemakkelijk onderscheiden door een onderzoek van twee bits in het besturingsveld.

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 volgende paragrafen leggen elk type besturingsveld uit.

I Frame

I frames stellen u in staat om opeenvolgend genummerde LPDU’s over te brengen die informatie bevatten (verbindingsgericht) tussen verbindingsstations. Het formaat van het I-frame bevat een NS- en NR-telling. De NS-telling is het volgnummer (modulo 128) van de LPDU die op dat moment wordt verzonden. De NR-telling is het volgnummer van het volgende LPDU I-frame dat de verzender verwacht te ontvangen. Om u later te helpen, onthoud dat NR “volgende ontvangst” betekent.

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

Het P/F bit wordt het P bit genoemd in command LPDUs en het F bit in response LPDUs. Het P/F-bit wordt in opdracht-LPDU’s gezet om het externe linkstation te verzoeken een antwoord te zenden met dit bit gezet. Er mag slechts één antwoord worden ontvangen met het F-bit ingesteld voor iedere opdracht die is verzonden met het P-bit ingesteld. Er zijn nog enkele andere details over het gebruik van het P/F-bit in verband met foutherstel, maar dit is de algemene regel.

Supervisory Frame

Supervisory frames voeren toezichthoudende controlefuncties uit, bijvoorbeeld om I-frames te bevestigen (RR), om hertransmissie van I-frames te verzoeken (REJ), en om tijdelijke opschorting (RNR) van I-frames te verzoeken. Toezichtframes bevatten geen informatieveld. Daarom hebben toezichtframes geen invloed op de NS in het zendende station, en bevatten ze dus ook geen NS-veld. Hier volgt het formaat van een Supervisory frame:

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

De “S”-bits geven het type supervisory frame aan.

• B’00’ = Receiver Ready

  Een station gebruikt het RR om aan te geven dat het station klaar is om te ontvangen, en bevat het NR-getal van het volgende I-frame dat zal arriveren. Wanneer een station een RR frame verstuurt, bevestigt het station de ontvangst van genummerde I frames van het station op afstand van maximaal NR – 1.

• B’01’=Receiver Not Ready

  Een station gebruikt de RNR om aan te geven dat het station tijdelijk niet gereed is voor ontvangst. RNR bevat ook de NR-telling die dezelfde regels volgt als RR. Voorbijgaande periodes van RNR’s zijn niet altijd indicatief voor een netwerkprobleem. Als RNR’s aanhoudend zijn, zoek dan naar congestie bij het eindstation.

• B’10’=Reject

  Een station gebruikt de REJ om de hertransmissie aan te vragen van I frame LPDU’s beginnend met het nummer dat is aangegeven in de NR-telling. REJ is geen indicatie van een ernstig probleem (wat betekent dat het te herstellen is). Als u veel REJ-commando’s ziet, zoek dan naar ontbrekende (dropped) I-frames in de tegenovergestelde richting. Verwar een REJ niet met een Frame reject (FRMR). Een FRMR is een ongenummerd frame en is altijd een indicatie van een ernstig probleem.

Ongenummerde frames

Ongenummerde frames verschaffen link control functies, bijvoorbeeld mode setting commando’s en antwoorden. In sommige gevallen kunnen ook ongenummerde informatieframes worden verzonden. Ongenummerde frames zijn slechts één byte lang. Zij bevatten geen velden voor NR- of NRS-tellingen. Hier volgt het formaat van een ongenummerd frame:

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

De “M”-bits geven het type ongenummerd frame aan.

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

  Een link station zendt een DM response om te melden dat het in asynchrone disconnect mode is. Dit betekent dat de verbinding niet actief is. Als een link station actief was en plotseling DM’s begint te zenden, is het link station waarschijnlijk gereset.

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

  Een link station zendt een DISC om de asynchrone verbindingsmodus te beëindigen. De DISC-opdracht informeert het verafgelegen linkstation dat het de werking onderbreekt. Het juiste antwoord op een DISC-commando is een UA (als het station zich in ABM bevindt), of een DM (als het station zich in ADM bevindt).

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

  Een link station zendt een UA als antwoord op de SABME en DISC commando’s.

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

  Een link station zendt een SABME om data overdracht in asynchrone gebalanceerde modus te initiëren. Het juiste antwoord op een SABME is een UA. Wanneer een station een SABME-commando ontvangt, zet het station de NR- en NS-tellingen op nul. Het zendende station doet hetzelfde wanneer het een UA antwoord ontvangt.

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

  Een link station zendt een Frame Reject antwoord om een fout te melden in een binnenkomende LPDU van het andere link station. Wanneer u een FRMR ziet, heeft het station dat de FRMR verstuurt een onherstelbare fout ontdekt. Het is niet de oorzaak van de fout. Alle frames die aankomen nadat de FRMR-fout is opgetreden, worden genegeerd totdat een DISC of SABME wordt ontvangen.

  Een FRMR-antwoord bevat informatie over de oorzaak van de FRMR-conditie.

  Bytes 0 en 1 bevatten de inhoud van het controleveld van het LPDU dat de oorzaak was van de frame reject. Bytes 2 en 3 bevatten de NS- en NR-tellingen, respectievelijk. Byte 4 bevat een aantal bits die het soort fout aangeven, zoals hier wordt getoond:

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

  De V bit geeft aan dat het NS nummer dat door het controle veld in bytes 0 en 1 wordt meegevoerd ongeldig is. Een NS is ongeldig als het groter is dan of gelijk is aan de laatste NS plus de maximale ontvangstvenster grootte. Wanneer deze voorwaarde zich voordoet, zendt het verbindingsstation een REJ LPDU, geen FRMR antwoord.

  De Z bit geeft aan dat het NR dat het controleveld draagt aangegeven in bytes 0 en 1 niet verwijst naar ofwel het volgende I frame of een I frame dat reeds is verzonden maar niet is bevestigd.

  Opmerking: Het is in orde om dezelfde NR-telling meerdere malen te ontvangen.

  De NR-telling is alleen ongeldig als de telling verwijst naar een I frame dat al is bevestigd of als de telling vooruit springt naar een I frame dat nog niet is verzonden. De eerste is het meest voorkomende geval van dit soort fouten. Als u dit soort fouten ziet, betekent dit meestal dat frames niet op volgorde zijn ontvangen, en moet u op zoek naar het netwerk dat frames niet op volgorde aflevert. Het is mogelijk dat het zendende link station ze in een verkeerde volgorde heeft verzonden, maar dat is zeer onwaarschijnlijk.

  De Y-bit geeft aan dat de lengte van het I-veld in de ontvangen LPDU de beschikbare buffercapaciteit heeft overschreden. Als deze situatie zich voordoet, zoek dan naar problemen in de eindstations, niet in het netwerk.

  De X bit geeft aan dat de LPDU een I-veld bevatte terwijl dat niet het geval zou moeten zijn, of er is een FRMR antwoord ontvangen dat geen 5 bytes bevatte. Dit lijkt een eindstation probleem te zijn, niet een netwerk probleem.

  De W bit geeft aan dat een niet-ondersteunde LPDU is ontvangen. Dit is een eindstation probleem.

• B’10111′ XID Command or Response

  Een linkstation gebruikt het XID-commando om kenmerken van het zendende knooppunt over te brengen en om het verafgelegen linkstation te laten antwoorden met een XID-antwoord. Linkstations kunnen XID’s in diverse formaten verzenden en ontvangen, waaronder SNA-formaten.

• B’11100′ TEST Command or Response

  Een link station zendt het TEST commando om het remote link station zo snel mogelijk te laten antwoorden met een TEST antwoord. Het TEST-commando wordt in het algemeen gebruikt voor padontdekking in een bron-route-bridgingomgeving.

  

LLC Control-veld Samenvatting

LLC2 Modes en Session Establishment

Er zijn twee modi voor de werking van LLC2:

• Asynchrone Balanced Mode Extended

• Asynchrone Disconnect Mode

Asynchrone Balanced Mode Extended (ABME)

ABME is een gebalanceerde modus van de werking tussen twee link stations. Balanced mode verwijst naar het feit dat elk station op elk moment commando’s kan versturen, onafhankelijk van het andere link station. Dit in tegenstelling tot SDLC, dat in ongebalanceerde modus werkt. In de ongebalanceerde modus moet het secundaire station wachten tot het door het primaire station wordt opgeroepen voordat het gegevens kan verzenden. Als gevolg van de “balanced mode” komt “polling” niet voor op LLC2-circuits in de traditionele zin. Een station zendt wel keepalives om de sessie in stand te houden, maar het is niet nodig om deze frequent te zenden voor optimale prestaties zoals in SDLC. Om deze reden is de keepalive-timer gewoonlijk 10 seconden of meer. Het is belangrijk op te merken dat de eindstations deze keepalive timer kunnen verhogen om de overhead te verminderen. Een verhoging van de keepalive-timer heeft geen negatief effect op doorvoer of responstijd.

Een station komt in ABME nadat het station een UA to to SABME-commando heeft verzonden of ontvangen. In ABME kan het station genummerde informatieframes verzenden en ontvangen.

Asynchronous Disconnect Mode (ADM)

Voor en nadat een station ABME beëindigt, bevindt het station zich in Asynchronous Disconnect Mode. In ADM is de verbinding logisch verbroken; daarom kunnen geen I-frames of toezichtframes worden gezonden. Een station kan onder deze omstandigheden in ADM komen:

• Ontvangst van een DISC-commando

• Het linkstation is geactiveerd

• Ontvangst van een DM-antwoord

• Retry limit is exhausted

Hier volgt een voorbeeld van een activeringsvolgorde van een 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

Stations die in ASBM werken, hebben geen strikt besef van primaire of secundaire stations. Stations hoeven niet te pollen of gepolled te worden om gegevens over te dragen. Stations kunnen naar elk station asynchroon gegevens verzenden. Stations hebben peer-to-peer relaties.

Ondanks dat er geen strikte betekenis is van primair en secundair, heeft een zendend station voor elk verzonden genummerd informatieframe een antwoord op verbindingsniveau nodig, dat een bevestiging wordt genoemd van het ontvangende station. Een station kan doorgaan met het zenden van I-frames naar een ander station totdat het aantal niet bevestigde frames een limiet bereikt. Dit aantal wordt de “venstergrootte” genoemd en is standaard 7. Op circuits met veel wachttijd kan de venstergrootte worden vergroot om te voorkomen dat het zendende station moet stoppen en wachten op een antwoord. Dit is gewoonlijk niet nodig, vooral in situaties waarin LLC lokaal wordt bevestigd. Wanneer een zendend station het zendvenster bereikt, stelt het station het poll-bit in om het ontvangende station te dwingen een antwoord te zenden. In de router wordt de venstergrootte het llc2 local-window genoemd.

Een ontvangend station heeft de mogelijkheid om bevestigingen achter te houden totdat ofwel een bepaald aantal I frames arriveert ofwel een timer afloopt. Deze parameters worden respectievelijk N3 en T2 genoemd. Op deze manier kunnen meerdere frames worden bevestigd met één RR frame, of kan een bevestiging worden verzonden bovenop een I frame. Cisco noemt de N3 teller llc2 ack-max. De standaardwaarde van drie geeft aan dat de router een bevestiging achterhoudt totdat de router drie I-frames ontvangt, of totdat de T2-timer, of de llc2 ack-delay-time, afloopt.

Wijziging van deze parameters op een station zonder rekening te houden met het partnerstation kan de responstijd en doorvoer beïnvloeden. Bijvoorbeeld, wat zou er gebeuren als het zendende station local-window is ingesteld op 5 en het ontvangende station waarden heeft van 7 voor ack-max en 500 milliseconden voor ack-delay-time.

In dit geval verstuurt het zendende station vijf frames en wacht dan op een bevestiging voordat het verder gaat. Omdat de ontvanger geen ontvangstbevestigingen stuurt totdat zeven frames zijn ontvangen, zal deze pas een bevestiging sturen nadat de 500 milliseconden vertragingstijd is verstreken. U kunt de prestaties drastisch verbeteren door de ack-max waarde op het ontvangende station te verlagen.

Een andere veel voorkomende LLC2-parameter wordt de Ti timer genoemd. De router noemt dit de llc2 idle-time. Het doel van de Ti timer is om de LLC2 sessie actief te houden gedurende perioden dat er geen I frames worden verzonden. De doorvoer en prestaties kunnen niet worden verbeterd als deze waarde wordt verlaagd. Als de Ti timer afloopt, wordt een RR frame verzonden met het poll bit aan om een antwoord van de ontvanger te krijgen. Als het station niet reageert, wordt het station na llc2 tpf-time opnieuw geprobeerd totdat het aantal herhalingen gedefinieerd door llc2 n2 is verlopen. Op dat moment wordt de sessie afgebroken.

Verhoog de idle-tijd om de hoeveelheid overhead op een LLC2-circuit te verminderen en u kunt dit instellen als alternatief voor local ack. Beschouw een voorbeeld waar 200 DSPUs zijn aangesloten op een NCP. Elk van de PU’s onderhoudt een onafhankelijke LLC2 sessie. Als elk van hen elke tien seconden een keepalive verstuurt, zijn er elke seconde 20 frames aan overhead. Als de idle tijd wordt verhoogd tot 30 seconden, vermindert het aantal overhead frames tot 6.67 frames per seconde. Het nadeel van deze aanpak is dat stations er langer over doen om te ontdekken dat hun partner onbereikbaar is. Maar afhankelijk van uw situatie, kan dit een goede zaak zijn.

LLC2 Afstembare Parameters

U kunt het show llc commando gebruiken om de waarden van deze parameters te zien:

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

Voorbeelden van LLC2 Parameter Configuraties

In een typisch DLSw+ netwerk met een Token Ring LAN aan beide uiteinden, wordt de configuratie van LLC2 parameters gemaakt op de uitgaande token ring interface.

Er zijn twee afzonderlijke LLC2-sessies. Configureer daarom LLC2-parameters zoals hier getoond:

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

Opmerking: Deze afgeroomde configuraties tonen alleen relevante LLC2-parameterconfiguraties.

LLC2-parameterconfiguraties moeten overeenkomen met de LLC2-parameters naar de FEP (naar DLSw1-router) en PC (naar DLSw2-router). Wanneer de DLSw+ peer van de centrale site zich op een CIP-router bevindt, is de configuratie enigszins anders.

De configuratie van de DLSw+-router op afstand blijft ongewijzigd. De LLC2-sessie op de centrale locatie vindt echter plaats tussen de CIP en de LLC2-stack in IOS. De CIP vertegenwoordigt het mainframe, en de LLC2-parameters van het mainframe naar IOS worden geconfigureerd onder de adapters op de LAN Token Ring (op de CIP). De LLC2-parameters van IOS naar het mainframe worden geconfigureerd op de uitgaande interface. Dat wil zeggen, interface kanaal x/2 (voor CIP) en interface kanaal x/0 (voor xCPA).Bijvoorbeeld:

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

Opmerking: Deze afgeroomde configuraties tonen alleen relevante LLC2 parameter configuraties.

Als de CIP-router via het LAN verbinding maakt met een lokaal station, hebt u alleen de LLC2-parameters onder de CIP-adapters nodig. De LLC2-parameters worden dan afgestemd op die van de PC. Eventuele LLC2 parameters onder interface kanaal 0/2 zijn ineffectief.

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

Opmerking: Deze afgeroomde configuraties tonen alleen relevante LLC2 parameter configuraties.

Als apparaten via bridge-groepen verbinding maken met DLSw+, worden LLC2-parameters geconfigureerd op de DLSW+ bridge-groepsverklaring zoals hier getoond:

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

Opmerking: Deze afgeroomde configuraties tonen alleen relevante LLC2-parameterconfiguraties.

Opmerking: Hoewel u LLC2 onder de ethernet 0 interface kunt configureren, hebben deze parameters geen effect. DLSw bridge-group LLC2 was nieuw in Cisco IOS Software Release 11.3.

Wanneer de router is geconfigureerd als een eindstation (bijvoorbeeld SNASw en DSPU), moet u de LLC2-parameters configureren op de uitgaande interface. Merk op dat niet alle virtuele interfaces configuratie van LLC2 parameters ondersteunen. Bijvoorbeeld:

Opmerking: Deze afgeroomde configuraties tonen alleen relevante LLC2-parameterconfiguraties.

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

LLC2 Foutcondities

Enkele fouten op LLC2-sessies zijn normaal en herstelbaar, bijvoorbeeld af en toe gemiste frames of frames die niet in de juiste volgorde staan. Deze resulteren gewoonlijk in een REJ en heruitgezonden frames. Buitensporige hertransmissies zijn niet normaal, en u moet de oorzaak vaststellen en het probleem oplossen. Overtollige heruitzendingen kunnen voorkomen door drops, meerdere paden, congestie en overmatige latency.

Sommige fouten in LLC2 zijn niet te herstellen en resulteren altijd in een sessie onderbreking. Deze fouten zijn uitsluitend protocolovertredingen. Zij kunnen optreden wanneer stations ongedefinieerde besturingsvelden of andere foutieve informatie verzenden. Deze protocol schendingen kunnen ertoe leiden dat een station een FRMR antwoord stuurt. Het station dat het FRMR-antwoord verstuurt, is hoogstwaarschijnlijk niet de overtreder, maar slechts de boodschapper. De FRMR bevat informatie die aangeeft waarom de FRMR wordt verzonden, hetgeen meestal het geval is wanneer een station een ander station verzoekt een I-frame dat het al heeft bevestigd opnieuw te verzenden. Omdat het station het frame niet opnieuw kan zenden (omdat het het al heeft weggegooid), heeft het geen andere keus dan de LLC sessie te beëindigen. Wanneer dit type fout optreedt, is de meest waarschijnlijke oorzaak dat frames niet in de juiste volgorde zijn.