Óptica : Synchronous Optical NETwork (SONET)

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

19 Setembro 2015 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


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. Igualmente anda você através de um scenario de Troubleshooting típico baseado em uma instalação de laboratório documentada.

Interprete o comando show interface pos

Para fins do documento, a saída da posição da relação da mostra é enquanto 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

A referência de comandos do � do Cisco IOS indica que o status do campo do protocolo de linha “indica se os processos de software que seguram o protocolo de linha consideram a linha útil (isto é, o Keepalives é bem sucedido) ou se ele esteve tomado para baixo por um administrador.”

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

  • Encapsulamento — Método de encapsulamento atribuído à relação.

  • loopback - indica se o circuito de retorno está configurado.

  • manutenção de atividade – Indica se as manutenções de atividade estão definidas.

Visão geral da pilha de protocolo POS

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

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

Interfaces POS são compatíveis com múltiplos encapsulamentos - HDLC, PPP e Frame Relay. Assim, o Packet over SONET é mais exatamente PPP over SONET ou HDLC over SONET. Este documento não cobre o Encapsulamento frame relay.

O PPP e o HDLC são estreitamente relacionados e compartilham destas características:

  • Forneça uma estrutura de enquadramento os encabeçamentos e os reboques. 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. No HDLC e no PPP, a delineação de frame é fornecida por meio de um padrão de interframe fill ou de um teste padrão especial da quietude. O teste 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.

Use comandos debug

A saída de vários comandos debug privileged exec fornece relativo à informação diagnóstico ao status do protocolo e à atividade de rede para muitos eventos de comunicação inter-redes.

cuidado Cuidado: Desde que resultado do debug é atribuído uma alta prioridade no processo de CPU, pode tornar o sistema inusável. 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.

Estes comandos debug são úteis para quando você pesquisa defeitos problemas da 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 manutenção de atividades 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 ? Exibe pacotes de PPP transmitidos durante a inicialização de PPP, em que as opções de PPP são negociadas.

  • debugar o pacote ppp — Pacotes PPP das mostras que estão sendo enviados e recebidos. Esse comando exibe os dumps de pacote de nível baixo.

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

Refira pesquisando defeitos problemas de linha serial para mais informação.

O protocolo de linha está desconectado com HDLC

HDLC é o tipo de encapsulamento padrão em uma interface de roteador POS. O HDLC é um internacional padrão, mas as implementações de fornecedor variam uns ou vários campos ou o encabeçamento ou o reboque em tamanho e formatam-nos. A especificação de Telecordia GR-253, que define o SONET, discute o mapeamento de HDLC sobre SONET (veja a edição 3, a seção 3.4.2.3, pp.3-59.) Especifica que o quadro HDLC byte-esteja alinhado com o sonet frame, e igualmente especifica um aparelho de interferência auto-sincronizante, uma verificação de redundância cíclica (CRC), e o uso do teste padrão da bandeira HDLC como o interframe fill esclarecer a natureza variável de quadros de chegada HDLC.

Se o comando show interface pos mostra que a linha e o protocolo estão para baixo com encapsulamento de HDLC, você pode usar o comando debug serial interface 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 por 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 seqüê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 seqüência myseq do roteador que recebeu um pacote de manutenção de atividade do roteador remoto.

Se os valores de keepalive no mineseq, yourseen, e os campos myseen não estão incrementando em cada linha subsequente de saída, há um problema em uma extremidade da conexão. Quando a diferença nos valores nos campos do myseq e do mineseen excede três, a linha vai para baixo e a relação é restaurada.

Este é exemplo de saída do comando debug serial interface para uma conexão de HDLC quando o Keepalives é recebido corretamente pelo 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 é exemplo de saída do comando debug serial interface para uma conexão de HDLC quando a interface remota é fechada e a interface local falta 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 1661leavingcisco.com define o PPP como um protocolo. Apoio PPP das interfaces pos no High-Level Data Link Control (HDLC) - como a moldação, como especificado no RFC 1662leavingcisco.com , para o encapsulamento de dados na camada 2. O formato de frame para o PPP no frame de HDLC é mostrado nesta figura.

gspos_a2.gif

