Fehlerbehebung für DLSw: SDLC

Download-Optionen

  • PDF     (190.4 KB)
    Mit Adobe Reader auf verschiedenen Geräten anzeigen
  • ePub     (222.5 KB)
    In verschiedenen Apps auf iPhone, iPad, Android, Sony Reader oder Windows Phone anzeigen
  • Mobi (Kindle)     (373.5 KB)
    Auf einem Kindle-Gerät oder einer Kindle-App auf mehreren Geräten anzeigen
Aktualisiert:28. Januar 2008
Dokument-ID:17566

Inklusive Sprache

In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.

Informationen zu dieser Übersetzung

Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.

Einführung

Dieses Dokument unterstützt Sie bei der Behebung von Problemen, die in einem Netzwerk auftreten können, wenn ein mit SDLC (Synchronous Data Link Control) verbundenes Endgerät mit einem Rechenzentrum verbunden ist, z. B. über Data-Link Switching (DLSw).

Voraussetzungen

Anforderungen

Für dieses Dokument bestehen keine speziellen Anforderungen.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- oder 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 in den Cisco Technical Tips Conventions.

Fehlerbehebung bei SDLC

Geben Sie den Befehl show interface serial x am Router ein, um mit der Fehlerbehebung für SDLC zu beginnen. Die Ausgabe dieses Befehls enthält Informationen, mit denen Sie das Problem leichter finden können.

Serial1/0 is up, line protocol is up

!--- If line is down/down, then check CLOCKING. !--- If line is up/down, then check NRZI_ENCODING. !--- If line is cycling between up/up and up/down, then check DUPLEX. !--- A modem sharing device (MSD) uses full duplex.

   Hardware is CD2430 in sync mode
   Description SDLC PU2.1 PRIMARY 
   MTU 1500 bytes, BW 128 Kbit, DLY 20000 usec, rely 255/255, load 1/255
   Encapsulation SDLC, loopback not set
     Router link station role: PRIMARY (DCE)

!--- DCE has to provide the clock. It is responsible for raising DCD, CTS, !--- and DSR. Issue the show controllers command to check DTE, DCE, and !--- cable type.

     Router link station metrics:
       slow-poll 10 seconds
       T1 (reply time out) 3000 milliseconds

!--- The sdlc t1 
         command sets the amount of time waited !--- for an acknowledgement to an SDLC frame, where 
       
         is a !--- numeric value in milliseconds between 1 and 64000 (default is 3000). 
       

       N1 (max frame size) 12016 bits

!--- The sdlc n1 
         commands sets the maximum size of an !--- incoming frame, where 
       
         is a numeric value from 1 to 12000 !--- (default is 12000). 
       

       N2 (retry count) 20

!--- The sdlc n2 
         command sets the number of times that an !--- SDLC frame is sent before the session is terminated, where 
       
         !--- is a numeric value between 1 and 255 (default is 20). 
       

       poll-pause-timer 200 milliseconds

!--- Set this with the sdlc poll-pause-timer 
         command, !--- where 
       
         is a numeric value in milliseconds from 1 to 10000. !--- Set this value to a minimum of 2000 before you run SDLC debugs; otherwise, !--- you will flood the console with SDLC polling messages. 
       

       poll-limit-value 1

!--- Set this with the sdlc poll-limit-value 
         command, where 
       
         !--- is a numeric value from 1 to 10. !--- Use this command on multidrops to determine the number of polls that are !--- dedicated to each secondary device. Higher value allows a single secondary !--- to send more data but can decrease overall secondary servicing efficiency. 
       

       k (windowsize) 1
       modulo 8

!--- Set K with the sdlc k 
         command, where 
       
         is a !--- numeric value of 1 through 7 (if modulo 7) or 1 through 127 (if modulo 128). !--- rrrz sss0 !--- rrr = Frame number of the block that is expected to be received next !--- (rrrrrrr if modulo 128) !--- z = Poll/Final bit, which may be 0 or 1. !--- sss = Frame number of the block that is expected to be sent next !--- (sssssss if modulo 128) !--- The K value determines how many frames after which the poll bit is set to 1, !--- which indicates that it is the other side???s turn to send. 
       

       sdlc vmac: 4000.1555.21--
   sdlc addr 01 state is CONNECT

