Óptica : Red óptica síncrona (SONET)

Resolución de problemas "el protocolo de línea no funciona" en las interfaces POS

31 Julio 2013 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (19 Mayo 2006) | Comentarios


Contenido


Introducción

Este documento describe cómo resolver problemas de una interfaz de router POS (Packet over SONET) que tiene un estado de protocolo de línea de "down".

Además de ayudar a identificar que el protocolo de línea está inactivo, explica los comandos show y debug que deben utilizarse para solucionar el problema de encapsulación de High-Level Data Link Control (HDLC) y Point-to-Point Protocol (PPP). También recorre usted a través de un escenario de Troubleshooting típico basado en una configuración de laboratorio documentada.

Interprete el comando show interface pos

Con el propósito del documento, la salida de la posición de la interfaz de la demostración es mientras que esta salida muestra. Observe las partes resaltadas de la pantalla y los comentarios:

RTR12410-2#show interface pos 6/0 
   POS6/0 is up, line protocol is down 

!---  The line protocol is down
.
     Hardware is Packet over SONET 
  MTU 4470 bytes, BW 2488000 Kbit, DLY 100 usec, rely 255/255, load 1/255 
     Encapsulation HDLC, crc 32, loopback not set 

!---  The loopback has not been set.

     Keepalive set (10 sec) 

!---  The keepalive is set as every ten seconds.

     Scramble disabled 
  Last input never, output 00:00:05, output hang never 
  Last clearing of "show interface" counters never 
  Queueing strategy: fifo 
  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 throttles 
              0 parity 
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
     3 packets output, 1074 bytes, 0 underruns 
     0 output errors, 0 applique, 1 interface resets 
     0 output buffer failures, 0 output buffers swapped out 
     2 carrier transitions

Los estados de la referencia de comandos del ® del Cisco IOS que el estado del campo del Line Protocol “indica si los procesos del software que dirigen el Line Protocol consideran la línea usable (es decir, el Keepalives es acertado) o si ha sido tomada abajo por un administrador.”

Otros campos importantes en la salida show interface pos son:

  • Encapsulación — Método de encapsulación asignado a la interfaz.

  • loopback - Indica si el loopback está configurado.

  • señal de mantenimiento: indica si se han definido señales de mantenimiento.

Descripción general del stack de protocolos POS

Este diagrama ilustra la pila del protocolo usada en una interfaz POS.

/image/gif/paws/16152/gspos_a0.gif

Las interfaces POS aceptan encapsulaciones múltiples: HDLC, PPP y retransmisión de tramas. Así, el Packet over SONET es más exactamente PPP over SONET o HDLC over SONET. Este documento no cubre la Encapsulación de Frame Relay.

El PPP y el HDLC están estrechamente vinculados y comparten estas características:

  • Proporcione una estructura de alineación de tramas con las encabezados y los remolques. La cola provee comprobación de errores.

  • Brinda delineación de trama, que define para un receptor el momento exacto en que un paquete y una trama comienzan y terminan. En el HDLC y el PPP, la delineación de tramas se proporciona mediante un patrón de llenado de intertramado especial o un modelo ocioso. El modelo es 0x7E, o 0111 1110.

  • Indique la longitud mínima y máxima de los paquetes.

  • Transporte paquetes del IP y brinde un método para que los receptores determinen el tipo exacto de paquete dentro de la trama que llega.

No obstante, aunque están estrechamente relacionados, PPP y HDLC no son lo mismo, y se utilizan diferentes comandos de depuración para solucionar problemas de protocolo de línea.

Utilice los comandos debug

La salida de los diversos comandos debug privileged exec proporciona relacionado con la información de diagnóstico al estado del protocolo y a la actividad de la red para muchos acontecimientos de funcionamiento entre redes.

precaución Precaución: Puesto que asignan salida de debbuging un prioritario en proceso de la CPU, puede hacer el sistema inutilizable. Por esta razón, sólo use los comandos de depuración para resolver problemas específicos o durante sesiones de resolución de problemas con el equipo de soporte técnico de Cisco. Es más, es mejor utilizar los comandos de depuración durante los períodos en que hay poco tráfico en la red y menos usuarios. La depuración durante estos períodos disminuye la posibilidad de que la sobrecarga por el mayor procesamiento del comando debug afecte el uso del sistema. Cuando termine de usar un comando debug, recuerde desactivarlo con su comando no debug específico o con el comando no debug all.

Estos comandos debug son útiles para cuando usted resolver problemas los problemas de la interfaz POS. Se brinda más información acerca de la función y resultado de cada uno de estos comandos en las publicaciones de Referencia de Comandos debug de Cisco:

  • debug serial interface - Verifica si los paquetes keepalive HDLC se están incrementando. Si no es así, es probable que haya un problema de sincronización en la tarjeta de interfaz o en la red.

  • debug ppp negotiation - Muestra los paquetes PPP transmitidos durante el inicio PPP, donde e negocian las opciones PPP.

  • paquete ppp del debug — Paquetes PPP de las demostraciones que son enviados y recibidos. Este comando indica el vaciado de paquetes de bajo nivel.

  • debug ppp errors - Muestra errores PPP (como tramas ilegales o deformadas) relacionados con el funcionamiento y la negociación de la conexión PPP.

Refiera a los problemas en la línea seriales del troubleshooting para más información.

El protocolo de línea está inactivo con HDLC

