BSC- und BSTUN-Leitfaden

Einführung

Dieses Dokument unterstützt Sie bei der Konfiguration und Verwendung des BSC-Datenübertragungsprotokolls (Binary Synchronous Communication) und des BSTUN (Block Serial Tunneling) auf Cisco Routern. Es hilft Ihnen auch, mögliche Probleme zu beheben.

Voraussetzungen

Anforderungen

Die Leser dieses Dokuments sollten folgende Themen kennen:

• Binary Synchronous Communications (BSC)-Konzepte

• Allgemeine Kenntnisse der Grundlagen der Datenverarbeitung.

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf Cisco IOS? Software mit dem IBM Feature Set.

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.

Systemübersicht

Die Abbildungen 1 und 2 zeigen, wie eine bestehende BSC-Verbindung zwischen zwei Geräten für die Verwendung von Cisco Routern neu konfiguriert werden kann. Dadurch wird dieselbe logische Verbindung ohne Änderungen an den vorhandenen BSC-Geräten hergestellt.

Die Cisco Router transportieren alle BSC-Blöcke zwischen den beiden Geräten mithilfe der BSTUN-Kapselung (Block Serial Tunneling). Für jeden BSC-Block, der von der Leitung empfangen wird, werden eine Adresse und Steuerungs-Bytes hinzugefügt, um einen BSTUN-Frame zu erstellen. Anschließend wird BSTUN zum Bereitstellen an den richtigen Zielrouter verwendet.

BSC/BSTUN-Konfiguration

Führen Sie auf einem sauberen Router diese Befehle in der Reihenfolge aus, in der sie aufgeführt sind.

Globale Befehle

[no] bstun peer name ip-address

Die IP-Adresse definiert die Adresse, über die dieser BSTUN-Peer anderen BSTUN-Peers, die den TCP-Transport verwenden, bekannt ist.

Hinweis: Dieser Befehl muss in Cisco IOS Software Releases vor Version 11.3 konfiguriert werden oder muss konfiguriert werden, wenn TCP/IP-Adressen in Routenanweisungen verwendet werden.

[no] bstun protocol-group group group number {bsc | bsc-local-ack | Adplex | adt-polll | adt-polll-select | adt-vari-Umfrage | Diebstahl | async-generisch | mdi}

Dies ist ein globaler Befehl zur Zuordnung von Gruppennummern zu Protokollnamen. Die Gruppennummer ist eine Dezimalzahl zwischen 1 und 255. Die Basiskonfiguration | bsc-local-ack | adplex sind vordefinierte BSTUN-Protokoll-Schlüsselwörter. Weitere Informationen finden Sie unter Definieren der Protokollgruppe unter Konfigurieren des seriellen Tunnels und Blockieren des seriellen Tunnels.

Die Auswahl des Gruppentyps ist wichtig, um zu bestimmen, ob Passthru oder lokale Bestätigung (Local-ack) verwendet werden soll.

Hinweis: Dieser Befehl muss immer konfiguriert werden.

Schnittstellenbefehle

Verkapselung

Dieser Schnittstellenbefehl konfiguriert die BSTUN-Funktion auf einer bestimmten seriellen Schnittstelle. Dieser Befehl muss auf einer Schnittstelle konfiguriert werden, bevor weitere BSTUN- oder BSC-Befehle für diese Schnittstelle konfiguriert werden.

[no] bstun group group number

Dieser Schnittstellenbefehl definiert die BSTUN-Gruppe, zu der diese Schnittstelle gehört. Jede BSTUN-fähige Schnittstelle auf einem Router muss einer zuvor definierten BSTUN-Gruppe angehören. Pakete werden nur zwischen BSTUN-fähigen Schnittstellen übertragen, die sich in derselben Gruppe befinden. Die Gruppennummer ist eine Dezimalzahl zwischen 1 und 255.

Die Gruppennummer hat bereits ermittelt, ob diese Schnittstelle lokal-ack oder passthru ausführt.

[no] Basismodus

Im Folgenden finden Sie eine Liste der wichtigsten Optionen. Eine umfassende Liste finden Sie unter Konfigurieren von Bisync-Optionen auf einer seriellen Schnittstelle bei der Konfiguration des seriellen Tunnels und des seriellen Tunnels blockieren.

Es werden keine Frames empfangen oder gesendet, bis der Modus für eine der folgenden Einstellungen konfiguriert wurde:

• Contention (Konflikt): Dieser Parameter legt fest, dass der mit der seriellen Schnittstelle verbundene BSC-Link eine Punkt-zu-Punkt-BSC-Station ist. Nur 3780 und nur im Passthru-Modus.

• Contention Virtual-Address (virtuelle Contention-Adresse) - Erstes verfügbar in Version 11.3 der Cisco IOS-Software. Wird mit Dial-Contention verwendet, um mehreren Remote-Geräten die Verwendung derselben Schnittstelle am Host-End-Router zu ermöglichen.

• Dial-Contention Timeout (Zeitüberschreitung bei gleichzeitiger Dial-Contention) - Erstes verfügbar in Version 11.3 der Cisco IOS-Software. Wird im Host-End-Router für Streitigkeiten verwendet. Mehrere Remote-Geräte können über dieselbe physische Schnittstelle multipliziert werden.

• primary (primär): Definiert, dass der Router als primärer Endpunkt der BSC-Verbindung fungiert und dass das bzw. die angeschlossenen Geräte Nebenstellen des BSC sind.

• Sekundär - Definiert, dass der Router als sekundäres Ende der BSC-Verbindung fungiert und dass das angeschlossene Remote-Gerät eine BSC-Kontrollstation ist (z. B. ein Front-End-Prozessor [FEP] oder ein anderes Host-Gerät).

