IP : Serial Tunnel (STUN)

Configurando e Troubleshooting de Serial Tunneling (STUN)

19 Setembro 2015 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


Introdução

Túnel em série (STUN) é o tunelamento dos quadros de SDLC por uma WAN. No mundo tradicional do Systems Network Architecture (SNA), os controladores remotos são anexados ao processador de front end (FEP) com um conjunto de modem anexado sobre POTENCIÔMETROS (serviço de telefonia velho liso) ou linhas alugadas.

Antes de Começar

Convenções

Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.

Pré-requisitos

O STUN SDLC é geralmente usado em dois ambientes: FEP ao controlador remoto, e AS/400 ao controlador remoto.

Componentes Utilizados

Troubleshooting de STUN usando comandos do software de Cisco IOS� assim como AS/400 às edições do específico do controlador remoto.

Informações de Apoio

Enquanto as redes se movem para a integração e os escritórios remotos exigem tipos de serviço diferentes (tais como NetBIOS, IP, IPX), fez o sentido de um ponto de vista da manutenção e do custo integrar toda a estes em um dispositivo único. Por exemplo, no seguinte diagrama nós vemos uma integração de 3270 terminais ao host com tráfego de netbios de estações de Windows.

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-stun-3.gif

ATURDIR licenças você para usar o IP como um transporte para quadros do Synchronous Data Link Control (SDLC) através de WAN ou da outra rede de mídias. Isto elimina a necessidade de ter uma linha alugada adicional ou POTENCIÔMETROS. Um recurso SDLC dos Cisco routers é a tradução de mídia. Na tradução de mídia, o roteador traduz a sessão do SDLC ao Logical Link Control, o tipo-2 (LLC2). Isto é discutido em detalhe em compreender e em pesquisar defeitos o SDLC à tradução de mídia de rede LLC.

Existem dois tipos de configurações de STUN: STUN básico e STUN SDLC. O primeiro é usado para quadros de tipo derivativo de Controle de Circuito de Dados de Alto Nível (HDLC) e o último é usado para quadros SDLC apenas. STUN básico pode igualmente ser usado para o SDLC, mas as características tais como o Local-ack não podem ser usadas. É comum usar STUN básico para o SDLC para propósitos de Troubleshooting desde que os parâmetros SDLC-específicos não precisam de ser configurados no roteador.

Configuração STUN

O primeiro comando para qualquer configuração de STUN (básica ou SDLC) é stun peer-name. Sem o stun peer-name, o roteador não deixará você continuar com os passos da configuração.

Tarefa Comando
Permita ATURDEM para um endereço IP particular.
stun peer-name ip-address

Você deve selecionar um endereço IP válido do roteador. Este endereço IP de Um ou Mais Servidores Cisco ICM NT deve ser a relação a mais segura na caixa. Para os melhores resultados, configurar o roteador com uma interface de loopback. (Para obter informações sobre como configurar interfaces de loopback, consulte a documentação da Cisco).

A próxima etapa é determinar o modo STUN que você deseja usar. Um modo é o STUN Basic, no qual se procura o início e o delimitador do quadro [7e] e ocorre o transporte desse quadro para o outro lado. Neste modo de operação, STUN não se importa com o estado específico da sessão ou da informação detalhada SDLC, como o endereço de polling. O outro modo é STUN SDLC. Esse modo exige decisões mais detalhadas do roteador, especialmente quando você usa reconhecimento local ou qualquer tipo de multiponto. Os comandos utilizados para especificar um modo STUN estão descritos na tabela abaixo:

Tarefa Comando
Especifique um grupo de protocolos básico e atribua um número de grupo.
stun protocol-group group-number basic 
Especifique um grupo de protocolos SDLC e atribua um número do grupo.
stun protocol-group group-number sdlc

A próxima etapa é configurar a interface serial para STUN. O grupo selecionado na interface de coincidir com aquele definido no grupo de protocolos. Com multipontos virtuais, também é possível criar um grupo de protocolo de stun com números diferentes para cara um dos multipontos virtuais. Certifique-se sempre de que você configurou somente uma interface secundária pelo aturdir-grupo, a menos que você estiver configurando o SDLC-TG. Consulte stun protocol-group.

Tarefa Comando
Permita ATURDEM a função em uma interface serial.
encapsulation stun
Coloque a interface em um grupo STUN previamente definido.
stun group group-number

Nota: Não configurar isto em um Cisco 7000, no Cisco 7500, ou no nenhum outro roteador que tiver um CxBUS, CyBus durante o tempo da rede de produção. Esta configuração faz com que o roteador mude o MTU da relação a 2032 bytes, que conduz a uma gravação de buffer cbus e faz todas as relações do roteador saltar (restauração). Em um ambiente de token ring, pode-se significar que os Token Ring irã0 para baixo por até 16 segundos. Além, desde que o Cisco 7000 é frequentemente o centro do núcleo onde este tipo de problema afeta muitos usuários.

O próximo passo na configuração de STUN é adicionar a instrução de rota stun. Você pode definir este como o stun route all ou o stun route [address]. As opções de configuração são explicadas abaixo.

Tarefa Comando
Envie todo o tráfego TCP para este endereço IP de Um ou Mais Servidores Cisco ICM NT.
stun route all tcp ip-address

Especifique o encapsulamento TCP.
stun route address address-number tcp ip-address [priority] [tcp-queue-max]

Os comandos acima são para os peers de encapsulamento de TCP. Você pode igualmente configurar ATURDE para o encapsulamento direto, mas esta configuração é usada raramente. A mais comum de todas as configurações é a de reconhecimento local de STUN.

