Contenido

Introducción

Prerequisites

Requirements

Componentes Utilizados

Convenciones

Ethernet

QLLC

Descripción general de la instrumentación de QLLC y los flujos de mensajes

Conexión QLLC normal para una PU 2.0, iniciada por el dispositivo X.25

Conexión QLLC Normal PU 2.0 Iniciada por un Dispositivo de LAN PU 2.0 a FEP Ejecutando la Interfaz de Switching por Paquetes NCP

Conexión QLLC normal para una PU 2.1, iniciada por un dispositivo X.25

Conexión QLLC PU 2.1 iniciada por dispositivo de LAN

Ejemplo de configuración y depuración de DLSw/SDLC en conexión QLLC

Pasos para la resolución de problemas

Depuraciones QLLC

Información Relacionada

Introducción

Este documento explica cómo implementar Qualified Logical Link Control (QLLC) en routers Cisco y flujos de mensajes para una conexión de llamada en una topología donde un Procesador frontal (FEP) está conectado a través de Ethernet y donde los dispositivos remotos (unidad física [PU] de tipo 2.0 o PU de tipo 2.1) están conectados a la red X.25. También trata los pasos adecuados para resolver problemas de este tipo de conexión de llamada.

Prerequisites

Requirements

No hay requisitos específicos para este documento.

Componentes Utilizados

Este documento no se limita a una versión específica de software o de hardware.

Convenciones

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Ethernet

Cuando está solucionando problemas con un dispositivo conectado a Ethernet que se comunica a través del switching de link de datos (DLSw), lo primero que debe verificar es que dlsw bridge-group x existe, donde x se refiere al número de puente configurado en el comando bridge-group en la interfaz Ethernet. Para verificar su configuración, consulte Configuraciones básicas de DLSw+ para configuraciones de ejemplo en dispositivos conectados a Ethernet.

Otro comando útil para la resolución de problemas es el show bridge, que verifica que el puente transparente conozca la dirección MAC local y remota del dispositivo. Las direcciones Ethernet MAC aparecen en formato canónico, a diferencia de las direcciones Token Ring que tienen formato no canónico. Utilice la siguiente pauta para traducir las direcciones MAC:

Dirección MAC Ethernet (formato canónico)

0 1 2 3 4 5 6 8 9

se convierte en

Dirección de Token Ring (formato no canónico)

0 8 4 C 2 A 6 E 1 9 5 D 3 B 7

Este es un ejemplo, en Ethernet, que sigue la regla:

1. Dirección MAC Ethernet (formato canónico)

0200.4556.1140

2. Paso intermedio

0400.2AA6.8820

3. Dirección Token Ring final (formato no canónico)

4000.A26A.8802

Nota: Para llegar a la dirección final, no canónica, se cambia alrededor de cada bit dentro de un byte.

Compare las entradas que se encuentran en el resultado del comando show bridge con las entradas que se encuentran en el resultado del comando show dlsw reachability. Recuerde que las entradas en la salida del comando show dlsw reachability aparecen en formato no canónico, a diferencia del formato canónico como en Ethernet o en la salida del comando show bridge.

Para la resolución general de problemas de Ethernet, consulte Resolución de problemas de Ethernet.

QLLC

Nota: La sección Contenido del documento de esta serie de documentos muestra todas las secciones de la serie, para ayudar a la navegación.

Descripción general de la instrumentación de QLLC y los flujos de mensajes

Los comandos QLLC se implementan en los paquetes X.25 mediante el bit Q. Los paquetes X.25 que contienen primitivas QLLC suelen tener cinco bytes, o la longitud del encabezado de paquete X.25 más dos bytes de información de control QLLC.

Nota: Los paquetes de datos X.25 que contienen datos de la arquitectura de red de sistemas (SNA) no utilizan el bit Q.

Después del establecimiento de la conexión QLLC, se utiliza el único circuito virtual de la conexión X.25 para reenviar el tráfico de datos. El Logical Link Control (LLC) es un subconjunto del High-Level Data Link Control (HDLC). El control de link de datos sincrónico (SDLC) y QLLC también son subconjuntos de HDLS. Cisco convierte estas primitivas de QLLC en primitivas de LLC y viceversa:

QLLC

LLC

QSM

SABME

QXID

XID

QDISC

DISCO

QUA

UA

PAQUETE DE DATOS X.25

I-FRAME

Conexión QLLC normal para una PU 2.0, iniciada por el dispositivo X.25

Figura 1?? Flujos QLLC para PU 2.0

Se inicia una conexión QLLC/LLC normal con la recepción de una LLAMADA ENTRANTE X.25, que contiene los datos de usuario de llamada QLLC (CUD) (0xc3). Una conexión QLLC inversa es una conexión QLLC/LLC iniciada por una LAN.

