Guia para BSC e BSTUN

Introduction

Este documento foi projetado para ajudá-lo a configurar e usar o protocolo de enlace de dados BSC (Binary Synchronous Communication) e BSTUN (Block Serial Tunneling, Encapsulamento Serial em Bloco) em roteadores Cisco. Também ajuda a solucionar problemas que possam ocorrer.

Prerequisites

Requirements

Os leitores deste documento devem estar cientes destes tópicos:

• Conceitos BSC (Binary Synchronous Communications).

• Compreensão geral dos princípios básicos de processamento de dados.

Componentes Utilizados

As informações neste documento são baseadas no Cisco IOS? com o conjunto de recursos 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.

Conventions

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

Visão geral sobre o sistema

As figuras 1 e 2 mostram como um link BSC existente entre dois dispositivos pode ser reconfigurado para usar roteadores Cisco. Isso fornece o mesmo link lógico, sem nenhuma alteração nos dispositivos BSC existentes.

Os roteadores Cisco transportam todos os blocos BSC entre os dois dispositivos, através do uso do encapsulamento BSTUN (Block Serial Tunneling, túnel serial de bloqueio). Para cada bloco BSC que é recebido da linha, um endereço e bytes de controle são adicionados para criar um quadro BSTUN, então o BSTUN é usado para entregar ao roteador de destino correto.

Configuração BSC/BSTUN

Em um roteador limpo, emita esses comandos, na ordem em que estão listados.

Comandos globais

[no] bstun peer-name ip-address

O ip-address define o endereço pelo qual esse peer BSTUN é conhecido por outros peers BSTUN que usam o transporte TCP.

Observação: esse comando deve ser configurado nas versões do Cisco IOS Software anteriores à versão 11.3 ou deve ser configurado se os endereços TCP/IP forem usados em instruções de rota.

[no] bstun protocol-group group-number {bsc | bsc-local-ack | adplex | adt-poll | adt-poll-select | adt-vari-poll | diebold | assíncrono-genérico | mdi}

Este é um comando global para associar números de grupo a nomes de protocolo. O group-number é um número inteiro decimal entre 1 e 255. O bsc | bsc-local-ack | adplex são palavras-chave predefinidas do protocolo BSTUN. Para obter mais informações, consulte Definindo o Grupo de Protocolos em Configurando o Túnel Serial e Bloquear o Túnel Serial.

A seleção do tipo de grupo é importante para determinar se deve ser usada a senha ou a confirmação local (local-ack).

Observação: esse comando deve ser sempre configurado.

Comandos de interface

encapsulation bstun

Esse é um comando de interface que configura a função BSTUN em uma interface serial específica. Esse comando deve ser configurado em uma interface antes que qualquer outro comando BSTUN ou BSC seja configurado para essa interface.

[no] bstun group group-number

Esse é um comando de interface que define o grupo BSTUN ao qual essa interface pertence. Cada interface habilitada para BSTUN em um roteador deve ser colocada em um grupo BSTUN previamente definido. Os pacotes trafegam somente entre interfaces habilitadas para BSTUN que estão no mesmo grupo. O group-number é um número inteiro decimal entre 1 e 255.

O número do grupo já determinou se essa interface executa o local-ack ou passthru.

[no] bsc mode

Aqui está uma lista de algumas das principais opções. Para obter uma lista abrangente, consulte Configuração de Opções Bisync em uma Interface Serial em Configuração de Túnel Serial e Túnel Serial de Bloco

Nenhum quadro é recebido ou enviado até que o modo esteja configurado para uma destas configurações:

• contenção—Define o link BSC conectado à interface serial como sendo para uma estação BSC ponto a ponto. Somente 3780 e somente no modo passthru.

• endereço virtual de contenção — Primeiro disponível no Cisco IOS Software Release 11.3. Usado com contenção de discagem para permitir que vários dispositivos remotos usem a mesma interface no roteador da extremidade do host.

• timeout de contenção de discagem —Disponível pela primeira vez no Cisco IOS Software Release 11.3. Usado no roteador da extremidade do host para contenção. Permite que vários dispositivos remotos se multiplexem pela mesma interface física.