Estes parâmetros de comando são descritos abaixo:

  • A opção de prioridade na instrução stun route serve para criar vários pipes TCP entre dois peers STUN para que as estruturas de prioridade possam ser criadas com o uso de enfileiramento personalizado ou por prioridade.

  • A opção tcp_queue_max aumenta ou diminui as filas de TCP entre os dois peers STUN. Isso será útil se a sessão de TCP entre os peers não for muito confiável e você precisar determinar o que está errado entre eles. Essa opção não é usada com freqüência em ambientes STUN, exceto quando realiza STUN FEP para FEP em que há muito mais tráfego envolvido.

Os comandos usados para configurar ATURDEM com reconhecimento local são descritos abaixo.

Tarefa Comando
Atribua ao roteador habilitado para STUN um papel principal SDLC.
stun sdlc-role primary
Atribua ao roteador habilitado para STUN um papel secundário SDLC.
stun sdlc-role secondary

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-stun-2.gif

Esses comandos definem o "papel" da configuração STUN. No caso do host no diagrama acima, o roteador é ajustado a preliminar, assim que significa que o host é esse que inicia a sessão. Isso torna o 3174 secundário. Ao usar o STUN básico, você não precisa definir a função, porque não precisa saber quem iniciará a sessão. Mas o reconhecimento local exige os detalhes da linha próprios e definir o papel deixa o roteador conhecer o fluxo da partida de sessão, que o roteador precisa de verificar antes de se transportar ao reconhecimento local.

Nota: Nos ambientes de STUN AS/400 que fazem o reconhecimento local, é muito importante ajustar o papel (na linha descrição) ao *pri de *negative. A razão para esta é aquela em um ambiente puro (conexão de modem direta), o AS/400 pode negociar o papel. Codificando o papel que nós estamos indo estar na linha, você pode assegurar-se de que o papel do roteador seja oposto do AS/400. Você quer geralmente o AS/400 iniciar a sessão (com “varie em” da linha). Vá à configuração de linha e configure isto para o *pri. A descrição da linha de exibição AS/400 é mostrada abaixo. Isso pode apenas ser feito durante a criação/cópia da descrição da linha.

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-as400-3.gif

O comando para configurar STUN com reconhecimento local é explicado abaixo.

Tarefa Comando
Estabeleça o reconhecimento local SDLC usando o encapsulamento TCP.
stun route address address-number tcp ip-address [local-ack] [priority] [tcp-queue-max]

O parâmetro importante aqui é o stun route [address] com Local-ack. Lembre-se de que local-ack de STUN pode ser feito com encapsulamento de TCP e de Frame Relay (usando a RFC 1490).

Como no RSRB e no DLSw, o Keepalives ATURDE dentro o fluxo entre os pares TCP para assegurar-se de que a conexão de peer esteja acima. Você poderá ajustar essa manutenção de atividades se seus peers forem desativados/ativados por causa de perda de atividade. Os comandos STUN utilizados para configurar as manutenções de atividades são descritos abaixo:

Tarefa Comando
Permita a detecção de um par perdido remoto.
stun remote-peer-keepalive seconds

Número de vezes para tentar uma conexão de peer antes de declarar o par “para baixo.” stun keepalive-count quantity

Configuração básica de exemplo de STUN

A configuração básica é a mais simples do STUN. Neste modo, todos os pacotes que o roteador recebe de um lado são transportados ao seguinte. Uma configuração STUN básico é mostrada no diagrama abaixo:

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-stun-1.gif

O Roteadores no diagrama acima é configurado como segue:

4700 2522
Current configuration:
!
version 10.3
service udp-small-servers
service tcp-small-servers
!
hostname s5e
!
stun peer-name 10.17.5.1
stun protocol-group 1 basic
!
interface Loopback1
 no ip address
!
interface Serial0
 ip address 10.17.5.1 255.255.255.0
 clockrate 2000000
!
interface Serial1
 no ip address
 encapsulation stun
 nrzi-encoding
 clockrate 56000
 stun group 1
 stun route all tcp 10.17.5.2
!

Current configuration:
!
version 11.0
no service pad
service udp-small-servers
service tcp-small-servers
!
hostname rick
!
stun peer-name 10.17.5.2
stun protocol-group 1 basic
!
interface Serial0
 ip address 10.17.5.2 255.255.255.0
 no fair-queue
 no cdp enable
!
interface Serial1
 ip address 10.17.92.4 255.255.255.0
 no fair-queue
 no cdp enable
!
interface Serial2
 no ip address
 encapsulation stun
 nrzi-encoding
 clockrate 56000
 stun group 1
 stun route all tcp 10.17.5.1

Configuração de exemplo de STUN SDLC

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-stun-1.gif

4700 2522
Current configuration:
!
version 10.3
service udp-small-servers
service tcp-small-servers
!
hostname s5e
!
stun peer-name 10.17.5.1
stun protocol-group 1 sdlc
!
interface Loopback1
 no ip address
!
interface Serial0
 ip address 10.17.5.1 255.255.255.0
 clockrate 2000000
!
interface Serial1
 no ip address
 encapsulation stun
 nrzi-encoding
 clockrate 56000
 stun group 1
 stun sdlc-role secondary
 sdlc address DD
 stun route address DD tcp 10.17.5.2
!

Current configuration:
!
version 11.0
no service pad
service udp-small-servers
service tcp-small-servers
!
hostname rick
!
stun peer-name 10.17.5.2
stun protocol-group 1 sdlc
!
interface Serial0
 ip address 10.17.5.2 255.255.255.0
 no fair-queue
 no cdp enable
