Troubleshooting de Problems de "O Line Protocol está Desconectado" em Interfaces POS

Introdução

Este documento descreve como resolver problemas de uma interface de roteador de pacote sobre SONET (POS) que tenha um status de protocolo de linha de "inativo".

Além de ajudar a identificar que o protocolo de linha está inativo, ele explica o uso dos comandos show e debug para fazer Troubleshooting do problema de encapsulamento dos protocolos PPP (Point-to-Point Protocol) e HDLC. Ele também o orienta em um cenário típico de solução de problemas com base em uma configuração de laboratório documentada.

Interpretar o comando show interface pos

Para fins de documento, a saída de show interface pos é como esta saída mostra. Observe as partes realçadas da exibição e dos comentários:

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

O Comando Reference do Cisco IOS® declara que o status do campo de protocolo de linha "indica se os processos de software que tratam do protocolo de linha consideram a linha útil (ou seja, keepalives bem-sucedidos) ou se foram removidos por um administrador".

Outros campos importantes na saída de show interface pos são:

• Encapsulamento — Método de encapsulamento atribuído à interface.

• loopback — Indica se o loopback está definido.

• keepalive — Indica se keepalives estão definidos.

Visão geral da pilha de protocolo POS

Este diagrama ilustra a pilha de protocolos usada em uma interface POS.

Interfaces POS são compatíveis com múltiplos encapsulamentos - HDLC, PPP e Frame Relay. Assim, o pacote sobre SONET é mais precisamente PPP sobre SONET ou HDLC sobre SONET. Este documento não aborda o encapsulamento do Frame Relay.

O PPP e o HDLC estão intimamente relacionados e compartilham estas características:

• Fornecer uma estrutura de enquadramento com cabeçalhos e trailers. O trailer fornece verificação de erros.

• Forneça delineamento de quadros, o que define um receptor exatamente no local em que um pacote e um quadro começam e terminam. Em HDLC e PPP, a delineação do quadro é fornecida por meio de um padrão especial de preenchimento entre quadros ou padrão ocioso. O padrão é 0x7E, ou 0111 1110.

• Defina um comprimento de pacote mínimo e máximo.

• Transporte pacotes de IP e forneça um método para os receptores determinarem o tipo preciso de pacote dentro do quadro recebido.

Entretanto, embora estejam intimamente relacionados, PPP e HDLC não são a mesma coisa, e diferentes comandos de depuração são usados para solucionar problemas de protocolo de linha.

Usar comandos debug

A saída de vários comandos EXEC privilegiados debug fornece informações de diagnóstico relacionadas ao status do protocolo e à atividade da rede para muitos eventos de internetworking.

Cuidado: como a saída de depuração recebe uma prioridade alta no processo da CPU, ela pode inutilizar o sistema. Por esta razão, use comandos de depuração somente para troubleshoot problemas específicos ou durante sessões de Troubleshooting com a equipe de suporte técnico Cisco. Além disso, é melhor usar comandos debug durante períodos de tráfego baixo de rede e menos usuários. A depuração durante esses períodos reduz a possibilidade de que o comando debug aumentado que processa a carga adicional afete o uso do sistema. Ao concluir o uso de um comando debug, lembre-se de desativá-lo com o comando específico no debug ou com o comando no debug all.

Esses comandos debug são úteis para solucionar problemas de interface POS. Mais informações sobre a função e a saída de cada um desses comandos são fornecidas nas publicações Cisco Debug Command Reference (Referência de comandos de depuração da Cisco):

• debug serial interface — Verifica se os pacotes de keepalive do HDLC estão sendo incrementados. Se não, é provável que exista um problema de cronometragem na placa de interface ou na rede.

• debug ppp negotiation — Mostra pacotes PPP transmitidos durante a inicialização de PPP, em que as opções de PPP são negociadas.

• debug ppp packet — Mostra os pacotes PPP sendo enviados e recebidos. Esse comando exibe os dumps de pacote de nível baixo.

• debug ppp errors — Mostra erros PPP (como quadros ilegais ou malformados) associados à negociação e operação da conexão PPP.

Consulte Troubleshooting de Problemas de Linha Serial para obter mais informações.

O protocolo de linha está desconectado com HDLC

HDLC é o tipo de encapsulamento padrão em uma interface de roteador POS. O HDLC é um padrão internacional, mas as implementações dos fornecedores variam em um ou mais campos ou no cabeçalho ou trailer em tamanho e formato. A especificação Telecordia GR-253, que define o SONET, discute o mapeamento HDLC sobre SONET (consulte a Edição 3, Seção 3.4.2.3, pp.3-59). Ele especifica que o quadro HDLC seja alinhado em bytes com o quadro SONET e também especifica um embaralhador de sincronização automática, uma verificação de redundância cíclica (CRC) e o uso do padrão de flag HDLC como o preenchimento entre quadros para levar em conta a natureza variável dos quadros HDLC que chegam.