• primary —Define que o roteador está atuando como a extremidade primária do link BSC e que o dispositivo ou dispositivos conectados são estações tributárias BSC.

• secondary —Define que o roteador está atuando como a extremidade secundária do link BSC e que o dispositivo remoto conectado é uma estação de controle BSC (como um processador de front-end [FEP] ou outro dispositivo host).

Se esse comando não estiver configurado, o protocolo de linha na interface será desativado e a interface não funcionará.

Configuração de rota TCP

Nesta configuração, o sistema de transporte é TCP/IP. Isso pode ser executado em qualquer meio físico sobre o qual o TCP/IP possa ser executado.

[no] bstun route all tcp ip-address

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

O endereço IP é o mesmo que o endereço IP especificado no nome do peer do roteador do parceiro.

Configuração de rota serial

Nesta configuração, o túnel usa o transporte proprietário da Cisco. É muito mais rápido que o TCP/IP, mas passa por uma interface serial apenas.

[no] bstun route all interface serial número da interface

[no] bstun route address address-number interface serial número de interface

Configuração de passagem do Frame Relay direto

Nesta configuração, o túnel usa uma forma proprietária de encapsulamento serial sobre Frame Relay, que funciona tão rápido quanto rotas seriais.

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

Emita este comando na interface do Frame Relay:

[no] frame-relay map dlci-number bstun

Configuração do Direct Frame Relay Local-Ack

Essa configuração usa o Logical Link Control (LLC2), tipo 2, sobre o encapsulamento do Frame Relay, para fornecer reconhecimento local e controle de sessão de ponta a ponta. A palavra-chave lsap deve ser incluída; caso contrário, o encapsulamento passthru.

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

Emita este comando na interface do Frame Relay:

[no] frame-relay map dlci-number llc2

Nota: Para obter mais informações, consulte Especificando como os quadros são encaminhados em Configuração de Túnel Serial e Túnel Serial de Bloco.

Configuração de passagem

Por que Passthru?

Passthru é o modo de tunelamento básico. Cada quadro que é transmitido entre os dispositivos é transmitido, inalterado, através do túnel BSTUN. Um número de sequência e um endereço de dispositivo são adicionados para garantir que as latências através da rede não afetem a operação do protocolo. A chegada de sondagens atrasadas ou sinais de fim de transmissão (EOT) pode interromper significativamente uma sessão existente.

Quando usar a passagem

O Passthru deve ser usado nestas circunstâncias:

• Os dados que estão sendo transferidos não têm um quadro de confirmação explícito enviado para verificar a integridade dos dados.

• O protocolo não é puro 3270.

• O usuário deseja conectividade de dispositivo de ponta a ponta e as latências de rede são pequenas.

Configuração Local-Ack

Por que Local-Ack?

Local-ack remove a sobrecarga do envio de todos os quadros de controle pelo túnel. Quando o host envia a primeira pesquisa para uma unidade de controle, um quadro de controle especial é enviado através do túnel para iniciar a pesquisa remota desse endereço de dispositivo. Quando o dispositivo remoto indica que ele está ativo, um quadro de controle é enviado ao roteador do host para informá-lo a responder às pesquisas. Quando o dispositivo remoto fica inativo, uma indicação é enviada pelo túnel para dizer ao roteador do host para não responder mais às pesquisas.

Quando usar Local-Ack

Local-ack pode ser usado nestas circunstâncias:

• 3270 bisync está em uso.

• A latência de rede causa tempos limite de sessão bisync.

• O excesso de tráfego na WAN é um problema.

Opções Local-Ack

[no] bsc pause time

Esse comando especifica a quantidade de tempo entre o início de um ciclo de pesquisa e o próximo. O valor padrão é 30 (ou seja, 30 décimos ou 3 segundos).

É recomendável configurar esse comando quando houver apenas um ou dois controladores na interface bisync. Ele efetivamente retarda a pesquisa e aloca mais ciclos de CPU para o dispositivo conectado.

