De standaard IEEE 802.2 definieert Logical Link Control (LLC) als een datalink-controlelaag die op 802.3, 802.5 en andere netwerken wordt gebruikt. IBM ontworpen LLC als sublaag in de IBM Token Ring-architectuur.
Cisco raadt kennis van de volgende onderwerpen aan:
Een basisbegrip van LLC
Dit document is niet beperkt tot specifieke software- en hardware-versies.
De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u de potentiële impact van elke opdracht begrijpen.
De LLC-laag biedt connectioneloze en op verbindingen gerichte gegevensoverdracht.
De connectioneloze gegevensoverdracht wordt algemeen aangeduid als LLC type 1 of LLC1. De dienst zonder verbindingen vereist niet dat u datalink of link stations instelt. Nadat een Service Access Point (SAP) is geactiveerd, kan SAP informatie naar en van een externe SAP verzenden en ontvangen die ook zonder verbinding werkt. De service zonder verbindingen heeft geen opdrachten voor het instellen van de modus (zoals SABME) en vereist niet dat de staatsinformatie behouden blijft.
De op verbinding gerichte gegevensoverdracht wordt aangeduid als LLC type 2 of LLC2. De op verbinding gerichte dienst vereist de oprichting van verbindingsstations. Wanneer het link station wordt geïnstalleerd, is een opdracht voor het instellen van de modus nodig. Daarna is elk link station verantwoordelijk voor het onderhouden van informatie over de verbindingsstaat.
LLC2 wordt geïmplementeerd wanneer Systems Network Architecture (SNA) via een netwerk of virtueel LAN verloopt. LLC2 wordt ook direct ingekapseld in Frame Relay. Soms passeert de router eenvoudigweg LC2 frames door en soms implementeert de router een LLC2 linkstation. Netopgemerkt ook: LLC. NetReset gebruikt LLC1 om een resource te vinden. LLC2 op verbindingen gerichte sessies worden dan opgezet.
De router implementeert een LLC2 stack wanneer een van deze functies is ingeschakeld:
Data-Link Switching (DLSw) (verbinding met LAN)
Remote Source-Route Bridging (RSRB) met lokale ACK
Kanaalinterfaceprocessor (CIP)
Geavanceerde peer-to-peer netwerken (SNASwitching)
Synchronous Data Link Control (SDLC) naar LCC Conversion (SDLLC)
Een basiskennis van LLC is genoeg om de meeste problemen te isoleren en op te lossen. Omdat er geen verbindingsstaten of sessies te onderhouden zijn, zijn problemen zeldzaam in LLC1.
In LLC2 kunnen twee categorieën problemen voorkomen:
Sessies die niet vastzitten
Vastgestelde sessies die periodiek falen
Om deze problemen op te lossen moet u over deze onderwerpen weten:
LLC-frame-formaten
LLC2-modi en -sessieinstelling
LLC2 asynchrone gebalanceerde werking
LLC2-foutenvoorwaarden
Deze sectie verschaft informatie over LLC frame-formaten.
DSAP/SAP | Beheer | |||
---|---|---|---|---|
Access point voor doelservices (1 bytes) | Control-veld - ongenummerd (1 bytes) | |||
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 |
Access Point voor bronservices (1 bytes) | Bedieningsveld - Toezicht ( 2 bytes ) | |||
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 |
Bedieningsveld - Informatiesoframes (2 bytes) | ||||
ssss sss0 |
xxxx |
Information format |
||
P = Poll bit ingesteld op "1" F = Eindbit ingesteld op "1" Z = Poll/Final bit ingesteld op "0" of "1" |
Een LLC-kader wordt een LLC Protocol Data Unit (LPDU) genoemd en wordt geformatteerd zoals hier wordt getoond:
DSAP (1 byte)-SSAP (1 byte)-Control Field (1 or 2 bytes)-Information Field (0 or more bytes)
Het Access Point of Destination Service (DSAP) identificeert de SAP waarvoor de LPDU is bedoeld. DSAP bestaat uit zes adresbits, een gebruikersbit (U) en een Individual/Group (I/G) bit, georganiseerd zoals hieronder wordt getoond:
D-D-D-D-D-D-D-I/G
Het U-bit geeft aan of het adres is gedefinieerd door de IEEE (1) of door de gebruiker gedefinieerd (0). Het I/G-bit geeft aan of SAP een groepsadres (1) of een individueel adres (0) is. Voor ons doel zijn geen van deze bits te belangrijk. Alles wat je echt hoeft te weten, is dat de DSAP de bestemming van de LPDU is. Een aantal vaak voorkomende komen steeds weer voor.
Het Source Service Access Point (SSAP) identificeert SAP die aan de LPDU is begonnen. SSAP bestaat uit zes adresbits, een gebruikersbit (U) en een commando/Response (C/R) bit, georganiseerd zoals hieronder wordt getoond:
S-S-S-S-S-S-U-C/R
Het U-bit geeft aan of het adres is gedefinieerd door de IEEE (1) of door de gebruiker gedefinieerd (0). Het C/R-bit geeft aan of de LPDU een opdracht of een respons is. Wanneer LPDU-frames worden ontvangen, wordt het C/R-bit niet beschouwd als deel van de SSAP. Daarom wordt het SSAP normaal beschouwd als slechts de laatste zeven bits.
Het LPDU-controleveld bevat opdracht, respons en informatie over het sequentienummer. U moet weten hoe u het controleveld kunt decoderen om te bepalen wat er op een bepaalde LLC2-sessie gebeurt. Er is echter gemakkelijk informatie over decodering beschikbaar.
Er zijn drie typen frames:
I frames
Toezichtframes
Ongenummerde frames
Hoewel elk type een ander formaat voor het controleveld heeft, kunt u dit gemakkelijk onderscheiden door een onderzoek van twee bits in het controleveld.
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
In de volgende paar secties wordt elk type controleveld uitgelegd.
Met IP-frames kunt u sequentieel genummerde LPDU's overdragen die informatie (op verbinding gericht) bevatten tussen de link stations. Het formaat van het I frame bevat een NS- en NR-telling. De NS-telling is het sequentienummer (modulo 128) van de LPDU die momenteel wordt doorgegeven. De NR-telling is het sequentienummer van het volgende LPDU I-frame dat de zender verwacht te ontvangen. Om je later te helpen, bedenk dan dat NR betekent "Volgende ontvangen".
NS-NS-NS-NS-NS-NS-NS-0-NR-NR-NR-NR-NR-NR-P/F
Het P/F-bit wordt het P-bit in opdracht LPDU's genoemd en het F-bit in reactie-LPDU's. Het P/F-bit is ingesteld in opdracht LPDU's om aan te vragen dat het externe link station een reactie met deze bit set verstuurt. Slechts één reactie moet ontvangen worden met het F bit set voor elke opdracht verzonden met het P bit set. Er zijn nog wat details over het gebruik van het P/F-bit in relatie tot foutenterugwinning, maar dat is de algemene regel.
Toezichtsframes vervullen toezichthoudende controlefuncties, bijvoorbeeld om I Frames (RR) te erkennen, om hertransmissie van I frames (REJ) aan te vragen en om tijdelijke opschorting (RNR) van I frames. Toezichtsframes bevatten geen informatieveld. Daarom hebben toezichtkaders geen invloed op de NS in het verzendende station en bevatten zij dus geen NS-veld. Dit is de vorm van een toezichtkader:
0-0-0-0-S-S-0-1-NR-NR-NR-NR-NR-NR-NR-P/F
De "S" - bits geven het soort toezichtkader aan.
B'00' = Ontvanger Klaar
Een station gebruikt de RR om aan te geven dat het station klaar is om te ontvangen en bevat de NR telling van het volgende I frame dat zal aankomen. Wanneer een station een RR frame verstuurt, geeft het station een ontvangstbevestiging van genummerde I beelden van het afgelegen station van maximaal NR - 1.
B'01'=ontvanger niet klaar
Een station gebruikt de RNR om aan te geven dat het station tijdelijk niet klaar is om te ontvangen. RNR bevat ook de NR-telling volgens dezelfde regels RR. Tijdelijke periodes van RNR's zijn niet altijd kenmerkend voor een netwerkprobleem. Als RNR's hardnekkig zijn, zoek dan naar congestie op het eindstation.
B'10'=Afwijzen
Een station gebruikt de REJ om de hertransmissie van LPDU's van het I-frame te vragen te beginnen met het nummer dat in de NR-telling wordt aangegeven. REJ wijst niet op een ernstig probleem (wat betekent dat het kan worden hersteld). Als je veel REJ opdrachten ziet, zoek dan naar ontbrekende (ingetrokken) I beelden in de tegenovergestelde richting. Verwar een REJ niet met een Frame Relay Wist (FRMR). Een FRMR is een ongenummerd kader en wijst altijd op een ernstig probleem.
Ongenummerde frames bieden functies voor link, bijvoorbeeld opdrachten voor mode-instelling en responsen. In sommige gevallen kunnen ook niet-genummerde informatiekaders worden verzonden. Ongenummerde frames zijn slechts één bytes in lengte. Ze bevatten geen velden voor NR- of NRS-tellingen. Dit is het formaat van een niet-genummerd kader:
M-M-M-P/F-M-M-1-1
De "M" bits geven het type ongenummerd frame aan.
B'00011'=DM-respons (0x1F)
Een verbindingsstation stuurt een DM antwoord om te melden dat het in asynchrone ontkoppelingsmodus is. Dit betekent dat de link niet actief is. Als een link station actief was en plotseling DM's begint te verzenden, is het link station waarschijnlijk gereset.
B'01000'=DISK Opdracht (0x53)
Een link station stuurt een DISK om asynchrone gebalanceerde modus te beëindigen. De opdracht DISK informeert het afstandsbediening die de werking opschort. De juiste reactie op een DISK-opdracht is een UA (indien het station in ABM is) of een DM (indien het station in ADM is).
B'01100'=UA-respons(0x73)
Een link station stuurt een UA in antwoord op de opdrachten SABME en DISK.
B'0111'=SABME-opdracht(0x7F)
Een link station verstuurt een SABME om gegevensoverdracht in asynchrone gebalanceerde modus te initiëren. De juiste reactie op een SABME is een UA. Wanneer een station een SABME-opdracht ontvangt, stelt het station de NR- en NS-tellingen op nul. Het verzendende station doet hetzelfde wanneer het de UA-reactie ontvangt.
B'10001'=FRMR-respons(0x87)
Een link station verstuurt een antwoord van Frame Relay om een fout in een inkomende LPDU van het andere link station te melden. Wanneer u een FRMR ziet, heeft het station dat de FRMR verstuurt een fout ontdekt die niet kan worden hersteld. Het is niet de oorzaak van de fout. Alle frames die aankomen nadat de FRMR-fout is opgetreden, worden genegeerd totdat een DISK of SABME is ontvangen.
Een FRMR-respons bevat informatie over de oorzaak van de FRMR-aandoening.
Bytes 0 en 1 bevatten de inhoud van het controleveld van de LPDU die het frame heeft verworpen. Bytes 2 en 3 bevatten respectievelijk de NS- en NR-tellingen. Byte 4 bevat verscheidene bits die het type fout zoals hieronder wordt getoond identificeren:
0-0-0-V-Z-Y-W-X
Het V-bit geeft aan dat het NS-nummer dat in bytes 0 en 1 door het controleveld wordt meegevoerd, ongeldig is. Een NS is ongeldig als deze groter is dan of gelijk is aan de laatste NS plus de maximale grootte van het ontvangstvenster. Wanneer deze voorwaarde zich voordoet, stuurt het link station een REJ LPDU, niet een FRMR-respons.
Het Z bit geeft aan dat het NR dat het controleveld bevat dat aangegeven wordt in bytes 0 en 1, niet verwijst naar het volgende I frame of een I frame dat al is verzonden maar niet wordt erkend.
Opmerking: Het is goed om dezelfde NR-telling meerdere malen te ontvangen.
De NR-telling is alleen ongeldig als de tellingen en het I-kader die al zijn erkend of als het tellen vooruitloopt op een getal dat nog niet is doorgegeven. Het eerste is het meest voorkomende geval van dit soort fouten. Wanneer je dit soort fout ziet, betekent het meestal dat er frames uit de sequentie werden ontvangen, en je zou moeten zoeken naar het netwerk dat frames uit volgorde aflevert. Het is mogelijk dat het verzendende link station ze buiten werking heeft gesteld, maar zeer onwaarschijnlijk.
Het 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, kijk dan naar problemen op de eindstations en niet het netwerk.
Het X-bit geeft aan dat de LPDU een I-veld bevat wanneer dit niet moet hebben, of dat er een FRMR-reactie is ontvangen die niet 5 bytes bevat. Dit lijkt een eindstationprobleem te zijn, geen netwerkprobleem.
Het W-bit geeft aan dat een niet-ondersteunde LPDU is ontvangen. Dit is een probleem van de eindstations.
B'1011' XID commando of respons
Een link station gebruikt de XID-opdracht om de kenmerken van het verzendende knooppunt over te brengen en om het externe link station ertoe te brengen te reageren met een XID-respons. Link-stations kunnen XID’s in verschillende indelingen verzenden en ontvangen, inclusief SNA-indelingen.
B'11100' TESTopdracht of -respons
Een link station stuurt de TEST opdracht om het afstandsverbindingsstation zo snel mogelijk te laten reageren met een TEST-respons. De opdracht TEST wordt over het algemeen gebruikt voor het opsporen van pad in een bron-route-overbruggingsomgeving.
Waarde | Ongenummerde frames |
---|---|
0x0F of 0x1F | Respons in disconnect-modus (DM) |
0x43 of 0x53 | Opdracht verbroken (DISK) |
0x63 of 0x73 | Ongenummerde antwoord op erkenning (UA) |
0x6F of 0x7F | Opdracht Asynchronous Balanced Mode (SABME) instellen |
0x87 of 0x97 | Frame Relay-respons (FRMR) |
0xAF of 0xBF | Opdracht of respons voor exchange-ID (XID) |
0xE3 of 0xF3 | Opdracht of respons van de test (TEST) |
Waarde | Toezichtframes |
---|---|
0x01 | Klaar voor ontvanger (RR) |
0x05 | Ontvanger niet klaar (RNR) |
0x09 | Afwijzen (REJ) |
Waarde | Informatieframes |
---|---|
0bnnnnnnnn0 | Informatieframe (INFO) |
Er zijn twee modi van LLC2:
Uitgebreide asynchrone gebalanceerde modus
Asynchrone ontkoppelingsmodus
ABME is een gebalanceerde manier van werken tussen twee verbindingsstations. De gebalanceerde modus verwijst naar het feit dat een van de stations op elk moment opdrachten kan verzenden, onafhankelijk van het andere link station. Contrast dit met SDLC, dat in ongebalanceerde modus werkt. In ongebalanceerde modus moet het secondaire station wachten om door het primaire station te worden gepolst voordat het gegevens kan versturen. Als resultaat van een gebalanceerde werking komen er geen opiniepeilingen voor op LLC2-circuits in de traditionele zin van het woord. Een station stuurt geen keepalives om de sessie te onderhouden, maar het is niet nodig om deze regelmatig te versturen voor optimale prestaties zoals in SDLC. Om deze reden is de timer voor het behouden normaal 10 seconden of groter. Het is belangrijk om op te merken dat de eindstations deze timer kunnen verhogen om de overhead te verminderen. Een grotere timer heeft geen negatief effect op doorvoersnelheid of responstijd.
Een station komt ABME in nadat het station UA naar SABME-opdracht verstuurt of ontvangt. Wanneer in ABME, kan het station genummerde informatiekaders verzenden en ontvangen.
Voor en nadat een station ABBYY beëindigt, bevindt het station zich in de asynchrone verbindingsmodus. In ADM is de link logisch losgekoppeld; Daarom kunnen er geen I-frames of toezichtkaders worden verstuurd. Een station kan onder deze voorwaarden ADM invoeren:
Ontvang een DISK-opdracht
Het linkstation is geactiveerd
Ontvangst van een DM-antwoord
De limiet opnieuw instellen is bereikt
Hier is een voorbeeld van een activeringssequentie van een link station:
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 ...
Stations die in ASBM werken hebben geen strikt gevoel voor primaire of secundaire stations. Stations hoeven niet te vragen of te worden gepolst om gegevens over te dragen. Stations kunnen gegevens asynchroon naar elk station verzenden. Stations hebben peer-to-peer relaties.
Hoewel er geen strikt gevoel is voor primair en secundair, vereist een verzendend station een reactie op het verbindingsniveau genaamd een erkenning van het ontvangende station voor elk genummerd informatiekader dat wordt verstuurd. Een station kan I frames naar een ander station blijven doorgeven totdat het aantal niet-erkende frames een limiet bereikt. Dit getal wordt de "venstergrootte" genoemd en is standaard ingesteld op 7. U kunt de venstergrootte vergroten op circuits waar er veel vertraging is om te voorkomen dat het verzendende station moet stoppen en wachten op een reactie. Dit is meestal niet nodig, vooral in situaties waar LLC lokaal wordt erkend. Wanneer een verzendend station het verzendvenster bereikt, stelt het station het poll-bit in om het ontvangende station te dwingen een reactie te sturen. In de router, wordt de venstergrootte genoemd LCC2 lokaal-venster.
Een ontvangststation heeft de optie om ontvangstbewijzen in te houden tot een bepaald aantal I frames aankomen of een timer afloopt. Deze parameters worden respectievelijk N3 en T2 genoemd. Op deze manier kunnen meerdere frames worden herkend met één RR-frame, of kan er een ontvangstbevestiging bovenop een I-frame worden verzonden. Cisco roept de N3 teller LLC2 ack-max aan. De standaardwaarde van drie wijst erop dat de router een erkenning onthoudt tot de router drie I frames ontvangt, of tot de T2 timer, of de llc2 ack-vertraagde tijd, verlopen.
Wijziging van deze parameters op een station zonder rekening te houden met het partnerstation kan de responstijd en doorvoersnelheid beïnvloeden. Bedenk bijvoorbeeld wat er zou gebeuren als het lokale venster van het verzendende station op 5 is ingesteld en het ontvangende station waarden van 7 voor ack-max en 500 milliseconden heeft voor ack-vertraagde tijd.
In dit geval stuurt het verzendende station vijf frames af en wacht vervolgens op een bevestiging voordat u doorgaat. Omdat de ontvanger ontvangstbevestiging inhoudt tot zeven frames ontvangen zijn, zal het geen ontvangstbevestiging sturen tot de 500 milliseconde vertragingstijd vervalt. U kunt de prestaties drastisch verbeteren als u de ack-max waarde op het ontvangende station verlaagt.
Een andere algemene LLC2 parameter wordt de timer genoemd. De router roept dit de lokale tijd inactief. Het doel van de Ti-timer is de LLC2-sessie actief te houden tijdens perioden waarin geen I-frames worden verzonden. U kunt de doorvoersnelheid en prestaties niet verbeteren als u deze waarde verlaagt. Wanneer de timer verloopt, wordt een RR-frame verzonden met het poll-bit om een reactie van de ontvanger te veroorzaken. Als het station niet reageert, wordt het station na llc2 tpf-tijd opnieuw beproefd totdat het aantal heraanvallen is verlopen dat door llc2 n2 is gedefinieerd. Op dat moment is de bijeenkomst afgebroken.
Vergroot de stille tijd om de hoeveelheid overhead op een LLC2-circuit te verminderen en u kunt dit als alternatief voor een lokale rack aanpassen. Neem een voorbeeld waar 200 DSPU's verbonden zijn met een NCP. Elk van de PU's onderhoudt een onafhankelijke LLC2-sessie. Als iedereen elke tien seconden een keeplevend versturen, zijn er elke seconde 20 beelden van overhead. Als u de ongebruikte tijd tot 30 seconden verhoogt, wordt de hoeveelheid overheadframes beperkt tot 6,67 frames per seconde. Het nadeel van deze benadering is dat stations er langer over doen om te ontdekken dat hun partner onbereikbaar is. Maar afhankelijk van uw situatie zou dit een goede zaak kunnen zijn.
Opdracht | Standaard | Beschrijving |
---|---|---|
LC2-vertragingstijd>/b> sec | 100 | De hoeveelheid tijd om op een antwoord te wachten alvorens een ontvangstbevestiging te verzenden wanneer de ack-max waarde niet is bereikt. |
llc2-rack-max-aantal | 3 beelden | Het aantal frames dat moet worden ontvangen voordat u een ontvangstbevestiging verstuurt. |
LC2-sec in onactieve tijd | 10000 | De hoeveelheid tijd tussen de opiniepeilingen tijdens ongebruikte perioden. |
llc2-telling voor de lokale venster | 7 beelden | Het aantal beelden dat moet worden verzonden alvorens op een antwoord te wachten. |
llc2 n2-telling | 8 herhalingen | Het aantal keren dat ik geen frames of peilingen heb opgegeven, wordt verstuurd zonder een antwoord te ontvangen vóór de beëindiging van de sessie. |
LC2 t1-tijd msec | 1000 | De hoeveelheid tijd om op een antwoord te wachten alvorens I frames door te zetten. Deze tijd moet groot genoeg zijn om de rondreisvertraging op te vangen. |
LC2-tijd msec | 9600 | De hoeveelheid tijd om te wachten voordat u een station gaat stemmen die een RNR heeft verstuurd. Verandert de waarde slechts om de waarde voor stations te verhogen die ongewoon lange, drukke periodes hebben alvorens zij hun status ontruimen. |
LC2 tpf-tijd msec | 1000 | De hoeveelheid tijd om op een definitieve reactie te wachten alvorens het opiniekader te herstellen. |
LC2 trej-tijd msec | 3200 | De hoeveelheid tijd om op een correct kader te wachten na het verzenden van een REJ. |
U kunt de opdracht Show Lc gebruiken om de waarden van deze parameters te zien:
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
In een typisch DLSw+ netwerk met een Token Ring LAN aan beide eind, wordt de configuratie van LLC2 parameters gemaakt op de uitgaande token ring interface.
Er zijn twee afzonderlijke LLC2 sessies. Configureer daarom de LLC2-parameters zoals hier wordt getoond:
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
Opmerking: Deze onderste configuraties tonen alleen de relevante LLC2-parameterconfiguraties.
LLC2-parameterconfiguraties moeten de LLC2-parameters aan de FEP (op DLSw1-router) en PC (op DLSw2-router) aanpassen. Wanneer de centrale plaats DLSw+ peer op een CIP router is, is de configuratie iets anders.
De externe DLSw+-routerconfiguratie blijft ongewijzigd. Maar de LLC2 sessie op de centrale site is tussen de CIP en de LLC2 stack in IOS. CIP vertegenwoordigt de infrastructuur en de LLC2-parameters van de Mainframe naar IOS worden geconfigureerd onder de adapters op LAN Token Ring (op het CIP). De LLC2-parameters van IOS naar de infrastructuur worden op de uitgaande interface geconfigureerd. Dat wil zeggen, interfacekanaal x/2 (voor CIP) en interfacekanaal x/0 (voor xCPA).Bijvoorbeeld:
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
Opmerking: Deze onderste configuraties tonen alleen de relevante LLC2-parameterconfiguraties.
Als de CIP-router via een LAN op een lokaal station wordt aangesloten, hebt u alleen de LLC2-parameters nodig onder de CIP-adapters. De LLC2-parameters zouden dan worden aangepast aan die van de PC. Alle LLC2-parameters onder interfacekanaal 0/2 zijn niet effectief.
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
Opmerking: Deze onderste configuraties tonen alleen de relevante LLC2-parameterconfiguraties.
Als apparaten via bruggroepen in DLSw+ worden aangesloten, worden LLC2-parameters ingesteld op de DLSW+ bridge-group statement zoals hier wordt getoond:
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
Opmerking: Deze onderste configuraties tonen alleen de relevante LLC2-parameterconfiguraties.
Opmerking: Hoewel u LLC2 kunt configureren onder de Ethernet 0 interface, hebben deze parameters geen effect. DLSw bridge-group LLC2 was nieuw in Cisco IOS-softwarerelease 11.3.
Wanneer de router als een end-station (bijvoorbeeld SNASw en DSPU) wordt geconfigureerd, moet u de LLC2-parameters op de uitgaande interface configureren. Merk op dat niet alle virtuele interfaces configuratie van LLC2-parameters ondersteunen. Bijvoorbeeld:
Opmerking: Deze onderste configuraties tonen alleen de relevante LLC2-parameterconfiguraties.
hostname snasw1 ! Interface fastethernet 0/0 llc2 tpf-timer 2000 llc2 n2 20 ! snasw cpname neta.snasw1 snasw port FASTETH0 FastEthernet0/0 conntype nohpr
Sommige fouten op LLC2 sessies zijn normaal en herstelbaar, bijvoorbeeld, incidenteel gemiste frames of frames buiten volgorde. Deze resulteren meestal in een REJ en opnieuw uitgezonden frames. Buitensporige teruggaven zijn niet normaal en je moet de oorzaak identificeren en de kwestie oplossen. Excessieve terugzenders kunnen optreden door druppels, meerdere paden, congestie en buitensporige vertraging.
Sommige fouten in LLC2 kunnen niet worden hersteld en resulteren altijd in een sessiestoring. Deze fouten zijn uitsluitend protocolschendingen. Ze kunnen voorkomen wanneer stations niet-gedefinieerde besturingsvelden of andere verkeerde informatie verzenden. Deze protocolschendingen kunnen een station ertoe aanzetten een FRMR-respons te sturen. Het station dat de reactie van de FRMR verstuurt is waarschijnlijk niet de overtreder, maar alleen de boodschapper. De FRMR bevat informatie die identificeert waarom de FRMR wordt verzonden, wat het meest gebruikelijk is wanneer een station een ander station vraagt om een I-frame te herhalen dat het al heeft erkend. Omdat het station het frame niet kan opnieuw verzenden (omdat het al is weggegooid) heeft het geen andere keuze dan de LLC-sessie te beëindigen. Wanneer dit type fout optreedt, is de meest waarschijnlijke oorzaak dat frames niet in orde zijn.