Wenn dieser Befehl nicht konfiguriert ist, wird das Verbindungsprotokoll auf der Schnittstelle deaktiviert, und die Schnittstelle wird nicht ausgeführt.

TCP-Routenkonfiguration

In dieser Konfiguration ist das Transportsystem TCP/IP. Dies kann über alle physischen Medien ausgeführt werden, auf denen TCP/IP ausgeführt werden kann.

[no] bstun route all tcp ip address

[no] bstun route address address-number tcp ip address

Die IP-Adresse entspricht der IP-Adresse, die im Peer-Namen des Partnerrouters angegeben ist.

Konfiguration der seriellen Route

In dieser Konfiguration verwendet der Tunnel den proprietären Transport von Cisco. Sie ist viel schneller als TCP/IP, geht aber nur über eine serielle Schnittstelle.

[no] bstun route all interface Serial interface number

[no] bstun route address address-number interface Serielle Schnittstellennummer

Passthrough-Konfiguration für Direct Frame Relay

In dieser Konfiguration verwendet der Tunnel eine proprietäre Form der seriellen Kapselung über Frame Relay, die genauso schnell funktioniert wie serielle Routen.

[no] bstun route address address-number interface serial interface-number dlci dlci-nummer

Führen Sie diesen Befehl auf der Frame Relay-Schnittstelle aus:

[no] Frame-Relay Map dlci-number bstun

Konfiguration des lokalen Direktwahl-Relay

Diese Konfiguration verwendet Logical Link Control, Typ 2 (LLC2) über Frame Relay-Kapselung, um eine lokale Bestätigung und End-to-End-Sitzungssteuerung zu ermöglichen. Das lsap-Schlüsselwort muss enthalten sein. Falls nicht, wird die Kapselung als Passthru.

[no] bstun route address address-number interface serial interface-number dlci dlci-number lsap lsap

Führen Sie diesen Befehl auf der Frame Relay-Schnittstelle aus:

[no] Frame-Relay Map dlci-number llc2

Hinweis: Weitere Informationen finden Sie unter Angeben der Weiterleitung von Frames bei der Konfiguration des seriellen Tunnels und des seriellen Tunnels blockieren.

Passthrough-Konfiguration

Warum Passthru?

Passthru ist der einfache Tunneling-Modus. Jeder Frame, der zwischen den Geräten übertragen wird, wird unverändert über den BSTUN-Tunnel weitergeleitet. Eine Sequenznummer und eine Geräteadresse werden hinzugefügt, um sicherzustellen, dass Latenzen im Netzwerk den Protokollbetrieb nicht beeinträchtigen. Durch das Eintreffen von Spätsollen oder das Ende von Übertragungssignalen (End of Transmission, EOT) kann eine vorhandene Sitzung erheblich unterbrochen werden.

Verwendung von Passthru

Passthru sollte in folgenden Fällen angewendet werden:

• Für die übertragenen Daten wird kein expliziter Bestätigungsrahmen gesendet, um die Datenintegrität zu überprüfen.

• Das Protokoll ist nicht rein 3270.

• Der Benutzer möchte eine End-to-End-Geräteanbindung, und die Netzwerklatenz ist gering.

Lokale Konfiguration

Warum Local-Ack?

Local-ack entfernt den Overhead beim Senden aller Kontrollrahmen über den Tunnel. Wenn der Host die erste Abfrage an eine Steuerungseinheit sendet, wird ein spezieller Kontrollrahmen über den Tunnel gesendet, um das Remote-Polling der Geräteadresse zu starten. Sobald das Remote-Gerät anzeigt, dass es aktiv ist, wird ein Steuerungs-Frame an den Host-Router gesendet, um ihm mitzuteilen, dass er auf die Umfragen antworten soll. Wenn das Remote-Gerät ausfällt, wird eine Meldung über den Tunnel gesendet, um dem Host-Router mitzuteilen, dass er nicht mehr auf Umfragen antworten soll.

Verwendung der lokalen Schnittstelle

Local-ack kann unter folgenden Umständen verwendet werden:

• 3270 Bisync wird angewendet.

• Netzwerklatenz verursacht bisync Session Timeouts.

• Der übermäßige Datenverkehr im WAN ist ein Problem.

Optionen für lokale Anrufe

[no] Basispause-Zeit

Dieser Befehl gibt die Zeitspanne zwischen dem Beginn eines Abfragezyklus und dem nächsten an. Der Standardwert ist 30 (d. h. 30 Zehntel oder 3 Sekunden).

Es empfiehlt sich, diesen Befehl zu konfigurieren, wenn nur ein oder zwei Controller auf der bisynchronen Schnittstelle vorhanden sind. Dadurch wird das Polling praktisch verlangsamt, und dem angeschlossenen Gerät werden mehr CPU-Zyklen zugewiesen.

[no] bsc polll timeout time

Mit diesem Befehl wird das Timeout für eine Abfrage- oder Auswahlsequenz in Einheiten von einem Zehntel einer Sekunde festgelegt. Der Standardwert ist 30 (d. h. 30 Zehntel oder 3 Sekunden).

Der kleinste Zeitwert wird durch die Geschwindigkeit des angeschlossenen Geräts bestimmt und ist für das Hostende von größerem Interesse. Wenn der Host, der den Router steuert, die Timeout-Einstellung auf den kleinstmöglichen Wert reduziert, kann die Leistung verbessert werden, wenn einige Geräte ausgefallen sind.

[no] bsc retries retry number

