Guide sur BSC et BSTUN

Introduction

Ce document est conçu pour vous aider à configurer et à utiliser le protocole de liaison de données BSC (Binary Synchronous Communication) et le BSTUN (Block Serial Tunneling) sur les routeurs Cisco. Il vous aide également à résoudre les problèmes qui peuvent survenir.

Conditions préalables

Conditions requises

Les lecteurs de ce document devraient avoir connaissance des sujets suivants :

• Concepts BSC (Binary Synchronous Communications).

• Compréhension générale des principes de base du traitement des données.

Components Used

Les informations de ce document sont basées sur Cisco IOS ? ? avec le jeu de fonctions IBM.

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Présentation du système

Les Figures 1 et 2 montrent comment une liaison BSC existante entre deux périphériques peut être reconfigurée pour utiliser les routeurs Cisco. Cela fournit la même liaison logique, sans modification des périphériques BSC existants.

Les routeurs Cisco transportent tous les blocs BSC entre les deux périphériques, via l’encapsulation BSTUN (Block Serial Tunneling). Pour chaque bloc BSC reçu de la ligne, une adresse et des octets de contrôle sont ajoutés pour créer une trame BSTUN, puis BSTUN est utilisé pour livrer au routeur de destination approprié.

Configuration BSC/BSTUN

Sur un routeur propre, exécutez ces commandes, dans l’ordre dans lequel elles sont répertoriées.

Commandes globales

[no] bstun peer-name ip-address

L'adresse IP définit l'adresse par laquelle cet homologue BSTUN est connu des autres homologues BSTUN qui utilisent le transport TCP.

Remarque : cette commande doit être configurée dans les versions du logiciel Cisco IOS antérieures à la version 11.3, ou elle doit être configurée si des adresses TCP/IP sont utilisées dans les instructions de route.

[no] bstun protocol-group group numéro-groupe {bsc | bsc-local-ack | adplex | adt-poll | adt-poll-select | adt-vari-poll | diebold | async-générique | mdi}

Il s'agit d'une commande globale permettant d'associer des numéros de groupe à des noms de protocole. Le numéro-groupe est un entier décimal compris entre 1 et 255. La base | bsc-local-ack | adplex sont des mots clés prédéfinis du protocole BSTUN. Pour plus d'informations, référez-vous à Définition du groupe de protocoles dans Configuration du tunnel série et du tunnel série de blocs.

La sélection du type de groupe est importante pour déterminer s'il faut utiliser passthru ou un accusé de réception local (local-ack).

Remarque : Cette commande doit toujours être configurée.

Commandes d'interface

encapsulation bstun

Il s’agit d’une commande d’interface qui configure la fonction BSTUN sur une interface série particulière. Cette commande doit être configurée sur une interface avant que d'autres commandes BSTUN ou BSC ne soient configurées pour cette interface.

[no] bstun group group numéro

Il s'agit d'une commande d'interface qui définit le groupe BSTUN auquel cette interface appartient. Chaque interface BSTUN sur un routeur doit être placée dans un groupe BSTUN défini précédemment. Les paquets circulent uniquement entre les interfaces BSTUN qui font partie du même groupe. Le numéro-groupe est un entier décimal compris entre 1 et 255.

Le numéro de groupe a déjà déterminé si cette interface exécute local-ack ou passthru.

[no] mode bsc

Voici une liste des principales options. Pour obtenir une liste complète, reportez-vous à Configuration des options de synchronisation sur une interface série dans Configuration du tunnel série et du tunnel série de bloc

Aucune trame n'est reçue ou envoyée tant que le mode n'est pas configuré pour l'un de ces paramètres :

• contention : définit la liaison BSC connectée à l'interface série comme étant destinée à une station BSC point à point. Seulement 3780, et seulement en mode passthru.

• contention virtual-address—Première disponible dans le logiciel Cisco IOS Version 11.3. Utilisé avec la fonction de conflit de numérotation pour permettre à plusieurs périphériques distants d’utiliser la même interface au niveau du routeur hôte.

• dial-contention timeout—Premier disponible dans le logiciel Cisco IOS Version 11.3. Utilisé au niveau du routeur hôte pour la gestion des conflits. Permet à plusieurs périphériques distants de se multiplier sur la même interface physique.

• primary - Définit que le routeur agit comme extrémité principale de la liaison BSC et que le ou les périphériques connectés sont des stations tributaires BSC.

