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

Opciones de descarga

PDF (212.6 KB)
Visualice con Adobe Reader en una variedad de dispositivos
ePub (109.3 KB)
Visualice en diferentes aplicaciones en iPhone, iPad, Android, Sony Reader o Windows Phone
Mobi (Kindle) (154.7 KB)
Visualice en dispositivo Kindle o aplicación Kindle en múltiples dispositivos

Actualizado:19 de mayo de 2006

ID del documento:16152

Lenguaje no discriminatorio

El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.

Acerca de esta traducción

Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).

Contenido

Introducción

Interpretar el comando show interface pos

Descripción general del stack de protocolos POS

Usar comandos debug

El protocolo de línea está inactivo con HDLC

Protocolo de línea desactivado con PPP

Configuración del link

Mantenimiento de link (con señales de mantenimiento)

Terminación del link

Secuencia de solución de problemas de ejemplo

Notas sobre la resolución de problemas

Pruebas de loopback

Estado del protocolo de línea con APS

Problemas conocidos

Información Relacionada

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 le guiará a través de un escenario típico de solución de problemas basado en una configuración de laboratorio documentada.

Interpretar el comando show interface pos

A los efectos del documento, el resultado de show interface pos es como muestra este resultado. 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

La Referencia de Comandos de Cisco IOS^® indica que el estado del campo de protocolo de línea "indica si los procesos de software que manejan el protocolo de línea consideran que la línea puede utilizarse (es decir, las señales de mantenimiento son exitosas) o si ha sido eliminada 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.
keepalive: indica si se han establecido señales de mantenimiento.

Descripción general del stack de protocolos POS

Este diagrama ilustra la pila de protocolo utilizada en una interfaz POS.

Las interfaces POS aceptan encapsulaciones múltiples: HDLC, PPP y retransmisión de tramas. Por lo tanto, el paquete sobre SONET es más preciso PPP sobre SONET o HDLC sobre SONET. Este documento no cubre la encapsulación de Frame Relay.

PPP y HDLC están estrechamente relacionados y comparten estas características:

Proporcione una estructura de entramado con encabezados y 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 HDLC y PPP, la delineación de tramas se proporciona mediante un patrón de relleno especial entre tramas o un patrón inactivo. El patrón 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.

Usar comandos debug

La salida de varios comandos EXEC debug privilegiados proporciona información de diagnóstico relacionada con el estado del protocolo y la actividad de la red para muchos eventos de interconexión.

caution Precaución: Dado que la salida de depuración tiene una prioridad alta en el proceso de la CPU, puede hacer que el sistema quede 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 resolver problemas de 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 aumentan. 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 se negocian las opciones PPP.
debug ppp packet—Muestra los paquetes PPP que se envían y reciben. Este comando indica el vaciado de paquetes de bajo nivel.
debug ppp errors: muestra errores PPP (como tramas ilegales o mal formadas) asociados con la negociación y operación de conexión PPP.

Refiérase a Resolución de Problemas de Línea Serial para obtener 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. HDLC es un estándar internacional, pero las implementaciones del proveedor varían en uno o más campos o en el encabezado o la cola en tamaño y formato. La especificación Telecordia GR-253, que define SONET, analiza el mapeo HDLC sobre SONET (consulte el número 3, sección 3.4.2.3, pp.3-59). Especifica que la trama HDLC esté alineada con los bytes con la trama SONET, y también especifica un codificador autosincronizado, una verificación de redundancia cíclica (CRC) y el uso del patrón del indicador HDLC como relleno entre tramas para tener en cuenta la naturaleza variable de las tramas HDLC que llegan.

Si el comando show interface pos muestra que la línea y el protocolo están inactivos con la encapsulación HDLC, puede utilizar el comando debug serial interface para 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 una vez que el router envía un paquete keepalive al router remoto.
mineseen: el valor del contador mineseen refleja el último número de secuencia myseq que el router remoto ha reconocido 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 el router ha recibido en un paquete keepalive del router remoto.

Si los valores de keepalive en los campos mineseq, yourseen y myseen no aumentan en cada línea de salida subsiguiente, hay un problema en un extremo de la conexión. Cuando la diferencia en los valores en los campos myseq y mineseen excede tres, la línea se desactiva y la interfaz se restablece.

