Understanding Logical Link Control

Introduction

Der IEEE-Standard 802.2 definiert Logical Link Control (LLC) als Data Link Control Layer, der in 802.3, 802.5 und anderen Netzwerken verwendet wird. IBM hat LLC ursprünglich als Unterschicht in der IBM Token Ring-Architektur entwickelt.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse zu folgenden Themen verfügen:

• Grundlegendes Verständnis von LLC

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardwareversionen beschränkt.

Die Informationen in diesem Dokument wurden mit den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte wurden mit einer gelöschten (Standard-)Konfiguration gestartet. Wenn Ihr Netzwerk in Betrieb ist, vergewissern Sie sich, dass Sie die potenziellen Auswirkungen jedes Befehls verstehen.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie in den Cisco Technical Tips Conventions.

Hintergrundinformationen

Die LLC-Schicht bietet verbindungslose und verbindungsorientierte Datenübertragung.

Die verbindungslose Datenübertragung wird gemeinhin als LLC Typ 1 oder LLC1 bezeichnet. Für den verbindungslosen Dienst ist es nicht erforderlich, Datenverbindungen oder Verbindungsstationen aufzubauen. Nachdem ein Service Access Point (SAP) aktiviert wurde, kann der SAP Informationen an einen entfernten SAP, der ebenfalls den verbindungslosen Dienst nutzt, senden und von ihm empfangen. Der verbindungslose Dienst verfügt über keine Befehle zur Einstellung des Modus (wie SABME) und erfordert nicht, dass Zustandsinformationen gepflegt werden.

Die verbindungsorientierte Datenübertragung wird als LLC Typ 2 oder LLC2 bezeichnet. Der verbindungsorientierte Dienst erfordert die Einrichtung von Link-Stationen. Wenn die Link-Station eingerichtet ist, ist ein Befehl zur Moduseinstellung erforderlich. Danach ist jede Link-Station für die Aufrechterhaltung der Verbindungsstatusinformationen verantwortlich.

Implementierungen von LLC

LLC2 wird immer dann implementiert, wenn die Systems Network Architecture (SNA) über ein LAN oder virtuelles LAN läuft. LLC2 wird auch direkt in Frame Relay eingekapselt. Manchmal leitet der Router LLC2-Frames einfach weiter, manchmal implementiert er eine LLC2-Linkstation. NetBIOS verwendet ebenfalls LLC. NetBIOS verwendet LLC1, um eine Ressource zu lokalisieren. LLC2 verbindungsorientierte Sitzungen werden dann aufgebaut.

Der Router implementiert einen LLC2-Stack, wenn eine dieser Funktionen aktiviert ist:

• Data-Link Switching (DLSw) (Verbindung zum LAN)

• Remote Source-Route Bridging (RSRB) mit lokalem ACK

• Channel Interface Processor (CIP)

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

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

Grundlegende Informationen, die Sie für die Fehlersuche kennen müssen

Grundlegende Kenntnisse über LLC reichen aus, um die meisten Probleme zu isolieren und zu lösen. Da es keine Verbindungszustände oder Sitzungen zu verwalten gibt, sind Probleme bei LLC1 selten.

Bei LLC2 können zwei Kategorien von Problemen auftreten:

1. Sitzungen, die nicht aufgebaut werden

2. Aufgebaute Sitzungen, die zeitweise ausfallen

Um diese Probleme zu lösen, müssen Sie diese Themen kennen:

• LLC-Rahmenformate

• LLC2-Modi und Sitzungsaufbau

• LLC2 Asynchronous Balanced Mode Betrieb

• LLC2-Fehlerbedingungen

LLC-Rahmenformate

Dieser Abschnitt enthält Informationen zu LLC-Rahmenformaten.

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

Ein LLC-Frame wird als LLC Protocol Data Unit (LPDU) bezeichnet, und ist wie hier gezeigt formatiert:

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

DSAP Feld

Der Destination Service Access Point (DSAP) identifiziert den SAP, für den die LPDU bestimmt ist. Der DSAP besteht aus sechs Adressbits, einem Benutzerbit (U) und einem Einzel-/Gruppenbit (I/G), die wie folgt angeordnet sind:

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

Das U-Bit zeigt an, ob die Adresse vom IEEE (1) oder vom Benutzer (0) definiert ist. Das I/G-Bit gibt an, ob es sich bei der SAP um eine Gruppenadresse (1) oder eine Einzeladresse (0) handelt. Für unsere Zwecke sind diese beiden Bits nicht besonders wichtig. Alles, was Sie wissen müssen, ist, dass der DSAP das Ziel der LPDU ist.