A RFC 2615 especifica a utilização de encapsulamento PPP sobre enlaces SONET ou SDH. O PPP foi projetado para o uso nos link de ponto a ponto e é apropriado para os links SONET ou SDH, que são fornecida como circuitos Point-to-Point mesmo nas 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 a esta fase produz um evento ASCENDENTE ao protocolo de controle de link (LCP), que forneça diversas funções. Uma função é determinação 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.

Então, o PPP deve enviar pacotes do protocolo network control (NCP) para escolher e configurar uns ou vários protocolos de 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 alista as três classes de pacotes de LCP:

Classe de pacotes LCP Tipos de Pacotes LCP Propósito
Configuração de link Configure-Request, Configure-Ack, Configure-Nak e Configure-Reject Utilizado para estabelecer e configurar um enlace.
Terminação de enlace Terminate-Request e Terminar-ACK Usado para terminar um link.
Manutenção de Link Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply e Discard-Request Utilizado para gerenciar e depurar um link

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 a fase da configuração de 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 

Nota: Uma interface pos configurada com o encapsulamento PPP tenta continuamente estabelecer uma sessão de 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)

A requisição de eco e os pacotes de resposta de eco LCP fornecem um mecanismo de loopback da camada 2 para ambos sentidos 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 keepalive PPP.

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

Estes pacotes de LCP incluem estes campos chaves:

  • Código - 9 para Echo-Request e 10 para Echo-Reply.

  • Identificador — Na transmissão, o campo do identificador deve ser mudado sempre que o índice das alterações de campo de dados e sempre que uma resposta válida foi recebida para uma requisição precedente. Para retransmissões, o identificador pode permanecer inalterado. Na recepção, o campo do identificador da requisição de eco é copiado no campo do identificador do pacote de resposta de eco.

  • Número mágico — O campo de número mágico é quatro octetos, e auxílios na detecção de links que estão na condição de loopback. Até que a opção de configuração de número mágico esteja negociada com sucesso, o número mágico 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 de dados é zero ou mais octetos, e contêm dados não interpretados para o uso do remetente. Os dados podem consistir em todo o valor binário. O final do campo é indicado pelo Length (Comprimento).

Está aqui um exemplo de debuga a negociação ppp quando o Keepalives é permitido:

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 terminar o link a qualquer hora. 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.

Os usos LCP terminam pacotes para fechar o link. O remetente de Terminate-Request deve desligar após ter recebido um Terminar-ACK, ou após o reinício o contador expira. 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).

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

Termine pacotes de LCP incluem estes campos chaves:

  • Código — 5 para Terminate-Request e 6 para o Terminar-ACK.

  • Identificador — Na transmissão, o campo do identificador deve ser mudado sempre que o índice das alterações de campo de dados, e sempre que uma resposta válida foi recebida para uma requisição precedente. 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 de dados é zero ou mais octetos, e contêm dados não interpretados para o uso do remetente. Os dados podem consistir em todo o valor binário. O final do campo é indicado pelo Length (Comprimento).

Está aqui um exemplo de debuga saídas de negociação ppp 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 hipótese de Troubleshooting para um link POS usando o encapsulamento PPP. Usa estas configurações:

Configuração de Roteador 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

Configuração do Roteador B
interface POS2/0 
 ip address 1.1.1.5 255.255.255.0 
 no ip directed-broadcast 
 encapsulation ppp 
 crc 16

Nota: Estes debugam foram capturados em dois Roteadores em uma instalação de laboratório lado a lado. Assim, cronometrar é ajustado a interno em um lado e para optar para alinhar na outra extremidade.

negociação de debug ppp

Esta saída ilustra o intercâmbio de pacotes capturado com debuga a negociação ppp durante a fase de estabelecimento de enlace do LCP.

Saída de depuração do roteador 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

Saída de depuração do roteador 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

depurar pacote ppp

Esta saída ilustra o intercâmbio de pacotes capturado com debuga o pacote ppp quando um link for 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). Igualmente há uns vários valores específicos de fornecedor. Clique aqui para uma lista completa de valores de campo do protocolo PPPleavingcisco.com .

Saída de depuração do roteador 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

Saída de depuração do roteador 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 Troubleshooting

