Verständnis der Steuerung logischer Verbindungen

Einführung

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.

Voraussetzungen

Anforderungen

Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu 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 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.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps zu Konventionen von Cisco).

Hintergrundinformationen

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.

Implementierungen von LLC

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)

Grundlegende Informationen, die Sie zur Fehlerbehebung kennen müssen

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:

1. Sitzungen, die keine

2. 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

LLC-Frame-Formate

Dieser Abschnitt enthält Informationen zu LLC-Frame-Formaten.

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

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

ssss sss0

xxxx

Information format

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)

DSAP-Feld

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.

SSAP-Feld

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.

Kontrollfeld

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.

I-Frame

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.

Überwachungsrahmen

Ü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

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.

  

LLC-Kontrollfeldübersicht

LLC2-Modi und Sitzungseinrichtung

Es gibt zwei Modi für den LLC2-Betrieb:

• Erweiterter asynchron-ausgeglichener Modus

• Asynchroner Trennmodus

Erweiterter asynchroner Balanced Mode (ABME)

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.

Asynchroner Disconnect Mode (ADM)

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 ...

Betrieb des asynchronen, ausgeglichenen LLC2-Modus

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.

Anpassbare LLC2-Parameter

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

Beispiele für LLC2-Parameterkonfigurationen

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

LLC2-Fehlerbedingungen

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.

Zugehörige Informationen

• Technischer Support und Dokumentation - Cisco Systems