Configuración y resolución de problemas de la tunelización serial (STUN)
Contenido
Introducción
La tunelización en serie (STUN) es la tunelización de tramas de SDLC a través de una WAN. En el mundo tradicional de la Arquitectura de red de sistemas (SNA), los controladores remotos están asociados al Procesador frontal (FEP) a través de un conjunto de módems asociados a través de POST (Servicio "telefónico sencillo antiguo") o líneas arrendadas.
Antes de comenzar
Convenciones
Para obtener más información sobre las convenciones del documento, consulte Convenciones de Consejos Técnicos de Cisco.
Prerequisites
STUN SDLC se utiliza más comúnmente en dos entornos: FEP al controlador remoto y AS/400 al controlador remoto.
Componentes Utilizados
Resolución de problemas STUN mediante los comandos del software Cisco IOS®, así como AS/400 para problemas específicos del controlador remoto.
Antecedentes
A medida que las redes avanzan hacia la integración y las oficinas remotas requieren diferentes tipos de servicios (como NetBIOS, IP, IPX), tenía sentido desde el punto de vista del mantenimiento y los costes integrar todos estos servicios en un único dispositivo. Por ejemplo, en el siguiente diagrama se ve la integración de los terminales 3270 al host con el tráfico NetBIOS de las estaciones de Windows.
STUN permite utilizar IP como transporte para tramas de control de enlace de datos síncronos (SDLC) a través de una WAN u otra red de medios. Esto elimina la necesidad de tener una línea arrendada adicional o POTS. Una función del SDLC de los routers de Cisco es la traducción de medios. En la traducción de medios, el router traduce la sesión de SDLC al Control de link lógico, tipo 2 (LLC2). Esto se discute en detalle en Comprensión y Troubleshooting de la Traducción de Medios de Red SDLC a LLC.
Existen dos tipos de configuraciones STUN: STUN Básica y STUN SDLC. El primero se utiliza para cualquier trama de tipo derivada de High-Level Data Link Control (HDLC) y el segundo se utiliza para tramas de tipo SDLC únicamente. STUN Basic también se puede utilizar para SDLC, pero no se pueden utilizar funciones como local-ack. Es común utilizar STUN Basic para SDLC con fines de resolución de problemas, ya que los parámetros específicos de SDLC no necesitan ser configurados en el router.
Configuración STUN
El primer comando para cualquier configuración STUN (Básica o SDLC) es stun peer-name. Sin el comando stun peer-name, el router no lo dejará continuar con los pasos de la configuración.
| Tarea | Comando |
|---|---|
| Habilite STUN para una dirección IP determinada. |
stun peer-name ip-address
|
Debe seleccionar una dirección de IP válida desde el router. Esta dirección IP debe ser la interfaz más fiable del cuadro. Para obtener los mejores resultados, configure el router con una interfaz de loopback. (Para obtener información sobre la configuración de interfaces de loopback.
El siguiente paso es para determinar el modo STUN que desea utilizar. Uno de los modos es STUN Básico, en el que busca el comienzo y la delimitación del marco [7e] y lo transforma hacia el otro lado. En este modo de funcionamiento, a STUN no le importa el estado específico de la sesión ni la información detallada de SDLC, como la dirección de sondeo. El otro modo es STUN SDLC. Este modo requiere decisiones más detalladas en el router, especialmente si ejecuta un reconocimiento local o cualquier tipo de multipunto. Los comandos usados para especificar un modo STUN se describen en la siguiente tabla:
| Tarea | Comando |
|---|---|
| Indique un grupo de protocolo básico y asigne un número de grupo. |
stun protocol-group group-number basic
|
| Indique un grupo de protocolo SDLC y asigne un número de grupo. |
stun protocol-group group-number sdlc
|
El siguiente paso es configurar la interfaz serial para STUN. El grupo que seleccione en la interfaz debe coincidir con el que se definió en el grupo de protocolos. Con multipuntos virtuales, usted también debería crear un grupo de protocolos stun con números diferentes para cada uno de los multipuntos virtuales. Asegúrese siempre de haber configurado sólo una interfaz secundaria por stun-group, a menos que esté configurando sdlc-tg. Vea stun protocol-group.
| Tarea | Comando |
|---|---|
| Activar la función STUN en una interfaz serial. | encapsulation stun |
| Coloque la interfaz en un grupo STUN previamente definido. |
stun group group-number
|
Nota: No configure esto en un Cisco 7000, Cisco 7500 o cualquier otro router que tenga un CxBUS, CyBUS durante el tiempo de la red de producción. Esta configuración hace que el router cambie la MTU de la interfaz a 2032 bytes, lo que da lugar a una separación de búfer CBUS y hace que todas las interfaces del router reboten (reset). En un entorno Token Ring, puede significar que los Token Rings se desactivarán hasta 16 segundos. Además, dado que Cisco 7000 es a menudo el centro del núcleo donde este tipo de problema afecta a muchos usuarios.
El siguiente paso en la configuración del STUN es agregar la declaración de router stun. Puede definir esto como stun route all o stun route [address]. A continuación, se explican las opciones de configuración.
| Tarea | Comando |
|---|---|
| Reenviar todo el tráfico TCP para esta dirección IP. |
stun route all tcp ip-address
|
| Especifique el encapsulado de TCP. | stun route address address-number tcp ip-address [priority] [tcp-queue-max] |
Los comandos arriba son para pares de encapsulación TCP. También puede configurar STUN para la encapsulación directa, pero esta configuración rara vez se utiliza. La configuración más común es la configuración de reconocimiento local STUN.
Estos parámetros de comando se describen a continuación:
-
La opción de prioridad en una declaración de ruta stun es utilizada para crear conductos TCP múltiples entre dos pares STUN de modo que las estructuras de prioridad pueden ser creadas mediante la colocación en cola personalizada o la colocación en cola prioritaria.
-
La opción tcp_queue_max aumenta o disminuye las colas TCP entre los dos pares STUN. Esto es útil si la sesión TCP entre los pares no es muy confiable y usted debe determinar qué problema existe entre ellos. Esta opción no se utiliza normalmente en los entornos STUN, salvo cuando se realiza un FEP-a-FEP STUN en el que hay mucho más tráfico involucrado.
A continuación se describen los comandos utilizados para configurar STUN con reconocimiento local.
| Tarea | Comando |
|---|---|
| Asigne al router con STUN una función principal SDLC. | stun sdlc-role primary |
| Asigne al router habilitado para STUN una función secundaria SDLC. | stun sdlc-role secondary |
Estos comandos definen el “rol” de la configuración STUN. En el caso del host en el diagrama anterior, el router se establece en primario, lo que significa que el host es el que inicia la sesión. Esto hace que 3174 sea secundario. Al utilizar STUN básica, no debe definir la función, porque no es necesario que sepa quién iniciará la sesión. Pero el reconocimiento local requiere detalles de la línea misma y la definición de la función permite al router conocer el flujo del inicio de la sesión, que el router debe verificar antes de pasar al reconocimiento local.
Nota: En entornos AS/400 STUN que realizan reconocimiento local, es muy importante establecer el rol (en la descripción de la línea) en *pri de *neg. La razón de esto es que en un entorno puro (conexión de módem directo), el AS/400 puede negociar la función. Al codificar la función que vamos a estar en la línea, puede asegurarse de que la función del router es opuesta a la del AS/400. Normalmente, desea que el AS/400 inicie la sesión (con "variación en" de la línea ). Vaya a la configuración de línea y configure esto para *pri. A continuación, se presenta la descripción de la línea de muestra AS/400. Esto sólo puede hacerse durante la creación/copia de la descripción de línea.
A continuación se explica el comando para configurar STUN con reconocimiento local.
| Tarea | Comando |
|---|---|
| Establezca el reconocimiento local de SDLC mediante la encapsulación TCP. | stun route address address-number tcp ip-address [local-ack] [priority] [tcp-queue-max] |
El parámetro importante aquí es la ruta stun [address] con Local-ack. Recuerde que puede efectuarse STUN local-ack con encapsulación TCP y encapsulación Frame Relay (mediante RFC 1490).
Al igual que en RSRB y DLSw, las señales de mantenimiento en STUN fluyen entre los pares TCP para asegurarse de que la conexión de peer esté activa. Si sus pares se activan y se desactivan debido a la pérdida de señales de mantenimiento, puede ajustar tales señales. A continuación, se describen los comandos STUN empleados para configurar las señales de mantenimiento:
| Tarea | Comando |
|---|---|
| Habilite la detección de un par perdido remoto. |
stun remote-peer-keepalive seconds
|
| Número de veces que se intenta una conexión de peer antes de declarar el par "inactivo". | stun keepalive-count quantity |
Ejemplo de configuración básica de STUN
STUN básico es la configuración más simple de STUN. En este modo, todos los paquetes que el router recibe de un lado se transportan al siguiente. En el diagrama siguiente se muestra una configuración de STUN Basic:
Los routers del diagrama anterior se configuran de la siguiente manera:
| 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 |
Ejemplo de configuración 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 |
Configuración de muestra multipunto STUN (con 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 |
Nota: En el router AS400, utilizamos las marcas sdlc k1 y idle-character. Consulte la sección Alerta de campo para más detalles.
Comandos show
El primer comando show utilizado con STUN es show stun. El resultado de este comando depende de si usted utiliza STUN Basic o STUN SDLC con local-ack. En la sección STUN Basic que se muestra a continuación, sólo verá los paquetes transmitidos y recibidos.
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
En la sección STUN SDLC con Local-ack que se muestra a continuación, obtiene más información porque ahora se conoce el estado de la sesión.
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
El comando show interface también proporciona información diferente, según se ejecute STUN Basic o STUN SDLC. La interfaz show para STUN Basic es la misma que para una línea serial normal.
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
El show interface para SDLC de STUN con reconocimiento local provee más información. A continuación, se muestra un resultado de ejemplo para una interfaz serie con local-ack.
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
Partes de este resultado se explican a continuación:
-
MTU es el tamaño físico del búfer que utiliza la interfaz.
-
PRIMARY (DCE) significa que ésta es la estación de consulta del cable y que estamos proporcionando el reloj. Si miráramos el lado que está asociado al primario real, este resultado habría sido SECUNDARIO.
-
N1 es el valor del tamaño utilizable de la trama SDLC que se puede alojar por la interfaz serial del router.
-
T1 es la cantidad de tiempo que esperamos una respuesta a una encuesta antes de que se agote el tiempo de espera de la línea.
-
poll-pause-timer corresponde al tiempo delta en milisegundos entre sondeos.
-
k es el tamaño de la ventana o la cantidad de tramas que se pueden tener pendientes en finales de sondeo.
-
estado es el estado actual de la sesión, que puede ser uno de los siguientes:
-
DESCONECTAR
-
CONECTADO
-
THEMBUSY (configurado normalmente como resultado de que este router reciba un RNR)
-
USBUSY (normalmente como resultado de no obtener una respuesta en el lado de la red).
-
-
los RNR son la cantidad de RNR enviados/recibidos.
-
DTR/RTS son las líneas que se utilizan en la mayoría de los entornos multidúplex semidúplex. Cuando esté depurando cualquier entorno STUN y observando la ubicación del controlador, preste mucha atención a RTS. Si esto baja intermitentemente mientras el DTR y el CTS son altos, es muy probable que el resultado de DTE sea semidúplex.
El comando final important show para STUN es el comando show tcp, que provee información referida a la sesión TCP entre las entidades pares.G A continuación, se muestra el ejemplo de resultado:
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
Resolución de problemas
La resolución de problemas relacionados con una configuración STUN es la misma que con cualquier convención entre pares. Si está experimentando problemas en el transporte, esto debe diagnosticarse antes de poder comenzar a solucionar el problema de la parte SDLC/STUN. Normalmente, el primer paso es hacer ping de par en par para asegurarse de que la IP esté configurada correctamente. Además, haga ping con tipos de paquetes extendidos para asegurarse de que el transporte sea confiable.
Solución de problemas básicos de SDLC
Esta sección trata sobre la resolución de problemas de una configuración de STUN Basic. En este ejemplo, suponga que la WAN funciona correctamente.
Este escenario tiene una configuración STUN Basic para conectar el 5494 al AS/400. Lo primero que se debe verificar con cualquier configuración STUN es que los pares están configurados en el router. Para determinar esto, utilice el comando show stun peer. Proporciona información sobre el estado del par y los paquetes que se transmitieron/recibieron. A continuación, se muestra el ejemplo de resultado:
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
Si el par está abierto, como se indica arriba, utilice el comando show interfacecommand para determinar qué está sucediendo con los paquetes. A continuación se muestra el ejemplo de salida para este comando:
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
Primero, verifique si el router tiene todas las señales seriales activadas. En la parte inferior del resultado anterior, podemos ver que todas las señales están "arriba" para el "Serial2" en el 2522. DTR y RTS indican que el controlador ya ha activado la línea y está esperando que el AS/400 envíe la conversación inicial.
A continuación, verifique la interfaz show para el lado AS/400 del router. En el resultado que se muestra a continuación, vemos que la interfaz serial que se conecta al AS/400 está inactiva/inactiva. Esto significa que el AS/400 probablemente esté "desactivado". Si la línea es "variada" y no puede poner la línea en funcionamiento o está ejecutando semidúplex, debe verificar la conexión 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#
En este punto, verifique "Trabajar con el Estado de la Configuración" para ese controlador específico, que es una pantalla AS/400 con el siguiente aspecto:
A continuación, varía según la definición de línea. Luego, debería observar que el router se dirige a una línea up/up. Si la línea se activa/activa pero el controlador aún no se activa, verifique la interfaz para verificar si algún paquete ha llegado a la interfaz de entrada desde el AS/400. Si el conteo es cero, verifique el mecanismo de codificación para la línea SDLC en el AS/400. Se encuentra en la descripción de la línea de visualización, como se muestra a continuación.
Nota: En esta pantalla, podemos ver que la codificación de línea está configurada para la codificación NRZI. Esto tiene que activarse con la opción de configuración de la codificación nrzi en el router.
Esta configuración no requiere codificación NRZ/NRZI de extremo a extremo, como en las convenciones SDLC convencionales punto a punto, pero puede ser NRZI en un lado y NRZ en el otro. Pero recuerde que la codificación tiene que ser la misma entre los dispositivos que comparten la línea SDLC.
La NRZI requiere una cuidadosa consideración. En los nuevos routers como Cisco 2500 y 4500, NRZI se configura a través del software. Sin embargo, con las plataformas más antiguas, incluido el NP-2T para el Cisco 4000, debe cambiar los puentes de las juntas. En estos casos, probablemente sea más fácil cambiar el AS/400 a NRZ/NRZI. Sin embargo, si necesita cambiar los puentes, consulte la documentación de hardware de Cisco para su plataforma específica.
Si el problema persiste, haga un debug stun packet 1. Este comando nos proporciona la siguiente información:
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
Puede ver a varias XID fluyendo desde el AS/400, pero no hay respuesta hacia ellos (CO es la dirección de sondeo y bf es la XID). Sabemos que el paquete proviene del AS/400 porque se originó desde SDI. Hay dos tipos de paquetes entrantes en esta salida de comando:
-
SDI: Entrada serial, que son paquetes recibidos desde la interfaz de SDLC.
-
NDI: Entrada de red, que son paquetes desencapsulados de la WAN.
A continuación, observe la parte XID de la trama en sí. En este ejemplo, el AS/400 está enviando un XID junto con su IDBLOCK e IDNUM, 05645253.
Este es un problema de tiempo de espera, porque el controlador no responde. En el AS/400, observe la "cola de mensajes de sysopr" para ver si hay algún mensaje que indique un problema. A continuación se muestra una pantalla "SYSOPR" con una falla.
Ahora en el 2522, active debug stun packet 1 para ver si los paquetes se envían al controlador. La salida del comando de ejemplo se muestra a continuación:
STUN basic: 0:00:34 Serial2 NDI: Data: c0bf324c056452530000 STUN basic: 0:00:42 Serial2 NDI: Data: c0bf324c056452530000
Esto nos muestra que el XID que se originó en el lado AS/400 está pasando al controlador, pero el controlador no responde, lo que significa que es un problema del controlador. Una interfaz show nos muestra si todos los leads del control están activos o no:
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
Los terminales de control están activados y la interfaz aparece up/up. También podemos ver que el router está enviando paquetes, pero no hay paquetes entrantes. Este señala la dirección de sondeo incorrecta configurada en AS/400, por lo tanto, el paso siguiente es verificar la dirección de sondeo del controlador.
Cada tipo de controlador tiene una manera única de configurar la dirección de sondeo, por lo que debe verificarlo con los manuales de controlador para su controlador.
En este ejemplo, descubrimos que el controlador estaba usando la dirección de sondeo de "DD". Después de cambiar esto en el AS/400, el resultado de debug stun packet se convierte en:
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 de depuración ayuda a determinar la siguiente información:
STUN basic: 0:24:03 Serial2 NDI: Data: ddbf324c056452530000
Esta línea incluye la XID de AS/400 para controlador. Esto viene de la NDI (que viene de la nube), dd (dirección de sondeo), bf (el XID) y el IDBLOCK y el IDNUM (05645253).
STUN basic: 0:00:00 Serial2 SDI: Data: ddbf3244073000dd0000
Esta es la respuesta del controlador. Esto está indicado por el SDI (proveniente de la línea del SDLC) y al igual que anteriormente, a excepción de la respuesta XID (073000dd), porque éste es un 5494.
STUN basic: 0:00:00 Serial2 NDI: Data: dd93
Este es el SNRM (93)desde AS/400 al controlador, el principal en esta configuración.
STUN basic: 0:00:00 Serial2 SDI: Data: dd73
Aquí vemos el controlador respondiendo (SDI) con un UA (73), lo que significa que la sesión está en funcionamiento. A continuación, deberíamos ver la desconexión proveniente del AS/400 a medida que la línea se desactivaba.
STUN basic: 0:00:00 Serial2 NDI: Data: dd53 STUN basic: 0:00:00 Serial2 SDI: Data: dd73
Estas líneas muestran DISC (53) y la respuesta de UA. La línea ahora está inactiva. A continuación se muestra una tabla con los valores necesarios para depurar estos problemas.
| Campo de control: sin numerar (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 control: supervisión (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 control: tramas de información (2 bytes) | ||
|---|---|---|
rrr1 sssz |
xx-xx |
Information format |
Clave:
z = El bit final de sondeo puede ser 0 o 1
rrr = Número de bloque que se espera recibir
sss = Número del bloque que se está enviando
Resolución de problemas de STUN SDLC con y sin reconocimiento local
Esta sección cubre el mismo escenario con el reconocimiento local configurado.
A diferencia de STUN Basic, STUN SDLC requiere que especifique la dirección de sondeo correcta o que el router ni siquiera vea los paquetes entrar. Esta es la razón por la que a veces se utiliza STUN Basic para encontrar la dirección de sondeo cuando no se tiene la información o no se puede llegar al host o al AS/400. El diagrama anterior muestra un escenario multipunto con Local-ack.
En un entorno tradicional punto a punto, las encuestas van de un extremo a otro. Cuando se introduce el reconocimiento local, la consulta finaliza en cada extremo de la nube; por lo tanto, cada router debe mantener una máquina de estado finito. Esta máquina lleva un registro de todas las sesiones y necesita saber el estado de la línea para cada estación sondeada. Debido a esto, debe asegurarse de que las estaciones están siguiendo el protocolo SDLC.
Primero, verifique que se encuentre en la función STUN correcta. Los AS/400 tienen problemas para negociar el rol con el controlador en entornos tradicionales punto a punto. La descripción de la línea se muestra a continuación.
Esto nos indica que la interfaz del router debe configurarse para un rol secundario. Siempre verifique la línea y verifique que sea *PRI , porque el AS/400 tiene el valor predeterminado *NEG cuando lo crea. NRZI se establece en *SÍ, por lo que debe codificar nrzi-encoding. Además, codifique marcas de caracteres inactivos y establezca la ventana en uno (1) usando sdlc k 1. (Consulte la Alerta de Campo FNA-IOS-0696-02 para obtener una descripción detallada de por qué se requieren marcas de caracteres inactivos en la interfaz.) Esta codificación se muestra a continuación:
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: La temporización que proporciona el router es independiente del parámetro de velocidad de línea configurado en la línea AS/400. (Este parámetro se utiliza para calcular el rendimiento; se puede dejar en el valor predeterminado de 9600.) El identificador de Exchange que se configura en la línea es el del AS/400, como el XID que enviará el AS/400. El controlador máximo es la cifra de la cantidad de PU (controladores) que se pueden crear y conectar con esta línea.
El primero de los dos controladores conectados a esta línea, IBM 5494, se muestra en la siguiente pantalla.
Podemos ver que el primer controlador será un PU 2.1 porque la categoría del controlador es "*APPC". Esta es la abreviatura de Advance Program-to-Program Communications, que sólo se puede lograr a través de una conexión T2.1. El identificador de red remota se relaciona de nuevo con APPN/APPC y se denomina "NETID". "*NETATR" es un parámetro que especifica el uso del NETID definido en el área de datos llamada "Atributos de red". Puede mostrar esta área de información utilizando el comando DSPNETA y sustituir los valores, si corresponde. El "punto de control remoto" o "CP_name" es el nombre del punto de control configurado en la PU2.1. En este caso, es CP5494. La función de enlace de datos se puede dejar como *NEG. La "dirección de la estación" debe coincidir con la "DD de dirección sdlc" que se configuró tanto en la interfaz secundaria como en una de las interfaces primarias.
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
Puede ver que la mayor parte de la información en la descripción del controlador corresponde a la unidad física en sí misma, y no es configurable en el router.
En esta pantalla, el segundo controlador (PU) es en realidad un 3174, que es un PU tipo 2. El XID configurado en este 3174 es 05600001. La "dirección de la estación", o dirección sdlc, que se utiliza es 01. Necesita una "dirección sdlc 01" configurada en la interfaz secundaria y una de las interfaces primarias remotas. Como puede ver a continuación, la configuración para una PU2 está menos involucrada que una 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
Display Networks Attributes (DSPNETA, Mostrar atributos de redes) en AS/400 se muestra abajo.
Esta pantalla muestra que el AS/400 se encuentra configurado actualmente para la ID de red "NETA", lo que significa que el 5494 debe ser configurado para la misma red. Esto, así como el resto de la configuración específica de APPN, se puede encontrar en la segunda pantalla de configuración en el 5494. El nombre del punto de control local del AS/400 es "RTP400A". El nombre de la LU del AS/400 es "LU9404;"; esto debe coincidir con lo que se configura en el campo de definición de LU del partner del 5494. La descripción del modo que está utilizando el 5494 debe coincidir con lo que está en la descripción del dispositivo. Por ejemplo, si el dispositivo dice "*NETATR", debe coincidir con el valor predeterminado de "BLANCO".
A continuación se muestra la descripción del dispositivo APPC creada para 5494.
Esta pantalla muestra que la descripción del dispositivo para el 5494 tiene un nombre de CP remoto de "CP5494;" esto necesita coincidir con lo que está configurado en el 5494. El NETID y la ubicación local han predeterminado "*NETATR", que se codificaron en LU9404 y NETA en el ejemplo anterior. Una vez más, deben coincidir con el nombre de la LU del partner y con los campos NETID del 5494.
A continuación se muestra la última parte de la configuración de dispositivo que se debe realizar para establecer una conexión.
Esta pantalla muestra que el modo que se utiliza en la descripción del dispositivo es "QRMTWSC". Este no es el valor predeterminado que se encontró en *NETATR; por lo tanto, significa que se lo ha anulado en la descripción del dispositivo. Este es uno de los modos predeterminados que suministra IBM como parte del soporte básico APPN en el AS/400. Si ve algo diferente, póngase en contacto con IBM porque se están ejecutando con una descripción de modo que crearon. Este ejemplo establece una conexión básica; si desea mostrar la información sobre los modos disponibles, puede utilizar el comando WRKMODD o Descripciones del modo de trabajo.
La descripción del modo se muestra a continuación.
Esta pantalla identifica claramente las definiciones de modo proporcionadas por IBM.
Solución de problemas de la interfaz multipunto de dúplex completo SDLC
Cuando realice un reconocimiento local en un entorno multipunto con AS/400, preste atención a la manera en que fue implementada la "Interfaz multipunto de dúplex completo SDLC" en las mini-tramas AS/400, SYS/38 y SYS/36. El alerta de campo FNA-IOS-0696-02 (se incluye a continuación) explica la clase de problemas que pueden ocurrir en esta situación.
Breve Descripción
Conectar a tierra la modificación del cable del router "carrier detect" no evitará que la línea SDLC periódica se reinicie en un AS/400 si se ha aplicado un PTF#MF10030 de IBM. Este alerta se aplica únicamente a las conexiones multipunto de dúplex completo STUN a un AS/400 donde el cable SDLC del router se ha modificado para deshabilitar la detección de la portadora.
Impacto
Los usuarios puede experimentar el reinicio periódico de la conexión STUN y de todos los dispositivos SDLC secundarios lo que resulta en una conexión no confiable.
Descripción completa/fondo
En un entorno de varias caídas, un AS/400 se comporta de manera diferente que otros dispositivos de IBM. Mientras que un FEP acepta caracteres 0x7E (indicadores) o 0xFF (marcas) como espacios "inactivos" entre tramas, un AS/400 trata los indicadores y marcas de manera diferente. Sólo se interpreta una marca como un carácter inactivo. Un indicador se interpreta como "la línea sigue activa; hay más datos pendientes". Un router Cisco puede configurarse para enviar indicadores o marcas, pero no ambas. No se alternará entre los dos para reflejar el estado de línea. El valor predeterminado es que el router envíe indicadores.
Esta diferencia plantea un problema en entornos de múltiples caídas de dúplex completo. Normalmente, el AS/400 pasa de un dispositivo a otro, sondeando cada uno por los datos. Si un dispositivo no responde y el AS/400 piensa que la línea sigue activa, restablecerá toda la línea. Dado que, de modo predeterminado, un router envía indicadores, el AS/400 siempre verá una línea activa y reiniciará la línea en vez de simplemente sondear el dispositivo siguiente.
Para evitar este problema, Cisco siempre ha recomendado una modificación de cable que desactive la señal carrier detect (CD). Esta modificación aprovecha la lógica AS/400 que interpreta la ausencia de portadora como "estado de línea inactiva". Por lo tanto, con la modificación, un AS/400 siempre detecta el estado de línea inactiva independientemente de los caracteres entre tramas que envía el router. Por lo tanto, si un dispositivo secundario no responde, el AS/400 comprobará el CD, verá una línea inactiva y pasará a sondear la siguiente estación.
Recientemente IBM lanzó el solucionador de problemas AS/400 PTF#MF 10030 que convierte el detector de portadora de lógica en líneas de acometidas múltiples. Con esta corrección instalada, un AS/400 ignora por completo el estado del CD en las líneas de varias caídas de dúplex completo. Como resultado, la modificación del cable de Cisco ya no es eficaz para evitar que se restablezcan las líneas periódicas.
Solución Aternativa
Tiene dos soluciones alternativas que dependen del modelo de router y de la versión del IOS de Cisco en ejecución. Ambas opciones requieren cambios de configuración en el router conectado al AS/400.
Opción 1
Cambie el carácter inactivo de SDLC del carácter predeterminado del indicador a un carácter de marca. El carácter inactivo puede cambiarse mediante el comando de configuración de interfaz del router:
idle-character marks
Agregue este comando a la interfaz serial SDLC conectada al AS/400. Este comando hará que el router transmita siempre caracteres de marca para una pausa entre tramas. Entonces, si un dispositivo secundario pierde un sondeo, el AS/400 verá una línea inactiva y se moverá para sondear el siguiente dispositivo. Lamentablemente, esto también significa que el AS/400 observará inactivo incluso si existen más tramas de datos en camino desde el dispositivo. El AS/400 sólo reconocerá la primera trama, incluso si el bit de sondeo/final es 0. Luego ignorará todas las tramas subsiguientes y sondeará el siguiente dispositivo, lo que provocará retransmisiones innecesarias de tramas. Para evitar las retransmisiones, también debe configurar el tamaño de la ventana SDLC a 1 con el comando:
sdlc k 1
Nota: El comando idle-character se soporta en la versión 10.0(5.2) y posteriores del IOS de Cisco, y funciona en los routers 2500s, 4x00 con NP-4T y 70x0/75xx.
Opción 2
Habilite la detección de dispositivos secundarios inactivos con el comando interface:
stun quick-response
Este comando hará que el router responda con una trama de "modo de desconexión" (DM) para cualquier dispositivo secundario inactivo sondeado por el AS/400. A continuación, el AS/400 procederá a sondear el siguiente dispositivo sin reiniciar la línea.
Nota: Este comando se soporta en Cisco IOS 11.1, 11.0(3.1) y posteriores o 10.3(7.2) y posteriores.
Sugerencia: Si experimenta problemas al activar la línea multipunto con la respuesta rápida configurada, utilice la opción 1. El código stun quick-response en el router es parte de la máquina de estado finito para Local-ack, que puede salirse del paso con algunas PU. Probamos el código en el laboratorio y verificamos su interoperabilidad con el 5494, 5394 y Perl494E. Es posible encontrar problemas si la PU que intenta asociar tiene temporizadores configurados de manera diferente a lo que espera la respuesta rápida.
Comentarios