Konfiguration und Fehlerbehebung für Serial Tunneling (STUN)

Einführung

Serial Tunneling (STUN) ist das Tunneling von SDLC-Frames über ein WAN. In der Welt der herkömmlichen Systemnetzwerkarchitektur (SNA) werden Remote-Controller über eine Reihe von Modems, die über POTS (Plain Old Telefone Service) oder Mietleitungen angeschlossen sind, mit dem Front-End-Prozessor (FEP) verbunden.

Bevor Sie beginnen

Konventionen

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

Voraussetzungen

STUN SDLC wird am häufigsten in zwei Umgebungen verwendet: FEP für Remote-Controller und AS/400 für Remote-Controller.

Verwendete Komponenten

STUN Sie die Fehlerbehebung mithilfe der Cisco IOS® Software-Befehle sowie der AS/400-Funktion für den Remote-Controller.

Hintergrundinformationen

Da Netzwerke in Richtung Integration streben und Außenstellen unterschiedliche Arten von Services benötigen (z. B. NetBIOS, IP, IPX), war es aus Wartungs- und Kostensicht sinnvoll, all diese Services in einem einzigen Gerät zu integrieren. Im folgenden Diagramm wird beispielsweise die Integration von 3270 Terminals in den Host mit NetBIOS-Datenverkehr von Windows-Stationen dargestellt.

Mit STUN können Sie IP als Transport für SDLC-Frames (Synchronous Data Link Control) in einem WAN oder einem anderen Mediennetzwerk verwenden. Somit ist keine zusätzliche Mietleitung oder ein POTS erforderlich. Eine SDLC-Funktion von Cisco Routern ist die Medienübersetzung. Bei der Medienübersetzung übersetzt der Router die Sitzung von SDLC in Logical Link Control, Typ 2 (LLC2). Dies wird ausführlich unter Grundlagen und Fehlerbehebung bei der Übersetzung von SDLC-zu-LLC-Netzwerkmedien beschrieben.

Es gibt zwei Arten von STUN-Konfigurationen: STUN Basic und STUN SDLC. Ersteres wird für jeden abgeleiteten Frame des High-Level Data Link Control (HDLC)-Typs verwendet, und letzteres wird nur für Frames in SDLC verwendet. STUN Basic kann auch für SDLC verwendet werden, Funktionen wie Local-ack können jedoch nicht verwendet werden. Es ist üblich, STUN Basic für SDLC zur Fehlerbehebung zu verwenden, da SDLC-spezifische Parameter nicht auf dem Router konfiguriert werden müssen.

STUN-Konfiguration

Der erste Befehl für eine STUN-Konfiguration (Basic oder SDLC) ist ein Stun-Peer-Name. Ohne betäubten Peer-Namen können Sie die Konfigurationsschritte nicht fortsetzen.

stun peer-name ip-address