!--- Refer to SDLC States 
.
       cls_state is CLS_IN_SESSION

!--- See Table 1 ??? CLS States.

       VS 6, VR 6, Remote VR 6, Current retransmit count 0
       Hold queue: 0/200 IFRAMEs 2649/683
       TESTs 0/0 XIDs 0/0, DMs 0/0 FRMRs 0/0

!--- FRMRs could indicate a bug in the end station SDLC emulation package. !--- Check the values in the FRMR frame against the FRMR frame description.

       RNRs 1797153/2291 SNRMs 222/0 DISC/RDs 12/0 REJs 0/0

!--- If you see a steady increase in RNRs, then check for congestion on the DLSw !--- peer (the value under the TCP column in show dlsw peer command output). !--- If RNRs are greater than 50 percent of the default TCP queue depth 200, then !--- there is congestion.

       Poll: clear, Poll count: 0, ready for poll, chain: 01/01
   Last input 00:00:00, output 00:00:00, output hang never
   Last clearing of "show interface" counters never
   Queueing strategy: fifo
   Output queue 0/40, 0 drops; input queue 0/75, 0 drops

!--- Check that the input and output queues are not wedged (41/40 or 76/75). !--- If the queue is wedged, then the router usually must be reloaded to recover.

   5 minute input rate 0 bits/sec, 4 packets/sec
   5 minute output rate 0 bits/sec, 4 packets/sec
      2857443 packets input, 5738306 bytes, 0 no buffer
      Received 409483 broadcasts, 0 runts, 0 giants, 0 throttles
      1 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 1 abort

!--- Giants and input errors might indicate a wrong NRZI value (NRZI-ENCODING).

      2857874 packets output, 6029620 bytes, 0 underruns
      0 output errors, 0 collisions, 60523 interface resets
      0 output buffer failures, 0 output buffers swapped out
      53 carrier transitions
      DCD=up  DSR=up  DTR=up  RTS=down  CTS=up

!--- RTS and CTS are always up, with full duplex. !--- RTS and CTS will cycle between up and down, with half duplex.
Tabelle 1:? CLS-Staaten

Staat Bedeutung
CLS_STN_CLOSED Es wurde noch kein Aktivierungsprozess für den Posten gestartet.
CLS_ROSCNF_PEND ReqOpenStn wurde an PU gesendet. Erwartung von ReqOpenStnCfm.
CLS_STN_GEÖFFNET ReqOpenStnCfm von PU empfangen.
CLS_CONNECT_RSP_PEND SNRM gesendet; Warten auf UA von PU.
CLS_DISCCNF_PEND PU sendet DISK (falls primär) oder RDISC (falls sekundär).
CLS_CONNECT_REQ_PEND Warten auf eine Verbindungs-Antwort.
CLS_FULL_XID_PEND Warten auf eine Antwort auf die gesendete Null-XID.
CLS_CONNECTED_IND_PEND Connect.Rsp, vom DLU empfangen
CLS_DISK_IND_SENT Disconnect.Ind wurde gesendet.
CLS_IN_SESSION Schaltanlage ist abgeschlossen.
CLS_CLOSING Cisco Link Services (CLS) befindet sich in einem Abschlusszustand.

PU-Typ

Bei SDLC-angeschlossenen Controllern ist es wichtig, den verwendeten Physical Unit (PU)-Typ (z. B. PU 2.0 oder PU 2.1) und die SDLC-Rolle zu kennen.

Tabelle 2 zeigt einige der gängigsten Geräte und den entsprechenden PU-Typ. Der PU-Typ legt die Konfiguration fest, die übernommen werden soll, wie im Abschnitt PU 2 mit der Rolle "SDLC Station auf Sekundäres festgelegt" veranschaulicht.

Tabelle 2? Geräte-PU-Typen

Gerät PU-Typ
5294 1
5394 1
5394 +RPQ 8Q0775 2,1
5494 2,1
3276 2,0
3274 2,0
3174 2,0/2,1
3745 4
3172 Kein PU XCA-Knoten
S/38 2,0
36XX 2,0
Netware/SAA 2,0/2,1
SNA-Server NT 2,0/2,1

