IP : Túnel serial (STUN)

Guías para BSC y BSTUN

18 Octubre 2015 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


Contenido


Introducción

Este documento se diseña para ayudarle a configurar y a utilizar el protocolo de link de datos de la Comunicación sincrónica binaria (BSC) y la tunelización en serie de bloques (BSTUN) en los routeres Cisco. También le ayuda a resolver problemas los problemas que pudieron ocurrir.

prerrequisitos

Requisitos

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

  • Conceptos de las comunicaciones sincrónicas binarias (BSC).

  • Conocimientos generales de los principios de proceso de datos básicos.

Componentes Utilizados

¿La información en este documento se basa en el Cisco IOS?? software con el conjunto de características de IBM.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.

Convenciones

Para obtener más información sobre las convenciones del documento, consulte las Convenciones de Consejos Técnicos de Cisco.

Información general del sistema

Los cuadros 1 y 2 muestran cómo un link existente BSC entre dos dispositivos se puede configurar de nuevo para utilizar a los routeres Cisco. Esto proporciona el mismo link lógico, sin ningunos cambios a los dispositivos existentes BSC.

Cuadro 1 - Configuración existente BSC

bsc_guide_1.gif

Cuadro 2 - BSC puesto con los routeres Cisco

bsc_guide_2.gif

Los routeres Cisco transportan todos los bloques BSC entre los dos dispositivos, con el uso de la encapsulación de la tunelización en serie de bloques (BSTUN). Para cada bloque BSC que se reciba de la línea, de un direccionamiento y de los bytes de control se agregan para crear una trama BSTUN, después un BSTUN se utiliza para entregar al router del destino correcto.

Configuración BSC/BSTUN

En un router limpio, publique estos comandos, en la orden en la cual son mencionados.

Comandos globales

no bstun peer-name ip-address

El IP address define el direccionamiento el cual conoce a este peerBSTUN a otros peerBSTUNs que utilicen el transporte TCP.

Nota:  Este comando se debe configurar en las versiones de Cisco IOS Software anterior que la versión 11.3, o debe ser configurado si los direccionamientos TCP/IP se utilizan en las sentencias de Route.

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

Esto es comando global de asociar los números de grupo a los Nombres del protocolo. El número de grupo es un entero decimal entre 1 y 255. El BSCA | Bsc-local-ack | el adplex es palabras claves de protocolo predefinidas BSTUN. Para más información, refiera a definir al grupo de protocolos en configurar el serial tunnel y bloquee el serial tunnel.

La selección del Tipo de grupo es importante determinar si utilizar el passthru o el Reconocimiento local (Local-ack).

Nota: Este comando debe ser configurado siempre.

Comandos de interfaz

bstun de encapsulación

Éste es un comando interface que configura la función BSTUN en una interfaz serial determinada. Este comando se debe configurar en una interfaz antes de que cualquier comandos más otra BSTUN o BSC se configuren para esta interfaz.

no bstun group group-number

Éste es un comando interface que define al grupo BSTUN a quien esta interfaz pertenece. Cada interfaz habilitado para BSTUN en un router se debe poner en un grupo BSTUN previamente definido. Los paquetes viajan solamente entre las interfaces habilitado para BSTUN que están en el mismo grupo. El número de grupo es un entero decimal entre 1 y 255.

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

no bsc mode

Aquí está una lista de alguna de la opción principal. Para una lista amplia, refiérase Configuración de opciones Bisync en una interfaz en serie en configurar el serial tunnel y bloquee el serial tunnel

