Der IEEE-Standard 802.2 definiert Logical Link Control (LLC) als Datenverbindungssteuerungs-Layer, der in 802.3-, 802.5- und anderen Netzwerken verwendet wird. IBM entwarf LLC ursprünglich als Unterschicht in der IBM Token Ring-Architektur.
Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu verfügen:
Grundlegendes Verständnis von LLC
Dieses Dokument ist nicht auf bestimmte Software- und Hardwareversionen beschränkt.
Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.
Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps zu Konventionen von Cisco).
Die LLC-Schicht ermöglicht verbindungslose und verbindungsorientierte Datenübertragung.
Verbindungslose Datenübertragung wird allgemein als LLC-Typ 1 oder LLC1 bezeichnet. Für den verbindungslosen Dienst müssen Sie keine Datenverbindungen oder Verbindungsstationen einrichten. Nachdem ein Service Access Point (SAP) aktiviert wurde, kann der SAP Informationen an und von einem Remote-SAP senden und empfangen, der auch einen verbindungslosen Service verwendet. Der verbindungslose Dienst verfügt über keine Moduseinstellbefehle (z. B. SABME) und erfordert nicht, dass die Statusinformationen beibehalten werden.
Verbindungsorientierte Datenübertragung wird als LLC-Typ 2 oder LLC2 bezeichnet. Verbindungsorientierte Dienste erfordern die Einrichtung von Verbindungsstationen. Wenn die Verbindungsstation eingerichtet ist, ist ein Befehl zum Einstellen des Modus erforderlich. Danach ist jede Verbindungsstation dafür verantwortlich, Informationen zum Verbindungsstatus zu speichern.
LLC2 wird immer dann implementiert, wenn die Systems Network Architecture (SNA) über ein LAN oder ein virtuelles LAN ausgeführt wird. LLC2 ist auch direkt in Frame Relay eingekapselt. Manchmal übergibt der Router nur LLC2-Frames und manchmal implementiert der Router eine LLC2-Verbindungsstation. NetBIOS verwendet auch LLC. NetBIOS verwendet LLC1 zum Suchen einer Ressource. Anschließend werden verbindungsorientierte LLC2-Sitzungen eingerichtet.
Der Router implementiert einen LLC2-Stack, wenn eine der folgenden Funktionen aktiviert ist:
Data-Link Switching (DLSw) (Verbindung mit LAN)
Remote Source-Route Bridging (RSRB) mit lokalem ACK
Channel Interface Processor (CIP)
Advanced Peer-to-Peer Networking (SNASwitching (SNASw))
Synchronous Data Link Control (SDLC) to LCC Conversion (SDLLC)
Eine Grundkenntnis des LLC reicht aus, um die meisten Probleme zu isolieren und zu beheben. Da keine Linkstatus oder Sitzungen verwaltet werden müssen, sind Probleme in LLC1 selten.
In LLC2 können zwei Kategorien von Problemen auftreten:
Sitzungen, die keine
Etablierte Sitzungen, die gelegentlich fehlschlagen
Um diese Probleme zu lösen, benötigen Sie Informationen zu folgenden Themen:
LLC-Frame-Formate
LLC2-Modi und Sitzungseinrichtung
Betrieb des asynchronen, ausgeglichenen LLC2-Modus
LLC2-Fehlerbedingungen
Dieser Abschnitt enthält Informationen zu LLC-Frame-Formaten.
DSAP/SSAP | Kontrolle | |||
---|---|---|---|---|
Ziel-Service-Zugangspunkt (1 Byte) | Kontrollfeld - Nicht nummeriert (1 Byte) | |||
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 |
Quellservice-Zugangspunkt (1 Byte) | Kontrollfeld - Supervisory (2 Byte) | |||
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 |
Kontrollfeld - Informationsrahmen (2 Byte) | ||||
ssss sss0 |
xxxx |
Information format |
||
P = Poll-Bit gesetzt auf "1" F = finales Bit gesetzt auf "1" Z = Poll/Final Bit gesetzt, entweder auf "0" oder "1" |
Ein LLC-Frame wird als LLC Protocol Data Unit (LPDU) bezeichnet und wie folgt formatiert:
DSAP (1 byte)-SSAP (1 byte)-Control Field (1 or 2 bytes)-Information Field (0 or more bytes)
Der Ziel Service Access Point (DSAP) identifiziert den SAP, für den die LPDU vorgesehen ist. Das DSAP besteht aus sechs Adressenbits, einem Benutzer-Bit (U) und einem Individual/Gruppe-Bit (I/G), das wie folgt organisiert ist:
D-D-D-D-D-D-D-I/G
Das U-Bit gibt an, ob die Adresse durch IEEE (1) oder benutzerdefinierte (0) definiert ist. Das I/G-Bit gibt an, ob es sich bei dem SAP um eine Gruppenadresse (1) oder eine einzelne Adresse (0) handelt. Für unsere Zwecke ist keines dieser Teile zu wichtig. Alles, was Sie wirklich wissen müssen, ist, dass das DSAP das Ziel der LPDU ist. Einige häufige treten immer wieder auf.
Der Source Service Access Point (SSAP) identifiziert den SAP, der die LPDU erstellt hat. Die SSAP besteht aus sechs Adressenbits, einem Benutzer-Bit (U) und einem Command/Response (C/R)-Bit, das wie folgt organisiert ist:
S-S-S-S-S-S-U-C/R
Das U-Bit gibt an, ob die Adresse durch IEEE (1) oder benutzerdefinierte (0) definiert ist. Das C/R-Bit gibt an, ob es sich bei der LPDU um einen Befehl oder eine Antwort handelt. Wenn LPDU-Frames empfangen werden, wird das C/R-Bit nicht als Teil des SSAP angesehen. Daher wird das SSAP in der Regel nur als die sieben Bit am linken Rand betrachtet.
Das LPDU-Kontrollfeld enthält Informationen zu Befehlen, Antworten und Sequenznummern. Sie müssen wissen, wie das Steuerelementfeld decodiert wird, um zu bestimmen, was in einer bestimmten LLC2-Sitzung geschieht. Entschlüsselungsinformationen sind jedoch sofort verfügbar.
Es gibt drei Arten von Frames:
I-Frames
Aufsichtsrahmen
Nicht nummerierte Frames
Obwohl jeder Typ ein anderes Format für das Kontrollfeld hat, können Sie diese einfach durch eine Untersuchung von zwei Bits im Kontrollfeld unterscheiden.
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 den nächsten Abschnitten werden die einzelnen Steuerelementfeldtypen erläutert.
In Frames können Sie sequenziell nummerierte LPDUs mit Informationen (verbindungsorientiert) zwischen Verbindungsstationen übertragen. Das Format des I-Frames enthält eine NS- und NR-Anzahl. Die NS-Anzahl ist die laufende Nummer (Modul 128) der momentan übertragenen LPDU. Die NR-Anzahl ist die Sequenznummer des nächsten LPDU I-Frames, den der Absender voraussichtlich erhält. 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 den LPDUs-Befehlen und das F-Bit als Antwort-LPDUs bezeichnet. Das P/F-Bit wird mit dem Befehl LPDUs festgelegt, um anzufordern, dass die Remote-Verbindungsstation eine Antwort mit diesem Bitsatz sendet. Für jeden Befehl, der mit dem P-Bit-Satz gesendet wird, muss nur eine Antwort empfangen werden, wenn das F-Bit festgelegt ist. Es gibt noch weitere Details über die Verwendung des P/F-Bits in Bezug auf die Fehlerwiederherstellung, aber das ist die allgemeine Regel.
Überwachungs-Frames übernehmen Überwachungsfunktionen, z. B. zur Bestätigung von I-Frames (RR), zur Anforderung einer erneuten Übertragung von I-Frames (REJ) und zur Anforderung einer vorübergehenden Aussetzung (RNR) von I-Frames. Überwachungsrahmen enthalten kein Informationsfeld. Daher beeinflussen Überwachungs-Frames das NS in der Sendestation nicht und enthalten daher kein NS-Feld. Das folgende Format des Aufsichtsrahmens:
0-0-0-0-S-S-0-1-NR-NR-NR-NR-NR-NR-NR-P/F
Die "S"-Bits geben die Art des Überwachungsrahmens an.
B'00' = Receiver-fähig
Eine Station verwendet den RR, um anzuzeigen, dass die Station bereit für den Empfang ist, und enthält die NR-Anzahl des nächsten I-Frames, der ankommen soll. Wenn eine Station einen RR-Frame sendet, bestätigt die Station den Empfang von nummerierten I-Frames von der Remote-Station von bis zu NR - 1.
B'01'=Empfänger nicht bereit
Eine Station verwendet den RNR, um anzuzeigen, dass die Station vorübergehend nicht für den Empfang bereit ist. RNR enthält auch die NR-Anzahl, die den gleichen Regeln RR folgt. Übergangszeiträume von RNR sind nicht immer ein Hinweis auf ein Netzwerkproblem. Wenn RNRs persistent sind, achten Sie auf Überlastungen in der Endstation.
B'10'=Ablehnen
Eine Station verwendet den REJ, um die erneute Übertragung von I-Frame-LPDUs anzufordern, beginnend mit der in der NR-Anzahl angegebenen Nummer. REJ ist kein Hinweis auf ein schwerwiegendes Problem (d. h. es ist wiederherstellbar). Wenn Sie viele REJ-Befehle sehen, suchen Sie nach fehlenden (verworfenen) I-Frames in die andere Richtung. Verwechseln Sie einen REJ nicht mit einem Frame Ablehnen (FRMR). Ein FRMR ist ein unnummerierter Rahmen und deutet immer auf ein ernstes Problem hin.
Nicht nummerierte Frames stellen Verbindungssteuerungsfunktionen bereit, z. B. Befehle zum Einstellen des Modus und Antworten. In einigen Fällen können auch unnummerierte Informationsrahmen gesendet werden. Nicht nummerierte Frames sind nur ein Byte lang. Sie enthalten keine Felder für NR- oder NRS-Zählungen. Das Format eines nicht nummerierten Frames ist wie folgt:
M-M-M-P/F-M-M-1-1
Die "M"-Bits geben den Typ des unnummerierten Frames an.
B'00011'=DM-Antwort (0 x 1 F)
Eine Verbindungsstation sendet eine DM-Antwort, um zu melden, dass sie sich im asynchronen Trennungsmodus befindet. Das bedeutet, dass der Link nicht aktiv ist. Wenn eine Verbindungsstation aktiv war und plötzlich beginnt, DMs zu senden, wurde die Verbindungsstation wahrscheinlich zurückgesetzt.
B'01000'=DISK-Befehl (0x53)
Eine Verbindungsstation sendet ein DISK, um den asynchronen Balancemodus zu beenden. Der Befehl DISK informiert die Remote Link Station, dass sie den Betrieb unterbricht. Die richtige Antwort auf einen DISK-Befehl ist ein UA (wenn sich die Station im ABM befindet) oder ein DM (wenn sich die Station im ADM befindet).
B'01100'=UA-Antwort(0x73)
Eine Verbindungsstation sendet eine UA als Antwort auf die Befehle SABME und DISK.
B'01111'=SABME-Befehl(0x7F)
Eine Verbindungsstation sendet ein SABME, um die Datenübertragung im asynchronen Balancing-Modus zu initiieren. Die richtige Antwort auf ein SABME ist eine UA. Wenn eine Station einen SABME-Befehl empfängt, setzt die Station die NR- und NS-Zählung auf Null zurück. Die Sendestation tut dies auch, wenn sie die UA-Antwort erhält.
B'10001'=FRMR-Antwort(0x87)
Eine Verbindungsstation sendet eine Frame Reject-Antwort, um einen Fehler in einem eingehenden LPDU von der anderen Verbindungsstation zu melden. Wenn Sie einen FRMR sehen, hat die Station, die den FRMR sendet, einen nicht behebbaren Fehler erkannt. Dies ist nicht die Fehlerursache. Alle Frames, die nach dem Fehler FRMR eintreffen, werden ignoriert, bis ein DISK oder SABME empfangen wird.
Eine FRMR-Antwort enthält Informationen zur Ursache der FRMR-Bedingung.
Die Byte 0 und 1 enthalten den Inhalt des Kontrollfelds der LPDU, die die Frame-Ablehnung verursacht hat. Byte 2 und 3 enthalten jeweils die NS- und NR-Werte. Byte 4 enthält mehrere Bits, die den Fehlertyp identifizieren, wie hier gezeigt:
0-0-0-V-Z-Y-W-X
Das V-Bit gibt an, dass die NS-Nummer, die vom Steuerfeld in Byte 0 und 1 übertragen wird, ungültig ist. Ein NS ist ungültig, wenn größer oder gleich dem letzten NS plus der maximalen Empfangsfenstergröße ist. In diesem Fall sendet die Verbindungsstation eine REJ-LPDU, keine FRMR-Antwort.
Das Z-Bit gibt an, dass das NR, das das Kontrollfeld in Byte 0 und 1 enthält, sich nicht auf den nächsten I-Frame oder einen I-Frame bezieht, der bereits übertragen, aber nicht quittiert wurde.
Hinweis: Es ist richtig, dieselbe NR-Anzahl mehrmals zu erhalten.
Die NR-Anzahl ist nur ungültig, wenn die Zahl auf einen bereits bestätigten I-Frame verweist oder wenn der Zähler auf einen Frame überspringt, der noch nicht übertragen wurde. Ersteres ist der häufigste Fall dieser Art von Fehler. Wenn Sie diese Art von Fehler sehen, bedeutet dies normalerweise, dass Frames nicht nacheinander empfangen wurden, und Sie sollten nach dem Netzwerk suchen, das Frames in der falschen Reihenfolge liefert. Es ist möglich, dass die sendende Verbindungsstation sie außer Betrieb gesetzt hat, aber sehr unwahrscheinlich.
Das Y-Bit gibt an, dass die Länge des I-Felds in der empfangenen LPDU die verfügbare Pufferkapazität überschritten hat. Wenn dies der Fall ist, suchen Sie nach Problemen in den Endstationen, nicht im Netzwerk.
Das X-Bit zeigt an, dass die LPDU ein I-Feld enthielt, wenn es nicht vorhanden sein darf, oder dass eine FRMR-Antwort empfangen wurde, die nicht 5 Byte enthielt. Dies scheint ein Endstation-Problem und kein Netzwerkproblem zu sein.
Das W-Bit zeigt an, dass eine nicht unterstützte LPDU empfangen wurde. Dies ist ein Endstation-Problem.
B'10111' XID-Befehl oder -Antwort
Eine Verbindungsstation verwendet den Befehl XID, um die Eigenschaften des sendenden Knotens zu übertragen und die Remote-Verbindungsstation dazu zu veranlassen, mit einer XID-Antwort zu reagieren. Link-Stationen können XIDs in verschiedenen Formaten, einschließlich SNA-Formaten, senden und empfangen.
B'1100' TEST-Befehl oder -Antwort
Eine Verbindungsstation sendet den TEST-Befehl, damit die Remote-Verbindungsstation so bald wie möglich eine TEST-Antwort sendet. Der TEST-Befehl wird in der Regel für die Pfaderkennung in einer Bridging-Umgebung auf Quellroute verwendet.
Wert | Nicht nummerierte Frames |
---|---|
0x0F oder 0x1F | Trennmodus (DM)-Antwort |
0x43 oder 0x53 | Befehl "Disconnect" (DISK) |
0x63 oder 0x73 | Antwort auf nicht nummerierte Bestätigungen (UA) |
0x6F oder 0x7F | Befehl Asynchronous Balanced Mode (SABME) festlegen |
0x87 oder 0x97 | FRMR-Antwort (Frame Reject) |
0xAF oder 0xBF | Befehl oder Antwort für Exchange-ID (XID) |
0xE3 oder 0xF3 | Test (TEST) - Befehl oder Antwort |
Wert | Aufsichtsrahmen |
---|---|
0 x 01 | Receiver-fähig (RR) |
0 x 05 | Empfänger nicht bereit (RNR) |
0 x 09 | Ablehnen (REJ) |
Wert | Informationsrahmen |
---|---|
0bnnnnn0 | Informationsrahmen (INFO) |
Es gibt zwei Modi für den LLC2-Betrieb:
Erweiterter asynchron-ausgeglichener Modus
Asynchroner Trennmodus
ABME ist ein ausgewogener Betriebsmodus zwischen zwei Verbindungsstationen. Ausgeglichener Modus bezieht sich darauf, dass jede Station unabhängig von der anderen Verbindungsstation jederzeit Befehle senden kann. Vergleichen Sie dies mit SDLC, das im unausgeglichenen Modus arbeitet. Im unausgeglichenen Modus muss die sekundäre Station auf das Polling durch die primäre Station warten, bevor sie Daten senden kann. Aufgrund des ausgeglichenen Modus-Betriebs erfolgt das Polling nicht auf LLC2-Schaltkreisen im traditionellen Sinne. Eine Station sendet zwar Keepalives, um die Sitzung aufrechtzuerhalten, es ist jedoch nicht erforderlich, diese regelmäßig zu senden, um eine optimale Leistung wie in SDLC zu erzielen. Aus diesem Grund ist der Keepalive-Timer in der Regel 10 Sekunden oder länger. Beachten Sie, 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 Reaktionszeit.
Eine Station gibt ABME ein, nachdem die Station einen UA an SABME-Befehl sendet oder empfängt. In ABME kann die Station nummerierte Informationsrahmen senden und empfangen.
Vor und nach dem Beenden von ABME befindet sich die Station im asynchronen Trennmodus. In ADM ist die Verbindung logisch getrennt. Daher können keine I-Frames oder Überwachungs-Frames gesendet werden. Eine Station kann unter den folgenden Bedingungen in das ADM eintreten:
Empfang eines DISK-Befehls
Die Verbindungsstation ist aktiviert.
Erhalt einer DM-Antwort
Der Grenzwert für Wiederholung ist erschöpft.
Hier ein Beispiel für eine Aktivierungssequenz für eine Verbindungsstation:
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 ...
Stationen, die in ASBM betrieben werden, verfügen nicht über einen strengen Sendersinn für primäre oder sekundäre Stationen. Stationen müssen nicht abfragen oder abgefragt werden, um Daten zu übertragen. Stationen können Daten asynchron an jede Station übertragen. Stationen verfügen über Peer-to-Peer-Beziehungen.
Auch wenn es keine strenge Vorder- und Sekundäreinheit gibt, erfordert eine Sendestation eine Reaktion auf die Verbindungsebene, die als Bestätigung der Empfangsstation für jeden nummerierten Informationsrahmen bezeichnet wird. Eine Station kann weiterhin I-Frames an eine andere Station übertragen, bis die Anzahl der unbestätigten Frames einen Grenzwert erreicht. Diese Nummer wird als "Fenstergröße" bezeichnet und ist in der Regel auf 7 eingestellt. Sie können die Fenstergröße bei Schaltkreisen erhöhen, bei denen eine hohe Latenz herrscht, um zu verhindern, dass die sendende Station anhalten und auf eine Antwort warten muss. Dies ist in der Regel nicht erforderlich, insbesondere in Situationen, in denen LLC lokal bestätigt wird. Wenn eine Sendestation das sendende Fenster erreicht, legt die Station das Abfragebit fest, um die Empfangsstation zum Senden einer Antwort zu zwingen. Im Router wird die Fenstergröße als lokales llc2-Fenster bezeichnet.
Eine Empfangsstation hat die Möglichkeit, Bestätigungen zurückzuhalten, bis entweder eine bestimmte Anzahl von I-Frames eingeht oder ein Timer abläuft. Diese Parameter werden als N3 bzw. T2 bezeichnet. Auf diese Weise können mehrere Frames mit einem RR-Frame bestätigt werden, oder eine Bestätigung kann auf einem I-Frame versendet werden. Cisco nennt den N3-Counter llc2 ack-max. Der Standardwert von drei gibt an, dass der Router eine Bestätigung zurückhält, bis der Router drei I-Frames empfängt oder bis der T2-Timer oder die llc2-Amortisierungsverzögerung abläuft.
Eine Änderung dieser Parameter auf einer Station ohne Rücksicht auf die Partnerstation kann die Reaktionszeit und den Durchsatz beeinflussen. Überlegen Sie sich beispielsweise, was passieren würde, wenn das lokale Fenster der Sendestation auf 5 festgelegt ist und die Empfangsstation Werte von 7 für ack-max und 500 Millisekunden für die Back-Delay-Zeit hat.
In diesem Fall sendet die Sendestation fünf Frames und wartet dann auf eine Bestätigung, bevor sie fortfährt. Da der Empfänger Bestätigungen zurückhält, bis sieben Frames empfangen wurden, sendet er erst eine Bestätigung, wenn die Verzögerung von 500 Millisekunden abläuft. Sie können die Leistung erheblich verbessern, wenn Sie den Wert für "ack-max" auf der Empfangsstation senken.
Ein weiterer allgemeiner LLC2-Parameter wird als Ti-Timer bezeichnet. Der Router nennt dies die LLC2-Leerlaufzeit. Der Ti-Timer dient dazu, die LLC2-Sitzung in Zeiträumen aktiv zu halten, in denen keine I-Frames übertragen werden. Durchsatz und Leistung können nicht verbessert werden, wenn Sie diesen Wert senken. Wenn der Ti-Timer abläuft, wird ein RR-Frame mit dem Polling-Bit gesendet, um eine Antwort vom Empfänger auszulösen. Wenn die Station nicht antwortet, wird die Station nach llc2 tpf-time erneut versucht, bis die Anzahl der durch llc2 n2 definierten Wiederholungen abgelaufen ist. Zu diesem Zeitpunkt wird die Sitzung beendet.
Erhöhen Sie die Leerlaufzeit, um den Overhead für einen LLC2-Stromkreis zu reduzieren. Sie können dies als Alternative zum lokalen Rack anpassen. Beispiel: 200 DSPUs sind mit einem NCP verbunden. Jede der PUs unterhält eine unabhängige LLC2-Sitzung. Wenn alle zehn Sekunden ein Keepalive gesendet wird, entstehen pro Sekunde 20 Frames Overhead. Wenn Sie die Leerlaufzeit auf 30 Sekunden erhöhen, reduziert sich die Anzahl der Overhead-Frames auf 6,67 Frames pro Sekunde. Der Nachteil dieses Ansatzes ist, dass die Station länger braucht, um festzustellen, dass ihr Partner nicht erreichbar ist. Aber je nach Ihrer Situation könnte das eine gute Sache sein.
Befehl | Standard | Beschreibung |
---|---|---|
llc2-ack-delay-time>/b> msec | 100 | Der Zeitraum, der gewartet wird, bis eine Antwort gesendet wird, bevor eine Bestätigung gesendet wird, wenn der ack-max-Wert nicht erreicht wurde. |
LLC2-ack-max-Anzahl | 3 Frames | Die Anzahl der Frames, die vor dem Senden einer Bestätigung empfangen werden. |
LLC2 Leerlaufzeit msec | 10.000 | Die Zeitspanne zwischen den Umfragen während Leerlaufzeiten. |
LC2-Anzahl lokaler Fenster | 7 Frames | Die Anzahl der Frames, die gesendet werden, bevor auf eine Antwort gewartet wird. |
LC2 n2-Zähler | 8 Wiederholungen | Die Anzahl der unbestätigten I-Frames oder Umfragen, die ohne eine Antwort gesendet werden, bevor die Sitzung beendet wird. |
LLC2 t1-Zeit ms | 1000 | Die Zeit, die gewartet wird, bevor I-Frames erneut gesendet werden. Diese Zeit muss groß genug sein, um die Round-Trip-Verzögerung zu bewältigen. |
LLC2-Tbuzy-Time msec | 9600 | Die Wartezeit vor dem Polling einer Station, die einen RNR gesendet hat. Ändern Sie den Wert nur, um den Wert für Stationen zu erhöhen, die ungewöhnlich lange, geschäftige Zeiten haben, bevor sie ihren Status löschen. |
LLC2 tpf-Zeit msec | 1000 | Die Zeitdauer, die gewartet wird, bis eine letzte Antwort eingeht, bevor der Rahmen der Umfrage erneut gesendet wird. |
LLC2-Trej-Zeit msec | 3200 | Die Zeitdauer, die nach dem Senden eines REJ auf einen korrekten Frame gewartet wird. |
Sie können den Befehl show llc verwenden, um die Werte dieser Parameter anzuzeigen:
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 einem typischen DLSw+-Netzwerk mit einem Token Ring-LAN an beiden Enden wird die Konfiguration der LLC2-Parameter an der ausgehenden Token-Ring-Schnittstelle vorgenommen.
Es gibt zwei separate LLC2-Sitzungen. Konfigurieren Sie daher die LLC2-Parameter wie folgt:
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
Hinweis: Diese überschaubaren Konfigurationen zeigen nur relevante LLC2-Parameterkonfigurationen an.
Die Konfigurationen der LLC2-Parameter müssen mit den LLC2-Parametern mit dem FEP (dem DLSw1-Router) und dem PC (dem DLSw2-Router) übereinstimmen. Wenn sich der DLSw+-Peer des zentralen Standorts auf einem CIP-Router befindet, ist die Konfiguration etwas anders.
Die Remote-DLSw+-Router-Konfiguration bleibt unverändert. Die LLC2-Sitzung in der Zentrale befindet sich jedoch zwischen dem CIP und dem LLC2-Stack in IOS. Der CIP stellt den Mainframe dar, und die LLC2-Parameter vom Mainframe zum IOS werden unter den Adaptern im LAN Token Ring (auf dem CIP) konfiguriert. Die LLC2-Parameter von 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).Beispiel:
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
Hinweis: Diese überschaubaren Konfigurationen zeigen nur relevante LLC2-Parameterkonfigurationen an.
Wenn der CIP-Router über das LAN mit einer lokalen Station verbunden wird, benötigen Sie nur die LLC2-Parameter unter den CIP-Adaptern. Die LLC2-Parameter werden dann den Parametern des PCs zugeordnet. Alle LLC2-Parameter unter Schnittstellenkanal 0/2 sind ineffektiv.
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
Hinweis: Diese überschaubaren Konfigurationen zeigen nur relevante LLC2-Parameterkonfigurationen an.
Wenn Geräte über Bridge-Gruppen eine Verbindung mit DLSw+ herstellen, werden die LLC2-Parameter in der DLSW+ Bridge-Group-Anweisung konfiguriert, wie hier gezeigt:
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
Hinweis: Diese überschaubaren Konfigurationen zeigen nur relevante LLC2-Parameterkonfigurationen an.
Hinweis: Obwohl Sie LLC2 unter der Ethernet 0-Schnittstelle konfigurieren können, haben diese Parameter keine Auswirkungen. DLSw Bridge-Group LLC2 wurde neu in Version 11.3 der Cisco IOS-Software entwickelt.
Wenn der Router als Endstation konfiguriert ist (z. B. SNASw und DSPU), müssen Sie die LLC2-Parameter für die ausgehende Schnittstelle konfigurieren. Beachten Sie, dass nicht alle virtuellen Schnittstellen die Konfiguration von LLC2-Parametern unterstützen. Beispiel:
Hinweis: Diese überschaubaren Konfigurationen zeigen nur relevante LLC2-Parameterkonfigurationen an.
hostname snasw1 ! Interface fastethernet 0/0 llc2 tpf-timer 2000 llc2 n2 20 ! snasw cpname neta.snasw1 snasw port FASTETH0 FastEthernet0/0 conntype nohpr
Einige Fehler bei LLC2-Sitzungen sind normal und behebbar, z. B. gelegentlich verpasste Frames oder Frames in der falschen Reihenfolge. Diese resultieren in der Regel in einem REJ und übertragene Frames. Übermäßige Übermittlungen sind nicht normal, und Sie müssen die Ursache identifizieren und das Problem beheben. Übermäßige Übermittlungen können durch Verwerfen, mehrere Pfade, Überlastungen und übermäßige Latenz auftreten.
Einige Fehler in LLC2 sind nicht behebbar und führen immer zu einem Sitzungsausfall. Diese Fehler sind ausschließlich Protokollverletzungen. Sie können auftreten, wenn Stationen nicht definierte Kontrollfelder oder andere fehlerhafte Informationen senden. Diese Protokollverletzungen können dazu führen, dass eine Station eine FRMR-Antwort sendet. Die Station, die die FRMR-Antwort sendet, ist höchstwahrscheinlich nicht der Verletzer, sondern nur der Bote. Die FRMR enthält Informationen, die angeben, warum der FRMR gesendet wird. Dies ist in der Regel der Fall, wenn eine Station eine andere Station anfordert, einen bereits bestätigten I-Frame erneut zu senden. Da die Workstation den Frame nicht erneut übertragen kann (weil er ihn bereits verworfen hat), bleibt ihr nichts anderes übrig, als die LLC-Sitzung zu beenden. Wenn dieser Fehlertyp auftritt, ist die wahrscheinlichste Ursache, dass die Frames nicht in der richtigen Reihenfolge angeordnet sind.