!
interface Serial1
 ip address 10.17.92.4 255.255.255.0
 no fair-queue
 no cdp enable
!
interface Serial2
 no ip address
 encapsulation stun
 nrzi-encoding
 clockrate 56000
 stun group 1
 stun sdlc-role primary
 sdlc address DD
 stun route address DD tcp 10.17.5.1

Configuração de exemplo do multiponto STUN (com local-ack)

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-stun-4.gif

4700 2522
hostname s5e
!
!
!
stun peer-name 10.17.5.1
stun protocol-group 1 sdlc
stun remote-peer-keepalive 5
!
interface Serial0
 ip address 10.17.5.1 255.255.255.0
 clockrate 2000000
!
interface Serial1
 no ip address
 encapsulation stun
 idle-character marks
 nrzi-encoding
 clockrate 56000
 stun group 1
 stun sdlc-role secondary
 sdlc K 1
 sdlc address 01
 sdlc address DD
 stun route address 1 tcp 10.17.5.2 local-ack
 stun route address DD tcp 10.17.5.2 local-ack
!

hostname rick
!
!

!
stun peer-name 10.17.5.2
stun protocol-group 1 sdlc
stun remote-peer-keepalive 5
!
interface Serial0
 ip address 10.17.5.2 255.255.255.0
 no fair-queue
 no cdp enable
!
interface Serial2
 no ip address
 encapsulation stun
 nrzi-encoding
 clockrate 56000
 stun group 1
 stun sdlc-role primary
 sdlc address DD
 stun route address DD tcp 10.17.5.1 local-ack
!
interface Serial3
 no ip address
 encapsulation stun
 clockrate 19200
 stun group 1
 stun sdlc-role primary
 sdlc address 01
 stun route address 1 tcp 10.17.5.1 local-ack

Nota: No roteador AS400, usamos sdlc k1 e idle-character marks. Consulte a seção Alerta de Campo para obter mais detalhes.

comandos show

O primeiro comando show usado com STUN é mostra aturde. A saída desse comando depende de você estar usando STUN Basic ou STUN SDLC com reconhecimento local. Na parcela STUN básico mostrada abaixo, você vê somente os pacotes transmitidos e recebidos.

rick#sh stun
This peer: 10.17.5.2
 
 *Serial2  (group 1 [basic])
                              state       rx_pkts   tx_pkts     drops
all     TCP 10.17.5.1        closed           5729      5718         0

ATURDIR SDLC com a parcela do Local-ack mostrada abaixo, você obtém mais informação porque o estado da sessão é sabido agora.

rick#sh stun
This peer: 10.17.5.2
 
 *Serial2  (group 1 [sdlc])
                              state       rx_pkts   tx_pkts     drops    poll
DD     TCP 10.17.5.1        open       *      182        94         0
 
 
  Serial3  (group 1 [sdlc])
                              state       rx_pkts   tx_pkts     drops    poll
1     TCP 10.17.5.1        open       *      209        89         0
 
SDLC Local Acknowledgement:
 
 *Serial2  (group 1 [sdlc])
                                 slack_state conn disc iframe_s iframe_r
DD     TCP 10.17.5.1                  Active    1    0        0        0
 
  Serial3  (group 1 [sdlc])
                                 slack_state conn disc iframe_s iframe_r
1     TCP 10.17.5.1                  Active    1    0        3        3

O comando show interface também fornece informações diferentes, e isso depende de você estar executando STUN Basic ou STUN SDLC. A relação da mostra para STUN básico é a mesma que para uma linha de série regular. A Documentação da Cisco fornece explicações específicas para cada entrada das saídas de interface da mostra, uma amostra de que é mostrado abaixo.

Serial2 is up, line protocol is up
  Hardware is CD2430 in sync mode
  MTU 1500 bytes, BW 115 Kbit, DLY 20000 usec, rely 255/255, load 1/255
  Encapsulation STUN, loopback not set
  Last input 1:10:40, output 0:18:12, output hang never
  Last clearing of "show interface" counters 0:21:49
  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
     0 packets input, 0 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     4 packets output, 312 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets, 0 restarts
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

O comando show interface de STUN SDLC com reconhecimento local fornece mais informações. A saída de exemplo para uma interface serial com local-ack é mostrada abaixo.

Serial3 is up, line protocol is up
  Hardware is CD2430 in sync mode
  MTU 1500 bytes, BW 115 Kbit, DLY 20000 usec, rely 255/255, load 1/255
  Encapsulation STUN, loopback not set
    Router link station role: PRIMARY (DCE)
    Router link station metrics:
      slow-poll 10 seconds
      T1 (reply time out) 3000 milliseconds
      N1 (max frame size) 12016 bits
      N2 (retry count) 20
      poll-pause-timer 10 milliseconds
      poll-limit-value 1
      k (windowsize) 7
      modulo 8
  sdlc addr 01 state is CONNECT
      VS 1, VR 0, Remote VR 1, Current retransmit count 0
      Hold queue: 0/200 IFRAMEs 16/12
      TESTs 0/0 XIDs 0/0, DMs 0/0 FRMRs 0/0
      RNRs 316/0 SNRMs 2/0 DISC/RDs 1/0 REJs 0/0
      Poll: clear, Poll count: 0, ready for poll, chain: 01/01
  Last input 0:00:00, output 0:00:00, output hang never
  Last clearing of "show interface" counters 1d06
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 0 bits/sec, 1 packets/sec
  5 minute output rate 0 bits/sec, 1 packets/sec
     332226 packets input, 664647 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     332227 packets output, 665220 bytes, 0 underruns
     0 output errors, 0 collisions, 3444 interface resets, 0 restarts
     0 output buffer failures, 0 output buffers swapped out
     5 carrier transitions
     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

