Guías para BSC y BSTUN

Introducción

Este documento se ha diseñado para ayudarle a configurar y utilizar el protocolo de enlace de datos de comunicación binaria sincrónica (BSC) y la tunelación en serie de bloques (BSTUN) en routers Cisco. También le ayuda a resolver problemas que puedan ocurrir.

Prerequisites

Requirements

Quienes lean este documento deben tener conocimiento de los siguientes temas:

• Conceptos de comunicación binaria sincrónica (BSC).

• Comprensión general de los principios básicos del procesamiento de datos.

Componentes Utilizados

La información en este documento se basa en Cisco IOS?? con el conjunto de funciones de IBM.

The information in this document was created from the devices in a specific lab environment. 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.

Convenciones

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

Información general del sistema

Las figuras 1 y 2 muestran cómo se puede reconfigurar un link BSC existente entre dos dispositivos para utilizar routers Cisco. Esto proporciona el mismo link lógico, sin ningún cambio en los dispositivos BSC existentes.

Los routers de Cisco transportan todos los bloques BSC entre los dos dispositivos mediante el uso de la encapsulación de tunelación en serie en bloque (BSTUN). Para cada bloque BSC que se recibe de la línea, se agregan una dirección y bytes de control para crear una trama BSTUN, luego BSTUN se utiliza para enviar al router de destino correcto.

Configuración de BSC/BSTUN

En un router limpio, ejecute estos comandos en el orden en que aparecen.

Comandos globales

[no] bstun peer-name ip-address

ip-address define la dirección por la cual este peer BSTUN es conocido por otros peers BSTUN que utilizan el transporte TCP.

Nota: Este comando debe configurarse en Cisco IOS Software Releases anteriores a la Versión 11.3, o debe configurarse si las direcciones TCP/IP se utilizan en las sentencias de ruta.

[no] bstun protocol-group group-number {bsc | bsc-local-ack | adplex | adt-poll | adt-poll-select | adt-vari-poll | diebold | async-generic | mdi}

Este es un comando global para asociar números de grupo con nombres de protocolo. El group-number es un entero decimal entre 1 y 255. El bsc | bsc-local-ack | adplex son palabras clave predefinidas del protocolo BSTUN. Para obtener más información, consulte Definición del Grupo de Protocolo en Configuración del Túnel Serial y del Túnel Serial de Bloque.

La selección del tipo de grupo es importante para determinar si se utiliza passthru o reconocimiento local (local-ack).

Nota: Este comando siempre se debe configurar.

Comandos de interfaz

encapsulation bstun

Este es un comando de interfaz que configura la función BSTUN en una interfaz serial determinada. Este comando debe configurarse en una interfaz antes de que se configure cualquier comando BSTUN o BSC adicional para esta interfaz.

[no] bstun group number

Este es un comando de interfaz que define el grupo BSTUN al que pertenece esta interfaz. Cada interfaz habilitada para BSTUN en un router debe ubicarse en un grupo BSTUN previamente definido. Los paquetes sólo viajan entre las interfaces habilitadas para BSTUN que están en el mismo grupo. El group-number es un entero decimal entre 1 y 255.

El número de grupo ya ha determinado si esta interfaz se ejecuta local-ack o passthru.

modo [no] bsc

A continuación se muestra una lista de algunas de las opciones principales. Para obtener una lista completa, consulte Configuración de Opciones Bisync en una Interfaz Serial en Configuración del Túnel Serial y del Túnel Serial de Bloque

No se reciben ni se envían tramas hasta que se configura el modo para una de estas configuraciones:

• contención: Esto configura el link BSC que está conectado a la interfaz serial para que sea para una estación BSC punto a punto. Sólo 3780, y sólo en modo passthru.

• contención dirección virtual —Primera disponible en Cisco IOS Software Release 11.3. Se utiliza con dial-contention para permitir que varios dispositivos remotos utilicen la misma interfaz en el router host-end.

• dial-contention timeout —Primero disponible en Cisco IOS Software Release 11.3. Se utiliza en el router del host para la contención. Permite que varios dispositivos remotos se multiplexen sobre la misma interfaz física.