Se o comando show interface pos mostrar que a linha e o protocolo estão desativados com o encapsulamento HDLC, você poderá usar o comando debug serial interface para isolar um problema de linha como a causa de uma falha de conexão. O HDLC utiliza manutenção de atividade e informa os valores dos três contadores na saída de depuração:

• myseq — Aumenta em um cada vez que o roteador envia um pacote keepalive ao roteador remoto.

• mineseen — O valor do contador mineseen reflete o último número de sequência myseq que o roteador remoto confirmou ter recebido do roteador. O roteador remoto armazena este valor no contador yourseen e envia esse valor em um pacote de manutenção de atividade para o roteador.

• yourseen — Reflete o valor do número de sequência myseq que o roteador recebeu em um pacote de keepalive do roteador remoto.

Se os valores de keepalive nos campos mineseq, yourseen e myseen não estiverem incrementando em cada linha de saída subsequente, há um problema em uma extremidade da conexão. Quando a diferença nos valores nos campos myseq e mineseen excede três, a linha fica inativa e a interface é redefinida.

Este é um exemplo de saída do comando debug serial interface para uma conexão HDLC quando os keepalives são recebidos corretamente por ambas as extremidades.

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 é um exemplo de saída do comando debug serial interface para uma conexão HDLC quando a interface remota está fechada e a interface local perde mais de três 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.
 

O protocolo de linha está desconectado com o PPP

O RFC 1661 define o PPP como um protocolo. As interfaces POS suportam o PPP no enquadramento do tipo HDLC (High-Level Data Link Control), conforme especificado no RFC 1662, para encapsulamento de dados na Camada 2. O formato de quadro para o PPP no enquadramento do tipo HDLC é mostrado nesta figura.

A RFC 2615 especifica a utilização de encapsulamento PPP sobre enlaces SONET ou SDH. O PPP foi projetado para uso em links ponto-a-ponto e é adequado para links SONET ou SDH, que são provisionados como circuitos ponto-a-ponto mesmo em topologias em anel.

Ao ativar um enlace ponto a ponto, o PPP percorre várias fases distintas, que podem ser demonstradas em um diagrama de estado. Quando um evento externo, como, por exemplo, uma detecção de portadores ou configuração de administrador de rede, indica que a camada física está pronta para ser usada, o PPP prossegue para a fase de estabelecimento de enlace. Uma transição para essa fase produz um evento UP para o LCP (Link Control Protocol), que fornece várias funções. Uma função é determinar quando um link está funcionando corretamente e quando está falhando. A fim de estabelecer a comunicação em um link ponto a ponto, cada extremidade do link PPP deve enviar primeiro pacotes LCP para configurar e testar o link de dados.

Em seguida, o PPP deve enviar pacotes de Network Control Protocol (NCP) para escolher e configurar um ou mais protocolos da camada de rede. Após a configuração de todos os protocolos de camada de rede escolhidos, os datagramas de cada protocolo podem ser enviados pelo enlace.

Esta tabela lista as três classes de pacotes LCP:

Configuração de link

LCP é usado para estabelecer a conexão por meio de um intercâmbio de pacotes de configuração. Essa troca está completa, e o estado LCP aberto entrou, uma vez que um pacote Configure-Ack foi não só enviado mas também recebido.

Este exemplo de saída captura o estágio de configuração do link LCP em uma interface 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 

Observação: uma interface POS configurada com encapsulamento PPP tenta continuamente estabelecer uma sessão PPP. Portanto, você visualiza o protocolo de linha surgir brevemente em intervalos periódicos quando há um problema prolongado, mesmo quando o canal de fibra está removido.

Manutenção de enlaces (com manutenção de atividades)

Os pacotes LCP Echo-Request e Echo-Reply fornecem um mecanismo de loopback de Camada 2 para ambas as direções do link. Na recepção de uma Requisição de Eco no estado de LCP Aberto, deve ser transmitida uma Resposta de Eco.

Este diagrama do RFC 1661 ilustra o formato de um pacote de manutenção de atividade PPP.

Esses pacotes LCP incluem estes campos principais:

• Código — 9 para Solicitação de Eco e 10 para Resposta de Eco.