HDLC es el tipo de encapsulación predeterminado en una interfaz de router POS. El HDLC es una Norma internacional, pero las instrumentaciones de vendedor varían uno o más campos o la encabezado o el remolque de tamaño y el formato. La especificación del Telecordia GR-253, que define SONET, discute mapeo HDLC sobre SONET (véase el problema 3, la sección 3.4.2.3, pp.3-59.) Especifica que la trama del HDLC byte-esté alineada con la trama de SONET, y también especifica un desmodulador autosincronizador, una verificación por redundancia cíclica (CRC), y el uso del modelo del indicador del HDLC como el llenado de intertramado de explicar la naturaleza variable de los bastidores de llegada del HDLC.

Si el comando show interface pos muestra que la línea y el protocolo están abajo con el encapsulado HDCL, usted puede utilizar el comando debug serial interface de aislar un problema de línea como la causa de una falla de conexión. El HDLC utiliza señales de mantenimiento e informa los valores de los tres contadores en la salida de los depuradores:

  • myseq — Aumenta en uno cada vez que el router envía un paquete de keepalive al router remoto.

  • mineseen – El valor del contador mineseen refleja el último número de la secuencia myseq que el router remoto ha indicado recibir del router. El router remoto almacena este valor en su contador yourseen y envía ese valor en un paquete de mantenimiento al router.

  • yourseen - Refleja el valor del número de secuencia de myseq que recibió el router en un paquete de señales de mantenimiento proveniente de un router remoto.

Si los valores del keepalive en el mineseq, yourseen, y los campos myseenes no están incrementando en cada línea subsiguiente de la salida, hay un problema en un extremo de la conexión. Cuando la diferencia en los valores en el myseq y los campos del mineseen excede de tres, la línea va abajo y se reajusta la interfaz.

Ésta es salida de muestra del comando debug serial interface para una conexión HDLC cuando el Keepalives es recibido correctamente por los ambos extremos.

hswan-12008-2a#debug serial interface 
Serial network interface debugging is on 
hswan-12008-2a# 
Oct 31 11:47:16: POS4/0: HDLC myseq 180, mineseen 0*, yourseen 1, line up 
Oct 31 11:47:17: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS4/0, 
changed state to up 

!---  Local router sees a remote keepalive with a sequence number of 1. 

Oct 31 11:47:26: POS4/0: HDLC myseq 181, mineseen 181*, yourseen 2, line up 
Oct 31 11:47:36: POS4/0: HDLC myseq 182, mineseen 182*, yourseen 3, line up 
Oct 31 11:47:46: POS4/0: HDLC myseq 183, mineseen 183*, yourseen 4, line up 
Oct 31 11:47:56: POS4/0: HDLC myseq 184, mineseen 184*, yourseen 5, line up 
Oct 31 11:48:06: POS4/0: HDLC myseq 185, mineseen 185*, yourseen 6, line up 

!---  Keepalives are sent every 10 seconds by default. 
!---  Both sides report incrementing sequence numbers. 

Ésta es salida de muestra del comando debug serial interface para una conexión HDLC cuando se cierra la interfaz remota y la interfaz local falta más de tres Keepalives.

hswan-12008-2a# 
Oct 31 11:49:46: POS4/0: HDLC myseq 195, mineseen 192, yourseen 13, line down 
Oct 31 11:49:47: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS4/0, 
changed state to down 

!---  The local router has failed to receive three keepalives and 
!---  brings down the line protocol.  Note the difference between 
!---  "myseq 195" and "mineseen 192". 

Oct 31 11:49:56: POS4/0: HDLC myseq 196, mineseen 192, yourseen 13, line down 
Oct 31 11:50:06: POS4/0: HDLC myseq 197, mineseen 192, yourseen 13, line down 
Oct 31 11:50:16: POS4/0: HDLC myseq 198, mineseen 192, yourseen 13, line down 
Oct 31 11:50:26: POS4/0: HDLC myseq 199, mineseen 192, yourseen 13, line down 
Oct 31 11:50:36: POS4/0: HDLC myseq 200, mineseen 0*, yourseen 1, line up 
Oct 31 11:50:37: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS4/0, 
changed state to up 

!---  After you execute the no shut command on the remote router, 
!---  the local router receives a keepalive again and brings up 
!---  the line protocol. 

Oct 31 11:50:46: POS4/0: HDLC myseq 201, mineseen 201*, yourseen 2, line up 
Oct 31 11:50:56: POS4/0: HDLC myseq 202, mineseen 202*, yourseen 3, line up 
Oct 31 11:51:06: POS4/0: HDLC myseq 203, mineseen 203*, yourseen 4, line up 
Oct 31 11:51:16: POS4/0: HDLC myseq 204, mineseen 204*, yourseen 5, line up 
Oct 31 11:51:26: POS4/0: HDLC myseq 205, mineseen 205*, yourseen 6, line up 
Oct 31 11:51:36: POS4/0: HDLC myseq 206, mineseen 206*, yourseen 7, line up 

!---  After the shut/no shut, the remote router re-initialized its 
!---  sequence number.
 

Protocolo de línea desactivado con PPP

El RFC 1661leavingcisco.com define el PPP como protocolo. Soporte PPP de las interfaces POS en el High-Level Data Link Control (HDLC) - como enmarcar, como se especifica en el RFC 1662leavingcisco.com , para la encapsulación de datos en la capa 2. El formato de trama para el PPP en la señalización con trama HDLC se muestra en esta figura.

gspos_a2.gif

RFC 2615 especifica el uso de la encapsulación PPP sobre los links SDH o SONET. El PPP fue diseñado para el uso en los links punto a punto y es conveniente para los links de SONET o SDH, que son aprovisionado como circuitos Point-to-Point incluso en topologías en anillo.