Este es un ejemplo de salida del comando debug serial interface para una conexión HDLC cuando las señales de mantenimiento son recibidas correctamente por 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.

Este es un ejemplo de salida del comando debug serial interface para una conexión HDLC cuando la interfaz remota se cierra y la interfaz local pierde más de tres señales de mantenimiento.

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

RFC 1661 define PPP como un protocolo. Las interfaces POS admiten PPP en el entramado tipo High-Level Data Link Control (HDLC), como se especifica en RFC 1662 , para la encapsulación de datos en la Capa 2. En esta figura se muestra el formato de trama para PPP en el entramado tipo HDLC.

RFC 2615 especifica el uso de la encapsulación PPP sobre los links SDH o SONET. PPP se diseñó para su uso en links punto a punto y es adecuado para links SONET o SDH, que se aprovisionan como circuitos punto a punto incluso en topologías de 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 UP al protocolo de control de enlaces (LCP), que proporciona varias funciones. Una función es determinar cuándo un link funciona correctamente y cuándo falla. 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.

A continuación, PPP debe enviar paquetes de protocolo de control de red (NCP) para elegir y 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	Terminate-Request y Terminate-Ack	Se utiliza para finalizar 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.

Este ejemplo de salida captura la etapa de configuración del 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 encapsulación PPP intenta continuamente establecer 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)

Los paquetes Echo-Request y Echo-Reply de LCP proporcionan un mecanismo de loopback de Capa 2 para 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 de RFC 1661 ilustra el formato de un paquete keepalive PPP.

Estos paquetes LCP incluyen estos campos clave:

Código: 9 para la solicitud de eco y 10 para la respuesta de eco.
Identificador: cuando se transmite, el campo Identificador se debe cambiar siempre que cambie el contenido del campo Datos y siempre que se reciba una respuesta válida para una solicitud anterior. Para las retransmisiones, el identificador puede permanecer inalterado. En recepción, el campo Identificador de la solicitud de eco se copia en el campo Identificador del paquete de respuesta de eco.
Magic-Number: el campo Magic-Number es de cuatro octetos y ayuda en la detección de links que se encuentran en la condición de looped-back. Hasta que la opción de configuración Magic-Number se negocie correctamente, 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 Datos es cero o más octetos y contiene datos no interpretados para su uso por el remitente. Los datos pueden constar de cualquier valor binario. El final del campo está indicado por la Longitud.

A continuación se muestra un ejemplo de debug ppp negotiation cuando se habilitan 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

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.

LCP utiliza Terminate packets para cerrar el link. El remitente de Terminate-Request debe desconectarse después de recibir una Terminate-Ack o después de que venza el contador Restart. 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 .

Los paquetes LCP de terminación incluyen estos campos clave:

Código: 5 para Terminate-Request y 6 para Terminate-Ack.
Identificador: cuando se transmite, el campo Identificador se debe cambiar siempre que cambie el contenido del campo Datos y siempre que se reciba una respuesta válida para una solicitud anterior. Para las retransmisiones, el identificador puede permanecer inalterado. 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 Datos es cero o más octetos y contiene datos no interpretados para su uso por el remitente. Los datos pueden constar de cualquier valor binario. El final del campo está indicado por la Longitud.

Este es un ejemplo de la salida de debug ppp negotiation cuando 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 solución de problemas para un link POS mediante 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: Estas depuraciones se capturaron en dos routers en una configuración de laboratorio adosada. Por lo tanto, la temporización se establece en interna en un lado y de forma predeterminada en línea en el otro extremo.

debug ppp negotiation

Este resultado ilustra el intercambio de paquetes capturado con la negociación ppp de debug durante la fase de establecimiento de link de 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 debug ppp packet mientras se establece un link. 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 varios valores específicos del proveedor. Haga clic aquí para ver una lista completa de valores de campo del protocolo PPP.

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

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

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 encapsulación PPP o HDLC soporta dos mecanismos para alertarle de una falla de link: señales de mantenimiento de capa 2 y alarmas de capa SONET. Las señales de mantenimiento demoran más tiempo en informar un problema que la estructura de alarma SONET inherente. Sin embargo, las señales de mantenimiento de Capa 2 son útiles porque verifican el trayecto de la CPU de la tarjeta de línea a la CPU de la tarjeta de línea, en lugar de la CPU de la tarjeta de línea a la del entramador como hacen las alarmas de nivel SONET. PPP reacciona más rápidamente para vincular los cambios de estado, ya que LCP se cae inmediatamente. En cambio, HDLC debe interrumpir las señales de mantenimiento.