Nota: Para una conexión QLLC/LLC, hay una conexión QLLC entre el dispositivo QLLC y el router, y una conexión LLC entre el dispositivo conectado a LAN y el router.

La figura 1 muestra esta secuencia:

1. Una llamada entrante X.25 QLLC recibe la respuesta X.25 CALL CONNECTED por parte del router.

2. A continuación, el router envía una trama TEST (o explorador) al dispositivo LAN para iniciar la conexión LAN.

3. Si el socio de la LAN puede reubicarse, enviará una respuesta de explorador con un campo de información de ruteo (RIF) que explica cómo encontrar al socio LAN.

4. A continuación, el router envía una identificación de intercambio nulo (XID) al partner LAN, bajo la suposición de que el dispositivo QLLC puede realizar la negociación XID. (La mayoría de los dispositivos SNA pueden realizar la negociación XID.) Si el dispositivo QLLC no puede realizar la negociación por sí solo, el router ofrece una utilidad de proxy XID.

5. El dispositivo QLLC envía un XID con un IDBLK e IDNUM que se compara con el IDNUM e IDBLK configurados en el host (nodo principal conmutado???PU).

6. Si los ID coinciden, el host envía un modo equilibrado síncrono extendido (SABME).

7. El SABME se convierte en un modo de respuesta de configuración cualificada (QSM) y el dispositivo QLLC envía un confirmación no numerado calificado (QUA).

8. Esta QUA se convierte en un Reconocimiento no numerado (UA) de LLC y se envía al partner de LAN.

En este punto, existe una conexión QLLC entre el dispositivo QLLC y el router, existe una conexión LLC entre el router y el dispositivo LAN, y existe una conexión QLLC/LLC activa en el router.

Conexión QLLC Normal PU 2.0 Iniciada por un Dispositivo de LAN PU 2.0 a FEP Ejecutando la Interfaz de Switching por Paquetes NCP

En un entorno Token Ring o de conexión en puente de ruta de origen remota (RSRB), se produce esta secuencia:

1. El dispositivo conectado a LAN se inicia y envía una prueba ascendente. Luego, envía un paquete XID nulo ascendente.

2. Si QLLC reenvía este XID nulo a un FEP conectado a X.25, el FEP responde como si se estuviera conectando a un dispositivo PU 2.1 y anula la conexión, cuando el dispositivo PU 2.0 luego envía un XID Format 0 Type 2.

3. El comando qllc npsi-poll intercepta cualquier paquete XID nulo que el IOS de Cisco?? el software se recibe en la interfaz LAN y devuelve una respuesta XID nula al dispositivo de flujo descendente. El comando qllc npsi-poll sigue para permitir los paquetes XID Formato 3 y XID Formato 0 a través del dispositivo X.25.

4. El router envía un paquete CALL REQUEST para iniciar la conexión X.25 y recibe el paquete CALL ACCEPTED en respuesta.

5. El dispositivo PU 2.0 SNA envía un XID con un IDBLK e IDNUM que se compara con el IDBLK e IDNUM que se configura en el host (nodo principal conmutado???PU).

6. Si las ID coinciden, el host envía un QSM. El QSM se convierte en un SABME.

7. El dispositivo de LAN responde con un UA, que es convertido en un QUA y enviado al FEP.

En este momento, hay:

- Una conexión QLLC entre el dispositivo QLLC y el router

- ‘Una conexión LLC entre el router y el dispositivo de LAN

- Una conexión QLLC/LLC activa en el router

Conexión QLLC normal para una PU 2.1, iniciada por un dispositivo X.25

Figura 2?? Flujos QLLC para PU 2.1

Se inicia una conexión QLLC/LLC normal con la recepción de una LLAMADA ENTRANTE X.25 que contiene el CUD QLLC (0xc3). Una conexión QLLC inversa es una conexión QLLC/LLC que inicia una LAN.

La figura 2 muestra esta secuencia:

1. Una llamada entrante X.25 QLLC recibe la respuesta X.25 CALL CONNECTED por parte del router.

2. El router envía una trama TEST (o explorador) al dispositivo LAN para iniciar la conexión LAN.

3. Si se puede localizar al partner LAN, el partner de LAN envía una respuesta del explorador, con un RIF que explica cómo se puede encontrar.

4. Luego, el router envía un XID nulo al socio LAN, bajo la suposición de que el dispositivo QLLC puede realizar la negociación XID. (La mayoría de los dispositivos SNA pueden realizar la negociación XID.) Si el dispositivo QLLC no puede realizar la negociación por sí solo, el router ofrece una utilidad de proxy XID.