Cuando se establece un link punto a punto, PPP pasa por diferentes fases que pueden presentarse en un diagrama de estado. Cuando un evento externo, por ejemplo, la detección de una portadora o la configuración del administrador de red, indica que la capa física está lista para ser usada, el PPP inicia la fase de establecimiento de link. Una transición a esta fase produce un evento ASCENDENTE al (LCP) del Link Control Protocol, que proporciona varias funciones. Una función es determinación cuando está funcionando un link correctamente y cuando está fallando. Para establecer la comunicación en un link punto a punto, cada extremo del link PPP debe primero enviar paquetes LCP para configurar y probar el link de datos.

Entonces, el PPP debe enviar los paquetes del protocolo network control (NCP) para elegir y para configurar uno o más protocolos de capa de red. Una vez que los protocolos de capa de red elegidos se han configurado, los datagramas de cada protocolo de capa de red pueden ser enviados a través del link.

Esta tabla enumera las tres clases de paquetes LCP:

Clases de paquetes LCP Tipos de paquetes LCP Propósito
Configuración del link Configure-Request, Configure-Ack, Configure-Nak y Configure-Reject Se utiliza para establecer y configurar un link.
Terminación del link Termine Request y Terminar-ACK Utilizado para terminar un link.
Mantenimiento del link Rechazo de código, Rechazo de protocolo, Solicitud de eco, Respuesta de eco y Solicitud de descarte. Utilizado para administrar y depurar un link.

Configuración del link

LCP se utiliza para establecer la conexión a través de un intercambio de paquetes tipo “Configurar”. Este intercambio se completa, y se ingresa el estado de LCP Abierto, luego de enviado y recibido el paquete Configure-Ack.

Esta salida de muestra captura la etapa de la configuración de link LCP en una interfaz POS:

4d01h: PO3/1 LCP: State is Open 
4d01h: PO3/1 PPP: I pkt type 0x8021, datagramsize 14 LCP_UP 
(0x639FCAD8) id 0 (0s.) queued 1/1/2 
4d01h: PO3/1 PPP: Phase is UP 
4d01h: PO3/1 IPCP: O CONFREQ [Closed] id 152 len 10 
4d01h: PO3/1 IPCP:    Address 172.16.1.1 (0x0306AC100101) 
4d01h: PO3/1 PPP: I pkt type 0x8021, datagramsize 14 
4d01h: PO3/1 IPCP: I CONFREQ [REQsent] id 1 len 10 
4d01h: PO3/1 IPCP:    Address 172.16.1.2 (0x0306AC100102) 
4d01h: PO3/1 IPCP: O CONFACK [REQsent] id 1 len 10 
4d01h: PO3/1 IPCP:    Address 172.16.1.2 (0x0306AC100102) 
4d01h: PO3/1 IPCP: I CONFACK [ACKsent] id 152 len 10 
4d01h: PO3/1 IPCP:    Address 172.16.1.1 (0x0306AC100101) 
4d01h: PO3/1 IPCP: State is Open 
4d01h: PO3/1 IPCP: Install route to 172.16.1.2 
4d01h: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS3/1, 
changed state to up 

Nota: Una interfaz POS configurada con la encapsulación PPP intenta continuamente establecer a una sesión PPP. Entonces, verá el protocolo de línea en actividad en forma breve y periódica cuando hay un problema continuo, aun si se elimina la fibra.

Mantenimiento de link (con señales de mantenimiento)

El pedido de eco y los paquetes de respuesta de eco LCP proporcionan un Loopback Mechanism de la capa 2 para las ambas direcciones del link. Al recibir una Solicitud de eco en el estado de LCP abierto, se debe transmitir una Respuesta de eco.

Este diagrama del RFC 1661 ilustra el formato de un paquete de keepalive PPP.

/image/gif/paws/16152/16152a.gif

Estos paquetes LCP incluyen estos campos claves:

  • Código - 9 para Solicitud de eco y 10 para Respuesta de eco.

  • Identificador — En la transmisión, el campo del identificador se debe cambiar siempre que el contenido de los Cambios en el campo de datos y siempre que una contestación válida se haya recibido para un pedido anterior. Para las retransmisiones, el identificador puede permanecer sin cambiar. En la recepción, el campo del identificador del pedido de eco se copia en el campo del identificador del paquete de respuesta de eco.

  • Número mágico — El campo Magic-Number es cuatro octetos, y asistentes en la detección de links que estén en la condición de Looped-Back. Hasta que la opción de configuración de números mágicos se negocie con éxito, el número mágico se debe transmitir como cero. Consulte la opción de configuración de números mágicos en RFC 1661 para más detalles.

  • Datos — El campo de datos es cero o más octeto, y contiene los datos sin interpretar para uso del remitente. Los datos pueden consistir en cualquier valor binario. El final del campo está indicado por la Longitud.

Aquí está un ejemplo de la negociación ppp del debug cuando se habilita el Keepalives:

4d01h: PO3/1 LCP: O ECHOREQ [Open] id 1 len 12 magic 0x1A45933B 
4d01h: PO3/1 PPP: I pkt type 0xC021, datagramsize 16 
4d01h: PO3/1 LCP: I ECHOREP [Open] id 1 len 12 magic 0x00000002 
4d01h: PO3/1 LCP: Received id 1, sent id 1, line up 

Terminación del link

El PPP puede terminar el link en cualquier momento. Los disparadores posibles incluyen la pérdida de la portadora, fallas de autenticación, fallas en la calidad del link, el vencimiento del temporizador del tiempo de espera o el cierre administrativo del link.