Algumas partes desse exemplo são explicadas abaixo:

  • O MTU é o tamanho físico do buffer que a relação usa.

  • PRIMARY (DCE) significa que essa é a estação de polling no fio e que estamos fornecendo o relógio. Se nós olhando o lado que é anexado ao principal real, esta saída seria SECUNDÁRIA.

  • O N1 é o valor do tamanho útil do quadro SDLC que pode ser acomodado pela interface serial do roteador.

  • O T1 é a quantidade de tempo que nós esperamos uma resposta a uma votação antes que a linha esteja programada-para fora.

  • poll-pause-timer é o tempo delta em milissegundos entre as apurações.

  • k é o tamanho da janela ou o número de quadros que podemos ter pendentes entre finais de chamadas seletivas.

  • o estado é o status atual da sessão, que pode ser um dos estados abaixo:

    • DESCONECTAR

    • CONECTADO

    • THEMBUSY (ajustado normalmente em consequência deste roteador que recebe um RNR.)

    • USBUSY (normalmente um resultado de não receber de volta uma resposta no lado da rede.)

  • RNRs corresponde ao número de RNRs enviados/recebidos.

  • O DTR/RTS é as linhas usadas na maioria de ambientes multidrop metade-frente e verso. Quando você está debugando todo o ambiente de STUN e está olhando a localização do controlador, pague a toda atenção ao RTS. Se isto vai para baixo intermitentemente quando o DTR e o CTS forem altos, é mais provável o resultado do DTE que é metade-frente e verso.

O comando show final importante para STUN é o comando show tcp, que fornece informações com relação à sessão TCP entre os correspondentes. Uma saída de exemplo é mostrada abaixo:

Stand-alone TCP connection from host 10.17.5.1
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Local host: 10.17.5.2, Local port: 1994
Foreign host: 10.17.5.1, Foreign port: 11035
 
Enqueued packets for retransmit: 0, input: 0, saved: 0
 
Event Timers (current time is 0x1B2E50):
Timer          Starts    Wakeups            Next
Retrans           229          0             0x0
TimeWait            0          0             0x0
AckHold           229          0             0x0
SendWnd             0          0             0x0
KeepAlive           0          0             0x0
GiveUp              0          0             0x0
PmtuAger            0          0             0x0
 
iss: 2847665974  snduna: 2847667954  sndnxt: 2847667954     sndwnd:   9728
irs: 3999497423  rcvnxt: 3999499452  rcvwnd:       9672  delrcvwnd:    568
 
SRTT: 300 ms, RTTO: 607 ms, RTV: 3 ms, KRTT: 0 ms
minRTT: 0 ms, maxRTT: 300 ms, ACK hold: 300 ms
Flags: passive open, higher precedence
 
Datagrams (max data segment is 1460 bytes):
Rcvd: 459 (out of order: 0), with data: 229, total data bytes: 2028
Sent: 457 (retransmit: 0), with data: 228, total data bytes: 1979

Troubleshooting

Troubleshooting de uma configuração de STUN é como solucionar problemas com qualquer convenção peer-to-peer. Se você está experimentando problemas no transporte, este precisa de ser diagnosticado antes que você possa começar pesquisar defeitos a parcela SDLC/STUN. Geralmente, a primeira etapa é sibilar do par para espreitar para certificar-se de que o IP se estabelece corretamente. Também, sibilo com os tipos de pacote prolongados para certificar-se de que o transporte é seguro.

Troubleshooting com SDLC Básico

Esta seção cobre a pesquisa de defeitos de uma instalação STUN básico. Neste exemplo, supõe que WAN está funcionando corretamente.

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-stun-1.gif

Esta encenação tem uma instalação STUN básico para conectar os 5494 ao AS/400. A primeira coisa a verificar com alguns ATURDE a instalação é que os pares se estabelecem no roteador. Para determinar isso, use o comando show stun peer. Fornecem a informação sobre o estado do par e os pacotes que foram transmitidos/recebidos. Uma saída de exemplo é mostrada abaixo:

rick#sh stun peer
This peer: 10.17.5.2

 *Serial2  (group 1 [basic])
                              state       rx_pkts   tx_pkts     drops
all     TCP 10.17.5.1        open             5729      5718         0

Se o par está aberto, como acima, use o interfacecommand da mostra para determinar o que está acontecendo aos pacotes. O exemplo de saída para este comando é mostrado abaixo:

Serial2 is up, line protocol is up
  Hardware is CD2430 in sync mode
  MTU 1500 bytes, BW 115 Kbit, DLY 20000 usec, rely 255/255, load 1/255
  Encapsulation STUN, loopback not set
  Last input 1:10:40, output 0:18:12, output hang never
  Last clearing of "show interface" counters 0:21:49
  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
     0 packets input, 0 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     4 packets output, 312 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets, 0 restarts
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

Primeiramente, verifique se o roteador tem todos os sinais de série acima. Na parte inferior da saída acima, nós podemos ver que todos os sinais estão “acima de” para o "Serial2" nos 2522. O DTR e o RTS indicam que o controlador já tem ativado a linha própria e está esperando o AS/400 para enviar a conversação inicial.