• primary: Define que el router está actuando como el extremo principal del link BSC y que el dispositivo o dispositivos conectados son estaciones tributarias BSC.

• secundario: define que el router actúa como el extremo secundario del link BSC y que el dispositivo remoto conectado es una estación de control BSC (como un procesador front-end [FEP] u otro dispositivo host).

Si no se configura este comando, el protocolo de línea en la interfaz se desactivará y la interfaz no funcionará.

Configuración de ruta TCP

En esta configuración, el sistema de transporte es TCP/IP. Esto puede ejecutarse en cualquiera de los medios físicos sobre los cuales TCP/IP puede ejecutarse.

[no] bstun route all tcp ip-address

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

La dirección IP es la misma que la dirección IP especificada en el nombre de peer del router asociado.

Configuración de la ruta serial

En esta configuración, el túnel utiliza el transporte propietario de Cisco. Es mucho más rápido que TCP/IP, pero sólo pasa por una interfaz serial.

[no] bstun route all interface serial interface-number

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

Configuración directa de Frame Relay Passthru

En esta configuración, el túnel utiliza una forma propietaria de encapsulación serial sobre Frame Relay, que funciona tan rápido como las rutas seriales.

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

Ejecute este comando en la interfaz de Frame Relay:

[no] frame-relay map dlci-number bstun

Configuración Local Ack De Frame Relay Directo

Esta configuración utiliza Control de link lógico, tipo 2 (LLC2) sobre encapsulación de Frame Relay, para proporcionar reconocimiento local y control de sesión de extremo a extremo. Debe incluirse la palabra clave lsap; si no, la encapsulación pasará como passthru.

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

Ejecute este comando en la interfaz de Frame Relay:

[no] frame-relay map dlci-number llc2

Nota: Para obtener más información, consulte Especificación de cómo se reenvían las tramas en Configuración del Túnel Serial y del Túnel Serial de Bloque.

Configuración de Passthru

¿Por qué Passthru?

Passthru es el modo básico de tunelización. Cada trama que se transmite entre los dispositivos se pasa, sin cambios, a través del túnel BSTUN. Se agrega un número de secuencia y una dirección del dispositivo para asegurarse de que las latencias a través de la red no afecten el funcionamiento del protocolo. La llegada de las encuestas tardías o las señales de fin de transmisión (EOT) podrían afectar significativamente a una sesión existente.

Cuándo Utilizar Passthru

Passthru debe utilizarse en estas circunstancias:

• Los datos que se están transfiriendo no tienen una trama de reconocimiento explícita enviada para verificar la integridad de los datos.

• El protocolo no es puro 3270.

• El usuario desea una conectividad de dispositivos de extremo a extremo y las latencias de red son pequeñas.

Configuración Local-Ack

¿Por qué Local-Ack?

Local-ack elimina la sobrecarga de enviar todas las tramas de control a través del túnel. Cuando el host envía la primera encuesta a una unidad de control, se envía una trama de control especial a través del túnel para iniciar el sondeo remoto de esa dirección de dispositivo. Una vez que el dispositivo remoto indica que está activo, se envía una trama de control al router host para indicarle que responda a las encuestas. Cuando el dispositivo remoto se desactiva, se envía una indicación a través del túnel para indicar al router host que ya no responda a las encuestas.

Cuándo Utilizar Local-Ack

Local-ack se puede utilizar en estas circunstancias:

• 3270 bisync está en uso.

• La latencia de la red causa tiempos de espera de sesión bisincronizados.

• El exceso de tráfico en la WAN es un problema.

Opciones de Local-Ack

[no] bsc pause time

Este comando especifica la cantidad de tiempo entre el inicio de un ciclo de sondeo y el siguiente. El valor predeterminado es 30 (es decir, 30 décimas o 3 segundos).

Es una buena idea configurar este comando cuando sólo hay uno o dos controladores en la interfaz bisync. Retrasa de forma efectiva el sondeo y asigna más ciclos de CPU al dispositivo conectado.

[no] bsc poll-timeout time