En una configuración adosada entre dos routers, al extraer uno de los hilos de fibra se rompe la conectividad de Capa 1 y ambas interfaces POS cambian el estado a down/down. Sin embargo, cuando dos interfaces POS de router se conectan a través de una nube de compañía telefónica con equipos SONET/SDH, la información de pérdida de Capa 1 no se propaga al extremo remoto. En esta configuración, las señales de mantenimiento son el mecanismo para desactivar el link.

Considere esta configuración.

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 señales de mantenimiento.
El router 7507b ve señales de mantenimiento de 7507a ya que la fibra de recepción sigue funcionando. Utilice debug serial interface 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 primero una prueba de loop local y luego una prueba remota. Refiérase a Comprensión de los Modos de Loopback en los Routers Cisco para obtener orientación.

Nota: Cambie la encapsulación de PPP a HDLC cuando utilice loopbacks. El protocolo de línea en una interfaz configurada con PPP aparece solamente cuando todas las sesiones LCP y NCP se negocian exitosamente.

Estado del protocolo de línea con APS

Una interfaz POS configurada para la conmutación de protección automática (APS) desactiva el protocolo de línea si la interfaz es el canal de protección y no el canal en funcionamiento. Considere esta topología de ejemplo:

Esta salida de registro de ejemplo se capturó después de que se quitó el cableado de fibra en la interfaz POS 1/0 de GSRb. Observe los cambios en el estado del protocolo de línea en ambas interfaces durante un intercambio APS. Tenga en cuenta también los cambios en los estados de adyacencia OSPF (Open Shortest Path First). (Consulte la página de soporte de tecnología APS para obtener 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 APS en una interfaz POS con encapsulación PPP. PPP no conoce APS. Si una interfaz está activa/inactiva debido a la deselección de APS, PPP intenta reiniciar la interfaz y transmite continuamente los paquetes de negociación PPP.

Además, inhabilite keepalives para evitar innecesarias inestabilidad en el protocolo de línea. Las señales de mantenimiento son deshabilitadas automáticamente en la mayoría del hardware del router POS.

Una interfaz POS de la serie 12000 de Cisco en el modo APS que funciona o protege puede quedar atascada en un estado activo/inactivo (incluso con un loopback) cuando APS está inhabilitado. Otra tarjeta insertada en la misma ranura experimenta este problema. Mueva la tarjeta a una nueva ranura para restaurar el estado adecuado del protocolo de línea. Este problema se resuelve en la versión 12.0(19)S del software del IOS de Cisco con el ID de bug de Cisco CSCdt43759 (sólo clientes registrados) .

Utilice estos pasos como solución alternativa:

Configure el comando aps protect.
Ejecute el comando aps force 1.
Configure el comando no aps protect.

Problemas conocidos

Tenga en cuenta estas advertencias cuando resuelva problemas de protocolo de línea con interfaces POS:

Una interfaz PA-POS podría restablecerse continuamente después de que la encapsulación se cambie de PPP a HDLC. Este problema se informa contra el PA-POS en el ID de bug Cisco CSCdk30893 (sólo clientes registrados) y se resuelve en el ID de bug Cisco CSCdk187777 (sólo clientes registrados) y en el ID de bug Cisco CSCdk1377555555555555550000000000000000000000000000000000000000000000000000000000clientes solamente) para varias interfaces que soportan encapsulación PPP y HDLC. El problema se origina cuando el PPP no se apaga completamente cuando se cambió la encapsulación.
Una interfaz POS configurada con encapsulación HDLC y keepalives experimenta inestabilidades de interfaz repetidas en lugar de desactivar el protocolo de línea cuando no se reciben señales de mantenimiento desde el extremo remoto. Este problema se resuelve con el ID de bug de Cisco CSCdp86387 (sólo clientes registrados) .

Información Relacionada

Historial de revisiones

Revisión	Fecha de publicación	Comentarios
1.0	19-May-2006	Versión inicial

Contribución realizada por

amdavis
pdockeri