Mit diesem Befehl wird die Anzahl der Wiederholungsversuche festgelegt, die ausgeführt werden, bevor ein Gerät als ausgefallen gilt. Der Bereich liegt zwischen 1 und 100; Der Standardwert ist 5 Wiederholungen.

[no] Service-Basiswert

Dieser Befehl gibt den Wert für servlim an (active und inactive End-Station Polling Ratio). Der Bereich liegt zwischen 1 und 50; Der Standardwert ist 3.

[no] bc spec-polll

Dieser Befehl weist den Host an, bestimmte Polls als allgemeine Polls zu behandeln. Verwenden Sie diesen Befehl, wenn Sie mit Tandem Hosts arbeiten.

Weitere Informationen finden Sie unter Konfigurieren von Bisync-Optionen auf einer seriellen Schnittstelle bei der Konfiguration des seriellen Tunnels und des seriellen Tunnels.

Konfliktkonfiguration

Warum Contention?

Der Konflikt ist die 3780 Variante des Bisync. Es gibt keine Adressen für Steuergeräte. Die Geräte sind Punkt-zu-Punkt verbunden. Im Allgemeinen wählt ein Remote-Gerät an einen zentralen Standort und geht davon aus, dass keine anderen Geräte vorhanden sind.

Wann wird der Wettbewerb verwendet?

Verwenden Sie den Konflikt nur, wenn Sie die Protokolle Remote Job Entry (RJE), 3780 und 2780 verwenden. Nachdem Sie einen Konflikt identifiziert haben, stellen Sie sicher, dass beide Enden für die Verwendung des Konflikts konfiguriert sind.

Wenn Sie sich nicht sicher sind, gehen Sie wie folgt vor:

1. Konfigurieren Sie die Basiskonfiguration als primär.

2. Aktivieren Sie das Debug-Basispaket.

3. Stellen Sie sicher, dass das angeschlossene Gerät mit der Abfrage beginnt.

Nachrichten mit 1 Byte 2D geben einen Konflikt an. Byte vor der 2D sind nicht 3780.

Prioritäten

Im Vergleich zum gesamten anderen Datenverkehr, der über den WAN-Backbone läuft, ist der bisynische Datenverkehr sehr klein und kann leicht durch anderen Datenverkehr überlastet werden. Ein Verlust von Frames in bisync erfordert ein langes Wiederherstellungsintervall, das für die Endgeräte leicht erkennbar ist. Um dieses Problem zu minimieren, wird eine Priorisierung des bisynchronen Datenverkehrs empfohlen. Sie können den Datenverkehr entweder mit BSTUN-Prioritäten oder mit benutzerdefinierter Warteschlangenverwaltung priorisieren.

• Prioritätswarteschlange ist eine Routing-Funktion, bei der Frames in einer Schnittstellenausgabewarteschlange basierend auf verschiedenen Eigenschaften wie Paketgröße oder Schnittstellentyp priorisiert werden.

  Mithilfe der Prioritätswarteschlange für die Ausgabe kann ein Netzwerkadministrator vier Prioritäten für den Datenverkehr definieren: hohe, normale, mittlere und niedrige?. Wenn der Datenverkehr in den Router eingeht, wird er einer der vier Ausgabewarteschlangen zugewiesen. Pakete in der Warteschlange mit der höchsten Priorität werden zuerst übertragen. Wenn diese Warteschlange leer ist, wird Datenverkehr in der Warteschlange mit der höchsten Priorität usw. übertragen. Dieser Mechanismus stellt sicher, dass bei Überlastungen die Daten mit der höchsten Priorität nicht durch Datenverkehr mit geringerer Priorität verzögert werden. Wenn jedoch der an eine bestimmte Schnittstelle gesendete Datenverkehr die Bandbreite dieser Schnittstelle überschreitet, kann es bei Datenverkehr mit niedrigerer Priorität zu erheblichen Verzögerungen kommen.

  Wenn Sie beispielsweise IP-Adressen für serielle WAN-Verbindungen mit einer höheren Priorität als IPX definieren, nutzt der BSC-Datenverkehr in TCP/IP die Tatsache, dass IP mit einer höheren Priorität übertragen wird.

• Mit der benutzerdefinierten Warteschlangenverwaltung kann ein Kunde einen Prozentsatz der Bandbreite für bestimmte Protokolle reservieren. Kunden können bis zu zehn Ausgabewarteschlangen für normale Daten und eine zusätzliche Warteschlange für Systemmeldungen definieren, z. B. LAN-Keepalive-Meldungen (Routingpakete werden der Systemwarteschlange nicht zugewiesen). Die Cisco Router bearbeiten die einzelnen Warteschlangen nacheinander: Sie übertragen einen konfigurierbaren Prozentsatz des Datenverkehrs in jeder Warteschlange, bevor sie zur nächsten weitergeleitet werden. Wenn Sie benutzerdefinierte Warteschlangen verwenden, können Sie garantieren, dass geschäftskritische Daten immer einen bestimmten Prozentsatz der Bandbreite erhalten, während ein vorhersehbarer Durchsatz für anderen Datenverkehr sichergestellt ist.

  Um diese Funktion bereitzustellen, legen die Cisco Router anhand der Schnittstellengeschwindigkeit und des konfigurierten Prozentsatzes fest, wie viele Bytes von jeder Warteschlange übertragen werden sollen. Wenn die berechnete Byteanzahl aus einer bestimmten Warteschlange übertragen wurde, schließt der Router die Übertragung des aktuellen Pakets ab und wechselt zur nächsten Warteschlange. Letztendlich wird jede Warteschlange in einem Round-Robin-Verfahren gewartet.