Este comando establece el tiempo de espera para una secuencia de sondeo o de selección, en unidades de un décimo de segundo; el valor predeterminado es 30 (es decir, 30 décimas o 3 segundos).

El valor de tiempo más pequeño está determinado por la velocidad del dispositivo conectado y es de mayor interés en el extremo del host. Si el host que impulsa el router reduce su tiempo de espera al menor valor posible, habrá una mejora del rendimiento cuando algunos dispositivos hayan fallado.

[no] bsc retries retry-number

Este comando establece el número de reintentos para intentar antes de que un dispositivo se considere muerto. El rango va de 1 a 100; el valor predeterminado es 5 reintentos.

valor [no] bsc servlim

Este comando especifica el valor servlim (relación de sondeo de estación final activa frente a inactivo). El rango va de 1 a 50; el valor predeterminado es 3.

[no] bsc spec-poll

Este comando indica al host que maneje encuestas específicas como encuestas generales. Utilice este comando cuando esté trabajando con Hosts en tándem.

Para obtener más información, consulte Configuración de Opciones Bisync en una Interfaz Serial en Configuración del Túnel Serial y del Túnel Serial de Bloque.

Configuración de contención

¿Por qué contención?

La contención es la variante 3780 de bisync. No hay direcciones de unidad de control. Los dispositivos están conectados punto a punto. Por lo general, un dispositivo remoto marca en una ubicación central y asume que no existen otros dispositivos.

Cuándo utilizar la contención

Utilice la contención sólo cuando utilice los protocolos de entrada de trabajo remota (RJE), 3780 y 2780. Una vez identificada la contención, asegúrese de que ambos extremos estén configurados para utilizar la contención.

Si no está seguro, siga estos pasos:

1. Configure bsc primary.

2. Active debug bsc packet.

3. Haga que el dispositivo conectado comience a sondear.

Los mensajes con 1 bytes 2D indican contención. Los bytes anteriores al 2D no son 3780.

Prioridades

En comparación con el resto del tráfico que pasa por la red troncal WAN, el tráfico bisíncrono es muy pequeño y se ve fácilmente saturado por otro tráfico. Una pérdida de tramas en bisync requiere un largo intervalo de recuperación, que es evidente fácilmente para los dispositivos finales. Para minimizar este problema, se recomienda priorizar el tráfico bisincronizado. Puede dar prioridad al tráfico con prioridades BSTUN o con colas personalizadas.

• La colocación en cola de prioridad es una función de ruteo en la que se da prioridad a las tramas de una cola de salida de interfaz en función de diversas características, como el tamaño del paquete o el tipo de interfaz.

  La cola de salida de prioridad permite a un administrador de red definir cuatro prioridades de tráfico???alta, normal, media y baja?? en una interfaz dada. A medida que el tráfico entra en el router, se asigna a una de las cuatro colas de salida. Los paquetes en la cola de prioridad más alta se transmiten primero. Cuando esa cola se vacía, se transmite el tráfico en la cola de prioridad más alta siguiente, y así sucesivamente. Este mecanismo garantiza que, durante la congestión, los datos de máxima prioridad no se retrasen por tráfico de menor prioridad. Sin embargo, si el tráfico enviado a una interfaz dada excede el ancho de banda de esa interfaz, el tráfico de menor prioridad puede experimentar retrasos significativos.

  Por ejemplo, si hace que IP sea una prioridad más alta que IPX en links seriales WAN, el tráfico BSC en TCP/IP aprovechará el hecho de que la IP se transfiere con una prioridad más alta.

