Configurando e Troubleshooting de Serial Tunneling (STUN)
Contents
Introduction
Túnel em série (STUN) é o tunelamento dos quadros de SDLC por uma WAN. No mundo da arquitetura de rede de sistemas tradicionais (SNA), os controladores remotos são conectados ao processador de front-end (FEP) por meio de um conjunto de modems conectados por POTS (Plain Old Telephone Service) ou linhas alugadas.
Antes de Começar
Conventions
Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.
Prerequisites
O STUN SDLC é geralmente usado em dois ambientes: FEP para controlador remoto e AS/400 para controlador remoto.
Componentes Utilizados
Solução de problemas STUN usando os comandos do software Cisco IOS® e AS/400 para problemas específicos do controlador remoto.
Informações de Apoio
À medida que as redes avançam para a integração e os escritórios remotos exigem diferentes tipos de serviços (como NetBIOS, IP, IPX), fazia sentido, do ponto de vista da manutenção e do custo, integrar tudo isso em um único dispositivo. Por exemplo, no diagrama a seguir, vemos a integração de terminais 3270 ao host com tráfego NetBIOS de estações Windows.
O STUN permite usar o IP como um transporte para quadros SDLC (Synchronous Data Link Control) em uma WAN ou em outra rede de mídia. Isso elimina a necessidade de ter uma linha alugada adicional ou POTS. Um recurso SDLC dos Cisco routers é a tradução de mídia. Na tradução de mídia, o roteador converte a sessão do SDLC para o Logical Link Control, type 2 (LLC2). Isso é discutido detalhadamente em Understanding and Troubleshooting SDLC to LLC Network Media Translation.
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. O STUN Basic também pode ser usado para SDLC, mas recursos como local-ack não podem ser usados. É comum usar o STUN Basic para SDLC para fins de solução de problemas, pois os parâmetros específicos do SDLC não precisam 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 |
|---|---|
| Ative o STUN para um endereço IP específico. |
stun peer-name ip-address
|
Você deve selecionar um endereço IP válido do roteador. Esse endereço IP deve ser a interface mais confiável na caixa. Para obter os melhores resultados, configure o roteador com uma interface de loopback. (Para saber mais sobre a configuração de interfaces de loopback.
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. Nesse modo de operação, o STUN não se preocupa com o estado específico da sessão ou com as informações detalhadas do SDLC, como o endereço de pesquisa. 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 ter configurado apenas uma interface secundária por stun-group, a menos que esteja configurando sdlc-tg. Consulte stun protocol-group.
| Tarefa | Comando |
|---|---|
| Ative a função STUN em uma interface serial. | encapsulation stun |
| Coloque a interface em um grupo STUN previamente definido. |
stun group group-number
|
Observação: não configure isso em um Cisco 7000, Cisco 7500 ou em qualquer outro roteador que tenha um CxBUS, CyBUS durante o tempo da rede de produção. Essa configuração faz com que o roteador altere o MTU da interface para 2032 bytes, o que resulta em uma gravação de buffer CBUS e faz todas as interfaces do roteador pularem (reinicializarem). Em um ambiente Token Ring, isso pode significar que os Token Rings ficarão inativos por até 16 segundos. Além disso, como o Cisco 7000 é frequentemente o centro do núcleo onde esse 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 isso como stun route all ou stun route [address]. As opções de configuração são explicadas abaixo.
| Tarefa | Comando |
|---|---|
| Encaminhe todo o tráfego TCP para esse endereço IP. |
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ê também pode configurar o STUN para o encapsulamento direto, mas essa configuração raramente é usada. 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 o STUN com confirmação local são descritos abaixo.
| Tarefa | Comando |
|---|---|
| Atribua ao roteador habilitado para STUN uma função principal de SDLC. | stun sdlc-role primary |
| Atribua ao roteador ativado para STUN uma função secundária SDLC. | stun sdlc-role secondary |
Esses comandos definem o "papel" da configuração STUN. No caso do host no diagrama acima, o roteador é definido como primário, o que significa que o host é o 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 a confirmação local exige detalhes da própria linha e a definição da função permite que o roteador saiba o fluxo da inicialização da sessão, que o roteador precisa verificar antes de passar para a confirmação local.
Observação: em ambientes AS/400 STUN com reconhecimento local, é muito importante definir a função (na descrição da linha) como *pri de *neg. A razão para isso é que em um ambiente puro (conexão de modem direto), o AS/400 pode negociar a função. Ao codificar a função que estaremos na linha, você pode garantir que a função do roteador seja oposta ao AS/400. Geralmente, você deseja que o AS/400 inicie a sessão (com "variável" na linha ). Vá para a configuração de linha e configure-a para *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.
O comando para configurar STUN com reconhecimento local é explicado abaixo.
| Tarefa | Comando |
|---|---|
| Estabeleça a confirmação local de SDLC usando o encapsulamento TCP. | stun route address address-number tcp ip-address [local-ack] [priority] [tcp-queue-max] |
O parâmetro importante aqui é 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, mantém o fluxo STUN entre os peers TCP para garantir que a conexão do peer esteja ativa. 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 |
|---|---|
| Habilite a detecção de um peer perdido remoto. |
stun remote-peer-keepalive seconds
|
| Número de vezes que tentar uma conexão de peer antes de declarar o peer "inativo". | stun keepalive-count quantity |
Configuração básica de exemplo de STUN
A configuração básica é a mais simples do STUN. Nesse modo, todos os pacotes que o roteador recebe de um lado são transportados para o próximo. Uma configuração básica STUN é mostrada no diagrama abaixo:
Os roteadores no diagrama acima são configurados da seguinte forma:
| 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
| 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)
| 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 |
Observação: no roteador AS400, usamos sdlc k1 e marcas de caractere ocioso. Consulte a seção Alerta de Campo para obter mais detalhes.
comandos show
O primeiro comando show usado com STUN é show stun. A saída desse comando depende de você estar usando STUN Basic ou STUN SDLC com reconhecimento local. Na parte básica do STUN mostrada abaixo, você vê apenas 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
No SDLC STUN com a parte local-ack mostrada abaixo, você obtém mais informações porque agora o estado da sessão é conhecido.
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. O comando show interface para STUN Basic é o mesmo que para uma linha serial regular.
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:
-
MTU é o tamanho físico do buffer que a interface usa.
-
PRIMARY (DCE) significa que essa é a estação de polling no fio e que estamos fornecendo o relógio. Se olhássemos para o lado que está ligado ao primário real, esta saída teria sido SECUNDÁRIA.
-
N1 é o valor do tamanho utilizável do quadro SDLC que pode ser acomodado pela interface serial do roteador.
-
T1 é a quantidade de tempo que esperamos uma resposta para uma votação antes que a linha tenha expirado.
-
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.
-
estado é o status atual da sessão, que pode ser um dos estados abaixo:
-
DESCONECTAR
-
CONECTADO
-
THEMBUSY (normalmente definido como resultado de este roteador receber um RNR.)
-
USBUSY (normalmente resultado de não obter uma resposta de volta no lado da rede).
-
-
RNRs corresponde ao número de RNRs enviados/recebidos.
-
DTR/RTS são as linhas usadas na maioria dos ambientes multidrop half-duplex. Ao depurar qualquer ambiente STUN e observar o local do controlador, preste muita atenção ao RTS. Se isso cair intermitentemente enquanto o DTR e o CTS estiverem altos, é mais provável que o resultado do DTE seja half-duplex.
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ê estiver tendo problemas no transporte, isso precisa ser diagnosticado antes de começar a solucionar problemas na parte SDLC/STUN. Geralmente, a primeira etapa é fazer ping de peer para peer para garantir que o IP esteja configurado corretamente. Além disso, faça ping com tipos de pacotes estendidos para garantir que o transporte seja confiável.
Troubleshooting com SDLC Básico
Esta seção aborda a solução de problemas de uma configuração básica STUN. Neste exemplo, suponha que a WAN esteja funcionando corretamente.
Esse cenário tem uma configuração básica STUN para conectar o 5494 ao AS/400. A primeira coisa a verificar com qualquer configuração STUN é que os peers estão configurados no roteador. Para determinar isso, use o comando show stun peer. Ele fornece informações sobre o estado do peer e dos 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 peer estiver aberto, como acima, use o comando show interfacecpara determinar o que está acontecendo com os pacotes. A saída de exemplo para este comando é mostrada 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
Primeiro, verifique se o roteador tem todos os sinais seriais ativados. Na parte inferior da saída acima, podemos ver que todos os sinais estão "acima" para "Serial2" no 2522. DTR e RTS indicam que a controladora já ativou a própria linha e está esperando que o AS/400 envie a conversação inicial.
Em seguida, verifique o show interface para o lado AS/400 do roteador. Na saída mostrada abaixo, vemos que a interface serial conectada ao AS/400 está inativa/inativa. Isso significa que o AS/400 está provavelmente "indisponível para uso". Se a linha for "variada" e você não conseguir ativar a linha ou estiver executando half duplex, então você precisará 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 ponto, verifique o "Work with Configuration Status" (Trabalho com status de configuração) desse controlador específico, que é uma tela AS/400 com aparência:
Em seguida, varie na definição de linha. Você observará então que o roteador entra em alinhamento up/up. Se a linha for ativada/ativada, mas o controlador ainda não estiver ativado, verifique a interface para verificar se algum pacote atingiu a interface de entrada do AS/400. Se a contagem for zero, verifique o mecanismo de codificação para a linha SDLC no AS/400. Ela está localizada na descrição da linha de exibição, como mostrado abaixo.
Observação: 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.
Essa configuração não exige a codificação NRZ/NRZI de ponta a ponta, como nas convenções ponto a ponto SDLC convencionais, mas pode ser NRZI de um lado e NRZ do outro. Mas lembre-se de que a codificação deve ser a mesma entre os dispositivos que compartilham a linha SDLC.
O NRZI requer uma consideração cuidadosa. Nos novos roteadores, como o Cisco 2500 e 4500, o NRZI é definido via software. Mas com plataformas mais antigas, incluindo o NP-2T para o Cisco 4000, você precisa mudar os jumpers nas próprias placas. Nesses casos, é provavelmente mais fácil alterar o AS/400 para NRZ/NRZI. Mas, se precisar alterar os jumpers, consulte a documentação de hardware da Cisco para sua plataforma específica.
Se o problema persistir, execute um debug stun packet 1. Esse comando fornece as seguintes informações:
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). Sabemos que o pacote está vindo do AS/400 porque o pacote foi originado do SDI. Há dois tipos de pacotes de entrada nesta saída de comando:
-
SDI: Entrada serial, que são os pacotes recebidos da interface do SDLC.
-
NDI: Entrada de rede, que são pacotes desencapsulados da WAN.
Em seguida, observe a porção XID do quadro em si. Neste exemplo, o AS/400 está enviando um XID junto com seu IDBLOCK e IDNUM, 05645253.
Esse é um problema de tempo limite, porque o controlador não está respondendo. No AS/400, examine a "fila de mensagens do sistema" para ver se há mensagens indicando um problema. Uma tela "SYSOPR" com falha é mostrada abaixo.
Agora, no 2522, ative o pacote 1 de depuração stun para ver se os pacotes estão sendo enviados 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
Isso nos mostra que o XID originado no lado AS/400 está chegando ao controlador, mas o controlador não está respondendo, o que significa que é um problema do controlador. Uma interface show nos mostra se todos os leads de controle estão ativos 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. Também podemos ver que o roteador está enviando pacotes, mas nenhum pacote está entrando. 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 uma maneira exclusiva de configurar o endereço de pesquisa, portanto, você precisa verificar isso com os manuais do controlador para seu controlador.
Neste exemplo, descobrimos que o controlador estava usando o endereço de pesquisa "DD". Depois de alterar isso no AS/400, a saída de debug stun packet se torna:
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
Essa saída de depuração ajuda a determinar as seguintes informações:
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 vemos o controlador respondendo (SDI) com um UA (73), o que significa que a sessão está funcionando. Em seguida, devemos ver a desconexão vindo do AS/400 como a linha variou.
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. A seguir, uma tabela com valores necessários para depurar esses problemas.
| Campo de controle - não numerado (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ão (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 - quadros de informações (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.
Ao contrário do STUN Basic, o STUN SDLC exige que você especifique o endereço de pesquisa correto ou o roteador nem verá os pacotes chegando. É por isso que, às vezes, o STUN Basic é usado para encontrar o endereço de pesquisa quando você não tem as informações ou não pode chegar ao host ou ao AS/400. O diagrama acima mostra um cenário multiponto com local-ack.
Em um ambiente ponto-a-ponto tradicional, a pesquisa vai de ponta a ponta. 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). Por causa disso, é necessário verificar se as estações estão seguindo o protocolo SDLC.
Primeiro, verifique se você está na função STUN correta. Os AS/400s têm problemas para negociar a função com o controlador em ambientes ponto-a-ponto tradicionais. A descrição de linha é mostrada abaixo.
Isso nos mostra que a interface do roteador precisa ser configurada para um papel secundário. Sempre marque a linha e verifique se ela é *PRI , pois o AS/400 assume como padrão *NEG quando você a cria. NRZI está definido como *SIM, então você precisa codificar nrzi-encoding. Além disso, codifique marcas de caractere ocioso e defina a janela para um (1) usando sdlc k 1. (Consulte o alerta de campo FNA-IOS-0696-02 para obter uma descrição detalhada do motivo pelo qual as marcas de caractere ocioso são necessárias na interface.) 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
Observação: a temporização fornecida pelo roteador é independente do parâmetro de velocidade de linha configurado na linha AS/400. (Este parâmetro é usado para cálculos de desempenho; pode ser deixado no padrão 9600.) O identificador do Exchange configurado na linha é o do AS/400, 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.
Podemos observar que o primeiro controlador será um PU 2.1, porque a categoria do controlador é "*APPC". Esta é a abreviação para Advanced Program-to-Program Communications, que só pode ser realizada por meio de uma conexão T2.1. O identificador de rede remota está novamente relacionado ao APPN/APPC e é conhecido como "NETID". "*NETATR" é um parâmetro que especifica o uso do 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" é o nome do ponto de controle configurado na PU2.1. Nesse caso, é CP5494. A função de enlace de dados pode ser deixada como *NEG. O "endereço da estação" precisa corresponder ao "endereço sdlc DD" configurado na interface secundária e em uma das interfaces primárias.
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.
Nesta tela, a segunda controladora (PU) é na verdade uma 3174, que é uma PU tipo 2. O XID configurado neste 3174 é 05600001. O "endereço da estação", ou endereço sdlc, sendo usado é 01. Você precisa de um "endereço sdlc 01" configurado na interface secundária e uma das interfaces primárias remotas. Como você pode ver abaixo, a configuração de uma PU2 é menos envolvida que uma 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.
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. Isso, assim como o resto da configuração específica da APPN, pode ser encontrado na segunda tela de configuração no 5494. O nome do ponto de controle local do AS/400 é "RTP400A". O nome da LU do AS/400 é "LU9404;", que precisa corresponder ao que está configurado no campo de definição da LU do parceiro do 5494. A descrição do modo que está sendo usada pelo 5494 precisa corresponder ao que está na descrição do dispositivo. Por exemplo, se o dispositivo disser "*NETATR", ele precisará corresponder ao padrão de "BLANK".
Uma descrição do dispositivo APPC criada para o 5494 é mostrada abaixo.
Esta tela mostra que a descrição do dispositivo para o 5494 tem um nome de PC remoto "CP5494"; isso precisa corresponder ao que está configurado no 5494. O NETID e o Local Local assumiram como padrão "*NETATR", que foram codificados para LU9404 e NETA no exemplo anterior. Novamente, eles precisam coincidir com o nome da LU do parceiro e os campos NETID no 5494.
A seguir, é mostrada a parte final da configuração do dispositivo relacionada à obtenção de uma conexão estabelecida.
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 pela IBM como parte do suporte básico APPN no AS/400. Se você vir algo diferente, entre em contato com a IBM, pois eles estão sendo executados com uma descrição do modo que eles criaram. Este exemplo estabelece uma conexão básica; se desejar exibir as informações sobre os modos disponíveis, use o comando WRKMODD ou Descrição do modo de trabalho.
A descrição de modo é apresentada abaixo.
Esta tela identifica claramente as definições de Modo fornecidas pela 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 completa/Informações gerais
Em um ambiente multidrop, um AS/400 se comporta de forma diferente de outros dispositivos IBM. Enquanto um FEP aceita caracteres 0x7E (flags) ou 0xFF (marcas) como espaço "ocioso" entre quadros, um AS/400 trata as flags e marcas de forma diferente. Somente uma marca é interpretada como caractere ocioso. Um sinalizador é interpretado como "a linha ainda está ativa - mais dados estão pendentes". Um roteador Cisco pode ser configurado para enviar sinalizadores ou marcas, mas não ambos. Ele não alternará entre os dois para refletir o estado da linha. O padrão é que o roteador envie sinalizadores.
Essa diferença coloca um problema em ambientes full duplex multi-drop. Normalmente, o AS/400 vai de dispositivo para dispositivo, pesquisando cada um dos dados. Se um dispositivo não responder e o AS/400 achar que a linha ainda está ativa, ele redefinirá 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. Portanto, com a modificação, um AS/400 sempre detecta o estado de linha ociosa independentemente dos caracteres entre quadros que estão sendo enviados pelo roteador. Assim, se um dispositivo secundário não responder, o AS/400 verificará o CD, verá uma linha ociosa e prosseguirá para pesquisar a próxima estação.
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 essa correção instalada, um AS/400 ignora completamente o estado do CD em linhas full duplex de várias solturas. Como resultado, a modificação de cabo da Cisco não é mais eficaz para impedir reinicializações periódicas de linha.
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 na configuração do roteador conectado ao AS/400.
Opção 1
Altere o caractere ocioso SDLC do caractere de flag padrão para um caractere de marca. O caractere ocioso pode ser alterado com o uso do comando de configuração de interface do roteador:
idle-character marks
Adicione esse comando à interface serial SDLC conectada ao AS/400. Esse comando fará com que o roteador sempre transmita caracteres de 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 só reconhecerá o primeiro quadro, mesmo que o bit de pesquisa/final seja 0. Em seguida, ele ignorará todos os quadros subsequentes e pesquisará o próximo dispositivo causando retransmissões desnecessárias de quadros. Para evitar as retransmissões, é preciso definir também o tamanho da janela do SDLC como 1, com o comando:
sdlc k 1
Observação: o comando idle-character é suportado no Cisco IOS versão 10.0(5.2) e posterior e funciona em roteadores 2500s, 4x00 com NP-4T e 70x0/75xx.
Opção 2
Ative a detecção de dispositivos secundários inativos com o comando interface:
stun quick-response
Esse comando fará com que o roteador responda com um quadro de "modo de desconexão" (DM) para qualquer dispositivo secundário inativo interrogado pelo AS/400. O AS/400 prosseguirá para pesquisar o próximo dispositivo sem redefinir a linha.
Observação: esse comando é suportado no Cisco IOS 11.1, 11.0(3.1) e posterior ou 10.3(7.2) e posterior.
Dica: se você tiver problemas para ativar a linha multiponto com a resposta rápida configurada, use a opção 1. O código stun quick-response no roteador faz parte da máquina de estado finito para local-ack, que pode sair de linha com algumas PUs. Nós testamos o código em laboratório e verificamos sua interoperabilidade com o 5494, 5394 e Perl494E. É possível ter problemas se a PU que você está tentando anexar tiver temporizadores definidos de forma diferente do que o quick_response está esperando.
Feedback