Em seguida, verifique a relação da mostra para ver se há o lado AS/400 do roteador. Na saída mostrada abaixo, nós vemos que a interface serial que anexa ao AS/400 é abaixo de/para baixo. Isso significa que o AS/400 está provavelmente "indisponível para uso". Se a linha “está variada em” e você não pode obter a formação nem é ser executado metade-frente e verso, a seguir você necessidade de verificar a conexão RS-232/V.35.

Serial1 is down, line protocol is down
  Hardware is HD64570
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
  Encapsulation STUN, loopback not set
  Last input never, output 1:51:24, output hang never
  Last clearing of "show interface" counters 0:00:01
  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
     0 packets input, 0 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     0 packets output, 0 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets, 0 restarts
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
     DCD=up  DSR=up  DTR=down  RTS=down  CTS=up
s5e#

Neste momento, verifique o “trabalho com Status de Configuração” para ver se há esse controlador específico, que é uma tela AS/400 que olhe como:

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-as400-1.gif

Em seguida, varie na linha definição. Você observará então que o roteador entra em alinhamento up/up. Se a linha vem Up/Up mas o controlador ainda não vem acima, verifique a relação para verificar se algum pacote bateu a relação de entrada do AS/400. Se a contagem é zero, verifique o mecanismo de codificação para ver se há a linha SDLC no AS/400. Isto é ficado situado na descrição da linha de exibição, como mostrado abaixo.

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-as400-4.gif

Nota: Nesta tela, podemos ver que a codificação de linha está definida para a codificação NRZI. Esse recurso precisa ser ativado por meio da opção de configuração nrzi-encoding do roteador.

Esta instalação não exige o End to End da codificação NRZ/NRZI, como em convenções pontos a ponto convencionais SDLC, mas pode ser NRZI em um lado e NRZ no outro. Mas recorde que a codificação tem que ser a mesma entre os dispositivos que compartilham da linha SDLC.

O NRZI exige a consideração cuidadosa. No Roteadores novo como Cisco2500 e os 4500, o NRZI é ajustado através do software. Mas com as Plataformas mais velhas, incluindo o NP-2T para o Cisco 4000, você precisa de mudar as ligações em ponte nas placas elas mesmas. Nesses casos, é provavelmente mais fácil mudar o AS/400 ao NRZ/NRZI. Mas, se você precisa de mudar as ligações em ponte, refira a documentação do hardware Cisco para sua plataforma específica.

Se o problema persiste, faça um debug stun packet 1. Este comando dá-nos a informação seguinte:

STUN basic: 0:00:35 Serial1         SDI:   Data: c0bf324c056452530000
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to down
%LINK-3-UPDOWN: Interface Serial1, changed state to down
STUN basic: 0:00:38 Serial1         SDI:   Data: c0bf324c056452530000
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up
%LINK-3-UPDOWN: Interface Serial1, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to down
STUN basic: 0:00:35 Serial1         SDI:   Data: c0bf324c056452530000
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to down
%LINK-3-UPDOWN: Interface Serial1, changed state to down

É possível observar vários XIDs em fluxo do AS/400, mas não há resposta a eles (CO é o endereço de polling e bf é o XID). Nós sabemos que o pacote está vindo do AS/400 porque o pacote originou do SDI. Há dois tipos de pacotes recebidos neste comando output:

  • SDI: Entrada serial, que são os pacotes recebidos da interface do SDLC.

  • NDI: Recebimento de rede, que são pacotes desencapsulados de WAN.

Em seguida, olhar na parcela XID do quadro próprio. Neste exemplo, o AS/400 está enviando um XID junto com seus IDBLOCK e IDNUM, 05645253.

Esta é uma questão de timeout, porque o controlador não está respondendo. No AS/400, olhar do “na fila de mensagem sysopr” para ver se há alguma mensagem que indica um problema. Uma tela “SYSOPR” com uma falha é mostrada abaixo.

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-as400-2.gif

Agora nos 2522, gire sobre o debug stun packet 1 para ver se os pacotes estão obtendo enviaram ao controlador. Um exemplo de saída de comando é mostrado abaixo:

STUN basic: 0:00:34 Serial2         NDI:   Data: c0bf324c056452530000
STUN basic: 0:00:42 Serial2         NDI:   Data: c0bf324c056452530000

Isto mostra-nos que o XID que originou no lado AS/400 está obtendo completamente ao controlador, mas o controlador não está respondendo, assim que significa que é um problema do controlador. Uma relação da mostra mostra-nos se todas as ligações do controle são acima ou não:

Serial2 is up, line protocol is up
  Hardware is CD2430 in sync mode
  MTU 1500 bytes, BW 115 Kbit, DLY 20000 usec, rely 255/255, load 1/255
  Encapsulation STUN, loopback not set
  Last input 0:50:56, output 0:00:23, output hang never
  Last clearing of "show interface" counters 0:02:06
  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
     0 packets input, 0 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     1 packets output, 78 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets, 0 restarts
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

Os condutores de controle estão ativados e a interface mostra up/up. Nós podemos igualmente ver que o roteador outputting pacotes, mas nenhum pacote é entrante. Isso aponta para o endereço de apuração incorreto configurado no AS/400, de forma que a próxima etapa é verificar o endereço de apuração do controlador.

Cada tipo de controlador tem um modo exclusivo de configurar o endereço de polling, assim que você precisa de verificar este com os manuais de controlador para seu controlador.

Neste exemplo, nós encontramos que o controlador usava o endereço de polling do “DD.” Após ter mudado isto no AS/400, a saída do debug stun packet torna-se:

STUN basic: 0:24:03 Serial2         NDI:   Data: ddbf324c056452530000
STUN basic: 0:00:00 Serial2         SDI:   Data: ddbf3244073000dd0000
STUN basic: 0:00:00 Serial2         NDI:   Data: dd93
STUN basic: 0:00:00 Serial2         SDI:   Data: dd73
STUN basic: 0:00:00 Serial2         NDI:   Data: dd11
STUN basic: 0:00:00 Serial2         SDI:   Data: dd11
STUN basic: 0:00:00 Serial2         NDI:   Data: dd11
STUN basic: 0:00:00 Serial2         SDI:   Data: dd102f00000200016b80
STUN basic: 0:00:00 Serial2         NDI:   Data: dd31
STUN basic: 0:00:00 Serial2         SDI:   Data: dd11
STUN basic: 0:00:00 Serial2         NDI:   Data: dd31
STUN basic: 0:00:00 Serial2         SDI:   Data: dd11
.
.
.
.
STUN basic: 0:00:00 Serial2         NDI:   Data: dd31
STUN basic: 0:00:00 Serial2         SDI:   Data: dd71
STUN basic: 0:00:00 Serial2         NDI:   Data: dd362f00020080004b80
STUN basic: 0:00:00 Serial2         NDI:   Data: dd31
STUN basic: 0:00:00 Serial2         NDI:   Data: dd53
STUN basic: 0:00:00 Serial2         SDI:   Data: dd73

Este resultado do debug ajuda a determinar a informação seguinte:

STUN basic: 0:24:03 Serial2         NDI:   Data: ddbf324c056452530000

Essa linha contém o XID do AS/400 para o controlador. Isto vem de NDI (com origem na nuvem), dd (endereço de eleição), bf (o XID), IDBLOCK e IDNUM (05645253).

STUN basic: 0:00:00 Serial2         SDI:   Data: ddbf3244073000dd0000

Esta é a resposta do controlador. Isso é indicado pelo SDI (vindo da linha SDLC) e como acima, à exceção da resposta do XID (073000dd), porque este é um 5494.

STUN basic: 0:00:00 Serial2         NDI:   Data: dd93

Esse é o SNRM (93) do AS/400 para o controlador, que é o principal nessa configuração.

STUN basic: 0:00:00 Serial2         SDI:   Data: dd73

Aqui nós vemos o controlador responder (SDI) com um UA (73), assim que significa que a sessão é em serviço. Em seguida, nós devemos ver a disconexão vir do AS/400 enquanto a linha foi variada fora.

STUN basic: 0:00:00 Serial2         NDI:   Data: dd53
STUN basic: 0:00:00 Serial2         SDI:   Data: dd73

Essas linhas mostram o DISC (53) e a resposta UA. A linha está inativa agora. Seguir é uma tabela com os valores necessários debugar estas edições.

Campo de controle - Unnumbered (1 byte)
000z 0011  
0001 0111  
0001 0111  
0001 1111  
0011 0011  
0101 0011  
0101 0011  
0101 0011  
0111 0011  
1001 0011  
1001 0111  
101z 1111  
110z 0111  
111z 0011  
 
03-13    UI  
07-17    SIM  
07-17    RIM  
0F-1F    DM  
23-33    UP  
43-53    DISC  
43-53    RD  
43-53    RD  
63-73    UA  
83-93    SNRM  
87-97    FRMR  
AF-BF    XID  
C7-D7    CFGR  
E3-F3    TEST  
 
Unnumbered Information   
Set Initialization mode  
Request Intialization Mode   
Secondary in Disconnect Mode  
Unumber Poll  
Disconnect  
Request Disconnect  
Secondary Requests Disconnect  
Unnumbered Acknowledgement  
Set Normal Response Mode  
Frame Reject  
Exchange Identification  
Configure  
I-Field contains test pattern 
   

Campo de controle - Supervisório (2 bytes)
rrrz cc01  
rrrz 0001  
rrrz 0101  
rrrz 1001  

 
xx-xx  
x1-x1  
x5-x5  
x9-x9  
 
 
Supervisory Format  
Receiver Ready  
Receiver Not Ready  
Reject  
  
   

Campo de controle - Frames de informação (2 bytes)
rrr1 sssz 

 
xx-xx
 
 
Information format
  
   

Chave:

z = O bit final de poll pode ser 0 ou 1

rrr = número do bloco que se espera receber

sss = Número do bloco que está sendo enviado

Troubleshooting de STUN SDLC Com e Sem Conhecimento Local

Esta seção abrange o mesmo cenário com o reconhecimento local configurado.

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-stun-4.gif

Em contraste com STUN básico, ATURDIR O SDLC exige que você especifica o endereço de polling correto ou o roteador verá nem sequer os pacotes entrar. Eis porque às vezes STUN básico é usado para encontrar o endereço de polling quando você não tem a informação, ou não pode obter ao host ou ao AS/400. O diagrama acima mostra um cenário de multiponto com Local-ack.

Em um ambiente Point-to-Point tradicional, a votação vai End to End. Quando o reconhecimento local for introduzido, a chamada seletiva será terminada em cada extremidade da nuvem, de modo que cada roteador deve manter uma máquina em estado finito. Esta máquina acompanha todas as sessões e precisa saber o estado da linha para cada estação de chamada seletiva). Devido a isto, você tem que certificar-se de que as estações estão seguindo o protocolo SDLC.

Primeiramente, verifique que você está no correto ATURDE o papel. Os AS/400 têm o problema que negocia o papel com o controlador em ambientes Point-to-Point tradicionais. A descrição de linha é mostrada abaixo.

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-stun-5.gif