• secondary - Définit que le routeur agit comme extrémité secondaire de la liaison BSC et que le périphérique distant connecté est une station de contrôle BSC (par exemple, un processeur frontal [FEP] ou un autre périphérique hôte).

Si cette commande n'est pas configurée, le protocole de ligne de l'interface est désactivé et l'interface ne fonctionne pas.

Configuration de la route TCP

Dans cette configuration, le système de transport est TCP/IP. Ceci peut s'exécuter sur n'importe quel support physique sur lequel TCP/IP peut s'exécuter.

[no] bstun route all tcp ip address

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

L'adresse IP est identique à l'adresse IP spécifiée dans le nom d'homologue du routeur partenaire.

Configuration de la route série

Dans cette configuration, le tunnel utilise le transport propriétaire Cisco. Il est beaucoup plus rapide que TCP/IP, mais passe uniquement sur une interface série.

[no] bstun route all interface serial interface number

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

Configuration directe du passage Frame Relay

Dans cette configuration, le tunnel utilise une forme propriétaire d’encapsulation série sur Frame Relay, qui fonctionne aussi rapidement que les routes série.

[no] bstun route address address-number interface serial interface number dlci dlci numéro-dlci

Exécutez cette commande sur l’interface Frame Relay :

[no] frame-relay map dlci-number bstun

Configuration Local Ack Direct Frame Relay

Cette configuration utilise le contrôle de liaison logique de type 2 (LLC2) sur l’encapsulation Frame Relay, pour donner un accusé de réception local et un contrôle de session de bout en bout. Le mot clé lsap doit être inclus ; si ce n’est pas le cas, l’encapsulation devient passthru.

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

Exécutez cette commande sur l’interface Frame Relay :

[no] frame-relay map dlci-number llc2

Remarque : Pour plus d'informations, référez-vous à Spécification du transfert des trames dans Configuration du tunnel série et du tunnel série de blocs.

Configuration du passage

Pourquoi Passthru ?

Passthru est le mode de tunnellisation de base. Chaque trame transmise entre les périphériques est transmise, sans modification, via le tunnel BSTUN. Un numéro d’ordre et une adresse de périphérique sont ajoutés pour s’assurer que les latences sur le réseau n’affectent pas le fonctionnement du protocole. L’arrivée de sondages tardifs ou de signaux de fin de transmission (EOT) pourrait perturber de manière significative une session existante.

Quand utiliser Passthru

Passthru doit être utilisé dans ces circonstances :

• Aucune trame d'accusé de réception explicite n'est envoyée pour vérifier l'intégrité des données.

• Le protocole n'est pas pur 3270.

• L'utilisateur souhaite une connectivité de bout en bout des périphériques et les latences réseau sont faibles.

Configuration Local-Ack

Pourquoi Local-Ack ?

Le serveur local supprime la surcharge de l'envoi de toutes les trames de contrôle dans le tunnel. Lorsque l’hôte envoie le premier sondage à une unité de contrôle, une trame de contrôle spéciale est envoyée à travers le tunnel pour démarrer l’interrogation à distance de l’adresse de ce périphérique. Une fois que le périphérique distant indique qu’il est actif, une trame de contrôle est envoyée au routeur hôte pour lui demander de répondre aux interrogations. Lorsque le périphérique distant tombe en panne, une indication est envoyée à travers le tunnel pour indiquer au routeur hôte de ne plus répondre aux interrogations.

Quand utiliser Local-Ack

Le serveur local peut être utilisé dans les circonstances suivantes :

• 3270 bisync est utilisé.

• La latence du réseau entraîne des délais d'attente de session bisync.

• L'excès de trafic sur le WAN est un problème.

Options Local-Ack

[non] durée de pause bsc

Cette commande spécifie la durée entre le début d'un cycle d'interrogation et le suivant. La valeur par défaut est 30 (30 dixièmes ou 3 secondes).

Il est recommandé de configurer cette commande lorsqu'il n'y a qu'un ou deux contrôleurs sur l'interface bisync. Il ralentit efficacement l'interrogation et alloue davantage de cycles CPU au périphérique connecté.

[no] bsc poll-timeout time

Cette commande définit le délai d'attente d'un sondage ou d'une séquence de sélection, en unités d'un dixièmes de seconde ; la valeur par défaut est 30 (30 dixièmes, ou 3 secondes).