PU 2 mit SDLC Station Role Set to Secondary 

interface serial x

encapsulation sdlc 
sdlc role primary

!--- Assumes SDLC station role secondary for the attached SDLC controller.

sdlc vmac 1234.3174.0000

!--- Virtual MAC address given to the SDLC controller, which has the !--- SDLC address (D2) appended to it.


!--- For more information about the sdlc vmac command, refer to !--- LLC2 and SDLC Commands.

sdlc address D2

!--- SDLC address obtained from SDLC controller configuration.

sdlc xid D2 01730020

!--- D2 is the SDLC address, and 01730020 is the IDBLK and IDNUM, which is !--- obtained from the Switched Major Node on the host.

sdlc partner 1000.5aed.1f53 D2

!--- 1000.5aed.1f53 is the MAC address of the host, and D2 is the SDLC address.

sdlc dlsw D2

PU 2 mit SDLC Station-Rolle auf "Primär" eingestellt 

interface serial x

sdlc role secondary
sdlc vmac 1234.3174.0000
sdlc address D2
sdlc xid D2 01730020
sdlc partner 1000.5aed.1f53 D2
sdlc dlsw D2

Knoten-Typ 2.1 mit SDLC-Stationsrolle auf Negotiated oder Primary eingestellt 

interface serial x

encapsulation sdlc
sdlc role none
sdlc vmac 1234.3174.0000
sdlc address D2
sdlc partner 1000.5aed.1f53 D2
sdlc dlsw D2

Knotentyp 2.1 mit sekundärer Rolle der SDLC-Station 

interface serial x

encapsulation sdlc
sdlc role prim-xid-poll
sdlc vmac 1234.3174.0000
sdlc address D2
sdlc partner 1000.5aed.1f53 D2
sdlc dlsw D2

Hinweis: Bei Multi-Drop-SDLC für PU 2.0 oder PU 2.1 und einer Kombination aus PU 2.0 und PU 2.1 finden Sie Informationen im DLSw+ mit SDLC Multidrop Support Configuration Example im Abschnitt Configuring Data-Link Switching Plus.

PU 4.0 mit SDLC 

interface serial x

no ip address
encapsulation sdlc
no keepalive
clock rate 19200 
sdlc vmac 4000.3745.0100
sdlc address 01 seconly
sdlc partner 4000.3745.2176 01
sdlc dlsw 1

Weitere Informationen zu SDLC in Logical Link Control, Typ 2 (LLC2)-Konvertierung für Format Indicator 4 (FID4)-Frames finden Sie unter DLSw+ FID4 LLC2-to-SDLC-Konvertierung für PU4/5-Geräte.

Cisco Link Services und SDLC stehen in direktem Zusammenhang. Bei Cisco Link Services treten erst dann Änderungen auf, wenn der normale Antwortmodus (Set Normal Response Mode, SNRM) durch eine nicht nummerierte Bestätigung (Unnumbered Acknowledgment, UA) bestätigt wird. Nach Erhalt einer UA sendet der Router einen Receiver Not Ready (RNR, USBUSY) an die SDLC-Station, um ihn ruhig zu halten, während DLSw den DLSw-Schaltkreis mit dem Host (primäre SDLC-Rolle) aufruft. Der SDLC-Code sendet eine Null-Exchange-Identifikation (XID) intern an den Cisco Link Services-Code, um dies zu initiieren. Folgende Status von Cisco Link Services sind zu sehen:

  • CLS_STN_CLOSED????Der CANUREACH-Explorer (CUR-ex) wird an den DLSw-Peer gesendet, aber eine ICANREACH-Explorer-Antwort (ICR-ex) ist noch nicht eingegangen. Das Problem ist wahrscheinlich eine falsche MAC-Adresse, oder der Host-Adapter ist nicht offen oder aktiv.

  • CLS_STN_OPENED???Eine NULL-XID wird gesendet, erhält aber keine Antwort vom Host. Das Problem ist wahrscheinlich ein falsches Ziel-Service Access Point (SAP), oder es sind keine logischen Leitungen verfügbar.

  • CLS_CONNECT_REQ_PEND???Eine SNA-XID (Systems Network Architecture) wird gesendet, und der Host gibt keine Antwort. Das Problem ist wahrscheinlich ein Switch-Hauptknoten, der nicht korrekt, nicht aktiv oder von einem anderen Gerät aktiviert ist.