• La colocación en cola personalizada permite al cliente reservar un porcentaje de ancho de banda para protocolos específicos. Los clientes pueden definir hasta diez colas de salida para los datos normales y una cola adicional para los mensajes del sistema, como los mensajes de señal de mantenimiento de LAN (los paquetes de enrutamiento no se asignan a la cola del sistema). Los routers de Cisco prestan servicio a cada cola secuencialmente: transmiten un porcentaje configurable del tráfico en cada cola antes de pasar al siguiente. Cuando utiliza colas personalizadas, puede garantizar que a los datos críticos siempre se les asigne un determinado porcentaje del ancho de banda, mientras que también se garantiza un rendimiento predecible para otro tráfico.

  Para proporcionar esta función, los routers Cisco determinan cuántos bytes se deben transmitir desde cada cola, en función de la velocidad de la interfaz y el porcentaje configurado. Cuando se ha transmitido el conteo de bytes calculado de una cola dada, el router completa la transmisión del paquete actual y pasa a la cola siguiente. Al final, cada cola se atiende, de forma rotatoria.

Consulte Configuración del Túnel Serial y del Túnel Serial de Bloqueo, y consulte Decisión sobre Qué Política de Colocación en Cola Utilizar en Descripción General de la Administración de Congestión.

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

Ejecute el comando de configuración priority-list protocol bstun global para establecer las prioridades de colocación en cola BSTUN basadas en el encabezado BSTUN. Ejecute la forma no del comando para volver a las prioridades normales.

[no] custom-queue-list [list]

La lista es un entero (1 - 16) que representa el número de la lista de colas personalizada.

Configuración de Keepalives

intervalo [no] bstun remote-peer-keepalive

Este comando habilita keepalives de peer BSTUN. Esto envía una solicitud al par siempre que el par ha permanecido en silencio durante más tiempo que el período de intervalo. Cualquier trama restablece el reloj, no sólo señales de mantenimiento. El valor predeterminado es de 30 segundos.

[no] bstun keepalive-count number

Cuando este número de señales de mantenimiento se pierde consecutivamente, se desactiva la conexión BSTUN. El valor predeterminado es 3.

Cuándo Utilizar Keepalives

Los keepalives son útiles para protegerse contra las interrupciones del túnel cuando se ejecuta local-ack y TCP/IP. El túnel desactiva una interfaz sólo cuando se recibe una señal del mando a distancia. Si el túnel está caído, nunca se recibe ninguna señal.

En passthru, esto no es necesario, porque se requiere conectividad de extremo a extremo.

Comandos de Debug

[no] debug bstun event group

Este comando le permite depurar conexiones BSTUN y estado. Cuando se activa, provoca la visualización de mensajes que muestran el establecimiento de la conexión y el estado general.

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

Este comando le permite depurar paquetes que viajan a través de los links BSTUN.

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

Este comando le permite depurar tramas que viajan a través de la función BSC.

[no] debug bsc packet

Este comando le permite depurar tramas que viajan a través de la función BSC. Rastrea todas las interfaces configuradas con un número de grupo BSTUN.

[no] debug bsc event group

Este comando le permite depurar eventos que se producen en la función BSC. Si se omite el número de grupo, se rastrean todas las interfaces configuradas con un número de grupo BSTUN.

Comandos show

show bstun

Este comando muestra el estado actual 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

Compruebe estos problemas:

• Estado cerrado.

• Caídas.

• Cantidad baja de paquetes.

  Nota: El recuento bajo de paquetes no siempre indica problemas. Cuando se está ejecutando local-ack, el recuento sólo consta de tramas de datos, que son significativamente menores que el número real de tramas enviadas desde el host.

show bsc

Este comando muestra el estado actual 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.

Compruebe estos problemas:

• Si el estado de aplicación HDX se bloquea en un estado distinto de IDLE, entonces puede haber un problema con el dispositivo conectado o con este router. Esto generalmente indica que el dispositivo no responde. Active la depuración de eventos bsc. Si ve mucha ausencia de respuesta de mensajes remotos, primero verifique que el dispositivo esté activado y luego marque el dúplex. Si no hay mensajes y no hay recuperación final, se ha perdido un evento de finalización de transmisión y se ha encontrado un error que puede ser potencialmente catastrófico.

• El estado de secuencia de tramas indica qué máquina de estado finito (FSM) comprobar.

• Si Rx-Active se atasca en True, esto indica que algo malo ha ocurrido con el hardware. Ejecute un shut y luego un no shut para restablecer la interfaz. Si esto no funciona, recargue el router.

