Exemplo de Configuração de Protocolos Assíncronos de Encapsulamento no BSTUN

Introduction

Os protocolos assíncronos dedicados e nativos não são suportados diretamente com nenhuma implementação da Cisco. No entanto, o tunelamento genérico assíncrono do BSTUN (Block Serial Tunnel) pode fornecer capacidade limitada para fazer o túnel desses dados.

Prerequisites

Requirements

Não existem requisitos específicos para este documento.

Componentes Utilizados

As informações neste documento são baseadas nas versões de software e hardware:

• Use o Feature Navigator II (somente clientes registrados) e use a opção Pesquisar por recurso.

• Use o Software Advisor (somente clientes registrados) para pesquisar a versão mínima de software compatível necessária para o seu hardware.

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

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Informações de Apoio

Os protocolos assíncronos como o TC500 de Diebold para se comunicar com ATMs de dinheiro ou tunelamento do HyperTerminal de um PC para outro PC não têm suporte ou implementação direta no Cisco IOS ®. Como o nome diz, essa é uma implementação genérica que tem alguma capacidade de transportar esse tipo de dados. Isso é conhecido como BSTUN async-generic e exige o conjunto de recursos IBM ou Enterprise IOS.

O BSTUN async-generic foi originalmente projetado para transportar pacotes pequenos e unidirecionais de dispositivos de segurança para um dispositivo de relatório. O BSTUN async-generic, no entanto, pode transportar tráfego interativo. Essencialmente, essa implementação se conecta a dispositivos nativos assíncronos e recebe os dados na interface serial e, em seguida, em um buffer de memória. Periodicamente, os dados armazenados em buffer são encapsulados em um pacote TCP e enviados ao peer BSTUN onde são desencapsulados e enviados ao dispositivo assíncrono conectado ao local remoto.

BSTUN async-generic é uma operação simplista. O roteador não tem capacidade de ser configurado para ter conhecimento do início do quadro (SOF), do fim do quadro (EOF) ou do esquema de endereçamento do protocolo assíncrono. Se a porção de endereço do quadro estiver em cada quadro, tiver um byte de comprimento e for o mesmo lugar no quadro, o comando asp address-offset poderá ser emitido para especificar ao roteador onde encontrar o endereço no quadro, como mostrado mais adiante neste documento. Em muitas situações, no entanto, não haverá uma parte de endereço contida no protocolo. Não ter conhecimento da construção do protocolo assíncrono significa que o roteador é incapaz de distinguir pacotes individuais de outros se eles não estiverem separados por um período de tempo. Aproximadamente 40 ms é necessário entre quadros a 9600 bits/s para fornecer ao roteador tempo adequado para discernir corretamente um pacote do outro. O roteador simplesmente vê um fluxo de dados na interface serial e, em seguida, envolve esses dados no TCP. Não há possibilidade de o roteador ser capaz de tomar decisões de roteamento com base em qualquer aspecto individual do quadro de entrada. Assim, o BSTUN async-generic deve ser fisicamente projetado para que apenas um dispositivo se conecte à interface serial do roteador. Não há nenhum recurso de reconhecimento local. O BSTUN oferece suporte somente ao protocolo BISYNC para IBM3270.

Configurar

Nesta seção, você encontrará informações para configurar os recursos descritos neste documento.

Diagrama de Rede

Este documento utiliza a configuração de rede mostrada neste diagrama.

Ambos os PCs usam o HyperTerminal da Microsoft ou em lugar de um dos PCs podem ser uma conexão na porta de console de um roteador Cisco. Esses exemplos de configurações representam as configurações implementadas de roteadores não configurados anteriormente em um cenário de laboratório e mostram as partes relevantes da configuração necessária. Eles são configurados presumindo uma conexão de 9600 bits/s, 8N1.

Configurações

Este documento usa as configurações mostradas nesta seção.

• Roteador principal (Cisco 1700 Router)

• Roteador remoto (Cisco 3640 Router)

• Roteador principal (Cisco 3600 Router)

• Remoto nº 1 (Roteador Cisco 1700)

• Remoto nº 2 (Roteador Cisco 1700)