Weitere Informationen finden Sie unter Konfigurieren des seriellen Tunnels und Blockieren des seriellen Tunnels und unter Festlegen der Warteschlangenrichtlinie für die Überlastungsverwaltung.

[no] priority-list list-list-number protocol bstun queue [gt | lt packetsize] [address bstun group bsc-addr]

Geben Sie den Befehl priority-list protocol bstun global configuration ein, um auf Basis des BSTUN-Headers Prioritäten für die BSTUN-Warteschlangenverwaltung festzulegen. Geben Sie die no-Form des Befehls aus, um zu normalen Prioritäten zurückzukehren.

[no] custom-queue-list [Liste]

Die Liste ist eine ganze Zahl (1 - 16), die die Nummer der benutzerdefinierten Warteschlangenliste darstellt.

Keepalives-Konfiguration

[no] bstun remote-peer-keepalive-Intervall

Dieser Befehl aktiviert BSTUN-Peer-Keepalives. Dadurch wird eine Anforderung an den Peer gesendet, wenn der Peer länger als den Intervallzeitraum stummgeschaltet wurde. Jeder Frame setzt die Uhr zurück, nicht nur Keepalives. Der Standardwert ist 30 Sekunden.

[no] Anzahl der Keepalive-Keepalive-Keepalive-Nachrichten

Wenn diese Anzahl von Keepalives nacheinander verpasst wird, wird die BSTUN-Verbindung unterbrochen. Der Standardwert ist 3.

Verwendung von Keepalives

Keepalives sind nützlich, um Tunnel-Ausfälle zu verhindern, wenn Sie lokal-ack und TCP/IP ausführen. Der Tunnel deaktiviert eine Schnittstelle nur, wenn ein Signal von der Fernbedienung empfangen wird. Wenn der Tunnel ausfällt, werden niemals Signale empfangen.

Im Passthru ist dies nicht erforderlich, da eine End-to-End-Anbindung erforderlich ist.

Debug-Befehle

[no] debug bstun event group

Mit diesem Befehl können Sie BSTUN-Verbindungen und -Status debuggen. Wenn diese Funktion aktiviert ist, werden Meldungen angezeigt, die die Verbindungsherstellung und den Gesamtstatus anzeigen.

[no] debug bstun paketgroup group buffer size displayed-bytes-size

Mit diesem Befehl können Sie Pakete debuggen, die über die BSTUN-Links übertragen werden.

[no] debug bsc group buffer-size display-byte-size

Mit diesem Befehl können Frames gedebuggt werden, die die BSC-Funktion durchlaufen.

[no] Debug-Basispaket

Mit diesem Befehl können Frames gedebuggt werden, die die BSC-Funktion durchlaufen. Er verfolgt alle Schnittstellen, die mit einer BSTUN-Gruppennummer konfiguriert wurden.

[no] Debug bsc-Ereignisgruppe

Mit diesem Befehl können Sie Ereignisse debuggen, die im BSC-Feature auftreten. Wenn die Gruppennummer weggelassen wird, werden alle Schnittstellen verfolgt, die mit einer BSTUN-Gruppennummer konfiguriert sind.

Befehle anzeigen

Schaubügel

Dieser Befehl zeigt den aktuellen Status von BSTUN an.

This peer: 10.10.20.108
 *Serial5 -- interface for ATM: R1710V421 (group 3 [bsc])
route  transport  address      state       rx_pkts   tx_pkts     drops
C2    TCP         10.10.10.107 open        655630    651332      0
 Serial6 -- interface for SEC: MST012  (group 2 [bsc])
route  transport  address      state       rx_pkts   tx_pkts   drops
C2     TCP        10.10.10.107 open        649385    644001      0

Prüfen Sie, ob folgende Probleme vorliegen:

• Staat geschlossen.

• Löscht.

• Niedrige Paketanzahl

  Hinweis: Die geringe Paketanzahl weist nicht immer auf Probleme hin. Wenn Sie Local-ack ausführen, besteht die Anzahl nur aus Datenframes, die deutlich kleiner sind als die tatsächliche Anzahl von Frames, die vom Host gesendet werden.

bsc anzeigen

Dieser Befehl zeigt den aktuellen Status von BSC an.

In Passthru

BSC pass-through on Serial5:
Output queue depth: 0.
HDX enforcement state: IDLE.
Frame sequencing state: SEC.
Tx-Active: Idle. Rx-Active: False.
Tx Counts: 670239 frames(total). 670239 frames(data). 9288816 bytes.
Rx Counts: 651332 frames(total). 651332 frames(data). 651332 bytes.

Prüfen Sie, ob folgende Probleme vorliegen:

• Wenn der HDX-Durchsetzungsstatus in einem anderen Zustand als IDLE feststeckt, kann ein Problem mit dem angeschlossenen Gerät oder mit diesem Router auftreten. Dies weist in der Regel darauf hin, dass das Gerät nicht reagiert. Aktivieren Sie das Basisereignisdebug. Wenn Remote-Nachrichten häufig keine Antwort anzeigen, überprüfen Sie zuerst, ob das Gerät aktiviert ist, und aktivieren Sie dann Duplex. Wenn keine Nachrichten vorhanden sind und keine Wiederherstellung erfolgt ist, ist ein Übertragungs-Abschlussereignis verloren gegangen, und es wurde ein Fehler gefunden, der möglicherweise katastrophal ist.

• Der Frame-Sequenzstatus gibt an, welches FSM (Finite State Machine, endliche Statusmaschine) überprüft werden soll.