SSAP-Feld

Der Source Service Access Point (SSAP) identifiziert den SAP, von dem die LPDU stammt. Der SSAP besteht aus sechs Adressbits, einem Benutzerbit (U) und einem Befehls/Antwort-Bit (C/R), die wie folgt angeordnet sind:

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

Das U-Bit zeigt an, ob die Adresse vom IEEE (1) oder vom Benutzer (0) definiert ist. Das C/R-Bit zeigt an, ob die LPDU ein Befehl oder eine Antwort ist. Wenn LPDU-Frames empfangen werden, wird das C/R-Bit nicht als Teil des SSAP betrachtet. Daher wird der SSAP normalerweise nur als die äußersten sieben Bits betrachtet.

Kontrollfeld

Das LPDU-Kontrollfeld enthält Befehls-, Antwort- und Sequenznummerninformationen. Sie müssen wissen, wie das Steuerfeld zu dekodieren ist, um festzustellen, was in einer bestimmten LLC2-Sitzung geschieht. Informationen zur Dekodierung sind jedoch ohne weiteres verfügbar.

Es gibt drei Arten von Frames:

• I Frames

• Supervisory Frames

• Unnumbered Frames

Obwohl jeder Typ ein anderes Format für das Kontrollfeld hat, lassen sie sich leicht durch eine Untersuchung von zwei Bits im Kontrollfeld unterscheiden.

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

In den folgenden Abschnitten werden die einzelnen Typen von Kontrollfeldern erläutert.

I-Frame

I-Frames ermöglichen die Übertragung von sequentiell nummerierten LPDUs, die Informationen (verbindungsorientiert) zwischen Verbindungsstationen enthalten. Das Format des I-Frames enthält eine NS- und NR-Zählung. Die NS-Zahl ist die Sequenznummer (Modulo 128) der gerade übertragenen LPDU. Die NR-Zahl ist die Sequenznummer des nächsten LPDU-I-Frames, den der Absender zu empfangen erwartet. Um Ihnen später zu helfen, denken Sie daran, dass NR „next receive“ bedeutet.

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

Das P/F-Bit wird als P-Bit in Befehls-LPDUs und als F-Bit in Antwort-LPDUs bezeichnet. Das P/F-Bit wird in Befehls-LPDUs gesetzt, um die entfernte Verbindungsstation aufzufordern, eine Antwort mit diesem Bit zu senden. Für jeden mit gesetztem P-Bit gesendeten Befehl darf nur eine Antwort mit gesetztem F-Bit empfangen werden. Es gibt noch einige andere Einzelheiten über die Verwendung des P/F-Bits in bezug auf die Fehlerbehebung, aber das ist die allgemeine Regel.

Überwachungsrahmen

Überwachungsrahmen führen Überwachungssteuerungsfunktionen aus, z. B. zur Bestätigung von I-Frames (RR), zur Anforderung der erneuten Übertragung von I-Frames (REJ) und zur Anforderung der vorübergehenden Aussetzung (RNR) von I-Frames. Überwachungsrahmen enthalten kein Informationsfeld. Daher haben Überwachungsrahmen keinen Einfluss auf die NS in der sendenden Station und enthalten daher auch kein NS-Feld. Hier ist das Format eines Überwachungsrahmens:

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

Die „S“-Bits geben den Typ des Überwachungsrahmens an.

• B’00‘ = Empfangsbereitschaft

  Eine Station verwendet den RR, um anzuzeigen, dass die Station empfangsbereit ist, und enthält die NR-Zahl des nächsten I-Rahmens, der ankommen soll. Wenn eine Station einen RR-Frame sendet, bestätigt die Station den Empfang von nummerierten I-Frames von der Gegenstation bis zu NR – 1.

• B’01’=Empfänger nicht bereit

  Eine Station verwendet RNR, um anzuzeigen, dass die Station vorübergehend nicht empfangsbereit ist. RNR enthält auch den NR-Zähler, der denselben Regeln folgt wie RR. Vorübergehende RNR-Perioden sind nicht immer ein Hinweis auf ein Netzproblem. Bei anhaltenden RNRs ist nach einer Überlastung der Endstation zu suchen.