main#show running-config 
Building configuration...
.
.
.
ip subnet-zero
bstun peer-name 10.1.1.1
bstun protocol-group 1 async-generic
interface loopback0
   ip address 10.1.1.1 255.0.0.0
interface serial0
   physical-layer async
   encapsulation bstun
   asp role secondary
   bstun group 1
   bstun route all tcp 30.1.1.1
interface serial1
   ip address 20.1.1.1 255.0.0.0
ip route 0.0.0.0 0.0.0.0 20.1.1.2
line 1
   speed 9600
   databits 8
   parity none
   stopbits 1
.
.
.
!
end

REMOTE#show running-config 
Building configuration...
bstun peer-name 30.1.1.1.
bstun protocol-group 1 async-generic
interface loopback 0
   ip address 30.1.1.1
interface ethernet1/0
   shutdown
interface serial 2/0
   physical-layer async
   encapsulation bstun
   asp role primary
   bstun group 1
   bstun route all tcp 10.1.1.1
   
interface serial 2/1
   ip address 20.1.1.2 255.0.0.0
ip route 0.0.0.0 0.0.0.0 20.1.1.1
line 65
   speed 9600
   parity none
   databits 8
   stopbits 1
.
.
!
end

Observação: quando você emite o comando physical-layer async na interface serial, uma linha TTY é atribuída à interface serial. Essa definição de linha TTY é onde os bancos de dados, os bits de paridade, a paridade e a velocidade são configurados. Essa é a fórmula para determinar qual linha corresponde a qual interface serial.

line#=(slot# x 32) + interface# + 1

O comando show line na saída da configuração do roteador Remoto indica na coluna da extrema direita o número de linha correspondente. Serial2/0 é representado pela linha 65 e as definições físicas para esse link são configuradas na linha 65

REMOTE#sh line 
   Tty Typ     Tx/Rx        A Modem  Roty AccO AccI   Uses   Noise  Overruns   Int 
*    0 CTY                      -        -          -        -        -          0           0         0/0           - 
    65 TTY   9600/9600  -        -          -        -        -      0           0         0/0     Se2/0 
   129 AUX 9600/9600  -        -          -        -        -        0           0         0/0       - 
   130 VTY                     -        -          -        -        -          0           0         0/0       - 
   131 VTY                     -        -          -        -        -          0           0         0/0       - 
   132 VTY                     -        -          -        -        -          0           0         0/0       - 
   133 VTY                     -        -          -        -        -          0           0         0/0       - 
   134 VTY                     -        -          -        -        -          0           0         0/0       - 

Line(s) not in async mode -or- with no hardware support: 
1-64, 66-128 

Neste cenário, um Tandem se comunica com dispositivos ATM remotos. Nesta configuração de exemplo, o protocolo assíncrono executa um protocolo 4800 7E2 e o roteador principal conectado ao TANDEM é um roteador da série 3600 para roteadores da série 1700 remotos. Veja este diagrama de rede.

main#show running-config 
Building configuration...
bstun peer-name 10.1.1.1.
bstun protocol-group 1 async-generic
bstun protocol-group 2 async-generic
interface loopback 0
   ip address 10.1.1.1
interface serial1/0
   encapsulation frame-relay
interface serial 1/0.1 point-to-point
   ip address 20.1.1.1 255.255.255.0
   frame-relay interface-dlci 100
interface serial 1/0.2 point-to-point
   ip address 20.2.1.1 255.255.255.0
   frame-relay interface-dlci 200
interface serial 2/0
   physical-layer async
   encapsulation bstun
   asp role secondary
   bstun group 1
   bstun route all tcp 30.1.1.1
   
interface serial 2/1
 physical-layer async
   encapsulation bstun
   asp role secondary
   bstun group 2
   bstun route all tcp 30.2.1.1
   
ip route 30.2.1.0 255.255.0.0 20.2.1.2
ip route 0.0.0.0 0.0.0.0 20.1.1.2
line 65
   speed 4800
   parity even
   databits 7
   stopbits 1
.
line 66
   speed 4800
   parity even
   databits 7
   stopbits 1