La plus petite valeur temporelle est déterminée par la vitesse du périphérique connecté et elle présente un intérêt plus grand à l'extrémité hôte. Si l’hôte qui dirige le routeur réduit son délai d’attente à la valeur la plus faible possible, il y aura une amélioration des performances lorsque certains périphériques ont échoué.

[no] bsc retries retry-number

Cette commande définit le nombre de tentatives avant qu'un périphérique ne soit considéré comme mort. La plage est comprise entre 1 et 100 ; la valeur par défaut est 5 tentatives.

[non] valeur servlim bsc

Cette commande spécifie la valeur servlim (rapport d'interrogation de station d'extrémité active/inactive). La plage est comprise entre 1 et 50 ; la valeur par défaut est 3.

[no] bsc spec-poll

Cette commande indique à l’hôte de traiter des sondages spécifiques en tant que sondages généraux. Utilisez cette commande lorsque vous utilisez des hôtes en tandem.

Pour plus d'informations, référez-vous à Configuration des options de synchronisation sur une interface série dans Configuration du tunnel série et du tunnel série de bloc.

Configuration des conflits

Pourquoi les conflits ?

Contention est la variante 3780 de bisync. Il n'existe aucune adresse d'unité de contrôle. Les périphériques sont connectés point à point. En règle générale, un périphérique distant se connecte à un emplacement central et suppose qu'il n'existe aucun autre périphérique.

Quand utiliser la contention

Utilisez la contention uniquement lorsque vous utilisez les protocoles RJE (Remote Job Entry), 3780 et 2780. Une fois que vous avez identifié un conflit, assurez-vous que les deux extrémités sont configurées pour utiliser le conflit.

Si vous n'êtes pas sûr, procédez comme suit :

1. Configurez bsc primary.

2. Activez debug bsc packet.

3. Faire en sorte que le périphérique connecté commence à interroger.

Les messages avec 1 octets 2D indiquent une contention. Tous les octets avant le 2D ne sont pas 3780.

Priorités

Par rapport à tout autre trafic qui passe par le réseau fédérateur WAN, le trafic bisync est très petit et facilement submergé par d'autres trafics. Une perte de trames en bisync nécessite un long intervalle de récupération, qui est facilement visible pour les périphériques finaux. Pour minimiser ce problème, il est recommandé d'établir un ordre de priorité pour le trafic bisync. Vous pouvez hiérarchiser le trafic avec des priorités BSTUN ou avec une file d'attente personnalisée.

• La mise en file d’attente par priorité est une fonction de routage dans laquelle les trames d’une file d’attente de sortie d’interface sont hiérarchisées en fonction de diverses caractéristiques, telles que la taille des paquets ou le type d’interface.

  La mise en file d’attente de sortie prioritaire permet à un administrateur réseau de définir quatre priorités de trafic ? ? haut, normal, moyen et bas ? ? sur une interface donnée. Lorsque le trafic entre dans le routeur, il est affecté à l’une des quatre files d’attente de sortie. Les paquets de la file d’attente de priorité la plus élevée sont transmis en premier. Lorsque cette file d'attente est vide, le trafic sur la file d'attente de priorité supérieure suivante est transmis, etc. Ce mécanisme garantit que, lors de la congestion, les données de priorité la plus élevée ne sont pas retardées par un trafic de priorité inférieure. Cependant, si le trafic envoyé à une interface donnée dépasse la bande passante de cette interface, un trafic de priorité inférieure peut connaître des retards importants.

  Par exemple, si vous faites de l'IP une priorité plus élevée que l'IPX sur les liaisons série WAN, le trafic BSC dans TCP/IP tirera parti du fait que l'IP est transféré à une priorité plus élevée.