5. Los dispositivos PU 2.1 intercambian XID3 hasta que se ponen de acuerdo en los roles primario y secundario y otros parámetros PU 2.1.

6. El nodo PU 2.1 que se convierte en el principal establece la conexión de nivel de link con su partner PU 2.1.

7. SABME se convierte en un QSM, y QUA en un UA.

Conexión QLLC PU 2.1 iniciada por dispositivo de LAN

1. La LAN PU 2.1 se inicia y envía una trama de prueba. Cuando recibe una respuesta de prueba del router, comienza a enviar un XID3 (o un XID nulo seguido de un XID3).

2. El router envía un paquete CALL REQUEST para establecer la conexión X.25. A partir de este punto, traduce todos los mensajes que se intercambian entre los dos nodos PU 2.1 de LLC2 a X.25.

3. Los dispositivos PU 2.1 intercambian XID3 hasta que se ponen de acuerdo en los roles primario y secundario y otros parámetros PU 2.1.

4. El nodo PU 2.1 que se convierte en el principal establece la conexión de nivel de link con su partner PU 2.1.

5. SABME se convierte en un QSM, y QUA en un UA.

En este momento, hay:

- Una conexión QLLC entre el dispositivo QLLC y el router

- ‘Una conexión LLC entre el router y el dispositivo de LAN

- Una conexión QLLC/LLC activa en el router

Ejemplo de configuración y depuración de DLSw/SDLC en conexión QLLC

Existen diferencias importantes entre RSRB sobre QLLC y DLSw sobre QLLC. Quizás lo más importante es que existe una interfaz uniforme (Cisco Link Services [CLS]) entre DLSw y los diversos Controles Data-Link (DLC) disponibles.

Antes de intentar cualquiera de los comandos debug en este documento, consulte Información Importante sobre Comandos Debug.

Cuando está resolviendo problemas en el router QLLC, se recomienda el resultado de estos comandos debug:

- debug dlsw core message

- debug cls message

- debug x25 event

- debug qllc state

- debug qllc packet

La salida de estos comandos show también es útil:

- show cls

- show qllc

En el router de par SDLC/DLSw, estos comandos debug son útiles:

- debug dlsw core message

- debug cls message

Figura 3?? Configuración y Depuraciones de QLLC/DLSw

Este diagrama de red utiliza estas configuraciones:

- Konjack

- Pivo

Konjack

X25 routing

dlsw local-peer peer-id 10.3.2.7

dlsw remote-peer 0 tcp 10.3.2.8

!

interface Serial3

encapsulation x25 dce

x25 address 9111

x25 ltc 10

x25 htc 4095

x25 map qllc 4000.0000.1111  1111

clockrate 19200

qllc dlsw vmacaddr 4000.0000.1111 partner 4000.0000.2222

Pivo

x25 routing

!

dlsw local-peer peer-id 10.3.2.8

dlsw remote-peer 0 tcp 10.3.2.7

!

interface serial 0

no ip address

encapsulation x25 dce

x25 address 4444

x25 map qllc 4000.0000.2222 4444

qllc dlsw vmac 4000.0000.2222 partner 4000.0000.1111

La figura 3 ilustra cómo dos servidores IBM AS/400 pueden comunicarse a través de QLLC/DLSw. vmacaddr 4000.000.1111 es la dirección MAC asociada al AS/400 (POW400) y el partner 4000.000.22222 es la dirección MAC asociada al AS/400 remoto (Canopus).

Para obtener más información sobre el comando qllc dlsw, consulte Comandos de Configuración de DLSw+.

El TEST.STN REQ des DLSw a QLLC debe dar como resultado un paquete TEST.STN.IND, y el paquete REQ OPEN STN REQ debe dar como resultado un CALL REQUEST.

El siguiente ejemplo de salida muestra el resultado de la depuración con anotación. Se ejecutaron estos comandos debug:

- debug dlsw core message

- debug cls message

- debug qllc state

- debug qllc packet

- debug x25 event

Konjack#

%DLSWC-3-RECVSSP: SSP OP = 3( CUR  ) -explorer from peer 10.3.2.8(2065)

!--- CUR_ex [Can You Reach (explorer)] is received from the peer. !--- (Note the -explorer.) DLSw starts to explore.

00:27:26: DLSW: DISP Sent : CLSI Msg : TEST_STN.Req   dlen: 46

00:27:26: (DLSWDLU:DLU-->SAP):

00:27:26:       TEST_STN.Req to pSAP: 0x5C733C sel: LLC hlen: 40, dlen: 46

00:27:26: DLSW: DISP Sent : CLSI Msg : TEST_STN.Req   dlen: 46

00:27:26: (DLSWDLU:DLU-->SAP):