En Local-Ack

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 el estado se atasca en TCU_Down, esto indica que algo está obligando a esa interfaz a permanecer inactiva. Verifique la temporización y el modo BSC y asegúrese de que nada esté inactivo administrativamente. Ocasionalmente, un comando shut seguido de un comando no shut inicia nuevamente la interfaz.

En general

• Una profundidad de cola de salida mayor que 1 indica un retraso en la interfaz. Verifique que semidúplex esté configurado correctamente.

• Fuera del modo SYN-hunt significa que la interfaz está inactiva o que el receptor ha sido inhabilitado. Lo que se aplica a Rx-Active también se aplica aquí.

show interface serial number

Este comando es útil para ver los contadores asociados con esa interfaz serial.

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

Nota: Cualquier error significa problemas.

Compruebe estos problemas:

• los abortos indican una transmisión incorrecta.

• las tramas ignoradas son tramas que violan el protocolo bisync.

• los gigantes indican que la MTU es demasiado pequeña o que una secuencia bisync es mala.

• desbordamiento indica escasez de recursos de la CPU.

• CRC indica corrupción en la línea (ruidosa u otra).

Si está utilizando el cable DTE y la línea parece estar cayendo con frecuencia, o transmite fallas pero recibe trabajo, es posible que necesite ejecutar el comando ignore-dcd. Esto se puede verificar con un analizador de protocolo. Cuando el DCE transmite, se provoca el Detección de datos transportados (DCD). Cuando termina, DCD se reduce para que el router no pueda responder.

• El hardware es CD2430 indica el conjunto de chips Cirrus.

• El hardware es HD64570 indica el conjunto de chips Hitachi.

Hitachi utiliza interrupciones de caracteres y entramado creado por software. No maneja bien el DCD. Cirrus utiliza interrupciones de trama. Las tramas se generan en ucode. Tiene opciones para reproducir con DCD. Es importante que, cuando esté depurando, conozca el tipo de interfaz, porque hay algunas diferencias entre ellos.

El protocolo de línea debe estar activo. Si el protocolo de línea no está activo, verifique que el modo BSC esté configurado.

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

Cómo solucionar problemas de IBM Bisync

Cómo usar Passthru FSM

Asegúrese de que está ejecutando passthru. Debe encontrar la máquina de estado finito (FSM) correcta a continuación.

Observe los mensajes de depuración de eventos. Hay dos FSM por los que pasar. El HDX-FSM es un FSM de aplicación semidúplex. Se controla independientemente de si la línea está configurada como dúplex completo o semidúplex. Intenta asegurarse de que la cola de transmisión de un router no se atrapa con los datos antiguos. FS-FSM garantiza que las tramas tardías a través de la red no destruyan las sesiones establecidas.

Para determinar dónde buscar, vaya directamente al FSM de contención, si se ha configurado la contención. De lo contrario, observe el estado en el que va después del estado IDLE. Si ve SEC, observe la secuencia de trama secundaria FSM. Si ve PRI, observe la secuencia de trama primaria 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.

Cuando se observa la tabla, se ven las entradas en el lado izquierdo y los estados en la parte superior. Cada entrada de una columna es del formulario {siguiente estado,action} La acción se realiza primero y luego se produce la transición.

Cómo utilizar Local-Ack FSM

Asegúrese de que está ejecutando local-ack. Un comando show bsc le indica si la interfaz es poller o pollee. A partir de esto, utilice el FSM NEGRO apropiado.

Problemas Comunes

Paso de datos 3780 a config 3270 o viceversa

Precaución: No lo haga. Esto no funciona de manera fiable.

Configurar ruta a un par incorrecto

Ha configurado todo y no pasa nada. Enciende debug bsc packet en el router remoto y no ve nada. Luego, activa debug bstun packet y aún no ve nada. En esta etapa, active debug bstun event; probablemente todavía no veas nada. Vuelva al router de extremo del host y active debug bstun event. Ahora debería ver varios mensajes que indican una conexión incorrecta.

Configuración de números de grupos incorrectos