• Wenn Rx-Active bei True feststeckt, weist dies darauf hin, dass etwas Schlechtes mit der Hardware passiert ist. Geben Sie ein Shut und dann ein no shutdown aus, um die Schnittstelle zurückzusetzen. Wenn dies nicht funktioniert, laden Sie den Router neu.

Lokal

BSC local-ack on Serial0:
Secondary state is CU_Idle.
Control units on this interface:

      Poll address: 40. Select address: 60 *CURRENT-CU*
      Current active device address is: 40.
      State is Active.
      Tx Counts: 87228 frames(total). 11 frames(data). 87353 bytes.
      Rx Counts: 87271 frames(total). 5 frames(data). 436312 bytes.

Total Tx Counts: 87228 frames(total). 11 frames(data). 87353 bytes.
Total Rx Counts: 174516 frames(total). 5 frames(data). 523557 bytes.

Wenn der Zustand in TCU_Down feststeckt, weist dies darauf hin, dass etwas die Schnittstelle zwingt, inaktiv zu bleiben. Prüfen Sie den Uhren- und den BSC-Modus, und stellen Sie sicher, dass keine administrativen Störungen auftreten. Gelegentlich startet ein shutdown-Befehl gefolgt von einem no shutdown-Befehl die Schnittstelle erneut.

Allgemein

• Eine Tiefe der Ausgabewarteschlange größer als 1 weist auf einen Rückstand an der Schnittstelle hin. Überprüfen Sie, ob Halbduplex richtig konfiguriert ist.

• Der Out-of-SYN-Hunt-Modus bedeutet entweder, dass die Schnittstelle inaktiv ist oder dass der Empfänger deaktiviert wurde. Das, was für Rx-Active gilt, gilt auch hier.

Seriennummer der Schnittstelle anzeigen

Dieser Befehl ist hilfreich, um die Zähler anzuzeigen, die dieser seriellen Schnittstelle zugeordnet sind.

Received 0 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

Hinweis: Fehler bedeuten Probleme.

Prüfen Sie, ob folgende Probleme vorliegen:

• Abgebrochen weist auf eine fehlerhafte Übertragung hin.

• ignorierte Frames sind Frames, die das Bisync-Protokoll verletzen.

• Giganten weisen darauf hin, dass entweder die MTU zu klein oder eine bisync Sequenz schlecht ist.

• overrun weist auf CPU-Ressourcenengpässe hin.

• CRC weist auf Beschädigungen an der Leitung hin (laut oder sonstige).

Wenn Sie das DTE-Kabel verwenden und die Leitung scheinbar häufig ausfällt oder wenn die Übertragung fehlschlägt, aber Arbeit erhält, müssen Sie möglicherweise den Befehl ignore-dcd ausführen. Dies kann mithilfe eines Protokollanalysators überprüft werden. Wenn das DCE überträgt, wird die Data Carried Detect (DCD) ausgelöst. Wenn der Vorgang abgeschlossen ist, wird die DCD heruntergefahren, sodass der Router nicht antworten kann.

• Hardware ist CD2430 zeigt den Cirrus-Chipsatz an.

• Hardware ist HD64570 zeigt den Hitachi-Chipsatz an.

Hitachi verwendet Zeichenunterbrechungen und softwarebasiertes Framing. DCD wird nicht gut behandelt. Cirrus verwendet Frame-Interrupts. Frames werden in Code integriert. Es bietet Optionen zum Abspielen mit DCD. Beim Debuggen ist es wichtig, dass Sie den Schnittstellentyp kennen, da zwischen diesen einige Unterschiede bestehen.

Das Verbindungsprotokoll muss aktiviert sein. Wenn das Verbindungsprotokoll nicht aktiv ist, überprüfen Sie, ob der BSC-Modus konfiguriert ist.

Serial5 is up, line protocol is up
  Hardware is CD2430 in sync mode
 MTU 265 bytes, BW 4 Kbit, DLY 20000 usec, rely 255/255, load 1/255
  Encapsulation BSTUN, loopback not set
    Half-duplex enabled.
      cts-delay 0 millisec
      dcd-txstart-delay 100 millisec
      dcd-drop-delay 100 millisec
      transmit-delay 0 millisec
      Errors - 0 half duplex violation
   Last input 10:27:12, output 1:07:12, output hang never
   Last clearing of "show interface" counters 4d11
   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
      3223346 packets input, 3223356 bytes, 0 no buffer
      Received 0 broadcasts, 0 runts, 0 giants
      0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
      3242346 packets output, 45259079 bytes, 0 underruns
      0 output errors, 0 collisions, 8 interface resets, 0 restarts
      0 output buffer failures, 0 output buffers swapped out
      4 carrier transitions
      DCD=up DSR=up DTR=up RTS=down CTS=down

Fehlerbehebung bei IBM Bisync

Verwenden von Passthru-FSMs

Stellen Sie sicher, dass Sie passthru ausführen. Sie müssen das passende Finite State Machine (FSM) finden, um zu folgen.

Überprüfen Sie die Ereignisdebugmeldungen. Es gibt zwei FSMs, die durchgehen müssen. Das HDX-FSM ist ein Halbduplex-Durchsetzungs-FSM. Die Stromversorgung erfolgt unabhängig davon, ob die Leitung für Vollduplex- oder Halbduplex konfiguriert ist. Es versucht sicherzustellen, dass die Übertragungswarteschlange eines Routers nicht mit alten Daten zurückprotokolliert wird. Der FS-FSM stellt sicher, dass späte Frames durch das Netzwerk nicht die etablierten Sitzungen zerstören.

