IP : Túnel serial (STUN)

Configuración y resolución de problemas de la tunelización serial (STUN)

17 Octubre 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


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.

prerrequisitos

STUN SDLC se utiliza más comúnmente en dos entornos: FEP al controlador remoto, y AS/400 al controlador remoto.

Componentes Utilizados

Troubleshooting de STUN usando los comandos del software del ½ del ¿Â de Cisco IOSï así como AS/400 a los problemas del específico del controlador remoto.

Antecedentes

Mientras que las redes se mueven hacia la integración y las oficinas remotas requieren diverso tipo de servicio (tal como NetBios, IP, IPX), tuvo sentido de un punto de vista del mantenimiento y del coste de integrar todos los éstos en un único dispositivo. Por ejemplo, en el diagrama siguiente vemos la integración de 3270 terminales al host con el tráfico de NETBIOS de las estaciones de Windows.

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

ATURDA los permisos usted de utilizar el IP como transporte para las tramas del Synchronous Data Link Control (SDLC) a través del WAN o de la otra red de medios. Esto elimina la necesidad de tener una línea arrendada adicional o CRISOLES. Una función del SDLC de los routers de Cisco es la traducción de medios. En traducción de medios, el router traduce la sesión del SDLC al Logical Link Control, el tipo-2 (LLC2). Esto se discute detalladamente en la comprensión y resolver problemas del SDLC a la Traducción de medios de red 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. El STUN Básico se puede también utilizar para el SDLC, pero las características tales como Local-ack no pueden ser utilizadas. Es común utilizar el STUN Básico para el SDLC para los propósitos de Troubleshooting puesto que los parámetros SDLC-específicos 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
El permiso ATURDE para un IP Address particular.
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 confiable del cuadro. Para los mejores resultados, configure al router con un Loopback Interface. (Para aprender cómo configurar interfaces de loopback, consulte la documentación de Cisco).

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 operación, STUN no cuida sobre el estado específico de la sesión o de la información detallada 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. Aseegurese siempre que usted ha configurado solamente una interfaz secundaria por el aturdir-grupo, a menos que usted esté configurando el SDLC-TG. Vea stun protocol-group.

Tarea Comando
El permiso ATURDE la función 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, el Cisco 7500, o ningún otro router que tenga un CxBUS, CyBus durante el tiempo de la red de producción. Esta configuración hace al router cambiar el MTU de la interfaz a 2032 bytes, que da lugar a división del búfer CBUS y hace que todas las interfaces del router despiden (restauración). En un entorno Token Ring, puede significar que los Token Ring irán abajo por hasta 16 segundos. Además, puesto que el Cisco 7000 es a menudo el centro de la base 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. Usted puede definir esto como stun route all o stun route [address]. A continuación, se explican las opciones de configuración.

Tarea Comando
Remita todos 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. Usted puede también configurar ATURDE para la encapsulación directa, pero esta configuración se utiliza raramente. 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.

Los comandos usados para configurar ATURDEN con el Reconocimiento local son descritos más abajo.

Tarea Comando
Asigne a router con STUN activado una función primaria SDLC.
stun sdlc-role primary
Asigne a router con STUN activado un SDLC rol secundario.
stun sdlc-role secondary

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

Estos comandos definen el “rol” de la configuración STUN. En el caso del host en el diagrama antedicho, fijan al router a primario, así 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 los detalles de la línea sí mismo y la definición del papel deja al router conocer el flujo de la iniciación de sesión, que el router necesita verificar antes de trasladarse al Reconocimiento local.

Nota: En los entornos STUN AS/400 que hacen el Reconocimiento local, es muy importante fijar el papel (en la línea descripción) al *pri de *negative. La razón de esto es ésa en un entorno puro (conexión del módem directa), el AS/400 puede negociar el papel. Cifrando el papel que vamos a estar en la línea, usted puede asegurarse de que el papel del router es opuesto del AS/400. Usted quisiera generalmente que el AS/400 iniciara la sesión (con “varíe en” de la línea). Vaya a la configuración de línea y configure esto para el *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.

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