00:27:26:       TEST_STN.Req to pSAP: 0x5C74A0 sel: LLC hlen: 40, dlen: 46

00:27:26: DLSW: DISP Sent : CLSI Msg : TEST_STN.Req   dlen: 46

00:27:26: (DLSWDLU:DLU-->SAP):

00:27:26:       TEST_STN.Req to pSAP: 0x5C7924 sel: LLC hlen: 40, dlen: 46

!--- There is a match on the destination MAC address in QLLC.

00:27:26: (DLSWDLU:CLS-->DLU):

00:27:26:       TEST_STN.Ind to uSAP: 0x5C78BC sel: LLC hlen: 36, dlen: 35

00:27:26:  DLSW Received-ctlQ : CLSI Msg : TEST_STN.Ind   dlen: 35

!--- DLSw sends an ICR_ex [I Can Reach (explorer)] to the peer.

%DLSWC-3-RECVSSP: SSP OP = 3( CUR  )  from peer 10.3.2.8(2065)

!--- CUR_cs [Can You Reach (circuit setup)] is received from the peer.

00:27:26:  DISP Sent : CLSI Msg : REQ_OPNSTN.Req   dlen: 102

!--- DLSw sends the CLS message Request Open Station Request to QLLC.

00:27:26: (DLSWDLU:DLU-->SAP):

00:27:26:       REQ_OPNSTN.Req to pSAP: 0x5C7924 sel: LLC hlen: 48, dlen: 102

!--- QLLC places the call to the AS/400.

00:27:26: Serial3: X25 O P3 CALL REQUEST (13) 8 lci 10

00:27:26: From(4): 9111 To(4): 1111

00:27:26:   Facilities: (0)

00:27:26:   Call User Data (4): 0xC3000000 (qllc)

!--- QLLC X.25 FSM handling Request Open Station Request !--- Output: Issues CALL REQUEST (see above), !--- Nothing to CLS/DLSw !--- Starts a 10000 msec timer !--- Enters State P2 (see X.25 standard)

00:27:26: QLLC-XFSM state P1, input QX25ReqOpenStnReq: (CallReq,-,XGo 10000) ->P2/D2

!--- QLLC receives CALL ACCEPT from the AS/400.

00:27:26: Serial3: X25 I P3 CALL CONNECTED (9) 8 lci 10

00:27:26: From(4): 9111 To(4): 1111

00:27:26:   Facilities: (0)

!--- QLLC X.25 FSM handling CALL ACCEPT !--- Output: Nothing to X.25 !--- Request Open Station Confirm to CLS/DLSw !--- Stops Timer !--- Enters State P4/D1

00:27:26: QLLC-XFSM state P2/D2, input QX25CallConfirm:

(-,ReqOpenStnConf,xStop) ->P4/D1

00:27:26: QLLC: Serial3 I: QXID-CMD  0 bytes

!--- QLLC Logical FSM Receives XID, send ID Indication to DLSw

00:27:26: QLLC-LFSM state QLClosed, input QLXID:  (-,IdInd,LGo 3000)

00:27:26: (DLSWDLU:CLS-->DLU):

00:27:26: REQ_OPNSTN.Cfm(CLS_OK) to uCEP: 0x5CA310 sel: LLC hlen: 48, dlen: 102

00:27:26: (DLSWDLU:CLS-->DLU):

00:27:26:       ID.Ind to uCEP: 0x5CA310 sel: LLC hlen: 40, dlen: 15

00:27:26:  DLSW Received-ctlQ : CLSI Msg : REQ_OPNSTN.Cfm CLS_OK dlen: 102

!--- DLSw receives Request Open Station Confirm from QLLC.

%DLSWC-3-SENDSSP: SSP OP = 4( ICR  )  to peer 10.3.2.8(2065) success

!--- DLSw sends ICR_cs [I Can Reach (circuit setup)] to the peer.

%DLSWC-3-SENDSSP: SSP OP = 4( ICR  )  to peer 10.3.2.8(2065) success

!--- DLSw receives ID.Ind from QLLC.

00:27:26: DLSW Received-ctlQ : CLSI Msg : ID.Ind dlen: 15

!--- DLSw receives Reach ACK from the peer.

%DLSWC-3-RECVSSP: SSP OP = 5( ACK  )  from peer 10.3.2.8(2065)

!--- DLSw receives XID from the peer.

%DLSWC-3-RECVSSP: SSP OP = 7( XID  )  from peer 10.3.2.8(2065)

!--- DLSw sends ID.Req to QLLC.

00:27:26:  DISP Sent : CLSI Msg : ID.Req   dlen: 12

00:27:26: (DLSWDLU:DLU-->CEP):

00:27:26:       ID.Req to pCEP: 0x4C51CC sel: LLC hlen: 40, dlen: 12