No se recibe o se envía ningunas tramas hasta que el modo se configure para una de estas configuraciones:

  • contención — Esto fija el link BSC que está conectado con la interfaz serial para estar para una estación del Punto a punto BSC. Solamente 3780, y solamente en el modo passthru.

  • dirección virtual de la contención — Primer disponible en el Cisco IOS Software Release 11.3. Utilizado con la dial-contención para permitir a los dispositivos remotos múltiples para utilizar lo mismo interconecte en el router de destino final del host.

  • descanso de la dial-contención — Primer disponible en el Cisco IOS Software Release 11.3. Utilizado en el router de destino final del host para la contención. Permite a los dispositivos remotos múltiples para multiplexar sobre la misma interfaz física.

  • primario — Define que el router está actuando como el extremo primario del link BSC y que el dispositivo conectado o los dispositivos es estaciones tributarias BSC.

  • secundario — Define que el router está actuando como el fin secundario del link BSC y que el dispositivo remoto asociado es una estación de control BSC (tal como el [FEP] del procesador frontal u otro dispositivo host).

Si este comando no se configura entonces el Line Protocol en la interfaz está abajo y la interfaz no actuará.

Configuración del router TCP

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

[no] ruta del bstun todo el IP address tcp

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

El IP address es lo mismo que la dirección IP que se especifica en el par-nombre del partner router.

Configuración del Serial Route

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

no bstun route all interface serial interface-number

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

Configuración del passthru de Frame Relay directo

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

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

Publique este comando en la interfaz de Frame Relay:

no frame-relay map dlci-number bstun

Configuración directa del Local-Ack de Frame Relay

Esta configuración utiliza el Logical Link Control, el tipo-2 (LLC2) sobre la Encapsulación de Frame Relay, para dar el Reconocimiento local y el control de sesión de punta a punta. La palabra clave lsap debe ser incluida; si no, la encapsulación irá como passthru.

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

Publique este comando en la interfaz de Frame Relay:

no frame-relay map dlci-number llc2

Nota: Para más información, refiera a especificar cómo los capítulos se remiten en configurar el serial tunnel y bloquee el serial tunnel.

Configuración de Passthru

¿Por qué passthru?

El passthru es el modo básico del tunneling. Cada trama que se transmite entre los dispositivos consigue pasada, sin cambios, a través del túnel BSTUN. Agregan un número de secuencia y a una dirección del dispositivo, para asegurarse de que los tiempos de espera a través de la red no afectan a la operación de protocolo. La llegada de las últimas encuestas o señales del Fin de transmisión (EOT) podría interrumpir perceptiblemente a una sesión existente.

Cuándo utilizar el passthru

El passthru se debe utilizar en estas circunstancias:

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

  • El protocolo no es 3270 puros.

  • El usuario quiere la conectividad del dispositivo de punta a punta y las latencias de red son pequeñas.

Configuración del Local-ack

¿Por qué Local-ack?

El Local-ack quita los gastos indirectos 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, una trama del control especial se envía a través del túnel para encender el sondeo remoto de esa dirección del dispositivo. Una vez que el dispositivo remoto indica que está para arriba, una trama de control se envía al router del host para decirlo responder a las encuestas. Cuando va el dispositivo remoto abajo, una indicación se envía a través del túnel de decir el router del host responder no más a las encuestas.

Cuándo utilizar el Local-ack

El Local-ack se puede utilizar en estas circunstancias:

  • 3270 BISYNC es funcionando.

  • La latencia de red causa el tiempo de espera de la sesión BISYNC.

  • El tráfico en exceso a través de WAN es un problema.

Opciones del Local-ack

no bsc pause time

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

Es una buena idea configurar este comando cuando hay solamente uno o dos reguladores en la interfaz BISYNC. Retrasa con eficacia la interrogación y asigna más ciclos de la CPU al dispositivo conectado.

[no] tiempo del encuesta-descanso BSCA

Este comandos estableces el descanso para una encuesta o una secuencia selecta, en las unidades de uno-décimos de un segundo; el valor predeterminado es 30 (es decir, 30 décimos, o 3 segundos).

El valor más de poca monta es determinado por la velocidad del dispositivo conectado, y está de más interés en el extremo del host. Si el host que está conduciendo al router reduce su descanso al valor más pequeño posible, habrá una mejora del rendimiento cuando algunos dispositivos han fallado.

no bsc retries retry-number

Este los comandos estableces el número de recomprobaciones a intentar antes de un dispositivo se consideran los muertos. El rango es 1 a 100; el valor por defecto es 5 recomprobaciones.