Las aplicaciones LCP terminan los paquetes para cerrar el link. El remitente de Termine Request debe desconectar después de recibir un Terminar-ACK, o después del reinicio el contador expira. El receptor de un Terminate-Request (Pedido de finalización) debe esperar hasta que el par se desconecte y no debe desconectarse hasta que se haya reiniciado al menos una vez luego de enviar un Terminate-Ack .

/image/gif/paws/16152/16152a.gif

Termine los paquetes LCP incluyen estos campos claves:

  • Código — 5 para Termine Request y 6 para el Terminar-ACK.

  • Identificador — En la transmisión, el campo del identificador se debe cambiar siempre que el contenido de los Cambios en el campo de datos, y siempre que una contestación válida se haya recibido para un pedido anterior. Para las retransmisiones, el identificador puede permanecer sin cambiar. Al momento de la recepción, el campo Identifier (Identificador) del Terminate Request (Pedido de finalización) se copia en el campo Identifier (Identificador) del paquete Terminate-Ack (Reconocimiento de finalización).

El campo de datos es cero o más octeto, y contiene los datos sin interpretar para uso del remitente. Los datos pueden consistir en cualquier valor binario. El final del campo está indicado por la Longitud.

Aquí está un ejemplo de los resultados de la negociación ppp del debug cuando usted recibe un paquete TERMREQ:

4d01h: PO3/1 PPP: I pkt type 0xC021, datagramsize 8 
4d01h: PO3/1 LCP: I TERMREQ [Open] id 4 len 4 
4d01h: PO3/1 LCP: O TERMACK [Open] id 4 len 4 
4d01h: PO3/1 PPP: I pkt type 0xC021, datagramsize 18 
4d01h: PO3/1 IPCP: State is Closed 
4d01h: PO3/1 PPP: Phase is TERMINATING 
4d01h: PO3/1 LCP: I CONFREQ [TERMsent] id 1 len 14 
4d01h: PO3/1 LCP:    MRU 1500 (0x010405DC) 
4d01h: PO3/1 LCP:    MagicNumber 0x00000002 (0x050600000002) 
4d01h: PO3/1 LCP: Dropping packet, state is TERMsent 

!---  While in the TERMsent state, PPP should drop all other packets. 

4d01h: PO3/1 IPCP: Remove route to 172.16.1.2 
4d01h: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS3/1, 
changed state to down 

Secuencia de solución de problemas de ejemplo

Esta sección describe un ejemplo de escenario de Troubleshooting para un link POS usando la encapsulación PPP. Utiliza estas configuraciones:

Configuración del router A
interface POS1/0 
 ip address 1.1.1.6 255.255.255.0 
 no ip directed-broadcast 
 encapsulation ppp 
 crc 16 
 clock source internal

Configuración del Router B
interface POS2/0 
 ip address 1.1.1.5 255.255.255.0 
 no ip directed-broadcast 
 encapsulation ppp 
 crc 16

Nota: Estos debugs fueron capturados en dos Routers en una configuración de laboratorio continua. Así, el cronometrar se fija a interno en un lado y omitir para alinear en el otro extremo.

debug ppp negotiation

Esta salida ilustra el intercambio de paquetes capturado con la negociación ppp del debug durante la fase de establecimiento de link LCP.

Salida de depuración del router A
Router A Debug Output  
(1)  

!---  The router sends an outgoing confreq.

hswan-12008-2a#
*Nov  7 08:27:00: %LINK-3-UPDOWN: Interface POS1/0, changed state to up
*Nov  7 08:27:00: PO1/0 PPP: Treating connection as a dedicated line
*Nov  7 08:27:00: PO1/0 PPP: Phase is ESTABLISHING, Active Open
*Nov  7 08:27:00: PO1/0 LCP: O CONFREQ [Closed] id 7 len 14 
*Nov  7 08:27:00: PO1/0 LCP:    MRU 4470 (0x01041176) 
*Nov  7 08:27:00: PO1/0 LCP:    MagicNumber 0x4F46AF4D (0x05064F46AF4D)
(4)  

!---  Router A receives an incoming confreq from router B. 

*Nov  7 08:27:00: PO1/0 LCP: I CONFREQ [REQsent] id 45 len 14 
*Nov  7 08:27:00: PO1/0 LCP: MRU 4470 (0x01041176) 
*Nov  7 08:27:00: PO1/0 LCP: MagicNumber 0x2631E6D2 (0x05062631E6D2)
(5) 

!---  Router A responds with a confack and receives a 
!---  confack from Router B.  The LCP state is open. 
 
*Nov  7 08:27:00: PO1/0 LCP: O CONFACK [REQsent] id 45 len 14 
*Nov  7 08:27:00: PO1/0 LCP:    MRU 4470 (0x01041176) 
*Nov  7 08:27:00: PO1/0 LCP:    MagicNumber 0x2631E6D2 (0x05062631E6D2) 
*Nov  7 08:27:00: PO1/0 LCP: I CONFACK [ACKsent] id 7 len 14 
Nov  7 08:27:00: PO1/0 LCP:    MRU 4470 (0x01041176)
*Nov  7 08:27:00: PO1/0 LCP: MagicNumber 0x4F46AF4D (0x05064F46AF4D) 
*Nov  7 08:27:00: PO1/0 LCP: State is Open
*Nov  7 08:27:00: PO1/0 PPP: Phase is UP
(7) 

!---  Router A begins the IPCP stage and negotiates an IP address. 
!---  In this setup, the peer router already has an address and 
!---  sends it in a confreq. If the peer router accepts the address, 
!---  it responds with a confack.