00:27:26: QLLC: Serial3 O: QXID-RSP  0 bytes

!--- QLLC Logical FSM Handling ID.Req from CLS/DLSw. !--- Output: QLLC XID to X.25 !--- Nothing to CLS !--- No Timer Action

00:27:26: QLLC-LFSM state QLClosed, input CLSXID:  (XId,-,-)

!--- QLLC Receives XID from X.25

00:27:26: QLLC: Serial3 I: QXID-CMD  77 bytes Fmt 3T2: 056B4532

00:27:26: QLLC-LFSM state QLClosed, input QLXID:  (-,IdInd,LGo 3000)

00:27:26: (DLSWDLU:CLS-->DLU):

00:27:26:       ID.Cfm(CLS_OK) to uCEP: 0x5CA310 sel: LLC hlen: 40, dlen: 92

!--- DLSw receives ID Confirm from QLLC.

00:27:26: DLSW Received-ctlQ : CLSI Msg : ID.Cfm CLS_OK dlen: 92

!--- DLSw sends XID to the peer.

%DLSWC-3-SENDSSP: SSP OP = 7( XID  )  to peer 10.3.2.8(2065) success

!--- DLSw receives XID from the peer.

%DLSWC-3-RECVSSP: SSP OP = 7( XID  )  from peer 10.3.2.8(2065)

00:27:27:  DISP Sent : CLSI Msg : ID.Req   dlen: 89

00:27:27: (DLSWDLU:DLU-->CEP):

00:27:27:       ID.Req to pCEP: 0x4C51CC sel: LLC hlen: 40, dlen: 89

00:27:27: QLLC: Serial3 O: QXID-RSP  77 bytes Fmt 3T2: 05627844

00:27:27: QLLC-LFSM state QLClosed, input CLSXID:  (XId,-,-)

00:27:27: QLLC: Serial3 I: QXID-CMD  77 bytes Fmt 3T2: 056B4532

!--- QLLC Logical FSM Handling ID.Req from CLS. !--- Output: Nothing to CLS !--- QLLC XID to X.25 !--- Timer started for 3000 msec

00:27:27: QLLC-LFSM state QLClosed, input QLXID:  (-,IdInd,LGo 3000)

!--- More XID negotiation.

00:27:27: (DLSWDLU:CLS-->DLU):

00:27:27:       ID.Cfm(CLS_OK) to uCEP: 0x5CA310 sel: LLC hlen: 40, dlen: 92

00:27:27:  DLSW Received-ctlQ : CLSI Msg : ID.Cfm CLS_OK dlen: 92

%DLSWC-3-SENDSSP: SSP OP = 7( XID  )  to peer 10.3.2.8(2065) success

%DLSWC-3-RECVSSP: SSP OP = 7( XID  )  from peer 10.3.2.8(2065)

00:27:30:  DISP Sent : CLSI Msg : ID.Req   dlen: 12

00:27:30: (DLSWDLU:DLU-->CEP):

00:27:30:       ID.Req to pCEP: 0x4C51CC sel: LLC hlen: 40, dlen: 12

00:27:30: QLLC: Serial3 O: QXID-RSP  0 bytes

00:27:30: QLLC-LFSM state QLClosed, input CLSXID:  (XId,-,-)

00:27:30: QLLC: Serial3 I: QXID-CMD  77 bytes Fmt 3T2: 056B4532

00:27:30: QLLC-LFSM state QLClosed, input QLXID:  (-,IdInd,LGo 3000)

00:27:30: (DLSWDLU:CLS-->DLU):

00:27:30:       ID.Cfm(CLS_OK) to uCEP: 0x5CA310 sel: LLC hlen: 40, dlen: 92

00:27:30:  DLSW Received-ctlQ : CLSI Msg : ID.Cfm CLS_OK dlen: 92

%DLSWC-3-SENDSSP: SSP OP = 7( XID  )  to peer 10.3.2.8(2065) success

%DLSWC-3-RECVSSP: SSP OP = 7( XID  )  from peer 10.3.2.8(2065)

00:27:30:  DISP Sent : CLSI Msg : ID.Req   dlen: 89

00:27:30: (DLSWDLU:DLU-->CEP):

00:27:30:       ID.Req to pCEP: 0x4C51CC sel: LLC hlen: 40, dlen: 89

00:27:30: QLLC: Serial3 O: QXID-RSP  77 bytes Fmt 3T2: 05627844

00:27:30: QLLC-LFSM state QLClosed, input CLSXID:  (XId,-,-)

00:27:30: QLLC: Serial3 I: QXID-CMD  77 bytes Fmt 3T2: 056B4532

00:27:30: QLLC-LFSM state QLClosed, input QLXID:  (-,IdInd,LGo 3000)