no bsc servlim value

Este comando especifica el valor del servlim (activo contra la velocidad del sondeo inactiva de la estación final). El rango es 1 a 50; el valor por defecto es 3.

no bsc spec-poll

Este comando dice al host manejar los sondeos específicos como sondeos generales. Utilice este comando cuando usted está trabajando con los host Tandem.

Para una más información, refiérase Configuración de opciones Bisync en una interfaz en serie en configurar el serial tunnel y bloquee el serial tunnel.

Configuración de contención

¿Por qué contención?

La contención es la variante 3780 de la BISYNC. No hay direcciones de la unidad de control. Los dispositivos son Punto a punto conectado. Generalmente, un dispositivo remoto marca en una ubicación central y asume que existen ningunos otros dispositivos.

Cuándo utilizar la contención

Utilice la contención solamente cuando usted es el usar Entrada de trabajo remota (RJE), 3780, y 2780 protocolos. Una vez que usted ha identificado la contención, asegúrese de que los ambos extremos estén configurados para utilizar la contención.

Si usted es inseguro, después haga estos pasos:

  1. Configuración bsc primario.

  2. Gire el bsc packet del debug.

  3. Haga que el dispositivo conectado comienza a sondear.

Los mensajes con 1 los bytes 2.o indican la contención. Ninguna bytes antes del 2.a no son 3780.

Prioridades

En comparación con el resto del tráfico que esté pasando la estructura básica de WAN, el tráfico BISYNC es muy pequeño y hundido fácilmente por el otro tráfico. Una pérdida de trama en la BISYNC requiere un Intervalo de recuperación largo, que es al final dispositivos fácilmente evidentes. Para minimizar este problema, el priorización del tráfico BISYNC se recomienda. Usted puede dar prioridad al tráfico con las prioridades BSTUN o con el formar la cola a medida.

  • La cola prioritaria es una función de ruteo en la cual las tramas en una cola de salida de la interfaz se dan prioridad sobre la base de las diversas características, tales como tamaños de paquetes o tipo de interfaz.

    ¿Los Datos en espera de prioridad de resultado permiten que un administrador de la red defina cuatro prioridades del tráfico??? ¿alto, normal, medio, y bajo??? en una interfaz dada. Mientras que el tráfico entra en al router, se asigna a una de las cuatro colas de salida. Los paquetes en la cola más prioritaria se transmiten primero. Cuando esa cola vacia, el tráfico en la cola más prioritaria siguiente se transmite, y así sucesivamente. Este mecanismo se asegura de que, durante la congestión, los datos de la más alta prioridad no consigan retrasados por el tráfico de prioridad más baja. Sin embargo, si el tráfico enviado a una interfaz dada excede el ancho de banda de esa interfaz, el tráfico de prioridad más baja puede experimentar los retrasos importantes.

    Por ejemplo, si usted hace IP una prioridad más alta que el IPX en los links seriales PÁLIDOS, el tráfico BSC en el TCP/IP se aprovechará del hecho de que el IP se está transfiriendo en una prioridad más alta.

  • El el formar la cola a medida permite que un cliente reserve un porcentaje de ancho de banda para los protocolos especificados. Los clientes pueden definir hasta diez colas de salida para los datos normales y una cola adicional para los mensajes del sistema, tales como mensajes de keepalive LAN (los paquetes de ruteo no se asignan a la cola del sistema). Los routeres Cisco mantienen cada cola secuencialmente: transmiten un porcentaje de tráfico configurable en cada cola antes de que se trasladen encendido la siguiente. Cuando usted utiliza el formar la cola a medida, usted puede garantizar que los datos esenciales para el objetivo están asignados siempre cierto porcentaje del ancho de banda, mientras que el rendimiento de procesamiento predecible para el otro tráfico también se asegura.

    Para proporcionar esta característica, los routeres Cisco determinan cuántos bytes se deben transmitir de cada cola, sobre la base de la velocidad de la interfaz y del porcentaje configurado. Cuando la cuenta de bytes calculada de una cola dada se ha transmitido, el router completa la transmisión del paquete actual y se traslada encendido a la cola siguiente. Eventual, cada cola se mantiene, en una forma de cargas balanceadas.