Uma interface pos com o PPP ou o encapsulamento de HDLC apoia dois mecanismos para alertá-lo de uma falha do link: Keepalives da camada 2 e alarmes da camada SONET. As manutenções de atividade demoram mais para reportar um problema do que a estrutura de alarme SONET inerente. Contudo, o Keepalives da camada 2 é útil porque verifica o trajeto da placa de linha CPU à placa de linha CPU, um pouco do que o conspirador ao conspirador como os alarmes de nível de SONET fazem. O PPP reage mais rapidamente para ligar mudanças de estado desde que o LCP vem para baixo imediatamente. Por outro lado, o HDLC deve esgotar o tempo das manutenções de tarefas.

Em uma instalação back-to-back entre dois Roteadores, puxar um dos fiações de fibra quebra a Conectividade do Layer 1, e ambas as interfaces pos mudam o estado a para baixo/para baixo. Contudo, quando duas interfaces pos do roteador conectam através de um nuvem Telco com o equipamento SONET/SDH, a informação de perda do Layer 1 não é propagada à extremidade remota. Nesta configuração, o Keepalives é o mecanismo para derrubar o link.

Considere esta instalação.

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

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

  • O roteador 7507b vê o Keepalives de 7507a desde que a fibra da recepção ainda está trabalhando. O uso debuga a interface serial para confirmar este.

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 um teste de loop local primeiramente, e então um teste remoto. Refira compreendendo modos loopback em roteadores Cisco para a orientação.

Nota: Mude o encapsulamento do PPP ao HDLC quando você usa laços de retorno. O protocolo de linha em uma relação configurada com PPP vem acima de somente quando todo o LCP e sessões de NCP são negociados com sucesso.

Status do protocolo de linha com APS

Uma interface pos configurada para o Automatic Protection Switching (APS) derruba o protocolo de linha se a relação é o canal da proteção e não o canal de funcionamento. Considere este exemplo de topologia:

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

Este registro de saída da amostra foi capturado depois que o cabeamento de fibra na relação POS 1/0 de GSRb foi removido. Observe as alterações no status do protocolo de linha nas duas interfaces quando ocorre o APS Switchover. Igualmente note as mudanças em estados da adjacência do Open Shortest Path First (OSPF). (Refira a página de suporte de tecnologia APS para mais informação.)

*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 o encapsulamento PPP. O PPP não está ciente do APS. Se uma relação é up/down devido à ausência de seleção de APS, o PPP tenta restaurar a relação e transmite continuamente pacotes de negociação PPP.

Além, o Keepalives do desabilitação para evitar o protocolo de linha desnecessário bate. As manutenções de atividade são desabilitadas automaticamente na maioria dos hardwares de roteadores POS.

Uma interface pos do Cisco 12000 Series no funcionamento de APS ou modo de proteção pode tornar-se colada em um estado up/down (mesmo com um laço de retorno) quando o APS é desabilitado. Um outro cartão introduzido no mesmo entalhe experimenta este problema. Mova o cartão para um entalhe novo para restaurar o status de protocolo de linha apropriado. Este problema é resolvido no Cisco IOS Software Release 12.0(19)S sob a identificação de bug Cisco CSCdt43759 (clientes registrados somente).

Use estas etapas como uma ação alternativa:

  1. Configure o comando aps protect.

  2. Emita o comando aps force 1:

  3. Configure o comando no aps protect:

Problemas conhecidos

Note estas advertências quando você pesquisa defeitos problemas do protocolo de linha com interfaces pos:

  • Uma relação PA-POS pôde restaurar continuamente depois que o encapsulamento é mudado do PPP ao HDLC. Este problema é relatado contra o PA-POS na identificação de bug Cisco CSCdk30893 (clientes registrados somente) e resolvido na identificação de bug Cisco CSCdk18777 (clientes registrados somente) e na identificação de bug Cisco CSCdk13757 (clientes registrados somente) para as várias relações que apoiam o PPP e o encapsulamento de HDLC. O problema é causado quando o PPP não é fechado completamente quando o encapsulamento esteve mudado.

  • Uma interface pos configurada com o encapsulamento de HDLC e o Keepalives submete-se a aletas repetidas da relação um pouco do que trazendo abaixo do protocolo de linha quando o Keepalives não é recebido da extremidade remota. Este problema é resolvido na identificação de bug Cisco CSCdp86387 (clientes registrados somente).

Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Informações Relacionadas


Document ID: 16152