• B’10’=Reject

  Eine Station verwendet REJ, um die erneute Übertragung von I-Frame-LPDUs anzufordern, beginnend mit der in der NR-Zählung angegebenen Zahl. REJ ist kein Anzeichen für ein ernsthaftes Problem (d. h. es ist behebbar). Wenn Sie viele REJ-Befehle sehen, suchen Sie nach fehlenden (verworfenen) I-Frames in der Gegenrichtung. Verwechseln Sie einen REJ nicht mit einem Frame reject (FRMR). Ein FRMR ist ein nicht nummerierter Frame und deutet immer auf ein ernstes Problem hin.

Unnumbered Frames

Unnumbered Frames bieten Verbindungssteuerungsfunktionen, z. B. Befehle zur Moduseinstellung und Antworten. In einigen Fällen können auch nicht nummerierte Informationsrahmen gesendet werden. Unnumbered Frames sind nur ein Byte lang. Sie enthalten keine Felder für NR- oder NRS-Zählungen. Das Format eines unnummerierten Rahmens ist wie folgt:

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

Die „M“-Bits geben den Typ des unnummerierten Rahmens an.

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

  Eine Verbindungsstation sendet eine DM-Antwort, um zu melden, dass sie sich im asynchronen Trennungsmodus befindet. Dies bedeutet, dass die Verbindung nicht aktiv ist. Wenn eine Link-Station aktiv war und plötzlich beginnt, DMs zu senden, wurde die Link-Station wahrscheinlich zurückgesetzt.

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

  Eine Link-Station sendet einen DISC-Befehl, um den asynchronen ausgeglichenen Modus zu beenden. Der DISC-Befehl teilt der entfernten Link-Station mit, dass sie den Betrieb einstellt. Die korrekte Antwort auf einen DISC-Befehl ist ein UA (wenn die Station im ABM ist) oder ein DM (wenn die Station im ADM ist).

• B’01100’=UA-Antwort(0x73)

  Eine Verbindungsstation sendet eine UA als Antwort auf die SABME- und DISC-Befehle.

• B’01111’=SABME-Befehl(0x7F)

  Eine Verbindungsstation sendet eine SABME, um eine Datenübertragung im asynchronen symmetrischen Modus einzuleiten. Die korrekte Antwort auf eine SABME ist eine UA. Wenn eine Station einen SABME-Befehl empfängt, setzt die Station die NR- und NS-Zähler auf Null zurück. Die sendende Station tut dasselbe, wenn sie die UA-Antwort empfängt.

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

  Eine Link-Station sendet eine Frame-Reject-Antwort, um einen Fehler in einer eingehenden LPDU von der anderen Link-Station zu melden. Wenn Sie eine FRMR sehen, hat die Station, die die FRMR sendet, einen nicht behebbaren Fehler festgestellt. Sie ist nicht die Ursache des Fehlers. Alle Frames, die nach dem Auftreten des FRMR-Fehlers ankommen, werden ignoriert, bis ein DISC oder SABME empfangen wird.

  Eine FRMR-Antwort enthält Informationen über die Ursache des FRMR-Zustands.

  Die Bytes 0 und 1 enthalten den Inhalt des Kontrollfeldes der LPDU, die den Frame-Reject verursacht hat. Die Bytes 2 und 3 enthalten die NS- bzw. NR-Zahlen. Byte 4 enthält mehrere Bits, die die Art des Fehlers kennzeichnen, wie hier gezeigt:

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

  Das V-Bit zeigt an, dass die im Steuerfeld in den Bytes 0 und 1 enthaltene NS-Nummer ungültig ist. Eine NS ist ungültig, wenn sie größer oder gleich der letzten NS plus der maximalen Empfangsfenstergröße ist. Wenn diese Bedingung eintritt, sendet die Link-Station eine REJ-LPDU und keine FRMR-Antwort.

  Das Z-Bit zeigt an, dass die NR, die das Steuerfeld in den Bytes 0 und 1 trägt, sich weder auf den nächsten I-Frame noch auf einen I-Frame bezieht, der bereits übertragen, aber nicht bestätigt wurde.

  Hinweis: Es ist in Ordnung, denselben NR-Zählerstand mehrfach zu empfangen.

  Der NR-Zählerstand ist nur dann ungültig, wenn sich der Zählerstand auf einen I-Frame bezieht, der bereits bestätigt wurde, oder wenn der Zählerstand zu einem I-Frame überspringt, der noch nicht übertragen wurde. Ersteres ist der häufigste Fall dieser Fehlerart. Wenn diese Art von Fehler auftritt, bedeutet dies in der Regel, dass Frames nicht in der richtigen Reihenfolge empfangen wurden, und Sie sollten nach dem Netzwerk suchen, das Frames in falscher Reihenfolge liefert. Es ist möglich, dass die sendende Link-Station sie in falscher Reihenfolge übertragen hat, aber sehr unwahrscheinlich.

  Das Y-Bit zeigt an, dass die Länge des I-Feldes in der empfangenen LPDU die verfügbare Pufferkapazität überschritten hat.

  Das X-Bit zeigt an, dass die LPDU ein I-Feld enthielt, obwohl es nicht hätte sein dürfen, oder dass eine FRMR-Antwort empfangen wurde, die keine 5 Bytes enthielt. Dies scheint ein Problem der Endstation und nicht des Netzes zu sein.

  Das W-Bit zeigt an, dass eine nicht unterstützte LPDU empfangen wurde. Dies ist ein Problem der Endstation.