Häufige SDLC-Probleme

In diesem Abschnitt werden einige der häufigsten Probleme von SDLC aufgeführt.

Falsche SDLC-Adresse

Die auf dem Router konfigurierte SDLC-Adresse muss mit der SDLC-Adresse des angeschlossenen SDLC-Controllers übereinstimmen. Beispiel: Bei einem Cluster-Controller 3174 ist dies die Konfigurationsleitungsnummer 104. Wenn der Router für die primäre SDLC-Rolle konfiguriert ist und der SDLC-Status in SNRMSENT feststeckt, können die beiden Adressen möglicherweise nicht übereinstimmen. Ein nützlicher Befehl zum Testen der SDLC-Leitung und des Controllers ist sdlc-Testseriell. Weitere Informationen finden Sie unter sdlc test serial in LLC2- und SDLC-Befehlen. Ähnlich wie IP-Ping sendet es zehn Testrahmen. Wenn alle zehn empfangen werden, gilt der Test als "???pass??? Bei diesem Test wird auch überprüft, ob Sie über die richtige Codierung verfügen (NRZ oder NRZI). Weitere Informationen finden Sie unter nrzi-Codierung in Serial Port Setup Commands. Ähnlich wie bei den SDLC-Adressparametern muss auch die Codierung auf der seriellen Router-Schnittstelle und auf dem SDLC-Controller erfolgen. Im Beispiel eines 3174 lautet dies für die Konfigurationsleitungsnummer 313: 0 bedeutet NRZ und 1 steht für NRZI. Der Standardwert auf dem Router ist 0 (NRZ).

DCE sendet einen DSR anstelle eines DCD-Signals.

Ein weiteres häufig auftretendes Problem von SDLC ist die Verwendung von DCE oder DTE sowie die Überwachung von Problemen. In der Regel stellt der Cisco Router die Taktgebung bereit und hat ein DCE-Kabel angeschlossen. Dadurch fungiert die serielle Router-Schnittstelle als DCE und der angeschlossene Controller fungiert als DTE. Diese Konfiguration kann auch umgekehrt werden: an der seriellen Schnittstelle des Routers ist ein DTE-Kabel angeschlossen, und der angeschlossene Controller stellt die Uhr bereit. Wenn die serielle Schnittstelle im DTE-Modus betrieben wird, wird das DCD-Signal standardmäßig als Anzeige für das Auf- oder Abfahren der Leitung überwacht. In der Regel sendet das angeschlossene DCE-Gerät das DCD-Signal. Wenn die DTE-Schnittstelle das DCD-Signal erkennt, ändert sie den Status der Schnittstelle in aktiv. In einigen Konfigurationen, z. B. in einer SDLC-Multidrop-Umgebung, sendet das DCE-Gerät das DSR-Signal anstatt des DCD-Signals, wodurch die Schnittstelle nicht aktiviert werden kann. Führen Sie den Befehl ignore-dcd im Schnittstellenkonfigurationsmodus aus, um die Schnittstelle zur Überwachung des DSR-Signals anstelle des DCD-Signals als Anzeige für das Auf- oder Abklappen der Leitung zu erhalten. Weitere Informationen finden Sie unter Ignore-dcd Serielle Port-Setup-Befehle.

DTE löst kein DTR-Signal aus.

Wenn die serielle Schnittstelle des Routers als DCE fungiert, kann ein Problem darin bestehen, dass die DTE das DTR-Signal nicht auslöst. Dies kann durch die letzte Zeile der Anzeigeausgabe des Befehls show interface überprüft werden. Das Problem kann auf eine fehlerhafte Verkabelung zurückzuführen sein, die auf eine falsche Pinbelegung (siehe Hardwarespezifikationen und Kabelbelegungen) oder darauf zurückzuführen ist, dass der SDLC-Controller nicht ordnungsgemäß hochgefahren wird. Verwenden Sie eine Breakout-Box, um alle Signale von der DCE- und der DTE-Seite zu überprüfen. Um den Kabeltyp zu bestimmen, der an die serielle Schnittstelle des Routers angeschlossen ist, führen Sie den Befehl show controller serial aus. Weitere Informationen finden Sie unter Serielle Controller in den Schnittstellenbefehlen.