Um herauszufinden, wo Sie hinschauen sollen, gehen Sie direkt zu konkurrierendem FSM, wenn Contention konfiguriert ist. Andernfalls sehen Sie sich den Zustand an, in dem der IDLE-Status ausgeführt wird. Wenn Sie SEC sehen, sehen Sie sich die sekundäre Frame-Sequenz FSM an. Wenn Sie PRI sehen, sehen Sie sich die primäre Frame-Sequenz FSM an.

BSC: Serial6: HDX-FSM event: RXV old_state: PND_RCV. new_state: IDLE.
BSC: Serial6: FS-FSM event: SDI EOT old_state: SEC. new_state: IDLE.
BSC: Serial6: NDI: Data (8 bytes): C24100C2C27F7F2D
BSC: Serial6: FS-FSM event: NDI BID old_state: IDLE. new_state: SEC.
BSC: Serial6: New Address(C2) New NS(01)
BSC: Serial6: HDX-FSM event: TX old_state: IDLE. new_state: PND_COMP.
BSC: Serial6: HDX-FSM event: CmpOTH old_state: PND_COMP. new_state: PND_RCV.
BSC: Serial6: SDI: Data (1 bytes): 37
BSC: Serial6: HDX-FSM event: RXV old_state: PND_RCV. new_state: IDLE.

Wenn Sie sich die Tabelle anschauen, sehen Sie Eingaben auf der linken Seite und Zustände oben. Jeder Eintrag in einer Spalte hat das Formular {nächster Zustand, Aktion} Die Aktion wird zuerst ausgeführt, dann erfolgt der Übergang.

Verwendung von lokalem FSM

Stellen Sie sicher, dass Sie local-ack verwenden. Ein Befehl show bsc gibt an, ob die Schnittstelle Abfragemodus oder Polling ist. Verwenden Sie daher das entsprechende LACK FSM.

Häufige Probleme

Übergeben von 3780 Daten an 3270 Konfig. oder umgekehrt

Vorsicht: Tun Sie dies nicht. Dies funktioniert nicht zuverlässig.

Konfigurationsroute zu einem fehlerhaften Peer

Sie haben alles konfiguriert, und es passiert nichts. Sie aktivieren das Debug-Basispaket auf dem Remote-Router und sehen nichts. Anschließend aktivieren Sie das Debugpaket und sehen immer noch nichts. Aktivieren Sie in dieser Phase das Debug-Bstun-Ereignis. Sie sehen wahrscheinlich immer noch nichts. Wechseln Sie zurück zum Hostendrouter, und aktivieren Sie das Debug-Bstun-Ereignis. Sie sollten jetzt mehrere Meldungen sehen, die auf eine fehlerhafte Verbindung hinweisen.

Konfiguration ungültiger Gruppennummern

Dies wird beobachtet, wenn an beiden Enden des Tunnels eine andere Gruppennummer konfiguriert ist. Daten werden entweder über die falsche Schnittstelle übertragen oder auf BSTUN-Ebene verworfen.

Lokale und Passthrough-Gruppen-Nummern mischen sich nicht. Stellen Sie sicher, dass die Protokollgruppendefinitionen im gesamten Netzwerk konsistent sind. Geräte, auf denen Contention (3780) ausgeführt wird, müssen sich ebenfalls auf einer anderen Gruppennummer als 3270 befinden.

Tandem-Hosts

21:55:18: BSC: Serial4: SDI-rx: Data (5 bytes): C7C740402D
21:55:19: BSC: Serial5: SDI-tx: Data (1 bytes): 37
21:55:19: BSC: Serial5: SDI-tx: Data (5 bytes): C2C240402D
21:55:21: BSC: Serial4: SDI-rx: Data (1 bytes): 37
21:55:21: BSC: Serial4: SDI-rx: Data (5 bytes): C7C740402D
21:55:22: BSC: Serial5: SDI-tx: Data (1 bytes): 37
21:55:22: BSC: Serial5: SDI-tx: Data (5 bytes): 404040402D
21:55:24: BSC: Serial4: SDI-rx: Data (1 bytes): 37

Tandems befolgen keine strengen 3270 Konventionen. Sie führen alle ihre Umfragen mit bestimmten Umfragen durch, was ein Problem für das Standard-LACK-FSM verursacht. Damit die Tandems ordnungsgemäß funktionieren, konfigurieren Sie bsc spec-polll auf der sekundären BSC-Schnittstelle.

Unterschied zwischen Voll- und Halbduplex

Vollduplex und Halbduplex sind leicht zu verwechseln.

• Vollduplex kann Daten gleichzeitig zwischen einer Sendestation und einer Empfangsstation übertragen.

• Halbduplex kann Daten jeweils nur in eine Richtung zwischen einer Sendestation und einer Empfangsstation übertragen.

Weitere Informationen finden Sie im Abschnitt zum Befehl show bsc.

Wenn Sie über einen Protokollanalyzer oder eine Breakout-Box verfügen, schließen Sie den Analyzer ohne Router im System an.

• Wenn RTS oder CTS das Signal ändert, haben Sie Halbduplex; Andernfalls ist es Vollduplex.

• Wenn DCD viel zu wechseln scheint und die Leitung immer höher und herunterfährt oder nicht mehr verfügbar ist, können Sie DCD-Switching verwenden.

Hinweis: Bei dem primären Router kann es sich um Vollduplex-Router handeln, während der Remote-Router Halbduplex ist, und umgekehrt. Dabei handelt es sich um separate physische Linien, und die Kontrollsignale von den Schnittstellen werden nicht über den Tunnel übertragen.

BSC- und BSTUN-Beispiele

Beispiel für keine Geräteantwort