00:27:30: (DLSWDLU:CLS-->DLU):

00:27:30:       ID.Cfm(CLS_OK) to uCEP: 0x5CA310 sel: LLC hlen: 40, dlen: 92

00:27:30:  DLSW Received-ctlQ : CLSI Msg : ID.Cfm CLS_OK dlen: 92

%DLSWC-3-SENDSSP: SSP OP = 7( XID  )  to peer 10.3.2.8(2065) success

%DLSWC-3-RECVSSP: SSP OP = 7( XID  )  from peer 10.3.2.8(2065)

00:27:30:  DISP Sent : CLSI Msg : ID.Req   dlen: 89

00:27:30: (DLSWDLU:DLU-->CEP):

00:27:30:       ID.Req to pCEP: 0x4C51CC sel: LLC hlen: 40, dlen: 89

00:27:30: QLLC: Serial3 O: QXID-RSP  77 bytes Fmt 3T2: 05627844

00:27:30: QLLC-LFSM state QLClosed, input CLSXID:  (XId,-,-)

!--- AS/400 becomes primary and sends QSM to QLLC.

00:27:30: QLLC: Serial3 I: QSM

!--- QLLC Logical FSM Handling QSM. !--- Output: Nothing !--- Connect.Ind to CLS/DLSw !--- Start Timer for 3000 msec !--- State QLogical Remote Opening

00:27:30: QLLC-LFSM state QLClosed, input QLSM:

(-,ConnInd,LGo 3000) ->QLRemoteOpening

00:27:30: (DLSWDLU:CLS-->DLU):

00:27:30:       CONNECT.Ind to uCEP: 0x5CA310 sel: LLC hlen: 40, dlen: 8

!--- DLSw receives CONNECT.Ind from QLLC and sends CON.Req to the peer.

00:27:30:  DLSW Received-ctlQ : CLSI Msg : CONNECT.Ind   dlen: 8

%DLSWC-3-SENDSSP: SSP OP = 8( CONQ )  to peer 10.3.2.8(2065) success

!--- DLSw receives CON.Response from the peer and sends Connect Response to QLLC.

%DLSWC-3-RECVSSP: SSP OP = 9( CONR )  from peer 10.3.2.8(2065)

00:27:30:  DISP Sent : CLSI Msg : CONNECT.Rsp   dlen: 20

00:27:30: (DLSWDLU:DLU-->CEP):

00:27:30:       CONNECT.Rsp to pCEP: 0x4C51CC sel: LLC hlen: 42, dlen: 20

!--- QLLC Handling Connect Response from CLS/DLSw. !--- Output: QUA to X.25 !--- Conected.Ind to CLS/DLSw !--- State to QLOpened

00:27:30: QLLC: Serial3 O: QUA

00:27:30: QLLC-LFSM state QLRemoteOpening,

input ConnectResponse:  (UA,ConnectedInd,lStop) ->QLOpened

00:27:30: (DLSWDLU:CLS-->DLU):

00:27:30:       CONNECTED.Ind to uCEP: 0x5CA310 sel: LLC hlen: 40, dlen: 8

00:27:30:  DLSW Received-ctlQ : CLSI Msg : CONNECTED.Ind   dlen: 8

Konjack# show dls reach

DLSw MAC address reachability cache list

Mac Addr        status     Loc.    peer/port            rif

4000.0000.1111  FOUND      LOCAL   P003-S000     --no rif--

4000.0000.2222  FOUND      REMOTE  10.3.2.8(2065)

!--- 4000.0000.2222 was the partner.

Pasos para la resolución de problemas

Esta sección detalla algunos de los comandos show que se pueden ejecutar en el router que ejecuta QLLC/DLSw.

Para eliminar la posibilidad de que el problema esté relacionado con el hardware, ejecute estos comandos:

- show interface serial 0

- show controllers serial 0

- show controllers cbus

Verifique la configuración del router: Dirección X.121, tamaño de paquete, número de módulo, circuitos virtuales permanentes (PVC), circuitos virtuales conmutados (SVC) y parámetros de Protocolo de acceso a link equilibrado (LAPB) (como el tamaño de ventana y módulo).

- Ejecute el comando show interface serial en la línea X.25 para ver el estado de la línea y el protocolo. Línea inactiva, protocolo inactivo (el DTR está inactivo).

- Emita el comando show controller serial y observe la parte superior del resultado. ¿Muestra el cable correcto?

Debe ver DCE-RS-232 o DCE-V.35 para los routers DCE (el router emula un módem con el comando clockrate).

Debería ver DTE-RS-232 o DTE-V.35 para los routers DTE (el router se conecta a un dispositivo DCE, como un módem o un router que emula un módem).