.
!
end

REMOTE1#show running-config 
Building configuration...
bstun peer-name 30.1.1.1
bstun protocol-group 1 async-generic
interface loopback0
   ip address 30.1.1.1 255.255.0.0
interface serial0
   physical-layer async
   encapsulation bstun
   asp role primary
   bstun group 1
   bstun route all tcp 10.1.1.1
interface serial1
   encapsulation frame-relay
interface serial1.1 point-to-point
   ip address 20.1.1.2 255.255.255.0
   frame-relay interface-dlci 100
ip route 0.0.0.0 0.0.0.0 20.1.1.1
line 1
   speed 4800
   databits 7
   parity even
   stopbits 2
.
.
.
!
end

REMOTE2#show running-config
Building configuration...
bstun peer-name 30.2.1.1
bstun protocol-group 2 async-generic
interface loopback0
   ip address 30.2.1.1 255.255.0.0
interface serial0
   physical-layer async
   encapsulation bstun
   asp role primary
   bstun group 2
   bstun route all tcp 10.1.1.1
interface serial1
   encapsulation frame-relay
interface serial1.1 point-to-point
   ip address 20.2.1.2 255.255.255.0
   frame-relay interface-dlci 100
ip route 0.0.0.0 0.0.0.0 20.2.1.1
line 1
   speed 4800
   databits 7
   parity even
   stopbits 2
.
.
.
!
end

Verificar

No momento, não há procedimento de verificação disponível para esta configuração.

Troubleshoot

O BSTUN recebe um pacote na interface serial, o encapsula e envia esse pacote TCP ao roteador remoto quando o comando bstun route all tcp é emitido. O pacote TCP é recebido no roteador remoto e é desencapsulado. Os dados são enviados na interface serial. Se essa conexão não funcionar, os dados de entrada devem primeiro ser verificados com o pacote debug asp. Você vê os dados recebidos pelo roteador na interface serial. Como o roteador não tem nenhuma construção de protocolo e varia de acordo com o protocolo assíncrono, o exemplo de depuração não é fornecido. O fluxo de dados visto pelo roteador deve corresponder ao que é enviado pelo dispositivo. Se não corresponder, mais do que provável, a velocidade, os bancos de dados, a paridade ou os bits de parada não são configurados para corresponder ao dispositivo. Isso também pode ocorrer se nenhum dado for recebido.

Se os dados forem recebidos na interface serial, execute o comando show bstun para mostrar se a conexão está aberta ou fechada. O estado aberto com apenas pacotes transmitidos indica que o TCP é enviado ao peer BSTUN remoto. Nesse ponto, um teste de ping do endereço IP do nome do peer BSTUN local para o endereço IP do nome do peer BSTUN remoto verifica se o IP está configurado e funcionando corretamente. Se o teste de ping for bem-sucedido, então no controle remoto, emita o comando debug asp packet para determinar se o pacote é recebido e enviado à interface serial para o dispositivo assíncrono.

Complete estas etapas para resolver problemas.

1. Verifique se os dados são recebidos no roteador do host com o comando debug asp packet.

2. Verifique a conectividade IP com ping test sourcing pings do endereço IP bstun peer-name para o endereço IP remoto do peer-name BSTUN remoto.

3. No controle remoto, verifique se os pacotes são enviados ao dispositivo remoto com o comando debug asp packet.

4. Se o protocolo assíncrono tiver um endereço contido nos pacotes enviados ao roteador, pode ser útil emitir o comando asp offset-address na interface com o número de byte apropriado correspondente ao local em que o endereço está contido no pacote. O valor padrão para isso é 0. Por exemplo, se o pacote for 01C1ABCDEF, onde C1 é o endereço, a interface serial poderá ser configurada com o comando asp offset-address 01. Em alguns casos, isso permite que o roteador identifique um pacote e aumenta a probabilidade de que ele trate os dados como um pacote enquadrado e não apenas como um fluxo de dados.

Informações Relacionadas

• Suporte técnico STUN (Serial Tunnel) e BSTUN (Block Serial Tunnel)
• Suporte Técnico - Cisco Systems

Histórico de revisões