[no] bsc poll-timeout time

Esse comando define o tempo limite para uma pesquisa ou sequência de seleção, em unidades de um décimo de segundo; o valor padrão é 30 (ou seja, 30 décimos ou 3 segundos).

O menor valor de tempo é determinado pela velocidade do dispositivo conectado e é de maior interesse na extremidade do host. Se o host que está dirigindo o roteador reduzir seu tempo limite para o menor valor possível, haverá uma melhora no desempenho quando alguns dispositivos falharem.

[no] bsc retries retry-number

Esse comando define o número de novas tentativas a serem tentadas antes que um dispositivo seja considerado inoperante. O intervalo é 1 a 100; o padrão é 5 novas tentativas.

[no] bsc servlim value

Este comando especifica o valor servlim (taxa de eleição da estação final ativa versus inativa). O intervalo é 1 a 50; o padrão é 3.

[no] bsc spec-poll

Esse comando instrui o host a tratar pesquisas específicas como pesquisas gerais. Use este comando quando estiver trabalhando com Hosts Tandem.

Para obter mais informações, consulte Configuração de Opções Bisync em uma Interface Serial em Configuração de Túnel Serial e Túnel Serial de Bloco.

Configuração de contenção

Por que Contenção?

A contenção é a variante 3780 da bisnaga. Não há endereços de unidade de controle. Os dispositivos estão conectados ponto-a-ponto. Geralmente, um dispositivo remoto disca para um local central e assume que não existem outros dispositivos.

Quando usar a contenção

Use a contenção somente quando estiver usando os protocolos Remote Job Entry (RJE), 3780 e 2780. Depois de identificar a contenção, certifique-se de que ambas as extremidades estejam configuradas para usar a contenção.

Se você não tiver certeza, faça o seguinte:

1. Configure o bsc primary.

2. Ative debug bsc packet.

3. Faça com que o dispositivo conectado comece a fazer uma pesquisa.

Mensagens com 1 bytes 2D indicam contenção. Todos os bytes anteriores ao 2D não são 3780.

Prioridades

Quando comparado a todo o tráfego que passa pelo backbone da WAN, o tráfego bisync é muito pequeno e facilmente inundado por outro tráfego. Uma perda de quadros em bisync requer um longo intervalo de recuperação, que é facilmente aparente para os dispositivos finais. Para minimizar esse problema, recomenda-se a priorização do tráfego bisync. Você pode priorizar o tráfego com prioridades de BSTUN ou com enfileiramento personalizado.

• O enfileiramento de prioridade é um recurso de roteamento no qual os quadros em uma fila de saída da interface são priorizados com base em várias características, como tamanho do pacote ou tipo de interface.

  O enfileiramento de saída de prioridade permite que um administrador de rede defina quatro prioridades de tráfego: alta, normal, média e baixa??? em uma determinada interface. À medida que o tráfego entra no roteador, ele é atribuído a uma das quatro filas de saída. Os pacotes na fila de prioridade mais alta são transmitidos primeiro. Quando essa fila fica vazia, o tráfego na próxima fila de prioridade mais alta é transmitido, e assim por diante. Esse mecanismo garante que, durante o congestionamento, os dados de prioridade mais alta não sejam atrasados pelo tráfego de prioridade mais baixa. No entanto, se o tráfego enviado a uma determinada interface exceder a largura de banda dessa interface, o tráfego de prioridade mais baixa poderá sofrer atrasos significativos.

  Por exemplo, se você fizer do IP uma prioridade mais alta que IPX em links seriais de WAN, o tráfego BSC em TCP/IP aproveitará o fato de que o IP está sendo transferido com uma prioridade mais alta.