Verifique el equipo conectado, incluso la placa serial, los módems, el dispositivo remoto y el cableado. Cuando compruebe el cableado, asegúrese de lo siguiente:

- El cable que provee Cisco se conecta a la interfaz correcta en el dispositivo remoto.

- Si el router es el DCE, el cable del router se conecta al cable del dispositivo DTE.

- Si la línea está activa y el protocolo está inactivo, determine si la interfaz del router es un DCE o DTE. El DCE proporciona el reloj.

- Si la interfaz del router es un DCE, ¿tiene el comando de ritmo del reloj configurado?

- ¿Ha configurado para encapsulación X.25?

- Ejecute el comando de show interface serial 0. ¿El estado del LARB es CONNECT?

- ¿Ambos lados están configurados para semidúplex o dúplex completo?

- Si la línea está activa y el protocolo está activo, ¿son correctos los parámetros de configuración de X.25 y LAPB? Estos parámetros deben coincidir con los definidos para el proveedor X.25.

- Asegúrese de que estos parámetros X.25 sean correctos:

- especificación de dirección X.121

- ¿Tamaño de paquetes de entrada y salida (x25 ips y x25 ops)???el valor predeterminado es 128 bytes.

- Tamaño de ventana (x25 wout y x25 win)???el valor predeterminado es 2.

- X.25 modulo???el valor predeterminado es 8.

- Verifique el valor QLLC del paquete más grande (el valor predeterminado es 256). Este valor coincide con el valor configurado en el dispositivo SNA remoto. El intervalo válido es de 0 a 1024.

- Asegúrese de que estos parámetros del LAPB sean correctos:

- Tamaño de la ventana LAPB (k)

- Temporizador de reconocimiento (T1) de LAPB

- módulo LAPB

- Los VMAC de QLLC (direcciones MAC virtuales) se asignan correctamente a las direcciones X.121

¿Es el número en el campo Set Asynchronous Balance Mode (SABM) (establecer modo de equilibrio asincrónico) mayor que diez? Controle la salida del comando show interface serial para el campo de pedidos SABM. Siempre debe haber al menos un SABM, pero hasta diez como máximo. Si hay más de diez SABM, es probable que el switch de paquetes no responda.

Revise los módems, cables y conexiones al nodo X.25. Llame al proveedor de X.25 para verificar la configuración y el estado del nodo X.25. ¿Puede utilizar ???? loopback?? para comprobar si hay un problema de conexión.

Ejecute el comando show interface serial varias veces. En cualquiera de los campos siguientes, ¿los números aumentan o son grandes? Considere que la carga es grande si representa más del 0.5% de la cantidad de tramas de información. Los números grandes de estos campos indican que existe un posible problema en algún lugar del proveedor de red X.25 (en cuyo caso, la calidad de la línea debe ser verificada):

- Número de rechazos (REJ)

- Cantidad de Eventos de receptor no preparado (RNR)

- Cantidad de errores de protocolo de tramas (FRMR)

- Número de reinicios (RESTARTs)

- Cantidad de desconexiones (DISC)

Si se utilizan subdirecciones, asegúrese de que se incluyen estas sentencias de configuración:

x25 routing x25 route ^xxx.*alias serial 0 - ?

!--- Your interface number could be different.

!

x25 routing

!--- Enables x25 switching.

!

x25 route

!--- Add an entry to the X.25 routing table.

!

interface serial y

x25 alias ^xxx.*

xxx indica la dirección serial 0 de la interfaz del router X.25.

Si utiliza QLLC invertida???donde un dispositivo PU 2.0 LAN se comunica con un IBM FEP que ejecuta el software NCP Packet Switching Interface (NPSI) X.25???, agregue estos parámetros de configuración a la serie 0:

1. El comando npsi-poll no permite que se envíen XID nulos al FEP. Habilita una conexión entre un PU 2.0 en el lado LAN y un FEP que ejecuta NPSI. Este comando es necesario porque, en un entorno Token Ring o RSRB, los dispositivos conectados a la LAN comienzan enviando un paquete XID nulo ascendente. Si el software Cisco IOS reenvía este XID nulo a un FEP conectado a X.25, entonces el FEP responde como si se estuviera conectando a un dispositivo PU 2.1 y rompe la conexión cuando el PU 2.0 luego envía un XID Format 0 Type 2.

2. El comando qllc npsi-poll intercepta cualquier paquete XID nulo que el software reciba en la interfaz LAN y devuelve una respuesta XID nula al dispositivo de flujo descendente. Continúa para permitir paquetes XID Formato 3 y XID Formato 0 a través del dispositivo X.25.