Vollduplex- oder Halbduplex-Betrieb

Die Duplexgeschwindigkeit ist ein weiterer häufiger Grund für SDLC-Verbindungen. Die Router-Schnittstelle und der SDLC-Controller müssen über identische Duplexgeschwindigkeits-Einstellungen verfügen: entweder halb oder voll. Beispiel: Bei einem Cluster-Controller 3174 ist dies die Konfigurationsleitungsnummer 318: 0 steht für Vollduplex-Geschwindigkeit, 1 für Halbduplex-Geschwindigkeit. Für die serielle Router-Schnittstelle wird standardmäßig Vollduplex verwendet. Wenn der Router an ein Modem Sharing Device (MSD) angeschlossen ist, sollten die serielle Schnittstelle des Routers und das MSD Vollduplex ausführen. Weitere Informationen finden Sie im Abschnitt Configure an SDLC Interface for Half-Duplex Mode unter Configuring LLC2 and SDLC Parameters.

Beispiel für Sitzungseinrichtungsflüsse für ein PU 2.0-Gerät

dlswts6_a.gif

Beispiel für Sitzungseinrichtungsflüsse für ein PU 2.1-Gerät

dlswts6_b.gif

Debuggen von SDLC-Ereignissen oder -Paketen

Die gängigsten Debug-Befehle für SDLC sind Debug-sdlc-Ereignis und Debug-sdlc-Paket. Sie können verwendet werden, wenn kein SDLC-Analyzer verfügbar ist und eine schnelle Diagnose erforderlich ist. Wenn mehrere SDLC-Adressen konfiguriert sind, können Sie für alle Adressen Debug-Ausgaben erhalten. Verwenden Sie das Debug-sdlc-Ereignis, das jedes Paket anzeigt, statt sdlc-Paket zu debuggen, das nur Ereignisse anzeigt.

Hinweis: Wenn Sie über mehrere serielle SDLC-Schnittstellen verfügen, generiert der Befehl Debug über alle in SDLC konfigurierten Schnittstellen.

Führen Sie die folgenden Befehle aus, um die Ausgabe auf nur eine Schnittstelle zu beschränken:

  • debug list serial x , wobei x die Schnittstellennummer ist

  • debuggen sdlc-Ereignis

Führen Sie den Befehl debug sdlc packet nicht aus, da er den Filter umgeht.

caution Vorsicht: Der Befehl debug sdlc kann zu schweren Leistungseinbußen führen, insbesondere wenn er auf einem Router ausgeführt wird, auf dem mehrere SDLC-Adressen konfiguriert sind. Bevor Sie diesen debug-Befehl versuchen, lesen Sie die Informationen unter Wichtige Informationen über Debug-Befehle.

SDLC-Frame-Formate

dlswts6_c.gif

SDLC-Pakete während des DLSw mit SDLC für PU 2.1

dlswts6_d.gif 

%LINK-3-UPDOWN: Interface Serial1, changed state to up

Nachdem Sie den Befehl debug sdlc packet ausgegeben haben, treten folgende Ereignisse auf:

  1. Eine XID oder BF wird an die SDLC-Broadcast-Adresse FF gesendet.

    Serial1 SDLC output???????? FFBF

  2. Eine XID wird vom 5494 ausgegeben. Dies ist ein XID-Format 3 Typ 2, das Sie mit dem Befehl debug sdlc packet anzeigen können.

    Serial1 SDLC input