• O enfileiramento personalizado permite que um cliente reserve uma porcentagem de largura de banda para protocolos especificados. Os clientes podem definir até dez filas de saída para dados normais e uma fila adicional para mensagens do sistema, como mensagens de keepalive de LAN (os pacotes de roteamento não são atribuídos à fila do sistema). Os roteadores Cisco atendem cada fila sequencialmente: eles transmitem uma porcentagem configurável de tráfego em cada fila antes de passarem para a próxima. Ao usar o enfileiramento personalizado, você pode garantir que os dados de missão crítica sempre recebem uma determinada porcentagem da largura de banda, enquanto o throughput previsível para outro tráfego também é garantido.

  Para fornecer esse recurso, os roteadores Cisco determinam quantos bytes devem ser transmitidos de cada fila, com base na velocidade da interface e na porcentagem configurada. Quando a contagem de bytes calculada de uma determinada fila é transmitida, o roteador conclui a transmissão do pacote atual e segue para a próxima fila. Eventualmente, cada fila é atendida, de modo round-robin.

Consulte Configurando o Túnel Serial e Bloquear o Túnel Serial e consulte Decidindo Qual Política de Enfileiramento Usar na Visão Geral do Gerenciamento de Congestionamento.

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

Emita o comando de configuração priority-list protocol bstun global para estabelecer prioridades de enfileiramento BSTUN com base no cabeçalho BSTUN. Emita a forma no do comando para reverter para as prioridades normais.

[no] custom-queue-list [list]

A lista é um número inteiro (1 - 16) que representa o número da lista de filas personalizadas.

Configuração do Keepalives

[no] bstun remote-peer-keepalive interval

Esse comando ativa keepalives de peer BSTUN. Isso envia uma solicitação ao peer sempre que o peer estiver em silêncio por mais tempo que o período de intervalo. Qualquer quadro redefine o relógio, não apenas keepalives. O padrão é 30 segundos.

[no] bstun keepalive-count number

Quando esse número de keepalives é perdido consecutivamente, a conexão BSTUN é interrompida. O padrão é 3.

Quando usar keepalives

Os keepalives são úteis para proteger contra interrupções de túnel quando você está executando local-ack e TCP/IP. O túnel desativa uma interface somente quando um sinal é recebido do controle remoto. Se o túnel estiver inoperante, nenhum sinal será recebido.

Em passthru, isso não é necessário, pois a conectividade fim-a-fim é necessária.

Comandos debug

[no] debug bstun event group

Esse comando permite depurar conexões e status de BSTUN. Quando habilitado, ele faz com que sejam exibidas mensagens que mostram o estabelecimento da conexão e o status geral.

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

Esse comando permite depurar pacotes que trafegam pelos links BSTUN.

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

Esse comando permite depurar quadros que trafegam pelo recurso BSC.

[no] debug bsc packet

Esse comando permite depurar quadros que trafegam pelo recurso BSC. Rastreia todas as interfaces configuradas com um número de grupo BSTUN.

[no] debug bsc event group

Esse comando permite depurar eventos que ocorrem no recurso BSC. Se o número do grupo for omitido, ele rastreará todas as interfaces configuradas com um número de grupo BSTUN.

comandos show

show bstun

Esse comando exibe o status atual do 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

Verifique estes problemas:

• Estado fechado.

• Quedas.

• Contagem de pacotes baixa.

  Observação: a contagem baixa de pacotes nem sempre indica problemas. Quando você está executando o local-ack, a contagem consiste apenas em quadros de dados, que é significativamente menor do que o número real de quadros enviados do host.

show bsc

Esse comando exibe o status atual do BSC.

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

Verifique estes problemas:

• Se o estado de imposição HDX ficar preso em um estado diferente de IDLE, então pode haver um problema com o dispositivo conectado ou com este roteador. Isso geralmente indica que o dispositivo não está respondendo. Ative a depuração de eventos bsc. Se você vir muito sem resposta de mensagens remotas, primeiro verifique se o dispositivo está ativado e, em seguida, verifique o modo duplex. Se não houver mensagens e nenhuma recuperação posterior, um evento de conclusão de transmissão foi perdido e foi encontrado um bug que pode ser catastrófico.

• O estado de sequência de quadros informa qual máquina de estado finito (FSM) deve ser verificada.