¿Utiliza PVC y SVC? Las especificaciones del canal del PVC deben ser menores que cualquier rango del SVC. El valor predeterminado es un intervalo bidireccional entre 1 y 1024, por lo que se debe elevar el valor de circuito bidireccional (LTC) más bajo para definir cualquier PVC. Consulte a su proveedor X.25 y vuelva a configurar los circuitos virtuales para que coincidan con los requisitos.

¿Se configuran los SVC X.25 en este orden?

1. Todos los circuitos entrantes unidireccionales.

2. Todos los circuitos bidireccionales.

3. Todos los circuitos de salida unidireccionales.

Puede ejecutar estos comandos para verificar los parámetros y el estado de la conexión:

- show llc2

- show x25 map

- show x25 vc

- show qllc

Depuraciones QLLC

Antes de intentar cualquiera de los comandos debug en este documento, consulte Información Importante sobre Comandos Debug.

Si el protocolo X.25 Layer 2 LAPB????en la salida del comando show interface serial???no está en estado CONNECT, ejecute este comando:

- debug lapb

Cuando esté resolviendo problemas de QLLC, ejecute estos comandos debug:

- debug qllc error

- debug qllc event

- debug qllc packet

- debug qllc state

- debug qllc timer

- debug qllc x25

- debug x25 all

- debug x25 events

El comando debug x25 vc muestra información sobre el tráfico para un circuito virtual determinado. Modifica la operación de los comandos debug x25 all o debug x25 events, de modo que uno de esos comandos se debe ejecutar con debug x25 vc, para producir resultados.

Para el router peer DLSw, estos comandos debug son útiles:

- debug dlsw core message

- debug cls message

La salida de estos comandos show también es útil:

- show cls

- show qllc

El siguiente resultado de ejemplo corto es de un inicio QLLC bajo estas circunstancias:

- Una PU 2.0 tonta está conectada coaxialmente a un controlador de establecimiento IBM 3174.

- El 3174 tiene una conexión QLLC hacia un router.

- El socio LAN es un Controlador de comunicación de IBM 3745 y PU está realizando la emulación 3270.

Nota: Para obtener una explicación más detallada de los parámetros y estados X.25, refiérase a las especificaciones de las normas internacionales X.25 en el Directorio de Protocolos.

Serial0: I X25 P1 CALL REQUEST (11) 8 lci 20

From(8): 06431743 To(2): 64

Facilities (0)

Call User Data (1): 0xC3 (qllc)

Serial 0: X25 O P4 CALL CONNECTED (5) 8 lci 20

From(0): To(0):

Facilities: (0)

QLLC: allocating new qllc lci 20

QLLC: tx POLLING TEST, da 4000.3172.0002,sa 4000.011c.3174

QLLC: rx explorer response, da 4000.011c.3174, sa c000.3172.0002,

rif 08B0.1A91.1901.A040

QLLC: gen NULL XID, da c000.3172.0002, sa 4000.011c.3174,

rif 0830.1A91.1901.A040, dsap 4, ssap 4

QLLC: rx XID response, da 4000.011c.3174, sa c000.3172.0002,

rif 08B0.1A91.1901.A040

Serial0 QLLC O: ADM XID

Serial0: X25 O P4 DATA (5) Q 8 lci 20 PS 0 PR 0

Serial0: X25 I P4 RR (3) 8 lci 20 PR 1

Serial0: X25 I D1 DATA (25) Q 8 lci 20 PS 0 PR 1

Serial0 QLLC I: QXID-RSPQLLC: addr 01, ctl BF

QLLC: Fmt 1T2: 01731743

QLLC: 4000.011c.3174DISCONNECT net <-SABME (NONE)6F

QLLC: QLLC_OPEN : VMAC 4000.011C.3174

SERIAL0 QLLC O: QSM-CMD

SERIAL0: X25 O D1 DATA (5) Q 8 LCI 20 PS 1 PR 1

Estas son algunas explicaciones de ese resultado:

- I???Un paquete de entrada.

- P1???Un estado X.25.

- ¿SOLICITUD DE LLAMADA???Un paquete DTE X.25 a DCE que inicia la conexión X.25.

- (11)??? La longitud del paquete, en bytes.

- 8???Indica módulo 8.

- lci 20???El número de canal lógico X.25 utilizado por esta conexión.

- De (8): 06431743???Dirección de llamada de ocho bytes.

- A(2): 64???Dirección llamada de dos bytes.

- (0)???Indica que no se utilizan instalaciones.

- (1): 0xC3???Un byte de datos de usuario X.25, que indica una conexión QLLC

Información Relacionada

- Resolución de problemas de DLSw

- Compatibilidad con DLSw y DLSw+

- Soporte de la Tecnología

- Soporte de Producto

- Soporte Técnico - Cisco Systems