• La mise en file d'attente personnalisée permet à un client de réserver un pourcentage de bande passante pour des protocoles spécifiés. Les clients peuvent définir jusqu'à dix files d'attente de sortie pour les données normales et une file d'attente supplémentaire pour les messages système, tels que les messages de veille LAN (les paquets de routage ne sont pas affectés à la file d'attente système). Les routeurs Cisco desservent chaque file d'attente de manière séquentielle : ils transmettent un pourcentage configurable du trafic sur chaque file d'attente avant de passer à la suivante. Lorsque vous utilisez la mise en file d'attente personnalisée, vous pouvez garantir que les données critiques sont toujours affectées à un certain pourcentage de la bande passante, tandis que le débit prévisible pour d'autres trafics est également assuré.

  Pour fournir cette fonctionnalité, les routeurs Cisco déterminent le nombre d’octets à transmettre à partir de chaque file d’attente, en fonction de la vitesse de l’interface et du pourcentage configuré. Lorsque le nombre d’octets calculé d’une file d’attente donnée a été transmis, le routeur termine la transmission du paquet en cours et passe à la file d’attente suivante. Finalement, chaque file d'attente est traitée de façon circulaire.

Référez-vous à Configuration du tunnel série et du tunnel série de blocs, et référez-vous à Choix de la stratégie de mise en file d'attente à utiliser dans Vue d'ensemble de la gestion de congestion.

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

Émettez la commande de configuration globale priority-list protocol bstun pour établir les priorités de mise en file d'attente BSTUN en fonction de l'en-tête BSTUN. Émettez la forme no de la commande pour revenir aux priorités normales.

[no] custom-queue-list [liste]

La liste est un entier (1 - 16) qui représente le numéro de la liste de file d'attente personnalisée.

Configuration de la sauvegarde

[no] bstun remote-peer-keepalive interval

Cette commande active les keepalives d'homologue BSTUN. Cela envoie une requête à l'homologue chaque fois que l'homologue est resté silencieux pendant plus longtemps que la période d'intervalle. Toute trame réinitialise l'horloge, et pas seulement des messages de veille. 30 secondes sont établies par défaut.

[no] bstun keepalive count number

Lorsque ce nombre de keepalives est manqué consécutivement, la connexion BSTUN est désactivée. Il est défini par défaut à 3.

Quand utiliser Keepalives

Les keepalives sont utiles pour vous protéger contre les pannes de tunnel lorsque vous exécutez les protocoles local-ack et TCP/IP. Le tunnel met une interface hors tension uniquement lorsqu'un signal est reçu de la télécommande. Si le tunnel est en panne, aucun signal n'est jamais reçu.

Dans le mode passthru, cela n'est pas nécessaire, car une connectivité de bout en bout est requise.

Commandes debug

[no] debug bstun event group

Cette commande vous permet de déboguer les connexions et l'état BSTUN. Lorsqu'elle est activée, elle entraîne l'affichage de messages indiquant l'établissement de la connexion et l'état général.

[no] debug bstun packet group group buffer-size display-bytes-size

Cette commande vous permet de déboguer les paquets qui traversent les liaisons BSTUN.

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

Cette commande vous permet de déboguer les trames qui traversent la fonction BSC.

[no] debug bsc packet

Cette commande vous permet de déboguer les trames qui traversent la fonction BSC. Il trace toutes les interfaces configurées avec un numéro de groupe BSTUN.

[no] debug bsc event group

Cette commande vous permet de déboguer les événements qui se produisent dans la fonction BSC. Si le numéro de groupe est omis, il trace toutes les interfaces configurées avec un numéro de groupe BSTUN.

Commandes show

show bstun

Cette commande affiche l'état actuel de BSTUN.

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

Vérifiez les problèmes suivants :

• État fermé.

• Des gouttes.

• Nombre de paquets faible.

  Remarque : Le faible nombre de paquets n'indique pas toujours les problèmes. Lorsque vous exécutez une liaison locale, le nombre se compose uniquement de trames de données, qui est significativement plus petit que le nombre réel de trames envoyées à partir de l'hôte.

show bsc

Cette commande affiche l'état actuel de BSC.

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

Vérifiez les problèmes suivants :

• Si l'état de mise en application HDX est bloqué dans un état autre que IDLE, il peut y avoir un problème avec le périphérique connecté ou avec ce routeur. Cela indique généralement que le périphérique ne répond pas. Activez le débogage d'événement bsc. Si vous ne voyez pas beaucoup de réponse de messages distants, vérifiez d'abord que le périphérique est activé, puis vérifiez le mode bidirectionnel. S'il n'y a aucun message et aucune récupération éventuelle, alors un événement d'achèvement de transmission a été perdu, et un bogue a été trouvé qui pourrait être catastrophique.

• L'état de séquence de trame vous indique la machine à état fini (FSM) à vérifier.

• Si Rx-Active est coincé sur True, cela indique que quelque chose de mauvais s'est produit avec le matériel. Émettez une fermeture, puis une non fermeture pour réinitialiser l'interface. Si cela ne fonctionne pas, rechargez le routeur.

En Ack Local

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.

Si l'état est bloqué dans TCU_Down, cela indique que quelque chose force cette interface à rester inactive. Vérifiez la synchronisation et le mode BSC et assurez-vous que rien n'est arrêté administrativement. Parfois, une commande shutdown suivie d'une commande no shut redémarre l'interface.

En général

• Une profondeur de file d'attente de sortie supérieure à 1 indique un arriéré sur l'interface. Vérifiez que le mode bidirectionnel non simultané est configuré correctement.

• Hors du mode de recherche SYN signifie que l'interface est désactivée ou que le récepteur a été désactivé. Ce qui s'applique à Rx-Active s'applique également ici.

show interface serial number

Cette commande est utile pour afficher les compteurs associés à cette interface série.

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

Note : Toute erreur entraîne des problèmes.

Vérifiez les problèmes suivants :

• les abandons indiquent une mauvaise transmission.

• les trames ignorées sont des trames qui violent le protocole bisync.

• les géants indiquent que le MTU est trop petit ou qu'une séquence de bisync est mauvaise.

• overrun indique une pénurie de ressources de CPU.

• CRC indique une corruption sur la ligne (bruyante ou autre).

Si vous utilisez un câble ETTD et que la ligne semble tomber fréquemment en panne, ou si la transmission échoue mais reçoit du travail, vous devrez peut-être émettre la commande ignore-dcd. Ceci peut être vérifié avec un analyseur de protocole. Lorsque le DCE transmet, le DCD (Data Carried Detect) est déclenché. Une fois terminé, le DCD est abaissé de sorte que le routeur ne peut pas répondre.

• Le matériel est CD2430 indique le jeu de puces Cirrus.

• Le matériel est HD64570 indique le jeu de puces Hitachi.

Hitachi utilise des interruptions de caractères et un tramage conçu par logiciel. Il ne gère pas bien DCD. Cirrus utilise des interruptions de trames. Les trames sont construites en ucode. Il a des options à jouer avec DCD. Il est important, lorsque vous déboguez, que vous connaissiez le type d'interface, car il y a des différences entre eux.

Le protocole de ligne doit être actif. Si le protocole de ligne n’est pas actif, vérifiez que le mode BSC est configuré.

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

Comment dépanner IBM Bisync

Comment utiliser les FSM Passthru

Vérifiez que vous exécutez passthru. Vous devez trouver la machine à état fini (FSM) correcte à suivre.

Regardez les messages de débogage d'événement. Il y a deux FSM à traverser. Le HDX-FSM est un FSM de mise en application semi-duplex. Il est piloté indépendamment du fait que la ligne soit configurée en mode bidirectionnel simultané ou en mode bidirectionnel non simultané. Il tente de s’assurer que la file d’attente de transmission d’un routeur n’est pas en attente avec d’anciennes données. Le système FS-FSM garantit que les trames tardives du réseau ne détruisent pas les sessions établies.

Pour déterminer où rechercher, accédez directement au FSM de contention, si le contention est configuré. Sinon, regardez l'état dans lequel il passe après l'état IDLE. Si vous voyez SEC, regardez la séquence de trame secondaire FSM. Si vous voyez PRI, regardez la séquence de trame principale FSM.

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.

Quand vous regardez la table, vous voyez des entrées sur le côté gauche et des états sur le dessus. Chaque entrée d'une colonne se présente sous la forme {next state, action} L'action est effectuée en premier, puis la transition se produit.

Comment utiliser Local-Ack FSM

Assurez-vous que vous exécutez local-ack. Une commande show bsc vous indique si l'interface est interrogatrice ou pollee. À partir de cela, utilisez le FSM LACK approprié.

Problèmes courants

Passage des données du 3780 à la configuration 3270 ou vice-versa

Attention : Ne faites pas ça. Cela ne fonctionne pas de manière fiable.

Configuration de la route vers un homologue incorrect

Vous avez tout configuré et rien ne se passe. Vous activez debug bsc packet sur le routeur distant et ne voyez rien. Vous activez ensuite debug bstun packet et ne voyez rien. À cette étape, activez debug bstun event ; vous ne voyez probablement toujours rien. Revenez au routeur hôte final et activez l'événement debug bstun. Vous devriez maintenant voir plusieurs messages indiquant une mauvaise connexion.

Configurer les numéros de groupe incorrects

Ceci est observé lorsque l'une des extrémités du tunnel est configurée avec un numéro de groupe différent. Les données sortent de la mauvaise interface ou sont rejetées au niveau BSTUN.

Les numéros de groupe de relais et de relais locaux ne se mélangent pas. Assurez-vous que les définitions de groupe de protocoles sont cohérentes sur l’ensemble du réseau. Les périphériques qui exécutent un conflit (3780) doivent également se trouver sur des numéros de groupe différents d'un 3270.

Hôtes Tandem

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

Les tandems n'obéissent pas à 3270 conventions strictes. Ils effectuent l'ensemble de leur interrogation avec des sondages spécifiques, ce qui cause un problème pour le FSM LACK par défaut. Pour que les tandems fonctionnent correctement, configurez bsc spec-poll sur l'interface secondaire BSC.

Différence entre le mode bidirectionnel simultané et le mode bidirectionnel non simultané

Il est facile de confondre le mode bidirectionnel simultané et le mode bidirectionnel non simultané.

• Le mode bidirectionnel simultané peut transmettre des données simultanément entre une station émettrice et une station réceptrice.

• Le mode bidirectionnel non simultané peut transmettre des données dans une seule direction à la fois, entre une station émettrice et une station réceptrice.

Consultez la section de la commande show bsc pour plus de détails.

Si vous disposez d'un analyseur de protocole ou d'une boîte de dérivation, connectez votre analyseur dans le système sans routeurs.

• Si RTS ou CTS change de signal, alors vous avez le mode bidirectionnel non simultané ; sinon, il s'agit du mode bidirectionnel simultané.

• Si DCD semble changer beaucoup, et que la ligne monte et descend ou reste inactive, vous pouvez avoir la commutation DCD.

Remarque : le routeur principal peut être en mode bidirectionnel simultané, tandis que le routeur distant est en mode bidirectionnel non simultané et vice versa. Il s’agit de lignes physiques distinctes et les signaux de contrôle des interfaces ne sont pas transportés à travers le tunnel.

Exemples BSC et BSTUN

Aucun exemple de réponse de périphérique

Voici un exemple de deux interfaces sur un routeur secondaire : un local-ack et l'autre passthru. Aucune réponse n'est reçue de la télécommande. Dès que vous voyez les sondages arriver dans le routeur secondaire, vous devez déterminer ce qui se passe à l’extrémité distante.

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

Lorsque vous regardez l'extrémité distante dans le boîtier passthru, vous pouvez voir des trames qui traversent le tunnel, mais le périphérique connecté est toujours silencieux.

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

Ensuite, déterminez si le périphérique connecté est inactif ou si le routeur a un émetteur incorrect : activez le débogage des événements.

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)