Sie müssen eine gültige IP-Adresse vom Router auswählen. Diese IP-Adresse sollte die zuverlässigste Schnittstelle im Paket sein. Konfigurieren Sie den Router mit einer Loopback-Schnittstelle, um die besten Ergebnisse zu erzielen. (Informationen zum Konfigurieren von Loopback-Schnittstellen.

Im nächsten Schritt wird der STUN-Modus bestimmt, den Sie verwenden möchten. Ein Modus ist STUN Basic, in dem es nach Start und Delimiter des Frames [7e] sucht und den Frame zur anderen Seite transportiert. In diesem Betriebsmodus ist es STUN nicht wichtig, den spezifischen Status der Sitzung oder detaillierte SDLC-Informationen, wie die Abfragesprache, anzugeben. Der andere Modus ist STUN SDLC. Dieser Modus erfordert detailliertere Entscheidungen im Router, insbesondere wenn Sie eine lokale Bestätigung oder einen beliebigen Multipoint-Typ ausführen. Die Befehle zum Angeben eines STUN-Modus werden in der folgenden Tabelle beschrieben:

stun protocol-group group-number basic 

stun protocol-group group-number sdlc

Im nächsten Schritt wird die serielle Schnittstelle für STUN konfiguriert. Die Gruppe, die Sie in der Schnittstelle auswählen, muss mit der Gruppe übereinstimmen, die in der Protokollgruppe definiert ist. Bei virtuellen Multipoints sollten Sie auch eine Stun-Protokoll-Gruppe mit unterschiedlichen Zahlen für jeden der virtuellen Multipoints erstellen. Vergewissern Sie sich immer, dass Sie nur eine sekundäre Schnittstelle pro Stun-Gruppe konfiguriert haben, es sei denn, Sie konfigurieren sdlc-tg. Siehe Stun protocol-group.

encapsulation stun

stun group group-number

Hinweis: Konfigurieren Sie dies während der Produktionsnetzwerkzeit nicht auf einem Cisco 7000, Cisco 7500 oder einem anderen Router, der über CxBUS, CyBUS verfügt. Diese Konfiguration veranlasst den Router, die MTU der Schnittstelle auf 2032 Byte zu ändern. Dies führt zu einer CBUS-Pufferkarve und macht alle Schnittstellen des Router-Bounce (Reset). In einer Token Ring-Umgebung kann dies bedeuten, dass die Token Rings bis zu 16 Sekunden lang ausfallen. Darüber hinaus ist der Cisco 7000 häufig das Herzstück, von dem viele Benutzer von dieser Art von Problem betroffen sind.

Der nächste Schritt bei der Konfiguration von STUN besteht darin, die Betäubungs-Route-Anweisung hinzuzufügen. Sie können dies als Betäubungsroute für alle oder als Betäubungsroute [address] definieren. Die Konfigurationsoptionen werden nachfolgend erläutert.

stun route all tcp ip-address

stun route address address-number tcp ip-address [priority] [tcp-queue-max]

Die obigen Befehle gelten für TCP-Kapselungs-Peers. Sie können STUN auch für die direkte Kapselung konfigurieren, aber diese Konfiguration wird selten verwendet. Die gängigste aller Konfigurationen ist die Einrichtung der lokalen STUN-Bestätigung.

Diese Befehlsparameter werden nachfolgend beschrieben:

• Die Prioritätsoption in der Betäubungs-Route-Anweisung wird verwendet, um mehrere TCP-Pipes zwischen zwei STUN-Peers zu erstellen, sodass Prioritätsstrukturen mithilfe benutzerdefinierter Warteschlangen oder Prioritätswarteschlangen erstellt werden können.

• Die Option tcp_queue_max erhöht oder verringert die TCP-Warteschlangen zwischen den beiden STUN-Peers. Dies ist nützlich, wenn die TCP-Sitzung zwischen den Peers nicht sehr zuverlässig ist und Sie feststellen müssen, was zwischen den Peers falsch ist. Diese Option wird in STUN-Umgebungen nicht häufig verwendet, außer bei STUN FEP-to-FEP, bei dem viel mehr Datenverkehr involviert ist.

Die Befehle zum Konfigurieren von STUN mit lokaler Bestätigung werden nachfolgend beschrieben.

stun sdlc-role primary

stun sdlc-role secondary

Diese Befehle definieren die "Rolle" des STUN-Setups. Im Fall des Hosts im obigen Diagramm ist der Router auf primär festgelegt, d. h. der Host ist derjenige, der die Sitzung initiiert. Damit ist der 3174 sekundär. Wenn Sie STUN Basic verwenden, müssen Sie die Rolle nicht definieren, da Sie nicht wissen müssen, wer die Sitzung initiieren wird. Für die lokale Bestätigung sind jedoch Details der Leitung selbst erforderlich. Durch die Definition der Rolle kann der Router den Start der Sitzung erkennen, den der Router überprüfen muss, bevor er zur lokalen Bestätigung übergeht.

Hinweis: In AS/400-STUN-Umgebungen, in denen eine lokale Bestätigung erfolgt, ist es sehr wichtig, die Rolle (in der Leitungsbeschreibung) auf *pri von *neg festzulegen. Der Grund dafür ist, dass das AS/400 in einer reinen Umgebung (direkte Modemverbindung) die Rolle aushandeln kann. Durch die Kodierung der Rolle, die wir in der Leitung übernehmen, können Sie sicherstellen, dass die Rolle des Routers dem AS/400 entgegensteht. In der Regel sollte die Sitzung vom AS/400 initiiert werden (wobei "variieren" auf der Leitung). Rufen Sie die Leitungskonfiguration auf, und richten Sie sie für *pri ein. Die Beschreibung der Angebotsposten für AS/400 wird unten angezeigt. Dies kann nur während der Erstellung/Kopie der Zeilenbeschreibung erfolgen.

Der Befehl zum Konfigurieren von STUN mit lokaler Bestätigung wird nachfolgend erläutert.

stun route address address-number tcp ip-address [local-ack] [priority] [tcp-queue-max]

Der wichtige Parameter ist hier die Betäubungsroute [address] mit local-ack. Denken Sie daran, dass die lokale STUN-Lösung mit TCP-Kapselung und Frame-Relay-Kapselung (unter Verwendung von RFC 1490) durchgeführt werden kann.

Wie bei RSRB und DLSw wird der STUN-Fluss zwischen den TCP-Peers beibehalten, um sicherzustellen, dass die Peer-Verbindung aktiv ist. Sie können die Keepalives abstimmen, wenn Ihre Peers wegen Keepalive-Verlustes heruntergefahren/hochgefahren werden. Die zum Konfigurieren von Keepalives verwendeten STUN-Befehle werden nachfolgend beschrieben:

stun remote-peer-keepalive seconds

Grundlegende STUN-Beispielkonfiguration

STUN Basic ist die einfachste Konfiguration von STUN. In diesem Modus werden alle Pakete, die der Router von einer Seite empfängt, zur nächsten übertragen. Eine STUN-Basiskonfiguration wird im Diagramm unten gezeigt:

Die Router im obigen Diagramm sind wie folgt konfiguriert:

Current configuration:
!
version 10.3
service udp-small-servers
service tcp-small-servers
!
hostname s5e
!
stun peer-name 10.17.5.1
stun protocol-group 1 basic
!
interface Loopback1
 no ip address
!
interface Serial0
 ip address 10.17.5.1 255.255.255.0
 clockrate 2000000
!
interface Serial1
 no ip address
 encapsulation stun
 nrzi-encoding
 clockrate 56000
 stun group 1
 stun route all tcp 10.17.5.2
!

Current configuration:
!
version 11.0
no service pad
service udp-small-servers
service tcp-small-servers
!
hostname rick
!
stun peer-name 10.17.5.2
stun protocol-group 1 basic
!
interface Serial0
 ip address 10.17.5.2 255.255.255.0
 no fair-queue
 no cdp enable
!
interface Serial1
 ip address 10.17.92.4 255.255.255.0
 no fair-queue
 no cdp enable
!
interface Serial2
 no ip address
 encapsulation stun
 nrzi-encoding
 clockrate 56000
 stun group 1
 stun route all tcp 10.17.5.1

STUN SDLC - Beispielkonfiguration

Current configuration:
!
version 10.3
service udp-small-servers
service tcp-small-servers
!
hostname s5e
!
stun peer-name 10.17.5.1
stun protocol-group 1 sdlc
!
interface Loopback1
 no ip address
!
interface Serial0
 ip address 10.17.5.1 255.255.255.0
 clockrate 2000000
!
interface Serial1
 no ip address
 encapsulation stun
 nrzi-encoding
 clockrate 56000
 stun group 1
 stun sdlc-role secondary
 sdlc address DD
 stun route address DD tcp 10.17.5.2
!

Current configuration:
!
version 11.0
no service pad
service udp-small-servers
service tcp-small-servers
!
hostname rick
!
stun peer-name 10.17.5.2
stun protocol-group 1 sdlc
!
interface Serial0
 ip address 10.17.5.2 255.255.255.0
 no fair-queue
 no cdp enable
!
interface Serial1
 ip address 10.17.92.4 255.255.255.0
 no fair-queue
 no cdp enable
!
interface Serial2
 no ip address
 encapsulation stun
 nrzi-encoding
 clockrate 56000
 stun group 1
 stun sdlc-role primary
 sdlc address DD
 stun route address DD tcp 10.17.5.1

STUN Multipoint (mit lokaler Rack-Konfiguration) - Beispielkonfiguration

hostname s5e
!
!
!
stun peer-name 10.17.5.1
stun protocol-group 1 sdlc
stun remote-peer-keepalive 5
!
interface Serial0
 ip address 10.17.5.1 255.255.255.0
 clockrate 2000000
!
interface Serial1
 no ip address
 encapsulation stun
 idle-character marks
 nrzi-encoding
 clockrate 56000
 stun group 1
 stun sdlc-role secondary
 sdlc K 1
 sdlc address 01
 sdlc address DD
 stun route address 1 tcp 10.17.5.2 local-ack
 stun route address DD tcp 10.17.5.2 local-ack
!

hostname rick
!
!

!
stun peer-name 10.17.5.2
stun protocol-group 1 sdlc
stun remote-peer-keepalive 5
!
interface Serial0
 ip address 10.17.5.2 255.255.255.0
 no fair-queue
 no cdp enable
!
interface Serial2
 no ip address
 encapsulation stun
 nrzi-encoding
 clockrate 56000
 stun group 1
 stun sdlc-role primary
 sdlc address DD
 stun route address DD tcp 10.17.5.1 local-ack
!
interface Serial3
 no ip address
 encapsulation stun
 clockrate 19200
 stun group 1
 stun sdlc-role primary
 sdlc address 01
 stun route address 1 tcp 10.17.5.1 local-ack

Hinweis: Auf dem AS400-Router wurden SDLCk1- und Leerzeichen verwendet. Weitere Informationen finden Sie im Abschnitt Feldwarnung.

Befehle anzeigen

Der erste Befehl show, der mit STUN verwendet wird, ist show stun. Die Ausgabe dieses Befehls hängt davon ab, ob Sie STUN Basic oder STUN SDLC mit Local-ack verwenden. Im unten abgebildeten Teil von STUN Basic werden nur die übertragenen und empfangenen Pakete angezeigt.

rick#sh stun
This peer: 10.17.5.2

 *Serial2  (group 1 [basic])
                              state       rx_pkts   tx_pkts     drops
all     TCP 10.17.5.1        closed           5729      5718         0

Im STUN SDLC mit dem unten abgebildeten lokalen Teil erhalten Sie weitere Informationen, da der Status der Sitzung jetzt bekannt ist.

rick#sh stun
This peer: 10.17.5.2

 *Serial2  (group 1 [sdlc])
                              state       rx_pkts   tx_pkts     drops    poll
DD     TCP 10.17.5.1        open       *      182        94         0


  Serial3  (group 1 [sdlc])
                              state       rx_pkts   tx_pkts     drops    poll
1     TCP 10.17.5.1        open       *      209        89         0

SDLC Local Acknowledgement:

 *Serial2  (group 1 [sdlc])
                                 slack_state conn disc iframe_s iframe_r
DD     TCP 10.17.5.1                  Active    1    0        0        0

  Serial3  (group 1 [sdlc])
                                 slack_state conn disc iframe_s iframe_r
1     TCP 10.17.5.1                  Active    1    0        3        3

Der Befehl show interface liefert außerdem unterschiedliche Informationen, je nachdem, ob Sie STUN Basic oder STUN SDLC ausführen. Die show-Schnittstelle für STUN Basic ist die gleiche wie für eine normale serielle Leitung.

Serial2 is up, line protocol is up
  Hardware is CD2430 in sync mode
  MTU 1500 bytes, BW 115 Kbit, DLY 20000 usec, rely 255/255, load 1/255
  Encapsulation STUN, loopback not set
  Last input 1:10:40, output 0:18:12, output hang never
  Last clearing of "show interface" counters 0:21:49
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     0 packets input, 0 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     4 packets output, 312 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets, 0 restarts
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

Die Show-Schnittstelle für STUN SDLC mit lokaler Bestätigung liefert weitere Informationen. Beispielausgabe für eine serielle Schnittstelle mit Local-ack ist unten dargestellt.

Serial3 is up, line protocol is up
  Hardware is CD2430 in sync mode
  MTU 1500 bytes, BW 115 Kbit, DLY 20000 usec, rely 255/255, load 1/255
  Encapsulation STUN, loopback not set
    Router link station role: PRIMARY (DCE)
    Router link station metrics:
      slow-poll 10 seconds
      T1 (reply time out) 3000 milliseconds
      N1 (max frame size) 12016 bits
      N2 (retry count) 20
      poll-pause-timer 10 milliseconds
      poll-limit-value 1
      k (windowsize) 7
      modulo 8
  sdlc addr 01 state is CONNECT
      VS 1, VR 0, Remote VR 1, Current retransmit count 0
      Hold queue: 0/200 IFRAMEs 16/12
      TESTs 0/0 XIDs 0/0, DMs 0/0 FRMRs 0/0
      RNRs 316/0 SNRMs 2/0 DISC/RDs 1/0 REJs 0/0
      Poll: clear, Poll count: 0, ready for poll, chain: 01/01
  Last input 0:00:00, output 0:00:00, output hang never
  Last clearing of "show interface" counters 1d06
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 0 bits/sec, 1 packets/sec
  5 minute output rate 0 bits/sec, 1 packets/sec
     332226 packets input, 664647 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     332227 packets output, 665220 bytes, 0 underruns
     0 output errors, 0 collisions, 3444 interface resets, 0 restarts
     0 output buffer failures, 0 output buffers swapped out
     5 carrier transitions
     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

Teile dieser Ausgabe werden nachfolgend erläutert:

• MTU ist die physische Größe des Puffers, den die Schnittstelle verwendet.

• PRIMARY (DCE) bedeutet, dass es sich um die Umfragestation am Kabel handelt und dass wir die Uhr bereitstellen. Wenn wir uns die Seite anschauen würden, die an den echten Primär angeschlossen ist, wäre diese Ausgabe SEKUNDÄR gewesen.

• N1 ist der Wert der verwendbaren Größe des SDLC-Frames, der von der seriellen Schnittstelle des Routers unterstützt werden kann.

• T1 ist die Zeitspanne, für die eine Antwort auf eine Umfrage erwartet wird, bevor die Leitung abgelaufen ist.

• Polll-Pause-Timer ist die Delta-Zeit in ms zwischen Umfragen.

• k ist die Fenstergröße oder die Anzahl der Frames, die zwischen den Umfrage-Finalen herausragend sein können.

• Status ist der aktuelle Status der Sitzung, der einer der folgenden Zustände sein kann:

  • TRENNEN

  • VERBUNDEN

  • THEMBUSY (wird normalerweise als Ergebnis dieses Routers festgelegt, der einen RNR empfängt)

  • USBUSY (in der Regel dadurch, dass keine Antwort auf die Netzwerkseite eingeht)

• RNRs sind die Anzahl der gesendeten/empfangenen RNRs.

• DTR/RTS sind die Leitungen, die in den meisten Halbduplex-Multidrop-Umgebungen verwendet werden. Achten Sie beim Debuggen einer STUN-Umgebung und beim Überprüfen des Controller-Standorts genau auf RTS. Wenn dies bei hoher DTR- und CTS-Geschwindigkeit periodisch abfällt, ist dies höchstwahrscheinlich das Ergebnis der DTE-Halbduplex.

Der letzte wichtige show-Befehl für STUN ist der Befehl show tcp, der Informationen über die TCP-Sitzung zwischen den Peers bereitstellt. Nachfolgend finden Sie eine Beispielausgabe:

Stand-alone TCP connection from host 10.17.5.1
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Local host: 10.17.5.2, Local port: 1994
Foreign host: 10.17.5.1, Foreign port: 11035

Enqueued packets for retransmit: 0, input: 0, saved: 0

Event Timers (current time is 0x1B2E50):
Timer          Starts    Wakeups            Next
Retrans           229          0             0x0
TimeWait            0          0             0x0
AckHold           229          0             0x0
SendWnd             0          0             0x0
KeepAlive           0          0             0x0
GiveUp              0          0             0x0
PmtuAger            0          0             0x0

iss: 2847665974  snduna: 2847667954  sndnxt: 2847667954     sndwnd:   9728
irs: 3999497423  rcvnxt: 3999499452  rcvwnd:       9672  delrcvwnd:    568

SRTT: 300 ms, RTTO: 607 ms, RTV: 3 ms, KRTT: 0 ms
minRTT: 0 ms, maxRTT: 300 ms, ACK hold: 300 ms
Flags: passive open, higher precedence

Datagrams (max data segment is 1460 bytes):
Rcvd: 459 (out of order: 0), with data: 229, total data bytes: 2028
Sent: 457 (retransmit: 0), with data: 228, total data bytes: 1979

Fehlerbehebung

Die Fehlerbehebung bei einer STUN-Konfiguration ist mit der bei jeder Peer-to-Peer-Konvention identisch. Wenn Transportprobleme auftreten, muss zunächst eine Diagnose durchgeführt werden, bevor mit der Fehlerbehebung für den SDLC/STUN-Teil begonnen werden kann. In der Regel besteht der erste Schritt darin, einen Ping von Peer zu Peer zu senden, um sicherzustellen, dass die IP-Adresse korrekt eingerichtet ist. Pingen Sie außerdem mit erweiterten Pakettypen, um sicherzustellen, dass der Transport zuverlässig ist.

Fehlerbehebung in SDLC Basic

In diesem Abschnitt wird die Fehlerbehebung bei einer STUN Basic-Konfiguration beschrieben. In diesem Beispiel nehmen Sie an, dass das WAN ordnungsgemäß funktioniert.

Dieses Szenario verfügt über eine STUN Basic-Konfiguration für die Verbindung des 5494 mit dem AS/400. Bei jeder STUN-Konfiguration muss zuerst überprüft werden, ob die Peers im Router eingerichtet sind. Um dies zu bestimmen, verwenden Sie den Befehl show stun peer. Sie liefert Informationen über den Zustand des Peers und die Pakete, die übertragen/empfangen wurden. Nachfolgend finden Sie eine Beispielausgabe:

rick#sh stun peer
This peer: 10.17.5.2

 *Serial2  (group 1 [basic])
                              state       rx_pkts   tx_pkts     drops
all     TCP 10.17.5.1        open             5729      5718         0

Wenn der Peer wie oben geöffnet ist, verwenden Sie den Befehl show interface, um zu bestimmen, was mit den Paketen geschieht. Nachfolgend finden Sie eine Beispielausgabe für diesen Befehl:

Serial2 is up, line protocol is up
  Hardware is CD2430 in sync mode
  MTU 1500 bytes, BW 115 Kbit, DLY 20000 usec, rely 255/255, load 1/255
  Encapsulation STUN, loopback not set
  Last input 1:10:40, output 0:18:12, output hang never
  Last clearing of "show interface" counters 0:21:49
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     0 packets input, 0 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     4 packets output, 312 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets, 0 restarts
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

Prüfen Sie zunächst, ob der Router alle seriellen Signale ausgibt. Unten in der Ausgabe oben sehen wir, dass alle Signale für die "Serial2" des 2522 "up" (oben) sind. DTR und RTS weisen darauf hin, dass der Controller die Leitung bereits selbst aktiviert hat und darauf wartet, dass das AS/400 die erste Konversation sendet.

Überprüfen Sie anschließend die Benutzeroberfläche für die AS/400-Seite des Routers. In der unten gezeigten Ausgabe sehen wir, dass die serielle Schnittstelle, die an das AS/400 angeschlossen ist, ausgefallen ist. Das bedeutet, dass der AS/400 wahrscheinlich "abweichen" kann. Wenn die Leitung "variiert" ist und Sie die Leitung nicht erreichen können oder Halbduplex ausführen, müssen Sie die RS-232/V.35 Verbindung überprüfen.

Serial1 is down, line protocol is down
  Hardware is HD64570
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
  Encapsulation STUN, loopback not set
  Last input never, output 1:51:24, output hang never
  Last clearing of "show interface" counters 0:00:01
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     0 packets input, 0 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     0 packets output, 0 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets, 0 restarts
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
     DCD=up  DSR=up  DTR=down  RTS=down  CTS=up
s5e#

Überprüfen Sie an diesem Punkt den Bildschirm "Work with Configuration Status" (Arbeiten mit Konfigurationsstatus) für den jeweiligen Controller. Dieser Bildschirm sieht wie folgt aus:

Als Nächstes variieren Sie je nach der Leitungsdefinition. Sie sollten dann sehen, dass der Router hochgefahren wird. Wenn die Leitung hochgefahren wird, der Controller aber immer noch nicht aktiviert ist, überprüfen Sie die Schnittstelle, ob Pakete die eingehende Schnittstelle des AS/400 erreicht haben. Wenn die Zahl 0 ist, überprüfen Sie den Kodierungsmechanismus für die SDLC-Leitung auf dem AS/400. Diese befindet sich, wie unten gezeigt, in der Beschreibung der Display-Leitung.

Hinweis: Auf diesem Bildschirm sehen wir, dass die Zeilenkodierung für die NRZI-Kodierung festgelegt ist. Dies muss mit der Konfigurationsoption nrzi-encoding auf dem Router aktiviert werden.

Für diese Konfiguration ist keine End-to-End-NRZ/NRZI-Codierung erforderlich, wie bei herkömmlichen Point-to-Point-Konventionen von SDLC, sondern es kann sich um NRZI auf der einen Seite und NRZ auf der anderen handeln. Beachten Sie jedoch, dass die Codierung für alle Geräte, die die SDLC-Leitung gemeinsam nutzen, gleich sein muss.

NRZI bedarf sorgfältiger Überlegungen. Bei den neuen Routern wie den Cisco 2500 und 4500 wird NRZI per Software eingerichtet. Bei älteren Plattformen, einschließlich der NP-2T für die Cisco Serie 4000, müssen Sie die Jumper auf den Platinen selbst wechseln. In solchen Fällen ist es wahrscheinlich einfacher, den AS/400 in NRZ/NRZI zu ändern. Wenn Sie die Jumper jedoch ändern müssen, lesen Sie die Cisco Hardwaredokumentation für Ihre spezifische Plattform.

Wenn das Problem weiterhin besteht, führen Sie ein Debug-Betäubungspaket 1 durch. Dieser Befehl enthält folgende Informationen:

STUN basic: 0:00:35 Serial1         SDI:   Data: c0bf324c056452530000
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to down
%LINK-3-UPDOWN: Interface Serial1, changed state to down
STUN basic: 0:00:38 Serial1         SDI:   Data: c0bf324c056452530000
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up
%LINK-3-UPDOWN: Interface Serial1, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to down
STUN basic: 0:00:35 Serial1         SDI:   Data: c0bf324c056452530000
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to down
%LINK-3-UPDOWN: Interface Serial1, changed state to down

Sie können sehen, dass mehrere XIDs vom AS/400 fließen, aber es gab keine Antwort darauf (CO ist die Polling-Adresse und bf die XID). Wir wissen, dass das Paket vom AS/400 kommt, weil es vom SDI stammt. In dieser Befehlsausgabe gibt es zwei Arten von eingehenden Paketen:

• SDI: Seriell eingehende Pakete, d. h. Pakete, die von der SDLC-Schnittstelle empfangen werden.

• NDI: Eingehendes Netzwerk, d. h. vom WAN entkapselte Pakete.

Sehen wir uns nun den XID-Teil des Frames selbst an. In diesem Beispiel sendet das AS/400 zusammen mit IDBLOCK und IDNUM 05645253 eine XID.

Dies ist ein Timeout-Problem, da der Controller nicht reagiert. Überprüfen Sie im AS/400 in der "Sysopr Message Queue", ob Meldungen auf ein Problem hinweisen. Im Folgenden wird ein Bildschirm "SYSOPR" mit einem Fehler angezeigt.

Schalten Sie jetzt auf dem 2522 das Debug-Betäubungspaket 1 ein, um festzustellen, ob die Pakete an den Controller gesendet werden. Nachfolgend finden Sie eine Beispielausgabe für Befehle:

STUN basic: 0:00:34 Serial2         NDI:   Data: c0bf324c056452530000
STUN basic: 0:00:42 Serial2         NDI:   Data: c0bf324c056452530000

Dies zeigt uns, dass die XID, die von der AS/400-Seite ausging, zum Controller gelangt, aber der Controller reagiert nicht, was bedeutet, dass es sich um ein Controller-Problem handelt. Eine Show-Schnittstelle zeigt an, ob alle Kontrollpunkte aktiv sind oder nicht:

Serial2 is up, line protocol is up
  Hardware is CD2430 in sync mode
  MTU 1500 bytes, BW 115 Kbit, DLY 20000 usec, rely 255/255, load 1/255
  Encapsulation STUN, loopback not set
  Last input 0:50:56, output 0:00:23, output hang never
  Last clearing of "show interface" counters 0:02:06
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     0 packets input, 0 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     1 packets output, 78 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets, 0 restarts
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

Die Steuerungs-Leads sind aktiv, und die Schnittstelle wird angezeigt. Wir können auch sehen, dass der Router Pakete ausgibt, aber keine Pakete eingehen. Dies verweist auf die falsche Polling-Adresse, die für das AS/400 konfiguriert wurde. Der nächste Schritt besteht also darin, die Polling-Adresse des Controllers zu überprüfen.

Jeder Controller-Typ verfügt über eine eindeutige Methode zur Konfiguration der Polling-Adresse. Sie müssen diese daher mithilfe der Controller-Handbücher für Ihren Controller überprüfen.

In diesem Beispiel haben wir festgestellt, dass der Controller die Polling-Adresse "DD" verwendet. Nachdem dies auf dem AS/400 geändert wurde, wird die Ausgabe des Debugstun-Pakets wie folgt:

STUN basic: 0:24:03 Serial2         NDI:   Data: ddbf324c056452530000
STUN basic: 0:00:00 Serial2         SDI:   Data: ddbf3244073000dd0000
STUN basic: 0:00:00 Serial2         NDI:   Data: dd93
STUN basic: 0:00:00 Serial2         SDI:   Data: dd73
STUN basic: 0:00:00 Serial2         NDI:   Data: dd11
STUN basic: 0:00:00 Serial2         SDI:   Data: dd11
STUN basic: 0:00:00 Serial2         NDI:   Data: dd11
STUN basic: 0:00:00 Serial2         SDI:   Data: dd102f00000200016b80
STUN basic: 0:00:00 Serial2         NDI:   Data: dd31
STUN basic: 0:00:00 Serial2         SDI:   Data: dd11
STUN basic: 0:00:00 Serial2         NDI:   Data: dd31
STUN basic: 0:00:00 Serial2         SDI:   Data: dd11
.
.
.
.
STUN basic: 0:00:00 Serial2         NDI:   Data: dd31
STUN basic: 0:00:00 Serial2         SDI:   Data: dd71
STUN basic: 0:00:00 Serial2         NDI:   Data: dd362f00020080004b80
STUN basic: 0:00:00 Serial2         NDI:   Data: dd31
STUN basic: 0:00:00 Serial2         NDI:   Data: dd53
STUN basic: 0:00:00 Serial2         SDI:   Data: dd73

Diese Debug-Ausgabe hilft bei der Ermittlung der folgenden Informationen:

STUN basic: 0:24:03 Serial2         NDI:   Data: ddbf324c056452530000

Diese Leitung enthält die XID vom AS/400 zum Controller. Diese stammen von NDI (aus der Cloud), dd (Abfrageadresse), bf (XID) sowie IDBLOCK und IDNUM (05645253).

STUN basic: 0:00:00 Serial2         SDI:   Data: ddbf3244073000dd0000

Dies ist die Antwort des Controllers. Dies wird durch SDI (von der SDLC-Leitung) und die gleiche wie oben angegeben, mit Ausnahme der XID-Antwort (073000dd), da es sich um einen 5494 handelt.

STUN basic: 0:00:00 Serial2         NDI:   Data: dd93

Dies ist der SNRM (93) vom AS/400 zum Controller, der in dieser Konfiguration primär verwendet wird.

STUN basic: 0:00:00 Serial2         SDI:   Data: dd73

Hier sehen wir, wie der Controller auf die SDI-Funktion (SDI) mit einem UA (73) reagiert, was bedeutet, dass die Sitzung aktiv ist. Als Nächstes sollte die Trennung vom AS/400 angezeigt werden, da die Leitung abgeändert wurde.

STUN basic: 0:00:00 Serial2         NDI:   Data: dd53
STUN basic: 0:00:00 Serial2         SDI:   Data: dd73

Diese Zeilen zeigen die DISK (53) und die UA-Antwort. Die Leitung ist jetzt inaktiv. Die nachfolgende Tabelle enthält Werte, die zum Debuggen dieser Probleme erforderlich sind.

000z 0011
0001 0111
0001 0111
0001 1111
0011 0011
0101 0011
0101 0011
0101 0011
0111 0011
1001 0011
1001 0111
101z 1111
110z 0111
111z 0011
 

03-13    UI
07-17    SIM
07-17    RIM
0F-1F    DM
23-33    UP
43-53    DISC
43-53    RD
43-53    RD
63-73    UA
83-93    SNRM
87-97    FRMR
AF-BF    XID
C7-D7    CFGR
E3-F3    TEST
 

Unnumbered Information
Set Initialization mode
Request Intialization Mode
Secondary in Disconnect Mode
Unumber Poll
Disconnect
Request Disconnect
Secondary Requests Disconnect
Unnumbered Acknowledgement
Set Normal Response Mode
Frame Reject
Exchange Identification
Configure
I-Field contains test pattern

rrrz cc01
rrrz 0001
rrrz 0101
rrrz 1001

 

xx-xx
x1-x1
x5-x5
x9-x9

 

Supervisory Format
Receiver Ready
Receiver Not Ready
Reject

rrr1 sssz

 

xx-xx

 

Information format

Schlüssel:

z = Das letzte Bit für die Abfrage kann 0 oder 1 sein.

rr = Anzahl der voraussichtlich empfangenen Blöcke

sss = Anzahl der gesendeten Blöcke

Fehlerbehebung bei STUN SDLC mit und ohne lokale Bestätigung

Dieser Abschnitt behandelt dasselbe Szenario mit konfigurierter lokaler Bestätigung.

Im Gegensatz zu STUN Basic erfordert STUN SDLC, dass Sie die richtige Polling-Adresse angeben, oder der Router sieht nicht einmal, dass die Pakete eingehen. Deshalb wird manchmal STUN Basic verwendet, um die Polling-Adresse zu finden, wenn Sie nicht über die Informationen verfügen oder nicht auf den Host oder das AS/400 zugreifen können. Das obige Diagramm zeigt ein Multipoint-Szenario mit lokalem Rack.

In einer herkömmlichen Point-to-Point-Umgebung werden die Umfragen von Ende zu Ende geführt. Wenn eine lokale Bestätigung eingeführt wird, wird das Polling an jedem Ende der Cloud beendet, sodass jeder Router ein Finite-State-System verwalten muss. Dieser Computer verfolgt alle Sitzungen und muss den Status der Leitung für jede Polling-Station kennen. Aus diesem Grund müssen Sie sicherstellen, dass die Stationen das SDLC-Protokoll befolgen.

Überprüfen Sie zunächst, ob Sie die richtige STUN-Rolle haben. Die AS/400-Router haben in herkömmlichen Point-to-Point-Umgebungen Schwierigkeiten, die Rolle mit dem Controller auszuhandeln. Die Postenbeschreibung ist unten dargestellt.

Dies zeigt, dass die Router-Schnittstelle für eine sekundäre Rolle konfiguriert werden muss. Überprüfen Sie immer, ob die Zeile *PRI ist, da AS/400 beim Erstellen standardmäßig auf *NEG festgelegt ist. NRZI ist auf *JA eingestellt, daher müssen Sie die nrzi-Codierung codieren. Codieren Sie auch Leerzeichen, und setzen Sie das Fenster mithilfe von sdlc k 1 auf 1 (1). (In der FNA-IOS-0696-02-Feldwarnung finden Sie eine detaillierte Beschreibung, warum auf der Schnittstelle Leerzeichen erforderlich sind.) Diese Codierung ist unten dargestellt:

interface Serial1
no ip address
encapsulation stun
idle-character marks
nrzi-encoding 
clockrate 56000 (real clockrate on the line; see note about as400 line speed)
stun group 1
stun sdlc-role secondary (this must be secondary because the line is primary)
sdlc K 1
sdlc address 01
sdlc address DD
stun route address 1 tcp 10.17.5.2 local-ack
stun route address DD tcp 10.17.5.2 local-ack

Hinweis: Die vom Router bereitgestellte Taktgebung ist unabhängig vom Parameter Line Speed (Leitungsgeschwindigkeit), der auf der AS/400-Leitung konfiguriert ist. (Dieser Parameter wird für die Leistungsberechnung verwendet. kann die Standardeinstellung "9600" beibehalten werden.) Die in der Leitung konfigurierte Exchange-ID ist die des AS/400, z. B. die XID, die vom AS/400 gesendet wird. Der Maximum Controller ist die Anzahl der PUs (Controller), die erstellt und an diese Leitung angeschlossen werden können.

Der erste der beiden an diese Leitung angeschlossenen Controller, der IBM 5494, wird unten im Bildschirm angezeigt.

Wie wir sehen, ist der erste Controller eine PU 2.1, da die Kategorie des Controllers "*APPC" lautet. Dies ist die Abkürzung für "Advance Program to Program Communications" (Erweiterte Programmkommunikation), die nur über eine T2.1-Verbindung möglich ist. Die Remote-Netzwerkkennung bezieht sich wiederum auf APPN/APPC und wird als "NETID" bezeichnet. "*NETATR" ist ein Parameter, der die Verwendung des NETID angibt, der im Datenbereich als "Netzwerkattribute" definiert ist. Sie können diesen Datenbereich mit dem Befehl DSPNETA anzeigen und die Werte entsprechend ersetzen. Der "Remote Control Point" oder "CP_Name" ist der Name des Kontrollpunkts, den Sie in PU2.1 konfiguriert haben. In diesem Fall ist es CP5494. Die Data Link-Rolle kann als *NEG belassen werden. Die "Station address" muss mit der "sdlc address DD" übereinstimmen, die sowohl an der sekundären Schnittstelle als auch an einer der primären Schnittstellen konfiguriert wurde.

interface Serial2
 no ip address
 encapsulation stun
 nrzi-encoding
 clockrate 56000
 stun group 1
 stun sdlc-role primary
 sdlc address DD
 stun route address DD tcp 10.17.5.1 local-ack

Wie Sie sehen, sind die meisten Informationen in der Controller-Beschreibung für die physische Einheit selbst und nicht für den Router konfigurierbar.

Auf diesem Bildschirm ist der zweite Controller (PU) tatsächlich ein 3174, also ein PU-Typ 2. Die in diesem 3174 konfigurierte XID lautet 0560001. Die verwendete "Stationsadresse" bzw. SDLC-Adresse ist 01. Sie benötigen eine "sdlc address 01", die auf der sekundären Schnittstelle und einer der primären Remote-Schnittstellen konfiguriert ist. Wie Sie unten sehen können, ist die Konfiguration für eine PU2 weniger beteiligt als eine PU2.1.

interface Serial3
 no ip address
 encapsulation stun
 clockrate 19200
 stun group 1
 stun sdlc-role primary
 sdlc address 01
 stun route address 1 tcp 10.17.5.1 local-ack

Die Display Networks Attributes (DSPNETA) im AS/400 sind im Folgenden dargestellt:

Dieser Bildschirm zeigt, dass das AS/400 derzeit für die Netzwerk-ID "NETA" konfiguriert ist. Das bedeutet, dass der 5494 für dasselbe Netzwerk konfiguriert werden muss. Dies sowie die restliche Konfiguration von APPN finden Sie auf dem zweiten Konfigurationsbildschirm im 5494. Der Name des lokalen Kontrollpunkts des AS/400 lautet "RTP400A". Der LU-Name des AS/400 lautet "LU9404;". Dieser muss mit dem übereinstimmen, was im Feld "Partner LU Definition" des Dokuments 5494 konfiguriert wurde. Die vom 5494 verwendete Modusbeschreibung muss mit der Gerätebeschreibung übereinstimmen. Wenn das Gerät beispielsweise "*NETATR" angibt, muss es mit dem Standardwert "BLANK" übereinstimmen.

Die für den 5494 erstellte APPC-Gerätebeschreibung ist unten dargestellt.

Dieser Bildschirm zeigt, dass die Gerätebeschreibung für den 5494 den Remote-CP-Namen "CP5494" hat; dieser muss mit dem übereinstimmen, was für den 5494 konfiguriert wurde. Der NETID und der lokale Standort sind standardmäßig auf "*NETATR" gesetzt, die im vorherigen Beispiel für LU9404 und NETA codiert wurden. Diese müssen wiederum mit dem Namen des Partner-Geschäftsbereichs und den NETID-Feldern im Feld 5494 übereinstimmen.

Der letzte Teil der Gerätekonfiguration, der für die Herstellung einer Verbindung relevant ist, wird unten gezeigt.

Dieser Bildschirm zeigt, dass der in der Gerätebeschreibung verwendete Modus "QRMTWSC" lautet. Dies ist nicht der Standardwert im *NETATR, d. h., er wurde in der Gerätebeschreibung überschrieben. Dies ist einer der Standardmodi, die IBM im Rahmen der APPN-Basisunterstützung auf dem AS/400 bereitstellt. Wenn Sie etwas Anderes sehen, wenden Sie sich an IBM, da sie mit einer von ihnen erstellten Modusbeschreibung ausgeführt werden. In diesem Beispiel wird eine Basisverbindung hergestellt. Wenn Sie Informationen über die verfügbaren Modi anzeigen möchten, können Sie den Befehl WRKMODD oder Arbeitsmodusbeschreibungen verwenden.

Die Modusbeschreibung ist unten abgebildet.

Auf diesem Bildschirm werden die von IBM bereitgestellten Modusdefinitionen deutlich angezeigt.

Fehlerbehebung bei SDLC Full Duplex Multipoint Interface

Achten Sie bei der lokalen Bestätigung in einer Multipoint-Umgebung mit AS/400 darauf, wie die "SDLC Full Duplex Multipoint Interface" auf den AS/400-, SYS/38- und SYS/36-Mini-Mainframes implementiert wurde. Die FNA-IOS-0696-02-Feldwarnung (weiter unten) erläutert die Art von Problemen, die in dieser Situation auftreten können.

Kurzbeschreibung

Die Änderung des Routerkabels, bei der "Carrier Detect" (Carrier Detection) mit dem Boden verbunden wird, verhindert nicht, dass periodische Zurücksetzungen der SDLC-Leitung von einem AS/400 vorgenommen werden, wenn beim AS/400 IBM PTF# MF10030 angewendet wurde. Diese Warnung gilt nur für STUN-Vollduplex-Multi-Drop-Verbindungen zu einem AS/400, bei denen das SDLC-Kabel des Routers so modifiziert wurde, dass die Carrier-Erkennung deaktiviert wird.

Auswirkungen

Die Benutzer können die STUN-Verbindung und alle sekundären SDLC-Geräte in regelmäßigen Abständen zurücksetzen, was zu einer unzuverlässigen Verbindung führt.

Vollständige Beschreibung/Hintergrund

In einer Multi-Drop-Umgebung verhält sich ein AS/400 anders als andere IBM-Geräte. Während ein FEP entweder 0x7E-Zeichen (Flags) oder 0xFF-Zeichen (Markierungen) als Leerzeichen zwischen Frames akzeptiert, behandelt ein AS/400 Flags und Markierungen anders. Nur eine Markierung wird als Leerzeichen interpretiert. Ein Flag wird interpretiert als "Zeile ist noch aktiv - weitere Daten stehen aus." Ein Cisco Router kann so konfiguriert werden, dass er entweder Markierungen oder Markierungen, aber nicht beide sendet. Sie wird nicht zwischen den beiden Optionen wechseln, um den Leitungsstatus wiederzugeben. Standardmäßig sendet der Router Flags.

Dieser Unterschied stellt ein Problem in Vollduplex-Multi-Drop-Umgebungen dar. In der Regel wechselt der AS/400 von Gerät zu Gerät und fragt jedes Gerät nach Daten ab. Wenn ein Gerät nicht reagiert und der AS/400 denkt, dass die Leitung noch aktiv ist, wird die gesamte Leitung zurückgesetzt. Da der Router standardmäßig Flags sendet, wird für das AS/400 immer eine aktive Leitung angezeigt. Anstatt einfach das nächste Gerät abzufragen, wird die Leitung zurückgesetzt.

Um dieses Problem zu vermeiden, hat Cisco in der Vergangenheit eine Kabeländerung empfohlen, durch die das Trägersignal (CD) deaktiviert wird. Diese Änderung nutzt die AS/400-Logik, die das Fehlen eines Carriers als "Inaktivitätszustand" interpretiert. Daher erkennt ein AS/400 bei der Änderung immer den Status inaktiver Leitungen, unabhängig von den vom Router gesendeten Frame-übergreifenden Zeichen. Wenn also ein sekundäres Gerät nicht reagiert, überprüft das AS/400 die CD, zeigt eine inaktive Leitung an und fragt die nächste Station ab.

IBM hat kürzlich eine AS/400-Problembehebung für PTF# MF10030 veröffentlicht, die die Carrier-Erkennungslogik auf Multi-Drop-Zeilen ändert. Wenn dieses Fix installiert ist, ignoriert ein AS/400 den Zustand der CD in Vollduplex-Multi-Drop-Leitungen. Infolgedessen verhindert die Kabeländerung von Cisco nicht mehr das regelmäßige Zurücksetzen von Leitungen.

Problemumgehung

Je nach Router-Modell und verwendeter Cisco IOS-Version stehen zwei Workarounds zur Verfügung. Beide Optionen erfordern Konfigurationsänderungen am Router, der mit dem AS/400 verbunden ist.

Option 1

Ändern Sie das freie SDLC-Zeichen aus dem Standardmarkierungszeichen in ein Markierungszeichen. Das Leerzeichen kann mithilfe des Befehls zur Konfiguration der Router-Schnittstelle geändert werden:

idle-character marks 

Fügen Sie diesen Befehl zur seriellen Schnittstelle von SDLC hinzu, die mit dem AS/400 verbunden ist. Dieser Befehl bewirkt, dass der Router während einer Pause zwischen Frames immer Zeichen überträgt. Wenn also ein sekundäres Gerät eine Umfrage nicht befolgt, sieht das AS/400 eine freie Leitung und fragt das nächste Gerät ab. Leider bedeutet dies auch, dass der AS/400 nicht aktiv ist, auch wenn mehr Datenframes auf dem Weg vom Gerät sind. Das AS/400 bestätigt nur den ersten Frame, selbst wenn das Polll/final-Bit 0 ist. Anschließend ignoriert er alle nachfolgenden Frames und fragt das nächste Gerät ab, was zu unnötigen Frame-Neuübertragungen führt. Um eine erneute Übertragung zu vermeiden, müssen Sie die Größe des SDLC-Fensters mit dem folgenden Befehl auf 1 festlegen:

sdlc k 1

Hinweis: Der Befehl Leerzeichen wird in Cisco IOS Version 10.0(5.2) und höher unterstützt und funktioniert auf Routern der Serien 2500, 4 x 00 mit NP-4T und 70x0/75xx.

Option 2

Ermöglichen Sie die Erkennung inaktiver sekundärer Geräte mit dem Schnittstellenbefehl:

stun quick-response

Dieser Befehl bewirkt, dass der Router mit einem DM-Frame (Disconnect Mode) auf alle vom AS/400 abgefragten inaktiven sekundären Geräte reagiert. Das AS/400 wird dann mit dem nächsten Gerät fortfahren, ohne die Leitung zurückzusetzen.

Hinweis: Dieser Befehl wird in Cisco IOS 11.1, 11.0(3.1) und höher oder in Version 10.3(7.2) und höher unterstützt.

Tipp: Wenn beim Hochfahren der Multipoint-Leitung Probleme mit der Konfiguration der Schnellantwort auftreten, wählen Sie Option 1 aus. Der Schnellreaktionscode für Betäubungen im Router ist Teil des Finite-State-Systems für das Local-Rack, das bei einigen PUs außer Kraft treten kann. Wir haben den Code im Labor getestet und seine Interoperabilität mit den Geräten 5494, 5394 und Perl494E überprüft. Es können Probleme auftreten, wenn die Timer für die anzufügende PU anders eingestellt sind als die Quick_response.

Zugehörige Informationen

• Support-Seite für STUN/BSTUN
• IBM Technology-Seite
• Technischer Support und Dokumentation - Cisco Systems