Isso nos mostra que a interface do roteador precisa ser configurada para um papel secundário. Sempre verifique a linha e verifique que é *PRI, porque o AS/400 opta o *NEG quando você o cria. O NRZI é ajustado ao *YES, assim que você precisa de codificar a NRZI-codificação. Também, as marcações de caractere inativo do código e ajustam o indicador a um (1) usando sdlc k 1. (refira a alerta de campo FNA-IOS-0696-02 para uma descrição detalhada de porque as marcações de caractere inativo são exigidas na relação.) Esta codificação é mostrada abaixo:

interface Serial1
no ip address
encapsulation stun
idle-character marks
nrzi-encoding 
clockrate 56000 (real clockrate on the line; see note about as400 line speed)
stun group 1
stun sdlc-role secondary (this must be secondary because the line is primary)
sdlc K 1
sdlc address 01
sdlc address DD
stun route address 1 tcp 10.17.5.2 local-ack
stun route address DD tcp 10.17.5.2 local-ack

Nota: Cronometrar que o roteador fornece é independente do parâmetro da velocidade de linha que é configurado na linha AS/400. (Este parâmetro é usado para Cálculos de desempenho; pode ser deixado no padrão de 9600.) O identificador da troca que é configurado na linha é aquele do AS/400, tal como o XID que o AS/400 enviará. O Maximum controllers é a quantidade de PUs (controladores) que podem ser criados e anexados a essa linha.

O primeiro dos dois controladores anexados a essa linha, um IBM 5494, é exibido na tela abaixo.

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-stun-6.gif

Podemos observar que o primeiro controlador será um PU 2.1, porque a categoria do controlador é "*APPC". Esta é a abreviatura para as comunicações programas-a-programa avançadas, que podem somente ser realizadas através de uma conexão T2.1. O identificador da rede remota outra vez é relacionado ao APPN/APPC e referido como o “NETID.” O “*NETATR” é um parâmetro que especifique usando o NETID definido na área de dados chamada “atributos de rede.” Você pode exibir esta área de dados por meio do comando DSPNETA e substituir os valores de acordo. “O ponto de controle remoto” ou “CP_name” são o nome do ponto de controle que você configurou no PU2.1. Neste caso, é CP5494. O papel do link de dados pode ser deixado como o *NEG. O “endereço da estação” precisa de combinar “o endereço DD sdlc” que foi configurado na interface secundária assim como em uma das interfaces principal.

interface Serial2
 no ip address
 encapsulation stun
 nrzi-encoding
 clockrate 56000
 stun group 1
 stun sdlc-role primary
 sdlc address DD
 stun route address DD tcp 10.17.5.1 local-ack

Você pode ver que maioria das informações que reside na descrição do controlador é pertinente à própria unidade física e não pode ser configurada no roteador.

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-stun-7.gif

Nesta tela, o segundo controlador (PU) é realmente uns 3174, que é um tipo-2 PU. O XID configurado nestes 3174 é 05600001. O “endereço da estação”, ou o endereço sdlc, sendo usado são 01. Você precisa “um endereço 01" configurado na interface secundária e um sdlc das interfaces principal remotas. Como você pode ver abaixo, a configuração para um PU2 é menos involvida do que um PU2.1.

interface Serial3
 no ip address
 encapsulation stun
 clockrate 19200
 stun group 1
 stun sdlc-role primary
 sdlc address 01
 stun route address 1 tcp 10.17.5.1 local-ack

O Display Networks Attributes (DSPNETA) no AS/400 é mostrado a seguir.

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-stun-8.gif

Esta tela mostra que o AS/400 está configurado atualmente para Network ID "NETA”, o que significa que o 5494 precisa ser configurado para a mesma rede. Isto, assim como o resto da configuração APPN-específica, podem ser encontrados na segunda tela de configuração nos 5494. O nome do ponto de controle local do AS/400 é "RTP400A." que o nome LU do AS/400 é "LU9404;" este precisa de combinar acima com o o que é configurado no campo de definição de LU do sócio 5494's. A descrição de modo que está sendo usada pelas 5494 necessidades de combinar o que está na descrição do dispositivo. Por exemplo, se o dispositivo diz o “*NETATR,” então precisa de combinar o padrão da “PLACA”.

Uma descrição do dispositivo APPC criada para o 5494 é mostrada abaixo.

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-stun-9.gif

Esta tela mostra que a descrição do dispositivo para os 5494 tem um nome remoto CP de "CP5494;" que esta precisa de combinar o que é configurado nos 5494. O NETID e a Localização Local optaram o “*NETATR,” que foram codificados ao LU9404 e ao NETA no exemplo anterior. Além disso, estes precisam de combinar o nome do sócio LU e campos NETID nos 5494.

A seguir, é mostrada a parte final da configuração do dispositivo relacionada à obtenção de uma conexão estabelecida.

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-stun-10.gif

Esta tela mostra que o modo sendo usado na descrição do dispositivo é "QRMTWSC". Este não é o padrão encontrado no *NETATR, portanto isso significa que foi substituído na descrição do dispositivo. Este é um dos modos padrão fornecidos pelo IBM como parte do suporte appn baixo no AS/400. Se você vê qualquer coisa diferente, contacte o IBM, porque estão sendo executado com uma descrição de modo que criem. Este exemplo estabelece uma conexão básica; se você quer indicar a informação sobre os modos disponíveis você pode usar o comando WRKMODD ou descrições do modo de trabalho.

A descrição de modo é apresentada abaixo.

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-stun-11.gif

Esta tela identifica claramente as definições de modo fornecidas pelo IBM.