0046C930: DDBF3244 073000DD 0000B084 00000000?? ...........d....
0046C940: 00000001 0B000004 09000000 00070010?? ................
0046C950: 17001611 01130012 F5F4F9F4 F0F0F2F0?? ........54940020
0046C960: F0F0F0F0 F0F0F0F0 0E0CF4D5 C5E3C14B?? 00000000..4NETA.
0046C970: C3D7F5F4 F9F4?????????????????????????????????????????????? CP5494

    Obwohl dieses Dokument nicht die vollständigen Details für die Analyse dieser XID enthält, handelt es sich um eine Beschreibung einiger der Felder:

    • 073000DD???Die Block-ID und die ID-Nummer, die im 5494 konfiguriert ist. Zusammen werden sie als XID bezeichnet und vom 5494 während der Sitzungsverhandlung an den Peer gesendet.

    • NETA?? Der verwendete Advanced Peer-to-Peer Networking (APPN) Network Identifier (NETID). Normalerweise sollte sie mit der im Peer konfigurierten NETID übereinstimmen. In diesem Fall ist der Peer ein AS/400.

    • CP5494???Der Kontrollpunktname des 5494.

  3. Die XID wird vom AS/400 ausgegeben.

    Serial1 SDLC output
004BC070:???????? FFBF 324C0564 52530000 000A0800?????? ...<..........
004BC080: 00000000 00010B30 0005BA00 00000007?? ................
004BC090: 000E0DF4 D5C5E3C1 4BD9E3D7 F4F0F0C1?? ...4NETA.RTP400A
004BC0A0: 1017F116 11011300 11F9F4F0 F4C6F2F5?? ..1......9404F25
004BC0B0: F1F0F0F0 F4F5F2F5 F3460505 80000000?? 100045253.......
004BC0C0:
SERIAL1 SDLC INPUT
0046C270:???????????????????????????????????? DDBF3244 073000DD?????????????????? ........
0046C280: 0000B084 00000000 00000001 0B000004?? ...D............
0046C290: 09000000 00070010 17001611 01130012?? ................
0046C2A0: F5F4F9F4 F0F0F2F0 F0F0F0F0 F0F0F0F0?? 5494002000000000
0046C2B0: 0E0CF4D5 C5E3C14B C3D7F5F4 F9F4?????????? ..4NETA.CP5494
SERIAL1 SDLC OUTPUT
004C0B10:???????? FFBF 324C0564 52530000 00F6C800?????? ...<.......6H.
004C0B20: 00000080 15010B10 0005BA00 00000007?? ................
004C0B30: 000E0DF4 D5C5E3C1 4BD9E3D7 F4F0F0C1?? ...4NETA.RTP400A
004C0B40: 1017F116 11011300 11F9F4F0 F4C6F2F5?? ..1......9404F25
004C0B50: F1F0F0F0 F4F5F2F5 F3460505 80150000?? 100045253.......
004C0B60:
SERIAL1 SDLC INPUT
0046BBC0: DDBF3244 073000DD 0000B084 00000000?? ...........D....
0046BBD0: 00000001 0B000004 09000000 00070010?? ................
0046BBE0: 17001611 01130012 F5F4F9F4 F0F0F2F0?? ........54940020
0046BBF0: F0F0F0F0 F0F0F0F0 0E0CF4D5 C5E3C14B?? 00000000..4NETA.
0046BC00: C3D7F5F4 F9F4?????????????????????????????????????????????? CP5494

    • 05645253??Die Block-ID und die ID-Nummer des AS/400.

    • RTP400A???Der Kontrollpunktname des AS/400.

      Dies finden Sie in der Datei Display Network Attributes (DSPNETA) auf dem AS/400.

  4. SNRM (93) und UA (73) sind auf der Leitung zu sehen. Vor dem SNRM verwendete der Router immer die Broadcast-Adresse. Daher verwendet der Router immer die tatsächliche Polling-Adresse von DD.

    Serial1 SDLC output???????? DD93
Serial1 SDLC input?????????? DD73
Serial1 SDLC output???????? DD11
Serial1 SDLC input?????????? DD11

    Wenn Sie den Controller auf dem AS/400 abweichen, werden auf der SDLC-Seite der Sitzung die Diskette (53) und die UA (73) angezeigt.

    Serial1 SDLC output DD53
Serial1 SDLC input

    Die übrigen Debugging-Elemente wurden weggelassen.

Zugehörige Informationen

War dieses Dokument hilfreich?

FeedbackFeedback

Cisco kontaktieren