Refiera a configurar el serial tunnel y bloquee el serial tunnel, y refiera a decidir qué política de colocación encola a utilizar en la descripción general de la administración de congestión.

[no] cola del bstun del protocolo del número de lista de la prioridad-lista [gt | el lt packetsize] el [address bstun-group bsc-addr]

Publique el comando priority-list protocol bstun global configuration de establecer las prioridades de envío a cola BSTUN basadas en el encabezado BSTUN. No publique la ninguna forma del comando de invertir a las prioridades normales.

[no] aduana-cola-lista [list]

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

Configuración de keepalives

no bstun remote-peer-keepalive interval

Este comando habilita el Keepalives del peerBSTUN. Esto envía una petición al par siempre que el par haya sido silencioso para más de largo que el período de la duración del intervalo. Cualquier trama reajusta el reloj, no apenas Keepalives. El valor predeterminado es de 30 segundos.

no bstun keepalive-count number

Cuando este número de Keepalives se falta consecutivamente, se derriba la conexión BSTUN. El valor por defecto es 3.

Cuándo utilizar el Keepalives

El Keepalives es útil de proteger contra las caídas del sistema del túnel en que usted está ejecutando el Local-ack y el TCP/IP. El túnel derriba una interfaz solamente cuando una señal se recibe del telecontrol. Si el túnel está abajo, no se recibe ningunas señales nunca.

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

comandos debug

[no] debug bstun event group

Este comando permite que usted haga el debug de las conexiones BSTUN y el estatus. Cuando está habilitado, causa la visualización de los mensajes que muestran el establecimiento de la conexión y el estado general.

no debug bstun packet group group buffer-size displayed-bytes-size

Este comando permite que usted haga el debug de los paquetes que viajan a través de los links BSTUN.

visualizar-byte-tamaños de los tamaños de almacén intermedios del grupo del grupo del no debug bsc packet

Este comando permite que usted haga el debug de las tramas que viajan a través de la característica BSC.

no debug bsc packet

Este comando permite que usted haga el debug de las tramas que viajan a través de la característica BSC. Localiza todas las interfaces que se configuren con un número de grupo BSTUN.

no debug bsc event group

Este comando permite que usted haga el debug de los eventos que ocurren en la característica BSC. Si se omite el número de grupo, después localiza todas las interfaces que se configuren con un número de grupo BSTUN.

Comandos show

show bstun

Este comando visualiza 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

Comprobación para estos problemas:

  • Estado cerrado.

  • Descensos.

  • Cuenta de paquetes baja.

    Nota: La cuenta de paquetes baja no indica siempre los problemas. Cuando usted está ejecutando el Local-ack, la cuenta consiste solamente en el marco de datos, que es perceptiblemente más pequeña que el número real de bastidores que se envíen del host.

show bsc

Este comando visualiza el estado actual de BSC.

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

Comprobación para estos problemas:

  • Si el estado de la aplicación HDX consigue pegado en un estado con excepción de la MARCHA LENTA, después puede haber un problema con el dispositivo conectado o con este router. Esto indica generalmente que no está respondiendo el dispositivo. Gire evento bsc el debug. Si usted no ve mucha ninguna respuesta de los mensajes remotos, en primer lugar controle que el dispositivo está activado, después duplex del control. Si no hay mensajes y ninguna recuperación final, después se ha perdido un evento de finalización del transmitir, y se ha encontrado un bug que puede potencialmente ser catastrófico.

  • El estado de la secuencia de la trama le dice cuál máquina de estados finitos (FSM) a marcar.

  • Si es Rx-activo se pega en verdad, esto indica que algo malo ha sucedido con el hardware. Publique haber cerrado y entonces un ningún cerrados para reajustar la interfaz. Si esto no trabaja, recargue al router.