*Nov  7 08:27:00: PO1/0 IPCP: O CONFREQ [Closed] id 7 len 10 
*Nov  7 08:27:00: PO1/0 IPCP: Address 1.1.1.6 (0x030601010106)
*Nov  7 08:27:00: PO1/0 CDPCP: O CONFREQ [Closed] id 7 len 4 
*Nov  7 08:27:00: PO1/0 IPCP: I CONFREQ [REQsent] id 9 len 10 
*Nov  7 08:27:00: PO1/0 IPCP: Address 1.1.1.5 (0x030601010105)
*Nov  7 08:27:00: PO1/0 IPCP: O CONFACK [REQsent] id 9 len 10 
*Nov  7 08:27:00: PO1/0 IPCP: Address 1.1.1.5 (0x030601010105)
*Nov  7 08:27:00: PO1/0 CDPCP: I CONFREQ [REQsent] id 9 len 4 
*Nov  7 08:27:00: PO1/0 CDPCP: O CONFACK [REQsent] id 9 len 4 
*Nov  7 08:27:00: PO1/0 IPCP: I CONFACK [ACKsent] id 7 len 10 
*Nov  7 08:27:00: PO1/0 IPCP: Address 1.1.1.6 (0x030601010106)
*Nov  7 08:27:00: PO1/0 IPCP: State is Open
*Nov  7 08:27:00: PO1/0 CDPCP: I CONFACK [ACKsent] id 7 len 4 
*Nov  7 08:27:00: PO1/0 CDPCP: State is Open
*Nov  7 08:27:00: PO1/0 IPCP: Install route to 1.1.1.5
*Nov  7 08:27:01: %LINEPROTO-5-UPDOWN: Line protocol on 
Interface POS1/0, changed state to up

Resultado de depuración del router B
(2) 

!---  Router  B receives an incoming  confrq from Router A. 

hswan-12008-2b#
Nov  7 10:29:19.043: PO2/0 LCP: I CONFREQ [Open] id 7 len 14 
Nov  7 10:29:19.043: PO2/0 LCP:    MRU 4470 (0x01041176) 
Nov  7 10:29:19.043: PO2/0 LCP:    MagicNumber 0x4F46AF4D (0x05064F46AF4D) 
Nov  7 10:29:19.043: PO2/0 IPCP: State is Closed
Nov  7 10:29:19.043: PO2/0 CDPCP: State is Closed
Nov  7 10:29:19.043: PO2/0 PPP: Phase is TERMINATING
Nov  7 10:29:19.043: PO2/0 PPP: Phase is ESTABLISHING
(3) 

!---  Router B sends its own LCP confreq.
  
Nov  7 10:29:19.043: PO2/0 LCP: O CONFREQ [Open] id 45 len 14 
Nov  7 10:29:19.043: PO2/0 LCP:    MRU 4470 (0x01041176) 
Nov  7 10:29:19.043: PO2/0 LCP:    MagicNumber 0x2631E6D2 (0x05062631E6D2)
(6) 

!---  Router B responds with a confack and receives a confack from Router A. 
 
The LCP state is open.  
Nov  7 10:29:19.043: PO2/0 LCP: O CONFACK [Open] id 7 len 14 
Nov  7 10:29:19.043: PO2/0 LCP:    MRU 4470 (0x01041176) 
Nov  7 10:29:19.043: PO2/0 LCP:    MagicNumber 0x4F46AF4D (0x05064F46AF4D) 
Nov  7 10:29:19.043: PO2/0 IPCP: Remove route to 1.1.1.6
Nov  7 10:29:19.047: PO2/0 LCP: I CONFACK [ACKsent] id 45 len 14 
Nov  7 10:29:19.047: PO2/0 LCP:    MRU 4470 (0x01041176) 
Nov  7 10:29:19.047: PO2/0 LCP:    MagicNumber 0x2631E6D2 (0x05062631E6D2) 
Nov  7 10:29:19.047: PO2/0 LCP: State is Open
Nov  7 10:29:19.047: PO2/0 PPP: Phase is UP
(8) 

!---  Router B also begins the IPCP stage and negotiates an IP address.
  
Nov  7 10:29:19.047: PO2/0 IPCP: O CONFREQ [Closed] id 9 len 10 
Nov  7 10:29:19.047: PO2/0 IPCP:    Address 1.1.1.5 (0x030601010105) 
Nov  7 10:29:19.047: PO2/0 CDPCP: O CONFREQ [Closed] id 9 len 4 
Nov  7 10:29:19.047: PO2/0 IPCP: I CONFREQ [REQsent] id 7 len 10 
Nov  7 10:29:19.047: PO2/0 IPCP:    Address 1.1.1.6 (0x030601010106) 
Nov  7 10:29:19.047: PO2/0 IPCP: O CONFACK [REQsent] id 7 len 10 
Nov  7 10:29:19.047: PO2/0 IPCP:    Address 1.1.1.6 (0x030601010106) 
Nov  7 10:29:19.047: PO2/0 CDPCP: I CONFREQ [REQsent] id 7 len 4 
Nov  7 10:29:19.047: PO2/0 CDPCP: O CONFACK [REQsent] id 7 len 4 
Nov  7 10:29:19.047: PO2/0 IPCP: I CONFACK [ACKsent] id 9 len 10 
Nov  7 10:29:19.047: PO2/0 IPCP:    Address 1.1.1.5 (0x030601010105) 
Nov  7 10:29:19.047: PO2/0 IPCP: State is Open
Nov  7 10:29:19.047: PO2/0 CDPCP: I CONFACK [ACKsent] id 9 len 4 
Nov  7 10:29:19.047: PO2/0 CDPCP: State is Open
Nov  7 10:29:19.047: PO2/0 IPCP: Install route to 1.1.1.6
*Nov  7 10:29:19.048: %LINEPROTO-5-UPDOWN: Line protocol on 
Interface POS2/0, changed state to up