• B’10111′ XID-Befehl oder -Antwort

  Eine Verbindungsstation verwendet den XID-Befehl, um Merkmale des sendenden Knotens zu übermitteln und um die entfernte Verbindungsstation zu veranlassen, mit einer XID-Antwort zu antworten. Link-Stationen können XIDs in verschiedenen Formaten, einschließlich SNA-Formaten, senden und empfangen.

• B’11100′ TEST-Befehl oder -Antwort

  Eine Verbindungsstation sendet den TEST-Befehl, um die entfernte Verbindungsstation zu veranlassen, so bald wie möglich mit einer TEST-Antwort zu antworten. Der TEST-Befehl wird im Allgemeinen zur Pfadermittlung in einer Quell-Route-Bridging-Umgebung verwendet.

  

Zusammenfassung der LLC-Steuerfelder

LLC2 Modes and Session Establishment

Es gibt zwei Modi für den LLC2 Betrieb:

• Asynchronous Balanced Mode Extended

• Asynchronous Disconnect Mode

Asynchronous Balanced Mode Extended (ABME)

ABME ist ein ausgeglichener Betriebsmodus zwischen zwei Link-Stationen. Balanced Mode bezieht sich auf die Tatsache, dass jede Station jederzeit Befehle senden kann, unabhängig von der anderen Link-Station. Dies steht im Gegensatz zu SDLC, das im unbalancierten Modus arbeitet. Im unbalancierten Modus muss die sekundäre Station warten, bis sie von der primären Station abgefragt wird, bevor sie Daten senden kann. Infolge des Balanced-Mode-Betriebs findet auf LLC2-Schaltungen kein Polling im herkömmlichen Sinne statt. Eine Station sendet zwar Keepalives, um die Sitzung aufrechtzuerhalten, aber es ist nicht notwendig, diese häufig zu senden, um eine optimale Leistung wie bei SDLC zu erzielen. Aus diesem Grund beträgt der Keepalive-Timer normalerweise 10 Sekunden oder mehr. Es ist wichtig zu beachten, dass die Endstationen diesen Keepalive-Timer erhöhen können, um den Overhead zu reduzieren. Eine Erhöhung des Keepalive-Timers hat keine negativen Auswirkungen auf den Durchsatz oder die Antwortzeit.

Eine Station geht in ABME über, nachdem die Station einen UA to to SABME-Befehl gesendet oder empfangen hat. Im ABME kann die Station nummerierte Informationsrahmen senden und empfangen.

Asynchronous Disconnect Mode (ADM)

Bevor und nachdem eine Station ABME beendet, befindet sich die Station im Asynchronous Disconnect Mode. Im ADM ist die Verbindung logisch unterbrochen; daher können keine I-Frames oder Überwachungsframes gesendet werden. Eine Station kann unter diesen Bedingungen in den ADM eintreten:

• Empfang eines DISC-Befehls

• Die Link-Station wird aktiviert

• Empfang einer DM-Antwort

• Retry-Limit ist ausgeschöpft

Hier ein Beispiel für eine Aktivierungssequenz einer Link-Station:

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

Stationen, die im ASBM-Betrieb arbeiten, haben kein striktes Verständnis von primären oder sekundären Stationen. Die Stationen müssen nicht abfragen oder abgefragt werden, um Daten zu übertragen. Stationen können Daten an jede beliebige Station asynchron übertragen. Stationen haben Peer-to-Peer-Beziehungen.