Dies ist ein Beispiel für zwei Schnittstellen auf einem sekundären Router: ein lokales und das andere Passthru. Auch von der Fernbedienung wird keine Antwort empfangen. Sobald Umfragen beim sekundären Router eingehen, müssen Sie ermitteln, was am Remote-Ende vor sich geht.

21:55:18: BSC: Serial4: SDI-rx: Data (5 bytes): C7C77F7F2D
21:55:19: BSC: Serial5: SDI-tx: Data (1 bytes): 37
21:55:19: BSC: Serial5: SDI-tx: Data (5 bytes): C2C27F7F2D
21:55:21: BSC: Serial4: SDI-rx: Data (1 bytes): 37
21:55:21: BSC: Serial4: SDI-rx: Data (5 bytes): C7C77F7F2D
21:55:22: BSC: Serial5: SDI-tx: Data (1 bytes): 37
21:55:22: BSC: Serial5: SDI-tx: Data (5 bytes): 40407F7F2D
21:55:24: BSC: Serial4: SDI-rx: Data (1 bytes): 37
21:55:24: BSC: Serial4: SDI-rx: Data (5 bytes): C7C77F7F2D
21:55:25: BSC: Serial5: SDI-tx: Data (1 bytes): 37
21:55:25: BSC: Serial5: SDI-tx: Data (5 bytes): C2C27F7F2D
21:55:27: BSC: Serial4: SDI-rx: Data (1 bytes): 37
21:55:27: BSC: Serial4: SDI-rx: Data (5 bytes): C7C77F7F2D
21:55:28: BSC: Serial5: SDI-tx: Data (1 bytes): 37
21:55:28: BSC: Serial5: SDI-tx: Data (5 bytes): C2C27F7F2D
21:55:30: BSC: Serial4: SDI-rx: Data (1 bytes): 37
21:55:30: BSC: Serial4: SDI-rx: Data (5 bytes): C7C77F7F2D

Wenn Sie sich das Remote-Ende im Passthru-Gehäuse anschauen, können Sie Frames sehen, die durch den Tunnel kommen, aber das angeschlossene Gerät ist immer noch ruhig.

BSC: Serial6: NDI: Data (8 bytes): C24100C2C27F7F2D
BSC: Serial6: NDI: Data (4 bytes): C2C00037
BSC: Serial6: NDI: Data (8 bytes): C24100C2C27F7F2D
BSC: Serial6: NDI: Data (4 bytes): C2C00037
BSC: Serial6: NDI: Data (8 bytes): C24100C2C27F7F2D
BSC: Serial6: NDI: Data (4 bytes): C2C00037
BSC: Serial6: NDI: Data (8 bytes): C24100C2C27F7F2D
BSC: Serial6: NDI: Data (4 bytes): C2C00037
BSC: Serial6: NDI: Data (8 bytes): C24100C2C27F7F2D
BSC: Serial6: NDI: Data (4 bytes): C2C00037

Prüfen Sie anschließend, ob das angeschlossene Gerät leer ist oder ob der Router einen fehlerhaften Sender hat: Aktivieren Sie das Ereignisdebuggen.

BSC: Serial6: NDI: Data (8 bytes): C24100C2C27F7F2D
BSC: Serial6: FS-FSM event: NDI BID old_state: IDLE. new_state: SEC.
BSC: Serial6: New Address(C2) New NS(01)
BSC: Serial6: HDX-FSM event: TX old_state: IDLE. new_state: PND_COMP.
BSC: Serial6: HDX-FSM event: CmpOTH old_state: PND_COMP. new_state: PND_RCV.
BSC: Serial6: Response not received from remote
BSC: Serial6: HDX-FSM event: T/O old_state: PND_RCV. new_state: IDLE.
BSC: Serial6: NDI: Data (4 bytes): C2C00037
BSC: Serial6: FS-FSM event: NDI EOT old_state: SEC. new_state: IDLE.
BSC: Serial6: HDX-FSM event: TX old_state: IDLE. new_state: PND_COMP.
BSC: Serial6: HDX-FSM event: CmpEOT old_state: PND_COMP. new_state: IDLE.
BSC: Serial6: NDI: Data (8 bytes): C24100C2C27F7F2D
BSC: Serial6: FS-FSM event: NDI BID old_state: IDLE. new_state: SEC.
BSC: Serial6: New Address(C2) New NS(01)

Folgen Sie der HDX-FSM-Leiterbahn. Wenn der Sender im Zustand PND_COMP feststeckt, schlägt er fehl. Es ist wahrscheinlich so, dass keine Uhr geliefert wird. Wie Sie in der vorherigen Beispielausgabe sehen können, wird der PND_RCV-Status erreicht, und Sie sehen die Antwort, die nicht von der Fernbedienung empfangen wurde, was auf einen schlechten Empfang oder ein inaktives Gerät zeigt.

Beispiel für Netzwerklatenzen

Dies ist ein Beispiel für Netzwerklatenzen in einer virtuellen Multi-Drop-Umgebung:

BSC: Serial0: NDI: Data (5 bytes): C703001061
BSC: Serial0: SDI: Data (1 bytes): 37
BSC: Serial0: SDI: Data (1 bytes): 37
BSC: Serial0: Discard SDI: Data (1 bytes): 37
BSC: Serial0: SDI: Data (5 bytes): 404040402D
BSC: Serial0: NDI: Data (4 bytes): 40C00037
BSC: Serial0: SDI: Data (1 bytes): 37
BSC: Serial0: Discard SDI: Data (1 bytes): 37

!--- Output suppressed.

BSC: Serial0: SDI: Data (1 bytes): 37
BSC: Serial0: Discard SDI: Data (1 bytes): 37
BSC: Serial0: SDI: Data (5 bytes): C4C4C4C42D