À partir de la trace, suivez le HDX-FSM. S'il est coincé dans l'état PND_COMP, l'émetteur échoue. Il est probable qu'aucune horloge n'est fournie. Comme vous pouvez le voir dans la sortie de l'exemple précédent, l'état PND_RCV est atteint, et vous voyez la réponse non reçue de distance, qui pointe vers une réception défectueuse ou un périphérique inactif.

Exemple de latence réseau

Voici un exemple de latence réseau dans un environnement virtuel multipoint :

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

Il y a un problème ici, parce que C4 n'a pas répondu à temps :

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

Encore une fois, c'est perdu. Regardez plus loin, et vous voyez que le problème s'aggrave un peu :

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

L'EOT pour C7 a soudainement réapparu. Éliminer l'EOT pour récupérer de cette situation ; la trame suivante est l’EOT pour C1.

Dans cet exemple, les trames en provenance du réseau arrivent en retard et hors séquence. Cela provoque un grand nombre d'interrogations non résolues sur l'hôte. La solution, dans ce cas, est de configurer local-ack.

Exemples de configuration BSC et BSTUN

Diagramme du réseau

Ce schéma est un exemple de configuration d'un site qui exécute à la fois 3270 et 3780 terminaux bisync.

Configurations

Ce diagramme utilise les configurations suivantes :

• Centrale

• Télécommande 1

• Distant 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

Références

Informations générales - Binary Synchronous Communication, IBM Systems Reference Library, GA27-3004-2.

IBM 3274 : Chapitre 4 : BSC des opérations à distance.

IBM 3275 : Chapitre 9.

Commandes BSTUN sur le CD-ROM de documentation Cisco (disponible en ligne dans les commandes Tunnel série et Block Serial Tunnel).

Informations connexes

• Configuration et dépannage de la tunnelisation série (STUN)
• Support technique - Cisco Systems