Auch wenn es keinen strikten Sinn von primär und sekundär gibt, benötigt eine sendende Station für jeden gesendeten nummerierten Informationsrahmen eine Antwort auf der Verbindungsebene, die als Quittierung bezeichnet wird, von der empfangenden Station. Eine Station kann so lange I-Frames an eine andere Station senden, bis die Anzahl der unbestätigten Frames eine bestimmte Grenze erreicht. Diese Zahl wird als „Fenstergröße“ bezeichnet und ist normalerweise auf 7 voreingestellt. Sie können die Fenstergröße auf Leitungen mit großer Latenz erhöhen, um zu vermeiden, dass die sendende Station anhalten und auf eine Antwort warten muss. Dies ist in der Regel nicht notwendig, insbesondere in Situationen, in denen LLC lokal quittiert wird. Wenn eine sendende Station das Sendefenster erreicht, setzt sie das Poll-Bit, um die empfangende Station zu zwingen, eine Antwort zu senden. Im Router wird die Fenstergröße als llc2 local-window bezeichnet.

Eine Empfangsstation hat die Möglichkeit, Bestätigungen zurückzuhalten, bis entweder eine bestimmte Anzahl von I-Frames eintrifft oder ein Timer abläuft. Diese Parameter werden als N3 bzw. T2 bezeichnet. Auf diese Weise können mehrere Frames mit einem RR-Frame quittiert werden, oder eine Quittierung kann zusätzlich zu einem I-Frame gesendet werden. Cisco nennt den N3-Zähler llc2 ack-max. Der Standardwert von drei bedeutet, dass der Router ein Acknowledgment zurückhält, bis er drei I-Frames empfängt oder bis der T2-Timer oder die llc2 ack-delay-time abgelaufen ist.

Die Änderung dieser Parameter auf einer Station ohne Berücksichtigung der Partnerstation kann die Antwortzeit und den Durchsatz beeinträchtigen. Was würde zum Beispiel passieren, wenn die sendende Station local-window auf 5 eingestellt ist und die empfangende Station Werte von 7 für ack-max und 500 Millisekunden für ack-delay-time hat.

In diesem Fall sendet die sendende Station fünf Rahmen und wartet dann auf eine Bestätigung, bevor sie fortfährt. Da der Empfänger Acknowledgments zurückhält, bis sieben Frames empfangen wurden, sendet er kein Acknowledgment, bis die Verzögerungszeit von 500 Millisekunden abgelaufen ist. Sie können die Leistung erheblich verbessern, wenn Sie den ack-max-Wert auf der Empfangsstation herabsetzen.

Ein weiterer gängiger LLC2-Parameter ist der Ti-Timer. Der Router nennt ihn llc2 idle-time. Der Zweck des Ti-Timers ist es, die LLC2-Sitzung während der Zeiträume, in denen keine I-Frames übertragen werden, aktiv zu halten. Sie können den Durchsatz und die Leistung nicht verbessern, wenn Sie diesen Wert verringern. Wenn der Ti-Timer abläuft, wird ein RR-Frame mit aktiviertem Poll-Bit gesendet, um eine Antwort vom Empfänger zu erhalten. Wenn die Station nicht antwortet, wird der Versuch nach llc2 tpf-time wiederholt, bis die durch llc2 n2 festgelegte Anzahl von Versuchen abgelaufen ist. Zu diesem Zeitpunkt wird die Sitzung abgebaut.

Erhöhen Sie die Leerlaufzeit, um den Overhead auf einer LLC2-Schaltung zu reduzieren, und Sie können dies als Alternative zu local ack einstellen. Betrachten wir ein Beispiel, bei dem 200 DSPUs an einen NCP angeschlossen sind. Jede der PUs unterhält eine unabhängige LLC2-Sitzung. Wenn jede von ihnen alle zehn Sekunden ein Keepalive sendet, fallen pro Sekunde 20 Frames Overhead an. Wenn Sie die Leerlaufzeit auf 30 Sekunden erhöhen, verringert sich die Anzahl der Overhead-Frames auf 6,67 Frames pro Sekunde. Der Nachteil dieses Ansatzes ist, dass die Stationen länger brauchen, um festzustellen, dass ihr Partner nicht erreichbar ist. Aber je nach Situation kann dies eine gute Sache sein.

LLC2 Abstimmbare Parameter

Mit dem Befehl show llc können Sie die Werte dieser Parameter anzeigen:

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

Beispiele für LLC2-Parameterkonfigurationen

In einem typischen DLSw+-Netzwerk mit einem Token Ring LAN an beiden Enden erfolgt die Konfiguration der LLC2-Parameter an der ausgehenden Token Ring-Schnittstelle.

Es gibt zwei separate LLC2-Sitzungen. Konfigurieren Sie daher die LLC2-Parameter wie hier gezeigt:

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