Hier liegt ein Problem vor, da C4 nicht rechtzeitig geantwortet hat:

BSC: Serial0: SDI: Data (1 bytes): 37
BSC: Serial0: SDI: Data (1 bytes): 37
BSC: Serial0: Discard SDI: Data (1 bytes): 37
BSC: Serial0: SDI: Data (5 bytes): C5C5C5C52D
BSC: Serial0: NDI: Data (4 bytes): C5C00037
BSC: Serial0: SDI: Data (1 bytes): 37
BSC: Serial0: Discard SDI: Data (1 bytes): 37
BSC: Serial0: SDI: Data (5 bytes): C7C7C7C72D

Das ist wieder verloren. Sehen Sie weiter, und Sie sehen, dass das Problem etwas schlimmer wird:

BSC: Serial0: SDI: Data (1 bytes): 37
BSC: Serial0: SDI: Data (1 bytes): 37
BSC: Serial0: Discard SDI: Data (1 bytes): 37
BSC: Serial0: SDI: Data (5 bytes): 404040402D
BSC: Serial0: NDI: Data (4 bytes): 40C00037
BSC: Serial0: SDI: Data (1 bytes): 37
BSC: Serial0: Discard SDI: Data (1 bytes): 37
BSC: Serial0: SDI: Data (5 bytes): C1C1C1C12D

Der EOT für C7 ist plötzlich wieder aufgetaucht. Verwerfen Sie diese EOT, um sich von dieser zu erholen. Der nächste Frame ist EOT für C1.

In diesem Beispiel kommen Frames aus dem Netzwerk spät und nicht nacheinander an. Dies führt zu einer großen Anzahl nicht beantworteter Umfragen am Host. Die Lösung in diesem Fall ist die Konfiguration des lokalen Racks.

BSC- und BSTUN-Beispielkonfigurationen

Netzwerkdiagramm

Dieses Diagramm ist eine Beispielkonfiguration eines Standorts, auf dem sowohl 3270 als auch 3780 Bisync-Terminals ausgeführt werden.

Konfigurationen

In diesem Diagramm werden folgende Konfigurationen verwendet:

• Zentral

• Remote 1

• Remote 2

hostname central
!
bstun peer-name 10.10.10.107
bstun protocol-group 1 bsc
bstun protocol-group 2 bsc
bstun protocol-group 44 bsc-local-ack
!
interface Serial0
 description EFTPOS host
 no ip address
 encapsulation bstun
 no keepalive
 full-duplex
 clockrate 19200
 bstun group 1
 bsc contention 1
 bstun route all tcp 10.10.10.108
!
interface Serial2
 description WAN-ppp backbone
 ip address 10.10.10.107 255.255.255.0
 encapsulation ppp
 clockrate 2000000
!
interface Serial3
 description WAN-hdlc
 ip address 10.10.20.107 255.255.255.0
 bandwidth 2000
 no keepalive
 clockrate 2000000
!
interface Serial4
 description ATM Host
 no ip address
 encapsulation bstun
 no keepalive
 full-duplex
 bstun group 44
 bsc secondary
 bstun route all tcp 10.10.20.108
!
interface Serial5
 description ATM host
 no ip address
 encapsulation bstun
 no keepalive
 bstun group 2
 bsc secondary
 bstun route address C2 tcp 10.10.20.108
!
end

hostname remote1
!
bstun peer-name 10.10.10.108
bstun protocol-group 1 bsc
bstun protocol-group 44 bsc-local-ack
!
interface Serial0
 description EFTPOS 1
 no ip address
 encapsulation bstun
 no keepalive
 full-duplex
 clockrate 19200
 bstun group 1
 bsc char-set ebcdic
 bsc contention
 bstun route all tcp 10.10.10.107
!
interface Serial1
 description ATM 3
 no ip address
 encapsulation bstun
 no keepalive
 bstun group 44
 bsc char-set ebcdic
 bsc primary
 bstun route address 40 tcp 10.10.10.107
!
interface Serial3
 description WAN -ppp
 ip address 10.10.10.108 255.255.255.0
 encapsulation ppp
!
end

hostname remote2
!
!
bstun peer-name 10.10.20.108
bstun protocol-group 2 bsc
bstun protocol-group 44 bsc-local-ack
bstun protocol-group 10 bsc-local-ack
!
interface Serial0
 description WAN-hdlc
 ip address 10.10.20.108 255.255.255.0
 bandwidth 2000
 no keepalive
!
interface Serial5
 description ATM 1
 mtu 265
 encapsulation bstun
 clockrate 19200
 bstun group 44
 bsc char-set ebcdic
 bsc primary
 bstun route address C2 tcp 10.10.10.107
!
interface Serial6
 description interface for ATM 2
 mtu 265
 encapsulation bstun
 clockrate 19200
 bstun group 2
 bsc char-set ebcdic
 bsc primary
 bstun route address C2 tcp 10.10.10.107
!
ip route 10.10.10.0 255.255.255.0 10.10.20.107
!
end

Referenzen

Allgemeine Informationen - Binäre synchrone Kommunikation, IBM Systems Reference Library, GA27-3004-2.

IBM 3274: Kapitel 4: Remote Operations BSC

IBM 3275: Kapitel 9.

BSTUN-Befehle auf der Cisco Documentation CD-ROM (online verfügbar in Serial Tunnel und Block Serial Tunnel Commands).

Zugehörige Informationen

• Konfiguration und Fehlerbehebung für Serial Tunneling (STUN)
• Technischer Support - Cisco Systems