A continuación se explica el comando para configurar STUN con reconocimiento local.

Tarea Comando
Establezca el Reconocimiento local SDLC usando la encapsulación TCP.
stun route address address-number tcp ip-address [local-ack] [priority] [tcp-queue-max]

El parámetro importante aquí es stun route [address] con el Local-ack. Recuerde que puede efectuarse STUN local-ack con encapsulación TCP y encapsulación Frame Relay (mediante RFC 1490).

Como en el RSRB y DLSw, el Keepalives adentro ATURDE el flujo entre los pares TCP para asegurarse de que la conexión de peer está para arriba. 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
Detección del permiso de un par perdido remoto.
stun remote-peer-keepalive seconds

Cantidad de veces para intentar una conexión de peer antes de declarar al par “abajo.” 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 a partir de un lado se transportan al siguiente. Una configuración de STUN Básico se muestra en el diagrama a continuación:

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

Configuran al Routers en el diagrama antedicho como sigue:

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

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

Configuración de muestra multipunto STUN (con 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: En el router AS400, utilizamos sdlc k1 y marcas de caracteres inactivos. Consulte la sección Alerta de campo para más detalles.

Comandos show

El primer comando show usado con STUN es demostración aturde. El resultado de este comando depende de si usted utiliza STUN Basic o STUN SDLC con local-ack. En la porción del STUN Básico mostrada abajo, usted ve solamente 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 el ATURDIR SDLC con la porción del Local-ack mostrada abajo, usted consigue más información porque ahora el estado de la sesión se sabe.

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 de la demostración para el STUN Básico es lo mismo que para una línea serial regular. La Documentación de Cisco proporciona las explicaciones específicas para cada entrada de la salida de la interfaz de la demostración, una muestra cuyo se muestra abajo.

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:

  • El MTU es el tamaño físico del buffer que la interfaz utiliza.

  • PRIMARY (DCE) significa que ésta es la estación de consulta del cable y que estamos proporcionando el reloj. Si mirando el lado que se asocia al primario real, esta salida habría sido SECUNDARIA.

  • El n1 es el valor del tamaño usable del bastidor SDLC que se puede acomodar por la interfaz serial del router.

  • El T1 es la cantidad de tiempo que contamos con una respuesta a una encuesta antes de que la línea sea sincronizada-hacia fuera.

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

  • el estado es el estado actual de la sesión, que puede ser uno de los estados abajo:

    • DESCONECTAR

    • CONECTADO

    • THEMBUSY (fijado normalmente como resultado de este router que recibe un RNR.)

    • USBUSY (normalmente un resultado de no conseguir una respuesta detrás en el lado de la red.)

  • los RNR son la cantidad de RNR enviados/recibidos.

  • El DTR/RTS es las líneas usadas en la mayoría de los entornos de acometidas múltiples semidúplexes. Cuando usted está haciendo el debug de cualquier entorno STUN y está mirando la ubicación del controlador, preste la mucha atención al RTS. Si va esto abajo intermitentemente mientras que el DTR y el CTS son altos, es más probable el resultado del DTE que es 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 usted está experimentando los problemas en el transporte, éste necesita ser diagnosticado antes de que usted pueda comenzar a resolver problemas la porción SDLC/STUN. Generalmente, el primer paso es hacer ping del par para mirar para aseegurarse que el IP está configurado correctamente. También, ping con los tipos de paquete extendidos a aseegurarse que el transporte es confiable.

Solución de problemas básicos de SDLC

Esta sección cubre resolver problemas una configuración del STUN Básico. En este ejemplo, asuma que está funcionando WAN correctamente.

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

Este escenario tiene una configuración del STUN Básico para conectar los 5494 con el AS/400. La primera cosa a verificar con ningunos ATURDE la configuración es que configuran a los pares en el router. Para determinar esto, utilice el comando show stun peer. Ella proporciona la información sobre el estado del par y los paquetes que fueron transmitidos/recibidos. 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 arriba, utilice el interfacecommand de la demostración para determinar qué está sucediendo a los paquetes. La salida de muestra para este comando se muestra abajo:

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 para arriba. En la parte inferior de la salida arriba, podemos ver que todas las señales están “encima de” para el "Serial2" en los 2522. El DTR y el RTS indican que el regulador ha activado la línea sí mismo y está esperando ya el AS/400 para enviar la conversación inicial.

Después, marque la interfaz de la demostración para el lado AS/400 del router. En la salida mostrada abajo, vemos que la interfaz serial que asocia al AS/400 es abajo de/abajo. Esto significa que el AS/400 “está variado probablemente apagado.” Si la línea “se varía en” y usted no puede conseguir la formación ni es el ejecutarse semidúplex, después usted necesidad de marcar 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 momento, marque el “trabajo con el estado de la configuración” para ese regulador específico, que es una pantalla AS/400 la cual parece:

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

Después, varíe en la línea definición. Luego, debería observar que el router se dirige a una línea up/up. Si sube la línea /up pero todavía no sube el regulador, marque la interfaz para verificar si algunos paquetes han golpeado la interfaz entrante del AS/400. Si la cuenta es cero, marque el mecanismo de codificación para la línea SDLC en el AS/400. Esto está situada en la descripción del mostrar línea, como se muestra abajo.

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

Nota: En esta pantalla, podemos ver que la codificación de línea está establecida para 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 el End to End de la codificación NRZ/NRZI, como en los convenios de punto a punto convencionales SDLC, sino puede ser NRZI en un lado y NRZ en el otro. Pero recuerde que la codificación tiene que ser lo mismo entre los dispositivos que comparten la línea SDLC.

El NRZI requiere la consideración apropiada. En el nuevo Routers como el Cisco2500 y los 4500, el NRZI se fija vía el software. Pero con más viejas Plataformas, incluyendo el NP-2T para el Cisco 4000, usted necesita cambiar los puentes en las tarjetas ellos mismos. En estos casos, es probablemente más fácil cambiar el AS/400 al NRZ/NRZI. Pero, si usted necesita cambiar los puentes, refiera a la documentación del Cisco Hardware para su plataforma específica.

Si persiste el problema, haga un debug stun packet 1. Este comando nos da 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 está viniendo del AS/400 porque el paquete originó del 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: Entrante de red, que son desencapsulado de los paquetes de WAN.

Después, mirada en la porción XID del bastidor sí mismo. En este ejemplo, el AS/400 está enviando un XID junto con su IDBLOCK y IDNUM, 05645253.

Esto es un problema de tiempo de espera, porque no está respondiendo el regulador. En el AS/400, mirada en la “cola de mensaje del sysopr” para ver si hay algunos mensajes que indican un problema. Una pantalla “SYSOPR” con un error se muestra abajo.

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

Ahora en los 2522, gire el debug stun packet 1 para ver si los paquetes están consiguiendo enviaron al regulador. 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 originó en el lado AS/400 está consiguiendo a través al regulador, pero el regulador no está respondiendo, así que significa que es un problema de controlador. Una interfaz de la demostración nos muestra si todos los leads del control están para arriba 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. Podemos también ver que el router está haciendo salir los 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 regulador tiene una forma única de configurar a la dirección de sondeo, así que usted necesita verificar esto con los manuales del controlador para su regulador.

En este ejemplo, descubrimos que el regulador utilizaba a la dirección de sondeo del “DD.” Después de cambiar esto en el AS/400, la salida del debug stun packet se convierte:

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

Esta salida de los debugs 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

Ésta es la respuesta del regulador. 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 al regulador el responder (SDI) con un UA (73), así que significa que la sesión es en servicio. Después, debemos ver la desconexión el venir del AS/400 mientras que la línea fue variada apagado.

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. Lo que sigue es una tabla con los valores necesarios para hacer el debug de estos problemas.

Campo de control - Innumerable (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 - Supervisor (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.

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

En contraste con el STUN Básico, ATURDA EL SDLC requiere que usted especifica a la dirección de sondeo correcta o el router ni siquiera verá los paquetes venir adentro. Esta es la razón por la cual el STUN Básico se utiliza a veces para encontrar a la dirección de sondeo cuando usted no tiene la información, o no puede conseguir al host o al AS/400. El diagrama antedicho muestra un escenario multipunto con el Local-ack.

En un entorno Point-to-Point tradicional, la interrogación va End to End. 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, usted tiene que aseegurarse que las estaciones están siguiendo el protocolo SDLC.

Primero, verifique que usted esté en el correcto ATURDA el papel. Los AS/400 tienen problema que negocia el papel con el regulador en los entornos Point-to-Point tradicionales. La descripción de la línea se muestra a continuación.

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

Esto nos indica que la interfaz del router debe configurarse para un rol secundario. Marque la línea y verifiquela siempre que es *PRI, porque el AS/400 omite el *NEG cuando usted lo crea. El NRZI se fija al *YES, así que usted necesita cifrar la NRZI-codificación. También, las marcas de carácter inactivo del código y fijan la ventana a un (1) usando SDLC k 1. (refiera a la alerta de campo FNA-IOS-0696-02 para una descripción profundizada de porqué las marcas de carácter inactivo se requieren en la interfaz.) Esta codificación se muestra abajo:

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: El cronometrar que el router proporciona es independiente del parámetro de la velocidad de línea que se configura en la línea AS/400. (Este parámetro se utiliza para los cálculos de rendimiento; puede ser dejado en el valor por defecto de 9600.) El identificador del intercambio que se configura en la línea es el del AS/400, tal como el XID que el AS/400 enviará. 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.

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

Podemos ver que el primer regulador va a ser un PU2.1 porque la categoría del regulador es “*APPC.” Ésta es la abreviatura para las comunicaciones anticipadas del Programa-a-programa, que pueden solamente ser realizadas vía una conexión T2.1. El identificador de la red remota se relaciona con el APPN/APPC y se refiere otra vez como el “NETID.” El “*NETATR” es un parámetro que especifica usando el NETID definido en la área de datos llamada los “atributos de red.” Puede mostrar esta área de información utilizando el comando DSPNETA y sustituir los valores, si corresponde. La “punta teledirigida” o “CP_name” es el nombre de punto de control que usted configuró en el PU2.1. En este caso, es CP5494. Rol del link de datos puede ser ido como *NEG. Las necesidades de la “dirección de estación” de hacer juego el “SDLC address DD” que fue configurado en la interfaz secundaria así como 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.

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

En esta pantalla, el segundo regulador (PU) es realmente 3174, que es un tipo-2 PU. El XID configurado en estos 3174 es 05600001. La “dirección de estación”, o el SDLC address, siendo utilizado es 01. Usted necesita un “SDLC address el 01" configurado en la interfaz secundaria y uno de las interfaces de remote primary. Como usted puede ver abajo, la configuración para un PU2 está menos implicada que un 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.

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

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. El, así como el resto de la configuración APPN-específica, se pueden encontrar en la segunda pantalla de configuración en los 5494. El nombre de la punta de control local del AS/400 es el "RTP400A." que el nombre LU del AS/400 es el "LU9404;" éste necesita hacer juego para arriba con qué se configura en el campo del partner 5494's definición de LU. La Descripción del modo que está siendo utilizada por las 5494 necesidades de hacer juego cuál está en la Descripción del dispositivo. Por ejemplo, si el dispositivo dice el “*NETATR,” entonces necesita hacer juego el valor por defecto del “ESPACIO EN BLANCO”.

A continuación se muestra la descripción del dispositivo APPC creada para 5494.

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

Esta pantalla muestra que la Descripción del dispositivo para los 5494 tiene un nombre del telecontrol CP del "CP5494;" que ésta necesita hacer juego qué se configura en los 5494. El NETID y la ubicación local han omitido el “*NETATR,” que fueron cifrados al LU9404 y al NETA en el ejemplo anterior. Una vez más este necesidad de hacer juego el nombre del partner LU y los campos NETID en los 5494.

A continuación se muestra la última parte de la configuración de dispositivo que se debe realizar para establecer una conexión.

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

Esta pantalla muestra que el modo que es utilizado 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. Éste es uno de los modos predeterminados suministrados por IBM como parte del soporte APPN bajo en el AS/400. Si usted ve cualquier cosa diferente, entre en contacto IBM, porque se están ejecutando con una Descripción del modo que crearon. Este ejemplo establece una conexión básica; si usted quiere visualizar la información sobre los modos disponibles usted puede utilizar el comando WRKMODD o las descripciones del modo de trabajo.

La descripción del modo se muestra a continuación.

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

Esta pantalla identifica claramente las definiciones del modo suministradas 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 la multicaída, un AS/400 se comporta diferentemente de otros dispositivos de IBM. Considerando que un FEP valida los caracteres caracteres 0x7E (indicadores) o 0xFF (marcas) como espacio “ocioso” entre los indicadores de las tramas, de las invitaciones un AS/400 y las marcas diferentemente. Sólo se interpreta una marca como un carácter inactivo. Un indicador se interpreta para significar que la “línea es todavía activa - más datos están pendientes.” Un router Cisco puede ser configurado para enviar los indicadores o las marcas pero no ambas. No alternarán entre los dos para reflejar la línea estado. El valor por defecto está para que el router envíe los indicadores.

Esta diferencia plantea un problema en los entornos de la multicaída del duplex lleno. El AS/400 va normalmente del dispositivo al dispositivo, sondeando cada uno para los datos. Si un dispositivo no puede responder y el AS/400 piensa que la línea es todavía activa, reajustará la línea entera. 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 se aprovecha de la lógica AS/400 que interpreta la ausencia de portadora para significar la “línea ociosa estado.” Por lo tanto, con la modificación, un AS/400 detecta siempre la línea ociosa estado sin importar los caracteres de la inter-trama que son enviados por el router. Así pues, si un dispositivo secundario no puede responder, el AS/400 marcará el CD, verá una línea ociosa y se moverá encendido para sondear la estación siguiente.

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 este arreglo instalado, un AS/400 ignora totalmente el estado de las líneas de caídas múltiples dúplexes del CD encendido por completo -. Como consecuencia, la modificación del cable Cisco es no más eficaz en la prevención de la línea periódica restauraciones.

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 los cambios de configuración al router conectado con el AS/400.

Opción 1

Cambie el carácter inactivo SDLC del carácter predeterminado del indicador a un carácter de la 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 con el AS/400. Este comando hará al router transmitir siempre los caracteres de la marca para una pausa entre las 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 reconocerá solamente la primera trama, incluso si el bit de consulta/final es 0. Después ignorará todas las tramas subsiguientes y sondeará el próximo dispositivo que causa las retransmisiones de la trama innecesaria. 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 admite en la versión 10.0(5.2) y posteriores del IOS de Cisco y funciona en los routers 2500, 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á al router responder con una trama del “Disconnect Mode” (DM) para cualquier dispositivo secundario inactivo sondeado por el AS/400. El AS/400 entonces procederá a sondear el próximo dispositivo sin el reajuste de la línea.

Nota: Este comando se soporta en el Cisco IOS 11.1, 11.0(3.1) y posterior o 10.3(7.2) y posterior.

Consejo: Si usted experimenta cualesquiera problemas que sacan a colación la línea multipunto con la respuesta rápida configurada, utilice la opción 1. El código del stun quick-response en el router es parte de la máquina de estados finitos para el Local-ack, que pueden salir del paso con algo de pus. Probamos el código en el laboratorio y verificamos su interoperabilidad con el 5494, 5394 y Perl494E. Es posible ejecutarse en los problemas si el PU que usted está intentando asociar tiene temporizadores fijados diferentemente de lo que está esperando el quick_response.


Información Relacionada


Document ID: 16398