• Identificador — Na transmissão, o campo Identificador deve ser alterado sempre que o conteúdo do campo Dados for alterado e sempre que uma resposta válida tiver sido recebida para uma solicitação anterior. Para retransmissões, o identificador pode permanecer inalterado. Na recepção, o campo Identificador da Solicitação de Eco é copiado no campo Identificador do pacote de Resposta de Eco.

• Número mágico — O campo Número mágico tem quatro octetos e ajuda na detecção de links que estão na condição de loopback. Até que a opção de configuração Magic-Number seja negociada com êxito, o Magic-Number deve ser transmitido como zero. Consulte a Opção de Configuração de Número Mágico no RFC 1661 para obter explicações adicionais.

• Dados — O campo Dados é zero ou mais octetos e contém dados não interpretados para uso pelo remetente. Os dados podem consistir em qualquer valor binário. O final do campo é indicado pelo Length (Comprimento).

Aqui está um exemplo de debug ppp negotiation quando as manutenções de atividades são ativadas:

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 

Terminação de enlace

O PPP pode encerrar o link a qualquer momento. Os disparadores possíveis incluem perda de portador, falha de autenticação, falha de qualidade do enlace, a expiração do cronômetro de período ocioso ou o fechamento administrativo do enlace.

O LCP usa pacotes Terminate para fechar o link. O remetente de Terminate-Request deve se desconectar depois de receber Terminate-Ack ou depois que o contador de Reinicialização expirar. O receptor de uma solicitação de encerramento (Terminate-Request) deve aguardar a desconexão do peer e não deve se desconectar até pelo menos uma reinicialização ter passado, após o envio de uma confirmação de encerramento (Terminate-Ack).

Os pacotes LCP de terminação incluem estes campos-chave:

• Code — 5 para Terminate-Request e 6 para Terminate-Ack.

• Identificador — Na transmissão, o campo Identificador deve ser alterado sempre que o conteúdo do campo Dados for alterado e sempre que uma resposta válida tiver sido recebida para uma solicitação anterior. Para retransmissões, o Identificador pode permanecer inalterado. Na recepção, o campo Identificador da Requisição de Terminação é copiado para o campo Identificador do pacote de Reconhecimento de Terminação.

O campo Dados é zero ou mais octetos e contém dados não interpretados para uso pelo remetente. Os dados podem consistir em qualquer valor binário. O final do campo é indicado pelo Length (Comprimento).

Aqui está um exemplo de saída de debug ppp negotiation quando você recebe um pacote 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 

Exemplo de Seqüência de Troubleshooting

Esta seção descreve um exemplo de cenário de Troubleshooting para um link POS usando o encapsulamento PPP. Ele usa as seguintes configurações:

interface POS1/0 
 ip address 1.1.1.6 255.255.255.0 
 no ip directed-broadcast 
 encapsulation ppp 
 crc 16 
 clock source internal

interface POS2/0 
 ip address 1.1.1.5 255.255.255.0 
 no ip directed-broadcast 
 encapsulation ppp 
 crc 16

Observação: essas depurações foram capturadas em dois roteadores em uma configuração de laboratório back-to-back. Assim, a temporização é definida como interna em um lado e como padrão para linha no outro lado.

negociação de debug ppp

Esta saída ilustra a troca de pacotes capturada com debug ppp negotiation durante a fase de estabelecimento de link do LCP.

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