debug ppp packet

Esta salida ilustra el intercambio de paquetes capturado con el paquete ppp del debug mientras que se está estableciendo un vínculo. Esta depuración captura el valor del campo de protocolo en el paquete PPP. RFC 1661 define el campo Protocolo como uno o dos octetos. El valor de este campo identifica el datagrama encapsulado en el campo Information (Información) del paquete.

Los valores del campo protocolo en el rango de "0***" a "3***" identifican el protocolo de capa de red de los paquetes específicos y los valores en el rango "8***" a "b***" identifican los paquetes que pertenecen a los protocolos de control de red (NCP), si los hubiera. Los valores de los campos de protocolos en el rango "c***" a "f***" identifican paquetes como protocolos de control de capa de link (tales como LCP). También hay diversos valores específicos del vendedor. Haga clic aquí para una lista completa de valores de campo del protocolo PPPleavingcisco.com .

Salida de depuración del router A
(1) 
*Nov  7 10:19:58: PO1/0 PPP: I pkt type 0xC021, datagramsize 18 

!---  0xC021 identifies LCP. 

*Nov  7 10:19:58: PO1/0 LCP: I CONFREQ [Closed] id 7 len 14 
*Nov  7 10:19:58: PO1/0 LCP:    MRU 4470 (0x01041176) 
*Nov  7 10:19:58: PO1/0 LCP:    MagicNumber 0x269933F4 (0x0506269933F4) 
*Nov  7 10:19:58: PO1/0 LCP: O CONFREQ [Closed] id 57 len 14^Z
*Nov  7 10:19:58: PO1/0 LCP:    MRU 4470 (0x01041176) 
*Nov  7 10:19:58: PO1/0 LCP:    MagicNumber 0x4FAE1B0C (0x05064FAE1B0C) 
*Nov  7 10:19:58: PO1/0 LCP: O CONFACK [REQsent] id 7 len 14 
*Nov  7 10:19:58: PO1/0 LCP:    MRU 4470 (0x01041176) 
*Nov  7 10:19:58: PO1/0 LCP:    MagicNumber 0x269933F4 (0x0506269933F4) 
*Nov  7 10:19:58: %LINK-3-UPDOWN: Interface POS1/0, changed state to up
*Nov  7 10:19:58: PO1/0 PPP: I pkt type 0xC021, datagramsize 18 
*Nov  7 10:19:58: PO1/0 LCP: I CONFACK [ACKsent] id 57 len 14ppp
*Nov  7 10:19:58: PO1/0 PPP: I pkt type 0x8021, datagramsize 14 

!---  0x8021 identifies IPCP, PPP internet protcol control protocol. 
 
*Nov  7 10:19:58: PO1/0 LCP:    MRU 4470 (0x01041176) 
*Nov  7 10:19:58: PO1/0 PPP: I pkt type 0x8207, datagramsize 8 

!---  0x8207 identifies Cisco discovery protocol control.
  
*Nov  7 10:19:58: PO1/0 LCP:    MagicNumber 0x4FAE1B0C (0x05064FAE1B0C) 
*Nov  7 10:19:58: PO1/0 IPCP: O CONFREQ [Closed] id 15 len 10 
*Nov  7 10:19:58: PO1/0 IPCP:    Address 1.1.1.6 (0x030601010106) 
*Nov  7 10:19:58: PO1/0 CDPCP: O CONFREQ [Closed] id 13 len 4 
*Nov  7 10:19:58: PO1/0 IPCP: I CONFREQ [REQsent] id 14 len 10packet
*Nov  7 10:19:58: PO1/0 IPCP:    Address 1.1.1.5 (0x030601010105) 
*Nov  7 10:19:58: PO1/0 IPCP: O CONFACK [REQsent] id 14 len 10 
*Nov  7 10:19:58: PO1/0 IPCP:    Address 1.1.1.5 (0x030601010105) 
*Nov  7 10:19:58: PO1/0 PPP: I pkt type 0x8021, datagramsize 14 
*Nov  7 10:19:58: PO1/0 CDPCP: I CONFREQ [REQsent] id 15 len 4 
*Nov  7 10:19:58: PO1/0 CDPCP: O CONFACK [REQsent] id 15 len 4 
*Nov  7 10:19:58: PO1/0 IPCP: I CONFACK [ACKsent] id 15 len 10 
*Nov  7 10:19:58: PO1/0 PPP: I pkt type 0x8207, datagramsize 8 
*Nov  7 10:19:58: PO1/0 IPCP:    Address 1.1.1.6 (0x030601010106) 
*Nov  7 10:19:58: PO1/0 CDPCP: I CONFACK [ACKsent] id 13 len 4 
*Nov  7 10:19:59: PO1/0 PPP: I pkt type 0x0207, datagramsize 376 

!---  0x0207 identifies Cisco Discovery Protocol (CDP). 
 
*Nov  7 10:19:59: PO1/0 PPP: I pkt type 0x0207, datagramsize 376 
*Nov  7 10:19:59: PO1/0 PPP: I pkt type 0x0207, datagramsize 376 
*Nov  7 10:19:59: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
POS1/0, changed state to up
(3) 

!---  ECHOREQand ECHOREP packets for PPP keepalives use packet type values 
!---  of 0xC021.
 