En el 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 consigue pegado en TCU_Down, éste indica que algo está forzando esa interfaz para permanecer abajo. El cronometrar y el modo BSC del control y se aseguran de que nada está abajo administrativo. De vez en cuando, un comando shut seguido por un comando no shut comienza la interfaz otra vez.

En el general

  • Una profundidad de la cola de salida mayor de 1 indica una reserva en la interfaz. Marque que el half duplex está configurado correctamente.

  • Fuera de la SYN-caza el modo significa cualquiera que la interfaz está abajo o que se ha inhabilitado el receptor. El que se aplica a Rx-activo también se aplica aquí.

muestre el número de serie de la interfaz

Este comando es útil para considerar los contadores que se asocian a 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 problemas malos de los errores.

Comprobación para estos problemas:

  • los abortos indican una mala transmisión.

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

  • los gigantes indican cualquiera que el MTU es demasiado pequeño o una secuencia BISYNC es mala.

  • el overrun indica las escaseces de los recursos de la CPU.

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

Si usted está utilizando el cable de DTE y la línea parece ir abajo con frecuencia, o transmite el fall pero recibe el trabajo, después usted puede ser que necesite publicar el comando ignore-dcd. Esto se puede verificar con un analizador de protocolo. Cuando el DCE transmite, los datos llevados detectan (DCD) se aumentan. Cuando acaba, el DCD se baja tan el router no capaz de contestar.

  • El hardware es CD2430 indica conjunto de chips Cirrus.

  • El hardware es HD64570 indica el chipset de Hitachi.

Interrupciones del carácter de las aplicaciones de Hitachi y el enmarcar software-construido. No dirige el DCD bien. Interrupciones de la trama de las aplicaciones del cirro. Los capítulos se construyen en el ucode. Tiene opciones a jugar con el DCD. Es importante, cuando usted está haciendo el debug de, que usted conoce al tipo de interfaz, porque hay algunas diferencias entre ellas.

El Line Protocol debe estar para arriba. Si el Line Protocol no está para arriba, después control que configuran al modo BSC.

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 usted esté ejecutando el passthru. Usted necesita encontrar el correcto máquina de estados finitos (FSM) seguir.

Mire los mensajes del debug del evento. Hay dos FS a ir a través. El HDX-FSM es a aplicación FSM de semi dúplex. Se conduce sin importar si la línea está configurada por completo - duplex o half duplex. Intenta asegurarse de que la cola de transmisión de un router no consigue reservada con los viejos datos. El FS-FSM se asegura de que las últimas tramas a través de la red no destruyan a las sesiones establecidas.

Para determinar donde mirar, vaya derecho a la contención FS, si se configura la contención. Si no, mire el estado el cual entra después del estado inactivo. Si usted ve el SEC, mire la secuencia de la trama secundaria FS. Si usted ve el PRI, mire la secuencia de la trama primaria FS.

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 usted mira la tabla, usted ve las entradas en el lado izquierdo y usted ver los estados en el top. Cada entrada en una columna está de la forma {estado, acción siguientes} que la acción se hace primero, después la transición sucede.

Cómo utilizar el Local-ack FS

Asegúrese de que usted esté ejecutando el Local-ack. Un comando show bsc le dice si la interfaz es poller o pollee. De esto, utilice la FALTA apropiada FS.

Problemas Comunes

Paso de datos 3780 a config 3270 o viceversa

precaución Precaución:  No haga esto. Esto no trabaja confiablemente.

Configurar ruta a un par incorrecto

Usted ha configurado todo y nada sucede. Usted gira el bsc packet del debug en el router remoto y no ve nada. Usted entonces gira el paquete bstun del debug y todavía no ve nada. En esta etapa, gire el debug bstun event; usted probablemente todavía no ve nada. Vuelva al router del extremo del host y gire el debug bstun event. Usted debe ahora ver varios mensajes que indiquen una conexión defectuosa.

Configuración de números de grupos incorrectos