(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

depurar pacote ppp

Esta saída ilustra a troca de pacotes capturada com debug ppp packet enquanto um link está sendo estabelecido. Esta depuração captura o valor do campo do protocolo no pacote PPP. O RFC 1661 define o campo Protocolo como um ou dois octetos. O valor nesse campo identifica o datagrama encapsulado no campo Informações do pacote.

Os valores do campo Protocol no intervalo de "0***" a "3***" identificam o protocolo de camada de rede de pacotes específicos e os valores no intervalo de "8***" a "b***" identificam pacotes pertencentes aos protocolos de controle de rede (NCPs) associados, se houver. Valores do campo Protocol no intervalo de "c***" a "f***" identificam pacotes como protocolos de controle da camada de enlace (como o LCP). Há também vários valores específicos do fornecedor. Clique aqui para obter uma lista completa de valores dos campos do protocolo PPP.

(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

(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 Troubleshooting

Uma interface POS com encapsulamento PPP ou HDLC suporta dois mecanismos para alertá-lo sobre uma falha de link: Keepalives de Camada 2 e alarmes de camada SONET. As manutenções de atividade demoram mais para reportar um problema do que a estrutura de alarme SONET inerente. No entanto, os keepalives de Camada 2 são úteis porque verificam o caminho da CPU da placa de linha para a CPU da placa de linha, em vez de framer para framer, como fazem os alarmes de nível SONET. O PPP reage mais rapidamente às alterações de estado do link, já que o LCP é desativado imediatamente. Por outro lado, o HDLC deve esgotar o tempo das manutenções de tarefas.

Em uma configuração back-to-back entre dois roteadores, o recebimento de um dos fios de fibra interrompe a conectividade da Camada 1, e ambas as interfaces POS mudam de estado para down/down. No entanto, quando duas interfaces POS do roteador se conectam através de uma nuvem Telco com equipamento SONET/SDH, as informações de perda da Camada 1 não são propagadas para a extremidade remota. Nessa configuração, os keepalives são o mecanismo para desativar o link.

Considere esta configuração.

Veja o que ocorre quando você transfere um filamento de cabo de transmissão no link de SDHb para SDHa:

• O roteador 7507a não recebe nenhum keepalive.

• O roteador 7507b vê keepalives do 7507a, já que a fibra de recepção ainda está funcionando. Use debug serial interface para confirmar isso.

Como alternativa, ao executar esse teste, execute o comando show controller pos, que exibe alarmes SONET. Você deverá visualizar um sinal de indicação de alarme de caminho (IP-AIS) no roteador 7507a e uma indicação de defeito remoto de caminho (P-RDI) no 7507b.

Testes de circuito de retorno

Se a saída do comando show interfaces pos indicar que a linha de série for mais alta, e o protocolo de linha estiver mais baixo, use os testes de loopback para determinar a origem do problema. Execute primeiro um teste de loop local e depois um teste remoto. Consulte Entendendo os Modos de Loopback em Cisco Routers para obter orientação.

Observação: altere o encapsulamento de PPP para HDLC ao usar loopbacks. O protocolo de linha em uma interface configurada com PPP é ativado somente quando todas as sessões de LCP e NCP são negociadas com êxito.

Status do protocolo de linha com APS

Uma interface POS configurada para comutação de proteção automática (APS - Automatic Protection Switching) desativará o protocolo de linha se a interface for o canal de proteção e não o canal em funcionamento. Considere este exemplo de topologia:

Esse exemplo de saída de registro foi capturado depois que o cabeamento de fibra na interface POS 1/0 do GSRb foi removido. Observe as alterações no status do protocolo de linha nas duas interfaces quando ocorre o APS Switchover. Observe também as alterações nos estados de adjacência do OSPF (Open Shortest Path First). (Consulte a página de suporte da tecnologia APS para obter mais informações.)

*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 o APS em uma interface POS com encapsulamento PPP. O PPP não reconhece o APS. Se uma interface estiver ativa/inativa devido à desseleção do APS, o PPP tenta redefinir a interface e transmite continuamente pacotes de negociação do PPP.

Além disso, desative os keepalives para evitar falhas desnecessárias no protocolo de linha. Os keepalives são desabilitados automaticamente na maioria dos hardwares de roteadores POS.

Uma interface POS do Cisco 12000 Series no modo de proteção ou de funcionamento do APS pode ficar presa em um estado ativo/inativo (mesmo com um loopback) quando o APS está desativado. Outra placa inserida no mesmo slot apresenta esse problema. Mova a placa para um novo slot para restaurar o status de protocolo de linha adequado. Esse problema é resolvido no Cisco IOS Software Release 12.0(19)S sob o bug da Cisco ID CSCdt43759 (somente clientes registrados) .

Use estas etapas como uma solução:

1. Configure o comando aps protect.

2. Emita o comando aps force 1:

3. Configure o comando no aps protect:

Problemas conhecidos

Observe estas advertências ao solucionar problemas de protocolo de linha com interfaces POS:

• Uma interface PA-POS pode ser redefinida continuamente depois que o encapsulamento é alterado de PPP para HDLC. Esse problema é reportado no PA-POS no bug da Cisco ID CSCdk30893 (somente clientes registrados) e resolvido no bug da Cisco ID CSCdk18777 (somente clientes registrados) e no bug da Cisco ID CSCdk13757 (somente clientes registrados) para várias interfaces que suportam encapsulamento PPP e HDLC. O problema é causado quando o PPP não é completamente desligado quando o encapsulamento foi alterado.

• Uma interface POS configurada com encapsulamento e keepalives HDLC sofre flaps de interface repetidos em vez de desativar o protocolo de linha quando os keepalives não são recebidos da extremidade remota. Esse problema é resolvido no bug da Cisco ID CSCdp86387 (somente clientes registrados) .

Informações Relacionadas

• Suporte à tecnologia óptica
• Suporte Técnico e Documentação - Cisco Systems