Esto se observa cuando cualquiera de los extremos del túnel se configura con un número de grupo diferente. Los datos se derraman de la interfaz incorrecta o se descartan en el nivel BSTUN.

Los números de grupo Local-ack y passthru no se mezclan. Asegúrese de que las definiciones de grupo de protocolos sean uniformes en toda la red. Los dispositivos que ejecutan la contención (3780) también deben estar en números de grupo diferentes de un 3270.

Hosts en tándem

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

Los tandems no obedecen a las convenciones estrictas 3270. Hacen todas sus encuestas con encuestas específicas, lo que causa un problema para el FSM NEGRO predeterminado. Para que los tandems funcionen correctamente, configure bsc spec-poll en la interfaz secundaria BSC.

Diferencia entre dúplex completo y medio dúplex

Es fácil confundir dúplex completo y semidúplex.

• El dúplex completo puede transmitir datos simultáneamente entre una estación de envío y una estación de recepción.

• El semidúplex puede transmitir datos en una sola dirección a la vez, entre una estación de envío y una estación de recepción.

Vea la sección del comando show bsc para obtener más detalles.

Si dispone de un analizador de protocolos o de una caja de escape, conecte el analizador en el sistema sin routers.

• Si RTS o CTS cambia la señal, entonces tiene semidúplex; de lo contrario, es dúplex completo.

• Si el DCD parece cambiar mucho y la línea se activa y desactiva o permanece desactivada, es posible que tenga que cambiar el DCD.

Nota: El router primario puede ser dúplex completo mientras que el router remoto es semidúplex y viceversa. Estas son líneas físicas independientes y las señales de control de las interfaces no se transportan a través del túnel.

Ejemplos de BSC y BSTUN

Ejemplo de respuesta de ningún dispositivo

Este es un ejemplo de dos interfaces en un router secundario: un local-ack y el otro passthru. Tampoco recibe una respuesta del mando a distancia. Tan pronto como vea que las encuestas entran en el router secundario, debe determinar lo que está ocurriendo en el extremo remoto.

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

Cuando observa el extremo remoto en el caso passthru, puede ver tramas que llegan a través del túnel, pero el dispositivo conectado sigue en silencio.

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

Luego, determine si el dispositivo conectado está muerto o si el router tiene un transmisor incorrecto: active la depuración de eventos.

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)

Desde el seguimiento, siga el HDX-FSM. Si está atascado en el estado PND_COMP, el transmisor está fallando. Probablemente no se está suministrando ningún reloj. Como puede ver en el ejemplo de salida anterior, se alcanza el estado PND_RCV, y verá la Respuesta no recibida desde el mando a distancia, que apunta a un dispositivo de recepción incorrecto o inactivo.

Ejemplo de latencias de red

Este es un ejemplo de latencias de red en un entorno virtual multidrop:

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

Hay un problema aquí, porque C4 no ha respondido a tiempo:

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

Una vez más, esto se ha perdido. Si miramos más lejos, vemos que el problema empeora un poco:

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

El EOT para C7 ha aparecido de repente de nuevo. Descarte ese EOT para recuperarse de esto; la siguiente trama es el EOT para C1.

En este ejemplo, las tramas de la red llegan tarde y fuera de secuencia. Esto provoca un gran número de encuestas sin contestar en el host. La solución, en este caso, es configurar local-ack.

Configuraciones de muestra de BSC y BSTUN

Diagrama de la red

Este diagrama es una configuración de ejemplo de un sitio que está ejecutando terminales bisync 3270 y 3780.

Configuraciones

Ese diagrama utiliza estas configuraciones:

• Central

• Remoto 1

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

Referencias

Información General - Comunicación Binary Synchronous Communication, IBM Systems Reference Library, GA27-3004-2.

IBM 3274: Capítulo 4: BSC de operaciones remotas.

IBM 3275: Capítulo 9.

Comandos BSTUN en el CD-ROM de documentación de Cisco (disponible en línea en Comandos de Túnel Serial y Túnel Serial de Bloqueo).

Información Relacionada

• Configuración y resolución de problemas de la tunelización serial (STUN)
• Soporte Técnico - Cisco Systems