• Se Rx-Ative estiver preso a True, isso indica que algo ruim aconteceu com o hardware. Emita um shut e um no shut para reiniciar a interface. Se isso não funcionar, recarregue o roteador.

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

Se o estado ficar preso em TCU_Down, isso indica que algo está forçando a interface a ficar inativa. Verifique o modo de temporização e BSC e certifique-se de que nada esteja inoperante administrativamente. Ocasionalmente, um comando shut seguido de um comando no shut inicia a interface novamente.

Em geral

• Uma profundidade da fila de saída superior a 1 indica um backlog na interface. Verifique se o half duplex está configurado corretamente.

• O modo de busca SYN significa que a interface está inativa ou que o receptor foi desabilitado. O que se aplica a Rx-Ative também se aplica aqui.

show interface serial number

Esse comando é útil para ver os contadores associados a essa interface serial.

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

Observação: quaisquer erros significam problemas.

Verifique estes problemas:

• abortos indicam uma transmissão ruim.

• quadros ignorados são quadros que violam o protocolo bisync.

• giants indicam que o MTU é muito pequeno ou que uma sequência bisync é ruim.

• overrun indica escassez de recursos da CPU.

• CRC indica corrupção na linha (ruído ou outro).

Se você estiver usando um cabo DTE e a linha parecer estar ficando inativa com frequência, ou se transmitir falha mas receber trabalho, então talvez seja necessário executar o comando ignore-dcd. Isso pode ser verificado com um analisador de protocolo. Quando o DCE transmite, o DCD (Data Carried Detect, Detecção de Dados Transportados) é elevado. Quando termina, o DCD é baixado para que o roteador não possa responder.

• Hardware is CD2430 indica o chip Cirrus.

• Hardware is HD64570 indica o chip Hitachi definido.

A Hitachi usa interrupções de caracteres e enquadramento de software. Ele não lida bem com o DCD. Cirrus usa interrupções de quadros. Os quadros são incorporados no código. Ele tem opções para reproduzir com o DCD. É importante, quando você estiver depurando, que você saiba o tipo de interface, pois há algumas diferenças entre eles.

O protocolo de linha deve estar ativo. Se o protocolo de linha não estiver ativo, verifique se o 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

Como solucionar problemas do IBM Bisync

Como utilizar FSMs de passagem

Verifique se você está executando passthru. Você precisa encontrar a máquina de estado finito (FSM) correta a ser seguida.

Examine as mensagens de depuração do evento. Há dois FSMs para passar. O HDX-FSM é um FSM de aplicação half-duplex. Ele é conduzido independentemente de a linha estar configurada em full duplex ou half duplex. Ele tenta garantir que a fila de transmissão de um roteador não receba o backlog de dados antigos. O FS-FSM garante que os quadros atrasados através da rede não destruam as sessões estabelecidas.

Para determinar onde procurar, vá diretamente para a contenção de FSM, se a contenção estiver configurada. Caso contrário, observe o estado em que ele passa após o estado IDLE. Se você vir SEC, observe a sequência de quadros secundária FSM. Se você vir PRI, observe a sequência de quadros principal 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.

Quando você olha para a tabela, você vê entradas no lado esquerdo e vê estados no topo. Cada entrada em uma coluna tem o formato {próximo estado,ação}. A ação é feita primeiro e a transição acontece.

Como usar o FSM de reconhecimento local

Verifique se você está executando o local-ack. Um comando show bsc informa se a interface é pesquisa ou pesquisa. A partir disso, use o FSM de FALTA apropriado.

Problemas comuns

Passando dados 3780 para a configuração 3270 ou vice-versa

Cuidado: não faça isso. Isso não funciona de forma confiável.

Configuração de rota para um peer incorreto

Você configurou tudo e nada acontece. Você ativa debug bsc packet no roteador remoto e não vê nada. Em seguida, você ativa o pacote debug bstun e ainda não vê nada. Neste estágio, ative o evento debug bstun; você provavelmente ainda não vê nada. Volte para o roteador de extremidade do host e ative o evento debug bstun. Agora você deve ver várias mensagens que indicam uma conexão incorreta.