*Nov  7 10:20:05: PO1/0 PPP: I pkt type 0xC021, datagramsize 16 
*Nov  7 10:20:05: PO1/0 LCP: I ECHOREQ [Open] id 1 len 12 magic 0x269933F4 
*Nov  7 10:20:05: PO1/0 LCP: O ECHOREP [Open] id 1 len 12 magic 0x4FAE1B0C 
*Nov  7 10:20:07: PO1/0 LCP: O ECHOREQ [Open] id 1 len 12 magic 0x4FAE1B0C 
*Nov  7 10:20:07: PO1/0 PPP: I pkt type 0xC021, datagramsize 16 
*Nov  7 10:20:07: PO1/0 PPP: O pkt type 0x0207, datagramsize 376 
*Nov  7 10:20:07: PO1/0 LCP: I ECHOREP [Open] id 1 len 12 magic 0x269933F4 
*Nov  7 10:20:07: PO1/0 LCP: Received id 1, sent id 1, line up

Resultado de depuración del router B
(2) 
Nov  7 12:22:16.947: PO2/0 PPP: I pkt type 0xC021, datagramsize 18 
Nov  7 12:22:16.947: PO2/0 LCP: I CONFREQ [REQsent] id 57 len 14 
Nov  7 12:22:16.947: PO2/0 LCP:    MRU 4470 (0x01041176) 
Nov  7 12:22:16.947: PO2/0 PPP: I pkt type 0xC021, datagramsize 18 
Nov  7 12:22:16.947: PO2/0 LCP:    MagicNumber 0x4FAE1B0C (0x05064FAE1B0C) 
Nov  7 12:22:16.947: PO2/0 LCP: O CONFACK [REQsent] id 57 len 14 
Nov  7 12:22:16.947: PO2/0 LCP:    MRU 4470 (0x01041176) 
Nov  7 12:22:16.947: PO2/0 LCP:    MagicNumber 0x4FAE1B0C (0x05064FAE1B0C) 
Nov  7 12:22:16.947: PO2/0 LCP: I CONFACK [ACKsent] id 7 len 14 
Nov  7 12:22:16.947: PO2/0 LCP:    MRU 4470 (0x01041176) 
Nov  7 12:22:16.947: PO2/0 LCP:    MagicNumber 0x269933F4 (0x0506269933F4) 
Nov  7 12:22:16.947: PO2/0 IPCP: O CONFREQ [Closed] id 14 len 10 
Nov  7 12:22:16.947: PO2/0 IPCP:    Address 1.1.1.5 (0x030601010105) 
Nov  7 12:22:16.947: PO2/0 CDPCP: O CONFREQ [Closed] id 15 len 4 
Nov  7 12:22:16.947: PO2/0 PPP: I pkt type 0x8021, datagramsize 14 
Nov  7 12:22:16.951: PO2/0 PPP: I pkt type 0x8207, datagramsize 8 
Nov  7 12:22:16.951: PO2/0 IPCP: I CONFREQ [REQsent] id 15 len 10 
Nov  7 12:22:16.951: PO2/0 IPCP:    Address 1.1.1.6 (0x030601010106) 
Nov  7 12:22:16.951: PO2/0 IPCP: O CONFACK [REQsent] id 15 len 10 
Nov  7 12:22:16.951: PO2/0 IPCP:    Address 1.1.1.6 (0x030601010106) 
Nov  7 12:22:16.951: PO2/0 PPP: I pkt type 0x8021, datagramsize 14 
Nov  7 12:22:16.951: PO2/0 CDPCP: I CONFREQ [REQsent] id 13 len 4 
Nov  7 12:22:16.951: PO2/0 CDPCP: O CONFACK [REQsent] id 13 len 4 
Nov  7 12:22:16.951: PO2/0 PPP: I pkt type 0x8207, datagramsize 8 
Nov  7 12:22:16.951: PO2/0 IPCP: I CONFACK [ACKsent] id 14 len 10 
Nov  7 12:22:16.951: PO2/0 IPCP:    Address 1.1.1.5 (0x030601010105) 
Nov  7 12:22:16.951: PO2/0 CDPCP: I CONFACK [ACKsent] id 15 len 4 
Nov  7 12:22:17.947: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS2/0, 
changed state to up
(4) 

!---  ECHOREQ and ECHOREP packets for PPP keepalives use packet type 
!---  values of 0xC021. 

Nov  7 12:22:17.947: PO2/0 PPP: O pkt type 0x0207, datagramsize 376 
Nov  7 12:22:17.947: PO2/0 PPP: O pkt type 0x0207, datagramsize 376 
Nov  7 12:22:17.947: PO2/0 PPP: O pkt type 0x0207, datagramsize 376 
Nov  7 12:22:23.403: PO2/0 LCP: O ECHOREQ [Open] id 1 len 12 magic 0x269933F4 
Nov  7 12:22:23.403: PO2/0 PPP: I pkt type 0xC021, datagramsize 16 
Nov  7 12:22:23.403: PO2/0 LCP: I ECHOREP [Open] id 1 len 12 magic 0x4FAE1B0C 
Nov  7 12:22:23.403: PO2/0 LCP: Received id 1, sent id 1, line up
Nov  7 12:22:25.595: PO2/0 PPP: I pkt type 0xC021, datagramsize 16

Notas sobre la resolución de problemas

Una interfaz POS con el PPP o el encapsulado HDCL soporta dos mecanismos para alertarle de una falla de link: Keepalives de la capa 2 y alarmas de la Capa SONET. Las señales de mantenimiento demoran más tiempo en informar un problema que la estructura de alarma SONET inherente. Sin embargo, el Keepalives de la capa 2 es útil porque él marca la trayectoria del linecard CPU al linecard CPU, bastante que el fundador al fundador como lo hacen las alarmas de Nivel del SONET. El PPP reacciona más rápidamente para conectar los cambios de estado puesto que baja el LCP inmediatamente. En cambio, HDLC debe interrumpir las señales de mantenimiento.

