In diesem Dokument wird erläutert, wie QLLC (Qualified Logical Link Control) in Cisco-Routern und -Nachrichtenflüssen für Anrufverbindungen in einer Topologie implementiert wird, in der ein Front-End-Prozessor (FEP) über Ethernet verbunden ist und Remote-Geräte (entweder physische Einheit [PU] Typ 2.0 oder PU Typ 2.1) mit dem X.25-Netzwerk verbunden sind. Außerdem werden geeignete Schritte zur Fehlerbehebung bei dieser Art von Anrufverbindung beschrieben.
Für dieses Dokument bestehen keine speziellen Anforderungen.
Dieses Dokument ist nicht auf bestimmte Software- oder Hardwareversionen beschränkt.
Weitere Informationen zu Dokumentkonventionen finden Sie in den Cisco Technical Tips Conventions.
Wenn Sie eine Fehlerbehebung für ein Ethernet-angeschlossenes Gerät durchführen, das über Data-Link Switching (DLSw) kommuniziert, müssen Sie zunächst überprüfen, ob dlsw Bridge-Group x vorhanden ist, wobei x auf die Bridge-Nummer verweist, die im Bridge-Group-Befehl auf der Ethernet-Schnittstelle konfiguriert ist. Informationen zum Überprüfen der Konfiguration finden Sie für Beispielkonfigurationen auf Ethernet-angeschlossenen Geräten unter Grundlegende DLSw+-Konfigurationen.
Ein weiterer nützlicher Befehl zur Fehlerbehebung ist show bridge, der überprüft, ob die transparente Bridge die MAC-Adresse des Geräts (lokal und remote) kennt. Ethernet-MAC-Adressen werden im kanonischen Format angezeigt, im Gegensatz zu Token Ring-Adressen, die ein nicht kanonisches Format haben. Verwenden Sie die folgende Richtlinie, um MAC-Adressen zu übersetzen:
Ethernet MAC-Adresse (kanonisches Format) | 0 1 2 3 4 5 6 7 9 A C E E F |
wird | |
Token Ring Address (nicht-kanonisches Format) | 0 8 4 C 2 A 6 E 1 9 5 D 3 B 7 F |
Dies ist ein Beispiel für Ethernet, das dieser Regel folgt:
1. Ethernet MAC-Adresse (kanonisches Format) | 0200 4556 1140 |
2. Zwischenschritt | 0400,2AA6,8820 |
3. Endgültige Token Ring-Adresse (nicht kanonisches Format) | 4000.A26A.8802 |
Hinweis: Um zur endgültigen, nicht-kanonischen Adresse zu gelangen, tauschen Sie jedes Bit innerhalb eines Bytes um.
Vergleichen Sie die Einträge in der Ausgabe des Befehls show bridge mit den Einträgen in der Befehlsausgabe show dlsw reachability. Beachten Sie, dass Einträge in der Ausgabe des Befehls show dlsw reachability im nicht-kanonischen Format im Gegensatz zum kanonischen Format wie auf Ethernet oder in der Befehlsausgabe show bridge erscheinen.
Allgemeine Informationen zur Fehlerbehebung bei Ethernet finden Sie unter Ethernet-Fehlerbehebung.
Hinweis: Der Abschnitt Dokumentinhalte dieser Dokumentreihe zeigt alle Bereiche der Serie an, um die Navigation zu erleichtern.
QLLC-Befehle werden in X.25-Paketen unter Verwendung des Q-Bit implementiert. X.25-Pakete, die QLLC-Primitive enthalten, sind in der Regel fünf Byte oder die Länge des X.25-Paket-Headers plus zwei Byte QLLC-Kontrollinformationen.
Hinweis: X.25-Datenpakete, die SNA-Daten (Systems Network Architecture) enthalten, verwenden das Q-Bit nicht.
Nachdem die QLLC-Verbindung hergestellt wurde, wird der eindeutige virtuelle Schaltkreis der X.25-Verbindung zum Weiterleiten von Datenverkehr verwendet. Logical Link Control (LLC) ist eine Teilmenge von High-Level Data Link Control (HDLC). Synchronous Data Link Control (SDLC) und QLLC sind ebenfalls Teilmengen von HDLC. Cisco wandelt diese QLLC-Primitive in LLC-Primitive um und umgekehrt:
QLLC | LLC |
QSM | GLEICH |
QXID | XID |
QDISC | DATENTRÄGER |
QUA | UA |
X.25-DATENPAKET | I-FRAME |
Eine normale QLLC/LLC-Verbindung wird mit dem Empfang eines X.25-EINGEHENDEN ANRUFS initiiert, der die QLLC Call User Data (CUD) (0xc3) enthält. Eine umgekehrte QLLC-Verbindung ist eine von einem LAN initiierte QLLC/LLC-Verbindung.
Hinweis: Für eine QLLC/LLC-Verbindung gibt es eine QLLC-Verbindung zwischen dem QLLC-Gerät und dem Router sowie eine LLC-Verbindung zwischen dem LAN-angeschlossenen Gerät und dem Router.
Abbildung 1 zeigt diese Sequenz:
Ein eingehender X.25-QLLC-Anruf wird mit einem X.25-ANRUF beantwortet, der vom Router VERBUNDEN wird.
Der Router sendet dann einen TEST-Frame (oder Explorer) an das LAN-Gerät, um die LAN-Verbindung zu initiieren.
Wenn der LAN-Partner gefunden werden kann, sendet der LAN-Partner eine Explorerantwort mit einem RIF (Routing Information Field), in dem die Identifizierung des LAN-Partners erläutert wird.
Der Router sendet dann eine Null-Exchange-ID (XID) an den LAN-Partner, unter der Annahme, dass das QLLC-Gerät XID-Aushandlung durchführen kann. (Die meisten SNA-Geräte können XID-Aushandlung durchführen.) Wenn das QLLC-Gerät die Aushandlung nicht selbst durchführen kann, bietet der Router ein XID-Proxy-Dienstprogramm an.
Das QLLC-Gerät sendet eine XID mit IDBLK und IDNUM, die mit IDNUM und IDBLK verglichen wird, die auf dem Host konfiguriert sind (schalteter Hauptknoten???PU).
Wenn die IDs übereinstimmen, sendet der Host ein Set Asynchronous Balanced Mode Extended (SABME).
Das SABME wird in einen QSM (Qualified Setup Response Mode) konvertiert, und das QLLC-Gerät sendet eine Qualified Unnumbered Acknowledgement (QUA).
Dieses QUA wird in eine LLC Unnumbered Acknowledgement (UA) umgewandelt und an den LAN-Partner gesendet.
An diesem Punkt besteht eine QLLC-Verbindung zwischen dem QLLC-Gerät und dem Router, zwischen dem Router und dem LAN-Gerät besteht eine LLC-Verbindung, und auf dem Router ist eine aktive QLLC/LLC-Verbindung vorhanden.
In einer Token Ring- oder Remote Source-Route Bridging (RSRB)-Umgebung tritt diese Sequenz auf:
Das mit dem LAN verbundene Gerät startet und sendet einen Upstream-Test. Anschließend sendet er ein NullxID-Paket Upstream.
Wenn QLLC diese Null-XID an eine X.25-angeschlossene FEP weiterleitet, antwortet der FEP, als ob er eine Verbindung mit einem PU 2.1-Gerät herstellen würde, und bricht die Verbindung ab, wenn das PU 2.0-Gerät als Nächstes ein XID-Format 0 Typ 2 sendet.
Der Befehl qllc npsi-poll fängt alle null-XID-Pakete ab, die das Cisco IOS? Software empfängt auf der LAN-Schnittstelle und gibt eine Null-XID-Antwort an das Downstream-Gerät zurück. Der Befehl qllc npsi-poll ermöglicht weiterhin Pakete im XID-Format 3 und im XID-Format 0 über das X.25-Gerät.
Der Router sendet ein CALL REQUEST-Paket, um die X.25-Verbindung zu initiieren, und er empfängt als Antwort das CALL ACCEPTED-Paket.
Das PU 2.0 SNA-Gerät sendet eine XID mit IDBLK und IDNUM, die mit IDBLK und IDNUM verglichen wird, die auf dem Host konfiguriert sind (geswitchter Hauptknoten????PU).
Wenn die IDs übereinstimmen, sendet der Host ein QSM. Das QSM wird in ein SABME konvertiert.
Das LAN-Gerät antwortet mit einem UA, der in ein QUA konvertiert und an den FEP gesendet wird.
An dieser Stelle gibt es folgende Punkte:
Eine QLLC-Verbindung zwischen dem QLLC-Gerät und dem Router
Eine LLC-Verbindung zwischen Router und LAN-Gerät
Eine aktive QLLC/LLC-Verbindung auf dem Router
Eine normale QLLC/LLC-Verbindung wird mit dem Empfang eines X.25-EINGEHENDEN ANRUFS initiiert, der den QLLC CUD (0xc3) enthält. Eine umgekehrte QLLC-Verbindung ist eine QLLC/LLC-Verbindung, die von einem LAN initiiert wird.
Abbildung 2 zeigt diese Abfolge:
Ein eingehender X.25-QLLC-Anruf wird mit einem X.25-ANRUF beantwortet, der vom Router VERBUNDEN wird.
Der Router sendet einen TEST-Frame (oder Explorer) an das LAN-Gerät, um die LAN-Verbindung zu initiieren.
Wenn der LAN-Partner gefunden werden kann, sendet der LAN-Partner eine Antwort des Explorers, in der er eine RIF mit einer Beschreibung seiner Vorgehensweise sendet.
Der Router sendet dann eine Null-XID an den LAN-Partner, unter der Annahme, dass das QLLC-Gerät XID-Aushandlung durchführen kann. (Die meisten SNA-Geräte können XID-Aushandlung durchführen.) Wenn das QLLC-Gerät die Aushandlung nicht selbst durchführen kann, bietet der Router ein XID-Proxy-Dienstprogramm an.
Die PU 2.1-Geräte tauschen XID3s aus, bis sie sich auf die primäre und sekundäre Rolle und andere PU 2.1-Parameter einigen.
Der PU 2.1-Knoten, der zum primären Knoten wird, stellt die Verbindung auf Verbindungsebene mit seinem PU 2.1-Partner her.
SABME wird in ein QSM und QUA in ein UA konvertiert.
Das PU 2.1 LAN startet und sendet einen Testrahmen. Wenn eine Testantwort vom Router empfangen wird, beginnt das Senden einer XID3 (oder einer NULL-XID, gefolgt von einer XID3).
Der Router sendet ein CALL REQUEST-Paket, um die X.25-Verbindung herzustellen. Ab diesem Zeitpunkt übersetzt es alle Nachrichten, die zwischen den beiden PU 2.1-Knoten von LLC2 in X.25 ausgetauscht werden.
Die PU 2.1-Geräte tauschen XID3s aus, bis sie sich auf die primäre und sekundäre Rolle und andere PU 2.1-Parameter einigen.
Der PU 2.1-Knoten, der zum primären Knoten wird, stellt die Verbindung auf Verbindungsebene mit seinem PU 2.1-Partner her.
SABME wird in ein QSM und QUA in ein UA konvertiert.
An dieser Stelle gibt es folgende Punkte:
Eine QLLC-Verbindung zwischen dem QLLC-Gerät und dem Router
Eine LLC-Verbindung zwischen Router und LAN-Gerät
Eine aktive QLLC/LLC-Verbindung auf dem Router
Zwischen RSRB über QLLC und DLSw im Vergleich zu QLLC bestehen große Unterschiede. Der vielleicht wichtigste ist, dass eine einheitliche Schnittstelle (Cisco Link Services [CLS]) zwischen dem DLSw und den verschiedenen verfügbaren Data-Link Controls (DLCs) vorhanden ist.
Bevor Sie einen der Debugbefehle in diesem Dokument versuchen, lesen Sie die Informationen unter Wichtige Informationen über Debug-Befehle.
Bei der Fehlerbehebung auf dem QLLC-Router wird die Ausgabe dieser Debugbefehle empfohlen:
debugdlsw-Kernmeldung
Debug-CLS-Meldung
x25-Debug-Ereignis
debug qllc status
debug qllc-Paket
Die Ausgabe dieser show-Befehle ist ebenfalls nützlich:
show cls
show qllc
Auf dem SDLC/DLSw-Peer-Router sind diese Debug-Befehle hilfreich:
debugdlsw-Kernmeldung
Debug-CLS-Meldung
In diesem Netzwerkdiagramm werden folgende Konfigurationen verwendet:
Konjack |
---|
X25 routing dlsw local-peer peer-id 10.3.2.7 dlsw remote-peer 0 tcp 10.3.2.8 ! interface Serial3 encapsulation x25 dce x25 address 9111 x25 ltc 10 x25 htc 4095 x25 map qllc 4000.0000.1111 1111 clockrate 19200 qllc dlsw vmacaddr 4000.0000.1111 partner 4000.0000.2222 |
Pivo |
---|
x25 routing ! dlsw local-peer peer-id 10.3.2.8 dlsw remote-peer 0 tcp 10.3.2.7 ! interface serial 0 no ip address encapsulation x25 dce x25 address 4444 x25 map qllc 4000.0000.2222 4444 qllc dlsw vmac 4000.0000.2222 partner 4000.0000.1111 |
Abbildung 3 zeigt, wie zwei IBM AS/400-Server über QLLC/DLSw kommunizieren können. vmacaddr 4000.000.111 ist die MAC-Adresse, die dem AS/400 (POW400) zugeordnet ist, und der Partner 4000.000.22222 ist die MAC-Adresse, die dem Remote-AS/4 zugeordnet ist. 0 (Canopus).
Weitere Informationen zum Befehl qllc dlsw finden Sie unter DLSw+-Konfigurationsbefehle.
Die TEST.STN REQ von DLSw zu QLLC sollte ein TEST.STN.IND-Paket ergeben, und das REQ OPEN STN REQ-Paket sollte eine ANRUFANFORDERUNG ergeben.
Die nächste Beispielausgabe zeigt die Debugausgabe mit Anmerkungen. Diese Debug-Befehle wurden ausgegeben:
debugdlsw-Kernmeldung
Debug-CLS-Meldung
debug qllc status
debug qllc-Paket
x25-Debug-Ereignis
Konjack# %DLSWC-3-RECVSSP: SSP OP = 3( CUR ) -explorer from peer 10.3.2.8(2065) !--- CUR_ex [Can You Reach (explorer)] is received from the peer. !--- (Note the -explorer.) DLSw starts to explore. 00:27:26: DLSW: DISP Sent : CLSI Msg : TEST_STN.Req dlen: 46 00:27:26: (DLSWDLU:DLU-->SAP): 00:27:26: TEST_STN.Req to pSAP: 0x5C733C sel: LLC hlen: 40, dlen: 46 00:27:26: DLSW: DISP Sent : CLSI Msg : TEST_STN.Req dlen: 46 00:27:26: (DLSWDLU:DLU-->SAP): 00:27:26: TEST_STN.Req to pSAP: 0x5C74A0 sel: LLC hlen: 40, dlen: 46 00:27:26: DLSW: DISP Sent : CLSI Msg : TEST_STN.Req dlen: 46 00:27:26: (DLSWDLU:DLU-->SAP): 00:27:26: TEST_STN.Req to pSAP: 0x5C7924 sel: LLC hlen: 40, dlen: 46 !--- There is a match on the destination MAC address in QLLC. 00:27:26: (DLSWDLU:CLS-->DLU): 00:27:26: TEST_STN.Ind to uSAP: 0x5C78BC sel: LLC hlen: 36, dlen: 35 00:27:26: DLSW Received-ctlQ : CLSI Msg : TEST_STN.Ind dlen: 35 !--- DLSw sends an ICR_ex [I Can Reach (explorer)] to the peer. %DLSWC-3-RECVSSP: SSP OP = 3( CUR ) from peer 10.3.2.8(2065) !--- CUR_cs [Can You Reach (circuit setup)] is received from the peer. 00:27:26: DISP Sent : CLSI Msg : REQ_OPNSTN.Req dlen: 102 !--- DLSw sends the CLS message Request Open Station Request to QLLC. 00:27:26: (DLSWDLU:DLU-->SAP): 00:27:26: REQ_OPNSTN.Req to pSAP: 0x5C7924 sel: LLC hlen: 48, dlen: 102 !--- QLLC places the call to the AS/400. 00:27:26: Serial3: X25 O P3 CALL REQUEST (13) 8 lci 10 00:27:26: From(4): 9111 To(4): 1111 00:27:26: Facilities: (0) 00:27:26: Call User Data (4): 0xC3000000 (qllc) !--- QLLC X.25 FSM handling Request Open Station Request !--- Output: Issues CALL REQUEST (see above), !--- Nothing to CLS/DLSw !--- Starts a 10000 msec timer !--- Enters State P2 (see X.25 standard) 00:27:26: QLLC-XFSM state P1, input QX25ReqOpenStnReq: (CallReq,-,XGo 10000) ->P2/D2 !--- QLLC receives CALL ACCEPT from the AS/400. 00:27:26: Serial3: X25 I P3 CALL CONNECTED (9) 8 lci 10 00:27:26: From(4): 9111 To(4): 1111 00:27:26: Facilities: (0) !--- QLLC X.25 FSM handling CALL ACCEPT !--- Output: Nothing to X.25 !--- Request Open Station Confirm to CLS/DLSw !--- Stops Timer !--- Enters State P4/D1 00:27:26: QLLC-XFSM state P2/D2, input QX25CallConfirm: (-,ReqOpenStnConf,xStop) ->P4/D1 00:27:26: QLLC: Serial3 I: QXID-CMD 0 bytes !--- QLLC Logical FSM Receives XID, send ID Indication to DLSw 00:27:26: QLLC-LFSM state QLClosed, input QLXID: (-,IdInd,LGo 3000) 00:27:26: (DLSWDLU:CLS-->DLU): 00:27:26: REQ_OPNSTN.Cfm(CLS_OK) to uCEP: 0x5CA310 sel: LLC hlen: 48, dlen: 102 00:27:26: (DLSWDLU:CLS-->DLU): 00:27:26: ID.Ind to uCEP: 0x5CA310 sel: LLC hlen: 40, dlen: 15 00:27:26: DLSW Received-ctlQ : CLSI Msg : REQ_OPNSTN.Cfm CLS_OK dlen: 102 !--- DLSw receives Request Open Station Confirm from QLLC. %DLSWC-3-SENDSSP: SSP OP = 4( ICR ) to peer 10.3.2.8(2065) success !--- DLSw sends ICR_cs [I Can Reach (circuit setup)] to the peer. %DLSWC-3-SENDSSP: SSP OP = 4( ICR ) to peer 10.3.2.8(2065) success !--- DLSw receives ID.Ind from QLLC. 00:27:26: DLSW Received-ctlQ : CLSI Msg : ID.Ind dlen: 15 !--- DLSw receives Reach ACK from the peer. %DLSWC-3-RECVSSP: SSP OP = 5( ACK ) from peer 10.3.2.8(2065) !--- DLSw receives XID from the peer. %DLSWC-3-RECVSSP: SSP OP = 7( XID ) from peer 10.3.2.8(2065) !--- DLSw sends ID.Req to QLLC. 00:27:26: DISP Sent : CLSI Msg : ID.Req dlen: 12 00:27:26: (DLSWDLU:DLU-->CEP): 00:27:26: ID.Req to pCEP: 0x4C51CC sel: LLC hlen: 40, dlen: 12 00:27:26: QLLC: Serial3 O: QXID-RSP 0 bytes !--- QLLC Logical FSM Handling ID.Req from CLS/DLSw. !--- Output: QLLC XID to X.25 !--- Nothing to CLS !--- No Timer Action 00:27:26: QLLC-LFSM state QLClosed, input CLSXID: (XId,-,-) !--- QLLC Receives XID from X.25 00:27:26: QLLC: Serial3 I: QXID-CMD 77 bytes Fmt 3T2: 056B4532 00:27:26: QLLC-LFSM state QLClosed, input QLXID: (-,IdInd,LGo 3000) 00:27:26: (DLSWDLU:CLS-->DLU): 00:27:26: ID.Cfm(CLS_OK) to uCEP: 0x5CA310 sel: LLC hlen: 40, dlen: 92 !--- DLSw receives ID Confirm from QLLC. 00:27:26: DLSW Received-ctlQ : CLSI Msg : ID.Cfm CLS_OK dlen: 92 !--- DLSw sends XID to the peer. %DLSWC-3-SENDSSP: SSP OP = 7( XID ) to peer 10.3.2.8(2065) success !--- DLSw receives XID from the peer. %DLSWC-3-RECVSSP: SSP OP = 7( XID ) from peer 10.3.2.8(2065) 00:27:27: DISP Sent : CLSI Msg : ID.Req dlen: 89 00:27:27: (DLSWDLU:DLU-->CEP): 00:27:27: ID.Req to pCEP: 0x4C51CC sel: LLC hlen: 40, dlen: 89 00:27:27: QLLC: Serial3 O: QXID-RSP 77 bytes Fmt 3T2: 05627844 00:27:27: QLLC-LFSM state QLClosed, input CLSXID: (XId,-,-) 00:27:27: QLLC: Serial3 I: QXID-CMD 77 bytes Fmt 3T2: 056B4532 !--- QLLC Logical FSM Handling ID.Req from CLS. !--- Output: Nothing to CLS !--- QLLC XID to X.25 !--- Timer started for 3000 msec 00:27:27: QLLC-LFSM state QLClosed, input QLXID: (-,IdInd,LGo 3000) !--- More XID negotiation. 00:27:27: (DLSWDLU:CLS-->DLU): 00:27:27: ID.Cfm(CLS_OK) to uCEP: 0x5CA310 sel: LLC hlen: 40, dlen: 92 00:27:27: DLSW Received-ctlQ : CLSI Msg : ID.Cfm CLS_OK dlen: 92 %DLSWC-3-SENDSSP: SSP OP = 7( XID ) to peer 10.3.2.8(2065) success %DLSWC-3-RECVSSP: SSP OP = 7( XID ) from peer 10.3.2.8(2065) 00:27:30: DISP Sent : CLSI Msg : ID.Req dlen: 12 00:27:30: (DLSWDLU:DLU-->CEP): 00:27:30: ID.Req to pCEP: 0x4C51CC sel: LLC hlen: 40, dlen: 12 00:27:30: QLLC: Serial3 O: QXID-RSP 0 bytes 00:27:30: QLLC-LFSM state QLClosed, input CLSXID: (XId,-,-) 00:27:30: QLLC: Serial3 I: QXID-CMD 77 bytes Fmt 3T2: 056B4532 00:27:30: QLLC-LFSM state QLClosed, input QLXID: (-,IdInd,LGo 3000) 00:27:30: (DLSWDLU:CLS-->DLU): 00:27:30: ID.Cfm(CLS_OK) to uCEP: 0x5CA310 sel: LLC hlen: 40, dlen: 92 00:27:30: DLSW Received-ctlQ : CLSI Msg : ID.Cfm CLS_OK dlen: 92 %DLSWC-3-SENDSSP: SSP OP = 7( XID ) to peer 10.3.2.8(2065) success %DLSWC-3-RECVSSP: SSP OP = 7( XID ) from peer 10.3.2.8(2065) 00:27:30: DISP Sent : CLSI Msg : ID.Req dlen: 89 00:27:30: (DLSWDLU:DLU-->CEP): 00:27:30: ID.Req to pCEP: 0x4C51CC sel: LLC hlen: 40, dlen: 89 00:27:30: QLLC: Serial3 O: QXID-RSP 77 bytes Fmt 3T2: 05627844 00:27:30: QLLC-LFSM state QLClosed, input CLSXID: (XId,-,-) 00:27:30: QLLC: Serial3 I: QXID-CMD 77 bytes Fmt 3T2: 056B4532 00:27:30: QLLC-LFSM state QLClosed, input QLXID: (-,IdInd,LGo 3000) 00:27:30: (DLSWDLU:CLS-->DLU): 00:27:30: ID.Cfm(CLS_OK) to uCEP: 0x5CA310 sel: LLC hlen: 40, dlen: 92 00:27:30: DLSW Received-ctlQ : CLSI Msg : ID.Cfm CLS_OK dlen: 92 %DLSWC-3-SENDSSP: SSP OP = 7( XID ) to peer 10.3.2.8(2065) success %DLSWC-3-RECVSSP: SSP OP = 7( XID ) from peer 10.3.2.8(2065) 00:27:30: DISP Sent : CLSI Msg : ID.Req dlen: 89 00:27:30: (DLSWDLU:DLU-->CEP): 00:27:30: ID.Req to pCEP: 0x4C51CC sel: LLC hlen: 40, dlen: 89 00:27:30: QLLC: Serial3 O: QXID-RSP 77 bytes Fmt 3T2: 05627844 00:27:30: QLLC-LFSM state QLClosed, input CLSXID: (XId,-,-) !--- AS/400 becomes primary and sends QSM to QLLC. 00:27:30: QLLC: Serial3 I: QSM !--- QLLC Logical FSM Handling QSM. !--- Output: Nothing !--- Connect.Ind to CLS/DLSw !--- Start Timer for 3000 msec !--- State QLogical Remote Opening 00:27:30: QLLC-LFSM state QLClosed, input QLSM: (-,ConnInd,LGo 3000) ->QLRemoteOpening 00:27:30: (DLSWDLU:CLS-->DLU): 00:27:30: CONNECT.Ind to uCEP: 0x5CA310 sel: LLC hlen: 40, dlen: 8 !--- DLSw receives CONNECT.Ind from QLLC and sends CON.Req to the peer. 00:27:30: DLSW Received-ctlQ : CLSI Msg : CONNECT.Ind dlen: 8 %DLSWC-3-SENDSSP: SSP OP = 8( CONQ ) to peer 10.3.2.8(2065) success !--- DLSw receives CON.Response from the peer and sends Connect Response to QLLC. %DLSWC-3-RECVSSP: SSP OP = 9( CONR ) from peer 10.3.2.8(2065) 00:27:30: DISP Sent : CLSI Msg : CONNECT.Rsp dlen: 20 00:27:30: (DLSWDLU:DLU-->CEP): 00:27:30: CONNECT.Rsp to pCEP: 0x4C51CC sel: LLC hlen: 42, dlen: 20 !--- QLLC Handling Connect Response from CLS/DLSw. !--- Output: QUA to X.25 !--- Conected.Ind to CLS/DLSw !--- State to QLOpened 00:27:30: QLLC: Serial3 O: QUA 00:27:30: QLLC-LFSM state QLRemoteOpening, input ConnectResponse: (UA,ConnectedInd,lStop) ->QLOpened 00:27:30: (DLSWDLU:CLS-->DLU): 00:27:30: CONNECTED.Ind to uCEP: 0x5CA310 sel: LLC hlen: 40, dlen: 8 00:27:30: DLSW Received-ctlQ : CLSI Msg : CONNECTED.Ind dlen: 8 Konjack# show dls reach DLSw MAC address reachability cache list Mac Addr status Loc. peer/port rif 4000.0000.1111 FOUND LOCAL P003-S000 --no rif-- 4000.0000.2222 FOUND REMOTE 10.3.2.8(2065) !--- 4000.0000.2222 was the partner.
In diesem Abschnitt werden einige der show-Befehle beschrieben, die auf dem Router ausgeführt werden können, auf dem QLLC/DLSw ausgeführt wird.
Führen Sie folgende Befehle aus, um die Möglichkeit zu vermeiden, dass das Problem hardwarebezogen ist:
show interface serial 0
Show Controller Serial 0
Show Controller-Bus
Überprüfen Sie die Router-Konfiguration: X.121-Adresse, Paketgröße, Modulnummer, Permanent Virtual Circuits (PVCs), Switched Virtual Circuits (SVCs) und Link Access Protocol Balanced (LAPB)-Parameter (wie Fenstergröße und Modulo).
Geben Sie den Befehl show interface serial in der X.25-Zeile ein, um den Status der Leitung und des Protokolls zu überprüfen. Line Down, Protokoll Down (DTR ist ausgefallen).
Geben Sie den Befehl show controller serial ein, und sehen Sie oben in der Ausgabe. Zeigt es das richtige Kabel an?
Für DCE-Router sollte DCE-RS-232 oder DCE-V.35 angezeigt werden (der Router emuliert ein Modem mit dem Befehl clockrate).
Für DTE-Router sollte DTE-RS-232 oder DTE-V.35 angezeigt werden (der Router ist mit einem DCE-Gerät verbunden, z. B. einem Modem oder einem Router, der ein Modem emuliert).
Überprüfen Sie die angeschlossenen Geräte, einschließlich der seriellen Platine, Modems, des Remote-Geräts und der Verkabelung. Wenn Sie die Verkabelung überprüfen, achten Sie auf folgende Punkte:
Das von Cisco bereitgestellte Kabel ist an die richtige Schnittstelle am Remote-Gerät angeschlossen.
Wenn der Router der DCE ist, ist das Kabel des Routers mit dem Kabel des DTE-Geräts verbunden.
Wenn die Leitung aktiv ist und das Protokoll ausgefallen ist, stellen Sie fest, ob es sich bei der Router-Schnittstelle um ein DCE oder ein DTE handelt. Die Uhr wird vom DCE bereitgestellt.
Wenn es sich bei der Router-Schnittstelle um ein DCE handelt, ist der Befehl clock rate konfiguriert?
Haben Sie die X.25-Kapselung konfiguriert?
Geben Sie den Befehl show interface serial 0 ein. Ist der LAPB-Status CONNECT?
Sind beide Seiten für Halbduplex oder Vollduplex konfiguriert?
Sind die X.25- und LAPB-Konfigurationsparameter korrekt, wenn die Leitung aktiv ist und das Protokoll aktiv ist? Diese Parameter müssen mit den für den X.25-Anbieter definierten Parametern übereinstimmen.
Stellen Sie sicher, dass diese X.25-Parameter korrekt sind:
X.121-Adressspezifikation
Eingabe- und Ausgabepaketgrößen (x25 IP und x25 ops)???Der Standardwert ist 128 Byte.
Fenstergrößen (x25 ohne und x25 win)???Der Standardwert ist 2.
Der Standardwert ist 8.
Aktivieren Sie den Wert für das größte QLLC-Paket (der Standardwert ist 256). Dieser Wert stimmt mit dem Wert überein, der auf dem Remote-SNA-Gerät konfiguriert wurde. Der gültige Bereich liegt zwischen 0 und 1024.
Stellen Sie sicher, dass diese LAPB-Parameter korrekt sind:
Größe des LAPB-Fensters (k)
LAPB-Bestätigungs-Timer (T1)
LAPB-Modul
QLLC-VMACs (virtuelle MAC-Adressen) sind X.121-Adressen korrekt zugeordnet
Ist die Zahl im Feld Set Asynchronous Balance Mode (SABM) größer als zehn? Aktivieren Sie das Feld show interface serial command output für das SABM-Anforderungsfeld. Es sollte immer mindestens ein SABM geben, aber nicht mehr als zehn. Wenn mehr als zehn SABMs vorhanden sind, reagiert der Paket-Switch wahrscheinlich nicht.
Überprüfen Sie die Modems, Kabel und Verbindungen zum X.25-Knoten. Rufen Sie den X.25-Anbieter auf, um die Konfiguration und den Status des X.25-Knotens zu überprüfen. Sie können ???loopback verwenden??? Modus, um ein Verbindungsproblem zu überprüfen.
Geben Sie den Befehl show interface serial mehrmals aus. Werden in einem der nächsten Felder die Zahlen erhöht oder groß? Betrachten Sie die große Zahl, wenn sie mehr als 0,5 Prozent der Anzahl an Informationsrahmen darstellt. Große Zahlen in diesen Feldern weisen auf ein mögliches Problem im X.25-Netzwerkanbieter hin (in diesem Fall muss die Leitungsqualität überprüft werden):
Anzahl der Zurückweisungen (REJs)
Anzahl der RNR-Ereignisse (Receive Not Ready)
Anzahl der Protokoll-Frame-Fehler (FRMR)
Anzahl Neustarts (RESTARTs)
Anzahl der Disconnects (DISCs)
Wenn Unteradressen verwendet werden, stellen Sie sicher, dass diese Konfigurationsanweisungen enthalten sind:
x25 routing x25 route ^xxx.*alias serial 0 - ? !--- Your interface number could be different. ! x25 routing !--- Enables x25 switching. ! x25 route !--- Add an entry to the X.25 routing table. ! interface serial y x25 alias ^xxx.*
Der xxx gibt die serielle 0-Adresse der Schnittstelle des X.25-Routers an.
Wenn Sie umgekehrte QLLC???Wo kommuniziert ein PU 2.0 LAN-Gerät mit einem IBM FEP, auf dem die NCP Packet Switching Interface (NPSI) X.25-Software ausgeführt wird??Fügen Sie diese Konfigurationsparameter der seriellen 0 hinzu:
Mit dem Befehl npsi-polll können keine NULL-XIDs an FEP gesendet werden. Sie ermöglicht eine Verbindung zwischen einer PU 2.0 auf der LAN-Seite und einem FEP, auf dem NPSI ausgeführt wird. Dieser Befehl ist erforderlich, da in einer Token Ring- oder RSRB-Umgebung die mit dem LAN verbundenen Geräte starten, indem sie ein NullxID-Paket Upstream senden. Wenn die Cisco IOS-Software diese Null-XID an eine X.25-angeschlossene FEP weiterleitet, antwortet der FEP, als ob er eine Verbindung mit einem PU 2.1-Gerät herstellen würde, und bricht die Verbindung, wenn die PU 2.0 als Nächstes ein XID-Format 0 Typ 2 sendet.
Der Befehl qllc npsi-poll fängt alle null-XID-Pakete ab, die die Software an der LAN-Schnittstelle empfängt, und gibt eine null-XID-Antwort an das Downstream-Gerät zurück. Es erlaubt weiterhin Pakete im XID-Format 3 und im XID-Format 0 über das X.25-Gerät.
Verwenden Sie PVCs und SVCs? Die PVC-Kanalspezifikationen müssen kleiner als jeder SVC-Bereich sein. Der Standardwert ist ein bidirektionaler Bereich zwischen 1 und 1024. Daher muss der niedrigste LTC-Wert (Two-Way Circuit) erhöht werden, um PVCs zu definieren. Wenden Sie sich an Ihren X.25-Anbieter, und konfigurieren Sie die virtuellen Schaltungen entsprechend der Anforderungen neu.
Sind die X.25 SVCs in dieser Reihenfolge konfiguriert?
Alle eingehenden unidirektionalen Schaltungen.
Alle bidirektionalen Schaltungen.
Alle ausgehenden Schaltungen in eine Richtung.
Mithilfe dieser Befehle können Sie die Parameter und den Status der Verbindung überprüfen:
show llc2
x25-Zuordnung anzeigen
x25 vc anzeigen
show qllc
Bevor Sie einen der Debugbefehle in diesem Dokument versuchen, lesen Sie die Informationen unter Wichtige Informationen über Debug-Befehle.
Wenn das X.25-Layer-2-Protokoll LAPB???in der Ausgabe des Befehls show interface serial????nicht den Status CONNECT aufweist, führen Sie den folgenden Befehl aus:
Debug-Laptop
Führen Sie bei der Fehlerbehebung von QLLC die folgenden Debug-Befehle aus:
debug qllc error
debug qllc-Ereignis
debug qllc-Paket
debug qllc status
debuggen qllc timer
debug qllc x25
debug x25 alle
x25-Debug-Ereignisse
Der Befehl debug x25 vc zeigt Informationen zum Datenverkehr für einen bestimmten virtuellen Schaltkreis an. Es ändert die Ausführung der Befehle debug x25 all oder debug x25 event, sodass einer dieser Befehle mit debug x25 vc ausgegeben werden muss, um Ausgabe zu erzeugen.
Für den DLSw-Peer-Router sind diese Debug-Befehle nützlich:
debugdlsw-Kernmeldung
Debug-CLS-Meldung
Die Ausgabe dieser show-Befehle ist ebenfalls nützlich:
show cls
show qllc
Die nächste, kurze Beispielausgabe ist ein QLLC-Start unter folgenden Umständen:
An einen IBM 3174 Establishment Controller ist ein stumpfes PU 2.0 coaxial angeschlossen.
Der 3174 verfügt über eine QLLC-Verbindung mit einem Router.
Der LAN-Partner ist ein IBM 3745 Communications Controller, und die PU führt 3270-Emulation durch.
Hinweis: Eine ausführlichere Erläuterung der X.25-Parameter und -Zustände finden Sie in den internationalen X.25-Standards-Spezifikationen im Protokollverzeichnis .
Serial0: I X25 P1 CALL REQUEST (11) 8 lci 20 From(8): 06431743 To(2): 64 Facilities (0) Call User Data (1): 0xC3 (qllc) Serial 0: X25 O P4 CALL CONNECTED (5) 8 lci 20 From(0): To(0): Facilities: (0) QLLC: allocating new qllc lci 20 QLLC: tx POLLING TEST, da 4000.3172.0002,sa 4000.011c.3174 QLLC: rx explorer response, da 4000.011c.3174, sa c000.3172.0002, rif 08B0.1A91.1901.A040 QLLC: gen NULL XID, da c000.3172.0002, sa 4000.011c.3174, rif 0830.1A91.1901.A040, dsap 4, ssap 4 QLLC: rx XID response, da 4000.011c.3174, sa c000.3172.0002, rif 08B0.1A91.1901.A040 Serial0 QLLC O: ADM XID Serial0: X25 O P4 DATA (5) Q 8 lci 20 PS 0 PR 0 Serial0: X25 I P4 RR (3) 8 lci 20 PR 1 Serial0: X25 I D1 DATA (25) Q 8 lci 20 PS 0 PR 1 Serial0 QLLC I: QXID-RSPQLLC: addr 01, ctl BF QLLC: Fmt 1T2: 01731743 QLLC: 4000.011c.3174DISCONNECT net <-SABME (NONE)6F QLLC: QLLC_OPEN : VMAC 4000.011C.3174 SERIAL0 QLLC O: QSM-CMD SERIAL0: X25 O D1 DATA (5) Q 8 LCI 20 PS 1 PR 1
Dies sind einige Erklärungen für diese Ausgabe:
I???? Ein Eingabepaket.
P1???Ein X.25-Status.
CALL REQUEST???Ein X.25-DTE-zu-DCE-Paket, das die X.25-Verbindung startet.
(11)??Die Länge des Pakets in Byte.
8?? gibt Modulo 8 an.
lci 20???Die von dieser Verbindung verwendete logische Kanalnummer X.25.
Von (8): 06431743??Die Anruferadresse mit acht Byte.
Bis(2): 64???Die 2 Byte lange angerufene Adresse.
(0)???Gibt an, dass keine Einrichtungen genutzt werden.
(1) 0xC3???Ein Byte X.25-Benutzerdaten, die eine QLLC-Verbindung anzeigen