Hinweis: Diese skizzierten Konfigurationen zeigen nur relevante LLC2-Parameter-Konfigurationen.

Die LLC2-Parameter-Konfigurationen müssen mit den LLC2-Parametern für das FEP (zum DLSw1-Router) und den PC (zum DLSw2-Router) übereinstimmen. Wenn sich der DLSw+-Peer am zentralen Standort auf einem CIP-Router befindet, ist die Konfiguration etwas anders.

Die Konfiguration des entfernten DLSw+-Routers bleibt unverändert. Die LLC2-Sitzung am zentralen Standort findet jedoch zwischen dem CIP und dem LLC2-Stack in IOS statt. Der CIP stellt den Mainframe dar, und die LLC2-Parameter vom Mainframe in Richtung IOS werden unter den Adaptern auf dem LAN Token Ring (auf dem CIP) konfiguriert. Die LLC2-Parameter vom IOS zum Mainframe werden auf der ausgehenden Schnittstelle konfiguriert. Das heißt, Schnittstellenkanal x/2 (für CIP) und Schnittstellenkanal x/0 (für xCPA). z.B.:

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

Hinweis: Diese abgespeckten Konfigurationen zeigen nur relevante LLC2-Parameter-Konfigurationen.

Wenn der CIP-Router eine Verbindung über das LAN zu einer lokalen Station herstellt, benötigen Sie nur die LLC2-Parameter unter den CIP-Adaptern. Die LLC2-Parameter würden dann mit denen des PCs übereinstimmen. Alle LLC2-Parameter unter dem Schnittstellenkanal 0/2 sind unwirksam.

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

Hinweis: Diese abgespeckten Konfigurationen zeigen nur relevante LLC2-Parameter-Konfigurationen.

Wenn sich Geräte über Bridge-Gruppen mit DLSw+ verbinden, werden die LLC2-Parameter in der DLSW+-Bridge-Group-Anweisung wie folgt konfiguriert:

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

Hinweis: Diese verkürzten Konfigurationen zeigen nur relevante LLC2-Parameter-Konfigurationen.

Hinweis: Obwohl Sie LLC2 unter der Schnittstelle ethernet 0 konfigurieren können, haben diese Parameter keine Auswirkungen. DLSw bridge-group LLC2 wurde neu in Cisco IOS Software Release 11.3 eingeführt.

Wenn der Router als Endstation konfiguriert ist (z. B. SNASw und DSPU), müssen Sie die LLC2-Parameter auf der ausgehenden Schnittstelle konfigurieren. Beachten Sie, dass nicht alle virtuellen Schnittstellen die Konfiguration von LLC2-Parametern unterstützen. Zum Beispiel:

Hinweis: Diese überschaubaren Konfigurationen zeigen nur relevante LLC2-Parameter-Konfigurationen.

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

LLC2-Fehlerbedingungen

Einige Fehler bei LLC2-Sitzungen sind normal und können behoben werden, z. B. gelegentlich verpasste Frames oder Frames in falscher Reihenfolge. Diese führen in der Regel zu einem REJ und neu übertragenen Frames. Übermäßige Neuübertragungen sind nicht normal, und Sie müssen die Ursache ermitteln und das Problem beheben. Übermäßige Neuübertragungen können aufgrund von Verbindungsabbrüchen, mehreren Pfaden, Überlastung und übermäßiger Latenz auftreten.

Einige Fehler in LLC2 sind nicht behebbar und führen immer zu einem Ausfall der Sitzung. Bei diesen Fehlern handelt es sich ausschließlich um Protokollverletzungen. Sie können auftreten, wenn Stationen undefinierte Kontrollfelder oder andere fehlerhafte Informationen senden. Diese Protokollverletzungen können eine Station veranlassen, eine FRMR-Antwort zu senden. Die Station, die die FRMR-Antwort sendet, ist höchstwahrscheinlich nicht der Verletzer, sondern lediglich der Überbringer. Die FRMR-Antwort enthält Informationen, aus denen hervorgeht, warum die FRMR-Antwort gesendet wird. Dies ist meistens der Fall, wenn eine Station eine andere Station auffordert, einen I-Frame erneut zu senden, den sie bereits bestätigt hat. Da die Station den Rahmen nicht erneut senden kann (weil sie ihn bereits verworfen hat), hat sie keine andere Wahl, als die LLC-Sitzung zu beenden. Wenn diese Art von Fehler auftritt, ist die wahrscheinlichste Ursache, dass die Rahmen nicht in der richtigen Reihenfolge gesendet wurden.