Troubleshooting de Interface Multiponto SDLC Bidirecional

Ao fazer um reconhecimento local em um ambiente multiponto com AS/400s, esteja atento em relação ao modo com que a "interface multiponto full duplex SDLC" é implementada no AS/400, SYS/38 e em mini-quadros principais de SYS/36. O Alerta de Campo FNA-IOS-0696-02 (incluído abaixo) explica o tipo de problema que pode ocorrer nesta situação.

Breve descrição

A modificação do cabo do roteador conectando o Carrier Detect ao terra não impede reinicializações de linha SDLC periódicas de um AS/400 se o AS/400 tiver tido o IBM PTF# MF10030 aplicado. Este alerta se aplica apenas às conexões de multi-queda bidirecionais completas STUN para um AS/400, onde o cabo do roteador SDLC tiver sido modificado para desabilitar a revelação do sinal de comunicação.

Impacto

Os usuários podem experimentar uma reinicialização periódica da conexão STUN e de todos os dispositivos SDLC secundários, resultando em uma conexão não-confiável.

Descrição direta/fundo

Em um ambiente da multiqueda, um AS/400 comporta-se diferentemente de outros dispositivos IBM. Considerando que um FEP aceita caráteres caráteres 0x7E (bandeiras) ou 0xFF (marcas) como o espaço “inativo” entre bandeiras dos quadros, dos deleites um AS/400 e as marcas diferentemente. Somente uma marca é interpretada como caractere ocioso. Uma bandeira é interpretada para significar que a “linha é ainda ativa - mais dados são pendentes.” Um roteador Cisco pode ser configurado para enviar bandeiras ou marcas mas não ambas. Não alternará entre os dois para refletir a linha estado. O padrão é para que o roteador envie bandeiras.

Esta diferença levanta um problema em ambientes da multiqueda do duplex completo. Normalmente o AS/400 vai do dispositivo ao dispositivo, votando cada um para dados. Se um dispositivo não responde e o AS/400 pensa que a linha é ainda ativa, restaurará a linha inteira. Como o padrão é o roteador enviar os sinalizadores, o AS/400 sempre verá uma linha ativa e redefinirá a linha, em vez de simplesmente escolher o próximo dispositivo.

Para evitar esse problema, a Cisco sempre recomendou uma modificação de cabo que desabilita o sinal CD (Carrier detect). Esta modificação tem a vantagem da lógica AS/400 que interpreta a ausência da portadora como “estado de linha ocioso”. Daqui, com a alteração, um AS/400 detecta sempre a linha inativa estado apesar dos caráteres do inter-quadro que estão sendo enviados pelo roteador. Assim, se um dispositivo secundário não responde, o AS/400 verificará o CD, verá uma linha inativa e mover-se-á sobre para votar a estação seguinte.

Recentemente, a IBM lançou o reparo de problema do AS/400, o PTF# MF10030, que altera a lógica de detecção de portadora em linhas de multiqueda. Com este reparo instalado, um AS/400 ignora completamente o estado de linhas de multi-queda frente e verso do CD sobre completamente -. Em consequência, a alteração do cabo Cisco é já não eficaz em impedir a linha periódica restaurações.

Solução

Duas soluções estão disponíveis, dependendo do modelo de roteador e da versão do Cisco IOS em execução. Ambas as opções exigem alterações de configuração ao roteador conectado ao AS/400.

Opção 1

Mude o caráter ocioso SDLC do caráter da bandeira do padrão a um caráter da marca. O caractere ocioso pode ser alterado com o uso do comando de configuração de interface do roteador:

idle-character marks 

Adicionar este comando à interface serial SDLC conectada ao AS/400. Este comando fará com que o roteador transmita sempre caráteres da marca para uma pausa entre quadros. Portanto, se um dispositivo secundário perder uma apuração, o AS/400 verá uma linha ociosa e irá para frente para apurar o próximo dispositivo. Infelizmente, isso também significa que o AS/400 será visto como ociosos mesmo que mais quadros de dados estiverem a caminho a partir do dispositivo. O AS/400 reconhecerá somente o primeiro quadro, mesmo se o bit de eleição/final é 0. Então ignorará todos os quadros subsequentes e votará o próximo dispositivo que causa retransmissões do frame desnecessário. Para evitar as retransmissões, é preciso definir também o tamanho da janela do SDLC como 1, com o comando:

sdlc k 1 

Nota: O comando idle-character é suportado na versão 10.0(5.2) do Cisco IOS e, posteriormente, funciona em roteadores 2500s, 4x00 com NP-4T e 70x0/75xx.

Opção 2

Permita a detecção de dispositivos secundários inativos com o comando interface:

stun quick-response

Este comando fará com que o roteador responda com um quadro do “Disconnect Mode” (DM) para todo o dispositivo secundário inativo votado pelo AS/400. O AS/400 continuará então votar o próximo dispositivo sem restaurar a linha.

Nota: Este comando é apoiado no Cisco IOS 11.1, em 11.0(3.1) e em mais atrasado ou 10.3(7.2) e em mais atrasado.

Dica: Se você experimenta quaisquer problemas que trazem acima a linha multiponto com a resposta rápida configurada, use a opção 1. O código do stun quick-response no roteador é parte da máquina de estado finito para o Local-ack, que podem sair da etapa com alguns PU. Nós testamos o código em laboratório e verificamos sua interoperabilidade com o 5494, 5394 e Perl494E. É possível ser executado em problemas se o PU que você está tentando anexar tem os temporizadores ajustados diferentemente do que o quick_response está esperando.

Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Informações Relacionadas


Document ID: 16398