En una configuración consecutiva entre dos Routers, la tracción de uno de los hilos de fibra rompe la Conectividad del Layer 1, y ambas interfaces POS cambian el estado a abajo/abajo. Sin embargo, cuando dos interfaces POS del router conectan a través de una nube de Telco con el equipo SONET/SDH, la información de pérdida del Layer 1 no se propaga al extremo remoto. En esta configuración, el Keepalives es el mecanismo para derribar el link.

Considere esta configuración.

/image/gif/paws/16152/16152b.gif

Esto es lo que sucede al quitar el hilo de fibra de transmisión en el link de SDHb a SDHa:

  • El router 7507a no recibe ningún Keepalives.

  • El router 7507b ve el Keepalives de 7507a puesto que la fibra de la recepción todavía está trabajando. Utilice la interfaz serial del debug para confirmar esto.

Alternativamente, cuando se realiza esta prueba, ejecute el comando show controller pos, que muestra las alarmas SONET. Debería poder ver una señal de indicación de alarma del trayecto (P-AIS) en el router 7507a y una indicación de defecto remoto de trayecto (P-RDI) en el 7507b.

Pruebas de loopback

Si la salida del comando show interfaces pos indica que la línea serial funciona pero que el protocolo de línea no funciona, utilice las pruebas de loopback para determinar el origen del problema. Realice un Local Loop Test primero, y entonces una prueba remota. Refiera comprensión de los Loopback Mode en los routeres Cisco para la dirección.

Nota: Cambie la encapsulación del PPP al HDLC cuando usted utiliza los loopback. El Line Protocol en una interfaz configurada con el PPP sube solamente cuando negocian todo el LCP y sesiones NCP con éxito.

Estado del protocolo de línea con APS

Una interfaz POS configurada para el Automatic Protection Switching (APS) derriba el Line Protocol si la interfaz es el canal de la protección y no el canal en funcionamiento. Considere esta topología de ejemplo:

/image/gif/paws/16152/16152c.gif

Capturaron a esta salida del registro de la muestra después de que el cableado de fibra en la interfaz POS 1/0 de GSRb fuera quitado. Observe los cambios en el estado del protocolo de línea en ambas interfaces durante un intercambio APS. También observe los cambios en los estados de la adyacencia del Open Shortest Path First (OSPF). (Refiera a la página de soporte de la tecnología APS para más información.)

*Sep  5 17:41:46: %SONET-4-ALARM:  POS1/0: SLOS 
*Sep  5 17:41:46: %SONET-4-ALARM:  POS2/0: APS enabling channel 
*Sep  5 17:41:46: %SONET-6-APSREMSWI: POS2/0: Remote APS status now Protect 
*Sep  5 17:41:46: %SONET-4-ALARM:  POS1/0: APS disabling channel 
*Sep  5 17:41:46: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS2/0, 
changed state to up 
*Sep  5 17:41:46: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS1/0, 
changed state to down 
*Sep  5 17:41:48: %LINK-3-UPDOWN: Interface POS1/0, changed state to down 
*Sep  5 17:41:48: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.100.100 on POS1/0 
from FULL to DOWN, Neighbor Down: Interface down or detached 
*Sep  5 17:41:56: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.100.100 on POS2/0 
from LOADING to FULL, Loading Done 

Evite configurar el APS en una interfaz POS con la encapsulación PPP. El PPP no es consciente del APS. Si una interfaz es arriba/abaja debido a la cancelación de la selección de APS, el PPP intenta reajustar la interfaz y transmite continuamente los Paquetes de negociación PPP.

Además, el Keepalives de la neutralización para evitar el Line Protocol innecesario agita. Las señales de mantenimiento son deshabilitadas automáticamente en la mayoría del hardware del router POS.

Una interfaz POS de las Cisco 12000 Series adentro modo de protección u operativo de APS puede pegarse en un estado encendido/apagado (incluso con un loopback) cuando se inhabilita el APS. Otro indicador luminoso LED amarillo de la placa muestra gravedad menor insertado en el mismo slot experimenta este problema. Mueva el indicador luminoso LED amarillo de la placa muestra gravedad menor a un nuevo slot para restablecer el estado del protocolo de la línea apropiado. Este problema se resuelve en el Cisco IOS Software Release 12.0(19)S bajo el Id. de bug Cisco CSCdt43759 (clientes registrados solamente).

Utilice estos pasos como solución alternativa:

  1. Configure el comando aps protect.

  2. Ejecute el comando aps force 1.

  3. Configure el comando no aps protect.

Problemas conocidos

Observe estas advertencias cuando usted resolver problemas los problemas del Line Protocol con las interfaces POS:

  • Una interfaz PA-POS pudo reajustar continuamente después de que la encapsulación se cambie del PPP al HDLC. Este problema está señalado contra el PA-POS en el Id. de bug Cisco CSCdk30893 (clientes registrados solamente) y resuelto en el Id. de bug Cisco CSCdk18777 (clientes registrados solamente) y el Id. de bug Cisco CSCdk13757 (clientes registrados solamente) para las diversas interfaces que soportan el PPP y el encapsulado HDCL. Se causa el problema cuando el PPP no se apaga totalmente cuando la encapsulación fue cambiada.

  • Una interfaz POS configurada con el encapsulado HDCL y el Keepalives experimenta las aletas relanzadas de la interfaz bastante que trayendo abajo del Line Protocol cuando el Keepalives no se recibe del extremo remoto. Este problema se resuelve en el Id. de bug Cisco CSCdp86387 (clientes registrados solamente).

Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Información Relacionada


Document ID: 16152