Se observa esto cuando cualquier extremo del túnel se configura con un diverso número de grupo. Los datos derraman la interfaz incorrecta de los o consiguen desechados en el nivel BSTUN.

El Local-ack y los números de grupo del passthru no se mezclan. Asegúrese de que las definiciones del grupo de protocolos sean constantes a través del toda la red. Dispositivos que ejecutan la necesidad de la contención (3780) también de estar en diversos números de grupo de 3270.

Host 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

Los tándems no obedecen a los 3270 convenios estrictos. Hacen toda su interrogación con los sondeos específicos, que causa un problema para la FALTA predeterminada FS. Para conseguir los tándems para trabajar correctamente, SPEC-encuesta de la configuración BSCA sobre la interfaz secundaria BSC.

Diferencia entre dúplex completo y medio dúplex

Es fácil confundir por completo - duplex y half duplex.

  • El Full-duplex puede transmitir los datos simultáneamente entre una estación remitente y una estación receptora.

  • El half duplex puede transmitir los datos en solamente un en un momento de la dirección, entre una estación remitente y una estación receptora.

Vea la sección en el comando show bsc para más detalles.

Si usted tiene un analizador de protocolo o una caja de conexión disponible, conecte su analizador en el sistema sin el Routers.

  • Si el RTS o el CTS cambia la señal, después usted tiene half duplex; es llena - duplex.

  • Si el DCD parece cambiar mucho, y la línea va hacia arriba y hacia abajo o permanece abajo, usted puede ser que tenga conmutar el DCD.

Nota: El router primario puede ser lleno - duplex mientras que el router remoto es semidúplex, y vice versa. Éstas son líneas físicas separadas, y las señales de control de las interfaces no se transportan a través del túnel.

BSC y ejemplos BSTUN

Ejemplo de respuesta de ningún dispositivo

Éste es un ejemplo de dos interfaces en un router secundario: el un Local-ack y el otro passthru. Ninguno está recibiendo una respuesta del telecontrol. Tan pronto como usted vea las encuestas entrar en el router secundario, usted necesita determinar qué está sucediendo 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 usted mira el extremo remoto en el caso del passthru, usted puede ver las tramas el venir a través del túnel, pero el dispositivo conectado es todavía reservado.

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

Después, determine si el dispositivo conectado está muerto o si el router tiene un mún transmisor: gire el debugging de evento.

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)

De la traza, siga el HDX-FSM. Si se pega en PND_COMP el estado, el transmisor está fallando. Es probablemente el caso que no se está suministrando ningún reloj. Como usted puede ver en la salida de ejemplo anterior, PND_RCV el estado se alcanza, y usted ve la respuesta no recibida del telecontrol, que señala a cualquiera que un malo recibe o un dispositivo inactivo.

Ejemplo de latencias de red

Éste es un ejemplo de las latencias de red en un entorno de la caída múltiple virtual:

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 contestado 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 se pierde esto. Mire más lejos, y usted ve que el problema se convierte en un poco peor:

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 repentinamente otra vez. Deseche ese EOT para recuperarse de esto; la trama siguiente es el EOT para el c1.

En este ejemplo, las tramas de la red están llegando tarde y fuera de la secuencia. Esto causa un gran número de encuestas por contestar en el host. La solución, en este caso, es configurar el Local-ack.

Configuraciones de muestra de BSC y BSTUN

Diagrama de la red

Este diagrama es una configuración de muestra de un sitio que esté funcionando con 3270 y 3780 terminales bisincrónicos.

/image/gif/paws/5316/bsc_guide_3.gif

Configuraciones

Ese diagrama utiliza estas configuraciones:

Central
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

Telecontrol 1
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

Telecontrol 2
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 sincrónica binaria, Biblioteca, GA27-3004-2.

IBM 3274: Capítulo 4: Operaciones remotas BSC.

IBM 3275: Capítulo 9.

Comandos BSTUN en el CD-ROM de la Documentación de Cisco (accesible en línea en el serial tunnel y los comandos del serial tunnel del bloque).

Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Información Relacionada


Document ID: 5316