Configuração inadequada de números de grupos

Isso é observado quando qualquer extremidade do túnel é configurada com um número de grupo diferente. Os dados vazam da interface errada ou são descartados no nível BSTUN.

Os números dos grupos de entrada local e de passagem não se misturam. Assegure-se de que as definições do grupo de protocolos sejam consistentes em toda a rede. Os dispositivos que executam a contenção (3780) também precisam estar em números de grupo diferentes de um 3270.

Hosts em 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

Os tandemas não obedecem a convenções rigorosas de 3270. Eles fazem toda a pesquisa com pesquisas específicas, o que causa um problema para o FSM de LACK padrão. Para que os tandems funcionem corretamente, configure bsc spec-poll na interface secundária BSC.

Diferença entre bidirecional e semi-duplex

É fácil confundir full duplex com half duplex.

• O full duplex pode transmitir dados simultaneamente entre uma estação emissora e uma estação receptora.

• O half duplex pode transmitir dados em apenas uma direção de cada vez, entre uma estação emissora e uma estação receptora.

Consulte a seção do comando show bsc para obter mais detalhes.

Se você tiver um analisador de protocolo ou uma caixa de breakout disponível, conecte seu analisador ao sistema sem roteadores.

• Se o RTS ou CTS alterar o sinal, então você tem half duplex; caso contrário, é full duplex.

• Se o DCD parecer mudar muito, e a linha subir e descer ou permanecer inativa, você pode ter o DCD de switching.

Observação: o roteador principal pode ser full duplex enquanto o roteador remoto é half duplex e vice-versa. Essas são linhas físicas separadas e os sinais de controle das interfaces não são transportados através do túnel.

Exemplos de BSC e BSTUN

Não há exemplo de resposta de dispositivo

Este é um exemplo de duas interfaces em um roteador secundário: um local-ack e o outro passthru. Nenhum dos dois está recebendo uma resposta do controle remoto. Assim que as pesquisas chegam ao roteador secundário, você precisa determinar o que está acontecendo na extremidade remota.

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

Quando você olha para a extremidade remota no caso de passagem, você pode ver quadros passando pelo túnel, mas o dispositivo conectado ainda está silencioso.

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

Em seguida, determine se o dispositivo conectado está inativo ou se o roteador tem um transmissor inválido: ative a depuração 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)

A partir do rastreio, siga o HDX-FSM. Se estiver preso no estado PND_COMP, o transmissor está falhando. É provável que não haja nenhum relógio sendo fornecido. Como você pode ver na saída do exemplo anterior, o estado PND_RCV é alcançado e você vê a Resposta não recebida do remoto, que indica um recebimento incorreto ou um dispositivo inativo.

Exemplo de latências de rede

Este é um exemplo de latências de rede em um ambiente multidrop 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

Há um problema aqui, porque o C4 não respondeu a tempo:

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

Novamente, isso é perdido. Olhe mais adiante e você vê que o problema se torna um pouco pior:

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

A EOT para C7 apareceu de repente novamente. Descartar essa EOT para se recuperar disso; o próximo quadro é o EOT para C1.

Neste exemplo, os quadros da rede estão chegando atrasados e fora de sequência. Isso causa um grande número de pesquisas não respondidas no host. A solução, nesse caso, é configurar o local-ack.

Exemplo de configurações BSC e BSTUN

Diagrama de Rede

Este diagrama é uma configuração de exemplo de um site que executa os terminais 3270 e 3780 bisync.

Configurações

Esse diagrama usa estas configurações:

• 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

Referências

Informações gerais - Binary Synchronous Communication, IBM Systems Reference Library, GA27-3004-2.

IBM 3274: Capítulo 4: Operações remotas BSC.

IBM 3275: Capítulo 9.

Comandos BSTUN no CD-ROM de documentação da Cisco (disponível online em Túnel serial e comandos Block Serial Tunnel).

Informações Relacionadas

• Configurando e Troubleshooting de Serial Tunneling (STUN)
• Suporte Técnico - Cisco Systems