WAN : Point-to-Point Protocol (PPP)

Compreendendo a saída debug ppp negotiation

3 Abril 2008 - Tradução Manual
Outras Versões: Versão em PDFpdf | Tradução por Computador (29 Julho 2013) | Inglês (4 Fevereiro 2010) | Feedback


Índice

Introdução
Pré-requisitos
     Requisitos
     Componentes Usados
     Convenções
Fase de Negociação PPP
Pacotes de Negociação do PPP: A Descrição
LCP, Autenticação e Estágio NCP
Solucionando Problemas com a Saída debug ppp negotiation
Leia a saída de debug ppp negotiation
Exemplo de Saída debug ppp negotiation
Glossário e Mensagens Comuns
     Geral
     LCP
     Autenticação
     NCP
Discussões relacionadas da comunidade de suporte da Cisco
Informações Relacionadas

Introdução

Nos aplicativos relacionados a discagem, o PPP é o tipo de encapsulamento mais comumente usado. O PPP permite que duas máquinas em um link de comunicação ponto-a-ponto negociem vários parâmetros de autenticação, compressão e protocolos de Camada 3 (L3), como IP. Uma falha na negociação de PPP entre dois roteadores causa uma falha na conexão.

O comando debug ppp negotiation permite que você exiba transações da negociação de PPP, identifique o problema ou o estágio em que o erro ocorre e desenvolva uma resolução. Entretanto, é imperativo que você entenda a saída do comando debug ppp negotiation. Este documento fornece um método abrangente para ler a saída do comando debug ppp negotiation.

Pré-requisitos

Requisitos

Os leitores deste documento devem garantir o cumprimento das seguintes condições:

  • O PPP deve ser habilitado na interface de ambos os roteadores. Execute o comando encapsulation ppp para fazer isso.

  • Execute este comando para habilitar os formatos de tempo em milissegundos no roteador:

    Router(config)# service timestamp debug datetime msec
                   

    Para obter mais informações sobre comandos de depuração, consulte Informações Importantes sobre os Comandos de Depuração.

Observação: A negociação PPP entre dois correspondentes de discagem não pode começar, a menos que a camada inferior (ISDN, interface física, linha de discagem etc) sob as funções do PPP funcione perfeitamente. Por exemplo, se você desejar executar PPP no ISDN, todas as camadas ISDN devem estar ativas. Caso contrário, o PPP não será iniciado.

Componentes Usados

Este documento não está restrito a versões específicas de software e de hardware.

Convenções

Consulte Convenções de Dicas Técnicas da Cisco para obter mais informações sobres as convenções de documentos.

Fase de Negociação PPP

O link passa por várias fases no processo de negociação de PPP, como mostrado na tabela. O resultado final é a ativação ou a desativação do PPP.

Fase

Descrição

DESATIVADO

Nessa fase, o PPP está desativado. Esta mensagem é exibida após a derrubada do link e do PPP:

*Mar  3 23:32:50.296: BR0:1 PPP: Phase is DOWN

ESTABELECENDO

O PPP muda para essa fase quando recebe uma indicação de que a camada física está ativa e pronta para uso. A negociação de LCP 1 ocorre nessa fase.

*Mar  3 23:32:06.884: BR0:1 PPP: Phase is ESTABLISHING

AUTENTICANDO

Se a autenticação do PPP (CHAP2 ou PAP3) for desejada no link, então o PPP entra em transição nesta fase. Lembre-se que a autenticação do PPP é opcional.

*Mar 3 23:32:06.952: BR0:1 PPP: Phase is AUTHENTICATING

ATIVO

Quando a autenticação tiver terminado, o PPP passa para a fase ATIVA. A negociação de NCP 4 ocorre nessa fase.

*Mar  3 23:42:53.412: BR0:1 PPP: Phase is UP

CONCLUINDO

Nessa fase, o PPP está desativado.

*Mar  3 23:43:23.256: BR0:1 PPP: Phase is TERMINATING

1. LCP = Link Control Protocol

2. CHAP = Challenge Handshake Authentication Protocol

3. PAP = Password Authentication Protocol

4. NCP = Network Control Protocol

Este diagrama exibe as transições de fase do PPP:

debug_ppp_negotiation3.gif

Pacotes de Negociação do PPP: A Descrição

Esta tabela inclui a descrição dos pacotes de negociação do PP usados na negociação de LCP e NCP:

Pacote

Código

Descrição

CONFREQ

Configure-Request

Para abrir uma conexão com o correspondente de discagem, o dispositivo transmite essa mensagem juntamente com as opções e os valores de configuração que o remetente deseja que o correspondente de discagem suporte. Todas os valores e as opções são negociados simultaneamente. Se o correspondente de discagem responder com uma mensagem CONFREJ ou CONFNAK, o roteador envia outro CONFREQ com outro conjunto de opções ou valores.

CONFREJ

Configure-Reject

Se alguma opção de configuração recebida na mensagem CONFREQ não for aceitável ou reconhecível, o roteador responde com uma mensagem CONFREJ. A opção inaceitável (a partir da mensagem de CONFREQ) está incluída na mensagem de CONFREJ.

CONFNAK

Configure-NAK1

Se a opção da configuração recebida for reconhecível e aceitável, mas algum valor não for aceitável, o roteador transmitirá uma mensagem CONNAK. O roteador complementa a opção e o valor que pode aceitar na mensagem CONFNAK de forma que o correspondente de discagem possa incluir essa opção na próxima mensagem CONFREQ.

CONFACK

Configure-ACK2

Se todas as opções mensagem CONFREQ forem reconhecíveis e os valores forem aceitáveis, o roteador transmitirá uma mensagem CONNAK.

TERMREQ

Terminate-Request

Essa mensagem é utilizada para iniciar um fechamento de LCP.

TERMACK

Terminate-ACK

Esta mensagem é transmitida em resposta à mensagem TERMREQ.

1. NAK = Negative Acknowledge (Reconhecimento Negativo)

2. ACK = Acknowledge (Reconhecer)

Observação: Cada correspondente de discagem pode enviar CONFREQs com a opção ou o valor que deseje que o correspondente de discagem suporte. Isso pode fazer com que as opções negociadas em cada sentido sejam diferentes. Por exemplo, um lado pode desejar autenticar o correspondente de discagem automaticamente, enquanto o outro, não.

LCP, Autenticação e Estágio NCP

Em algumas das fases de PPP descritas previamente, o PPP também entra em estágios específicos como negociação de LCP, autenticação e negociação de NCP. Para obter mais informações, consulte RFC 1548 leavingcisco.com e RFC 1661 leavingcisco.com.

LCP (Fase Obrigatória)

A LCP é a fase em que os parâmetros para estabelecer, configurar e testar a conexão do link de dados são negociados. Um estado aberto do LCP significa que o LCP foi concluído com êxito, enquanto um estado fechado de LCP indica uma falha de LCP.

Este diagrama mostra uma exibição conceitual de um cumprimento de LCP:

debug_ppp_negotiation1.gif

A negociação LCP também utiliza um parâmetro chamado MagicNumber, utilizado para determinar se o link tem o loop fechado. Uma seqüência de caracteres aleatória é enviada pelo link, caso o mesmo valor seja retornado, e, em seguida, o roteador determina se o link terá loop.

Autenticação (Fase Opcional por Padrão)

Nesse estágio, a autenticação é realizada com o protocolo de autenticação (CHAP ou PAP) em acordo com a negociação de LCP. Para obter informações relacionadas a PAP, consulte Configuring and Troubleshooting PPP Password Authentication Protocol (PAP) (Configurando e Solucionando Problemas do Password Authentication Protocol (PAP) do PPP)

Para obter informações relacionadas a CHAP, consulte Entendendo e Configurando a Autenticação CHAP do PPP .

Observação: A autenticação é opcional e o PPP só entra nesse estágio se precisar ser autenticado.

NCP (Fase Obrigatória)

Essa fase é usada para estabelecer e configurar diferentes tipos de protocolos de camada de rede. O protocolo L3 mais comumente negociado é o IP. Os roteadores trocam mensagens de IP Control Protocol (IPCP) para negociar opções específicas ao protocolo (IP, neste exemplo).

RFC 1332 leavingcisco.com diz que o IPCP negocia duas opções: Compressão e atribuições de endereço IP. Entretanto, o IPCP também é usado para passar informações relacionadas a rede, como servidores principais e de backup do Windows Name Service (WINS) e do Domain Name System (DNS).

A negociação ocorre com o uso de mensagens CONF, como descrito na seção Pacotes de Negociação de PPP : uma descrição, neste documento.

Solucionando Problemas com a Saída debug ppp negotiation

Quando você ler a saída de comando debug ppp negotiation para fins de solução de problemas, siga estas instruções:

  1. Identifique as transições de fase na saída do comando debug. Determine a fase de conexão mais afastada atingida, como ATIVO ou AUTENTICANDO. Isso pode ajudá-lo a identificar a fase em que houve falha na conexão. Para obter mais informações sobre as fases, consulte a seção Fases de Negociação do PPP .

  2. Para saber sobre a fase em que a falha ocorreu, observe as mensagens que indicam que o LCP, a autenticação ou o NCP (conforme apropriado) tenham sido bem-sucedidos.

    • O estado do LCP deve ser aberto. Você também pode observar as últimas mensagens CONFACK de entrada e de saída para verificar se os parâmetros que você exige têm sido negociados.

    • A autenticação deve ser bem-sucedida. Se você usar autenticação bidirecional, todas as transações deverão ser bem-sucedidas. Para obter mais informações relacionadas a soluções de problemas relacionados a falhas do PPP, consulte Solucionando Problemas da Autenticação do PPP (CHAP ou PAP).

    • O estado do IPCP deve ser aberto. Verifique se o endereçamento está correto e se existe uma rota instalada para o correspondente de discagem.

Leia a saída de debug ppp negotiation

A maioria das linhas da saída do comando debug ppp negotiation são caracterizadas por:

  1. O formato de tempo - Formatos de tempo em milissegundos são úteis. Consulte a seção Pré-requisitos deste documento para obter mais informações.

  2. Interface e Número de interface — este campo é útil quando as conexões depuradas usam várias conexões ou quando as conexões transitam por várias interfaces. Por exemplo, determinadas conexões (como chamadas multilink) são controladas pela interface física no começo, mas posteriormente são controladas pela interface do discador ou pela interface de acesso virtual.

  3. Tipo de mensagem de PPP — este campo indica se a linha é uma mensagem de PPP geral, LCP, CHAP, PAP ou IPCP.

  4. Sentido da mensagem — Um I indica um pacote de entrada, e um O indica um pacote de saída. Este campo pode ser usado para determinar se a mensagem foi gerada ou recebida pelo roteador.

  5. Mensagem — este campo inclui a transação específica em negociação.

  6. ID — este campo é usado para corresponder e coordenar mensagens solicitadas com as mensagens de resposta apropriadas. Você pode usar o campo ID para associar uma resposta com uma mensagem de entrada. Essa opção é especialmente útil quando a mensagem de entrada e a resposta estão muito separadas na saída de depuração.

  7. Comprimento — este campo indica o comprimento do campo de informações. Este campo não é importante para a solução de problemas gerais.

Observação: Os campos 4 a 7 podem não ser exibidos em todas as mensagens de PPP, dependendo do objetivo da mensagem.

Observação: Este exemplo ilustra os campos:

debug_ppp_negotiation2.gif

Exemplo de Saída debug ppp negotiation

Esta é uma descrição de saída do comando debug ppp negotiation:

maui-soho-01#debug ppp negotiation
PPP protocol negotiation debugging is on
maui-soho-01#
*Mar  1 00:06:36.645: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up

               !--- A Camada Física (Interface BRI) está ativa. A negociação do PPP
!--- só pode começar agora.
            
*Mar  1 00:06:36.661: BR0:1 PPP: Treating connection as a callin
*Mar  1 00:06:36.665: BR0:1 PPP: Phase is ESTABLISHING, Passive Open
[0 sess, 0 load]

               !--- A Fase do PPP é ESTABELECENDO. A negociação do LCP pode ocorrer agora.
            
*Mar  1 00:06:36.669: BR0:1 LCP: State is Listen
*Mar  1 00:06:37.034: BR0:1 LCP: I CONFREQ [Listen] id 7 len 17

               !--- Este é o CONFREQ de entrada. O campo de ID é 7.
            
*Mar  1 00:06:37.038: BR0:1 LCP:    PAP AuthProto (0x0304C023)
*Mar  1 00:06:37.042: BR0:1 LCP:    MagicNumber 0x507A214D (0x0506507A214D)
*Mar  1 00:06:37.046: BR0:1 LCP:    Retorno de chamada 0  (0x0D0300)

               !--- O correspondente de discagem solicitou:
!--- Opção: Protocolo de Autenticação, Valor: PAP
!--- Opção: MagicNumber (usado para detectar loopbacks e é sempre enviado)
!--- Opção: Retorno de Chamada, Valor: 0 (esse valor é para o Retorno de Chamada do PPP. O MS Callback usa 6)
            
*Mar  1 00:06:37.054: BR0:1 LCP: O CONFREQ [Listen] id 4 len 15

               !--- Este é um CONFREQ de saída com parâmetros a serem implementados pelo correspondente de discagem.
!--- Observe que o Campo ID é 4, portanto não há relação com o anterior.
!---mensagem CONFREQ.
            
*Mar  1 00:06:37.058: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 00:06:37.062: BR0:1 LCP:    MagicNumber 0x1081E7E1 (0x05061081E7E1)

               !--- Requisição desse roteador:
!--- Opção: Protocolo de Autenticação; Valor: CHAP
!--- Opção: MagicNumber (usado para detectar loopbacks e é sempre enviado.)
            
*Mar  1 00:06:37.066: BR0:1 LCP: O CONFREJ [Listen] id 7 len 7

               !--- Este é um CONFREJ de saída para mensagem com ID de Campo 7.
!--- Essa é a resposta para o CONFREQ recebido primeiro.
            
*Mar  1 00:06:37.070: BR0:1 LCP:    Retorno de Chamada 0  (0x0D0300)

               !--- A opção que o roteador rejeita é o Retorno de Chamada.
!--- Se o roteador queria fazer retorno de chamada da MS em vez de retorno de chamada do PPP,
!--- ele teria enviado uma mensagem CONFNAK.
            
*Mar  1 00:06:37.098: BR0:1 LCP: I CONFACK [REQsent] id 4 len 15

               !--- Este é um CONFACK de entrada para uma mensagem com ID de Campo 4.
            
*Mar  1 00:06:37.102: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 00:06:37.106: BR0:1 LCP:    MagicNumber 0x1081E7E1 (0x05061081E7E1)

               !--- O correspondente de discagem pode suportar todos os parâmetros solicitados.
            
*Mar  1 00:06:37.114: BR0:1 LCP: I CONFREQ [ACKrcvd] id 8 len 14

               !--- Esta é uma mensagem CONFREQ de entrada; o Campo de ID é 8.
!--- Essa é uma nova mensagem CONFREQ do correspondente de discagem em resposta à CONFREJ id:7
            
*Mar  1 00:06:37.117: BR0:1 LCP:    PAP AuthProto (0x0304C023)
*Mar  1 00:06:37.121: BR0:1 LCP:    MagicNumber 0x507A214D (0x0506507A214D)

               !--- O correspondente de discagem solicitou:
!--- Opção: Protocolo de Autenticação; Valor: PAP
!--- Opção: MagicNumber (usado para detectar loopbacks e é sempre enviado.)
            
*Mar  1 00:06:37.125: BR0:1 LCP: O CONFNAK [ACKrcvd] id 8 len 9

               !--- Este é um CONFACK de saída para uma mensagem com ID de Campo 8.
            
*Mar  1 00:06:37.129: BR0:1 LCP:    CHAP AuthProto (0x0305C22305)

               !--- Este roteador reconhece a opção Protocolo de Autenticação,
!--- mas não aceita o valor do PAP. Na mensagem de CONFNAK,
!--- ele sugere CHAP.
            
*Mar  1 00:06:37.165: BR0:1 LCP: I CONFREQ [ACKrcvd] id 9 len 15

               !--- Esta é uma mensagem CONFREQ de entrada; o Campo de ID é 9.
            
*Mar  1 00:06:37.169: BR0:1 LCP:    CHAP AuthProto (0x0305C22305)
*Mar  1 00:06:37.173: BR0:1 LCP:    MagicNumber 0x507A214D (0x0506507A214D)

               !--- Autenticação CHAP é solicitada.
            
*Mar  1 00:06:37.177: BR0:1 LCP: O CONFACK [ACKrcvd] id 9 len 15

               !--- Este é um CONFACK de saída para uma mensagem com ID de Campo 9.
            
*Mar  1 00:06:37.181: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 00:06:37.185: BR0:1 LCP:    MagicNumber 0x507A214D (0x0506507A214D)
*Mar  1 00:06:37.189: BR0:1 LCP: O estado é aberto
            
               !--- Indica que o estado do LCP é Aberto.
            
*Mar  1 00:06:37.193: BR0:1 PPP: Fase AUTENTICANDO por ambos [0 sess, 0 load]

               !--- A Fase do PPP é AUTENTICANDO. A autenticação do PPP ocorre agora.
!--- A autenticação bidirecional é realizada agora (indicada pela palavra-chave ambos).
            
*Mar  1 00:06:37.201: BR0:1 CHAP: O CHALLENGE id 4 len 33 from "maui-soho-01"

               !--- Este é o Desafio CHAP de saída.
!--- No LCP, os roteadores concordaram em ter o CHAP como protocolo de autenticação.
            
*Mar  1 00:06:37.225: BR0:1 CHAP: I CHALLENGE id 3 len 33 from "maui-soho-03"

               !--- Esta é uma mensagem de Desafio de entrada do correspondente de discagem.
            
*Mar  1 00:06:37.229: BR0:1 CHAP: Waiting for peer to authenticate first
*Mar  1 00:06:37.237: BR0:1 CHAP: I RESPONSE id 4 len 33 from "maui-soho-03"

               !--- Esta é uma mensagem de resposta do correspondente de discagem.
            
*Mar  1 00:06:37.244: BR0:1 CHAP: O SUCCESS id 4 len 4

               !--- Este roteador foi autenticado com êxito pelo correspondente de discagem.
            
*Mar  1 00:06:37.248: BR0:1 CHAP: Processing saved Challenge, id 3
*Mar  1 00:06:37.260: BR0:1 CHAP: O RESPONSE id 3 len 33 from "maui-soho-01"
*Mar  1 00:06:37.292: BR0:1 CHAP: I SUCCESS id 3 len 4

               !--- Esta é uma mensagem de sucesso. Cada lado
!--- autenticou com êxito o outro.
            
*Mar  1 00:06:37.296: BR0:1 PPP: Fase ATIVO [0 sess, 0 load]

               !--- O status do PPP agora é ATIVO. A negociação do NCP (IPCP) começa.
            
*Mar  1 00:06:37.304: BR0:1 IPCP: O CONFREQ [Closed] id 4 len 10
*Mar  1 00:06:37.308: BR0:1 IPCP:    Address 172.22.1.1 (0x0306AC160101)

               !D--- Essa é uma mensagem de saída CONFREQ. Ela indica que
!--- o endereço da máquina local é 172.22.1.1.
            
*Mar  1 00:06:37.312: BR0:1 CDPCP: O CONFREQ [Closed] id 4 len 4
*Mar  1 00:06:37.320: BR0:1 CDPCP: I CONFREQ [REQsent] id 4 len 4
*Mar  1 00:06:37.324: BR0:1 CDPCP: O CONFACK [REQsent] id 4 len 4

               !--- Essas mensagens são para CDP Control Protocol (CDPCP).
            
*Mar  1 00:06:37.332: BR0:1 IPCP: I CONFREQ [REQsent] id 4 len 10
*Mar  1 00:06:37.336: BR0:1 IPCP:    Address 172.22.1.2 (0x0306AC160102)

               !--- Esta é uma mensagem CONFREQ de entrada que indica que o endereço do peer
!--- correspondente de discagem é 172.22.1.2.  Um endereço de 0.0.0.0 indica que o correspondente de discagem
!--- não tem um endereço e solicita ao roteador local o fornecimento do mesmo.
!--- com um endereço na negociação do IPCP.
            
*Mar  1 00:06:37.344: BR0:1 IPCP: O CONFACK [REQsent] id 4 len 10
*Mar  1 00:06:37.348: BR0:1 IPCP:    Address 172.22.1.2 (0x0306AC160102)
*Mar  1 00:06:37.356: BR0:1 IPCP: I CONFACK [ACKsent] id 4 len 10
*Mar  1 00:06:37.360: BR0:1 IPCP:    Address 172.22.1.1 (0x0306AC160101)
*Mar  1 00:06:37.363: BR0:1 IPCP: State is Open

               !--- O estado do IPCP deve ser aberto. Observe que na negociação do IPCP, cada lado
!--- foi aceito no endereço IP do correspondente de discagem e um deles foi atribuído ao correspondente de discagem.
            
*Mar  1 00:06:37.371: BR0:1 CDPCP: I CONFACK [ACKsent] id 4 len 4
*Mar  1 00:06:37.375: BR0:1 CDPCP: O estado é aberto
            
               !--- Indica que o estado do CDPCP é Aberto.
            
*Mar  1 00:06:37.387: BR0 IPCP: Instalar a rota no 172.22.1.2
            
               !--- Uma rota é instalada no correspondente de discagem.
            
*Mar  1 00:06:38.288: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1,
 changed state to up
*Mar  1 00:06:42.609: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to
 maui-soho-03

Glossário e Mensagens Comuns

Geral

CONFREQ (Configure-Request):

Quando a camada mais baixa se torna disponível (Ativa), uma CONFREQ é envaida ao início da primeira fase do PPP (Fase LCP). Ela é usada nas fases de LCP e NCP como tentativa de configurar a conexão. Para abrir uma conexão com o correspondente de discagem, o dispositivo transmite essa mensagem juntamente com as opções e os valores de configuração que o remetente deseja que o correspondente de discagem suporte. Todas os valores e as opções são negociados simultaneamente. Se o correspondente de discagem responder com uma mensagem CONFREJ ou CONFNAK, o roteador envia outro CONFREQ com outro conjunto de opções ou valores.

CONFACK (Configure-Acknowledge):

Se todas as opções mensagem CONFREQ forem reconhecíveis e os valores forem aceitáveis, o roteador transmitirá uma mensagem CONNAK.

CONFREJ (Rejeição da Configuração):

Se alguma opção de configuração recebida na CONFREQ não for aceitável ou reconhecível, o roteador responde com uma mensagem CONFREJ. A opção inaceitável (de CONFREQ) está inclusa na mensagem CONFREJ.

CONFACK (Reconhecimento Negativo da Configuração):

Se a opção da configuração recebida for reconhecível e aceitável, mas algum valor não for aceitável, o roteador transmitirá uma mensagem CONNAK. O roteador complementa a opção e o valor que pode aceitar na mensagem CONFNAK de forma que o correspondente de discagem possa incluir essa opção na próxima mensagem CONFREQ.

ECHOREQ (Solicitação de Eco) e ECHOREP (Resposta de Eco):

O PPP usa keepalives para manter a integridade da conexão. Os keepalives são o quadro ECHOREQ enviado a um correspondente de discagem remoto do PPP; esse correspondente de discagem remoto do PPP deve responder com um quadro de ECHOREP ao receber o quadro ECHOREQ. Por padrão, se o roteador perder cinco quadros de ECHOREP, o link será considerado inativo e o PPP será derrubado.

TERMREQ (Solicitação de término):

Este quadro indica que o correspondente de discagem do PPO que enviou o quadro encerrou a conexão do PPP.

TERMACK (reconhecimento de terminação)

Esta mensagem é transmitida em resposta à mensagem TERMREQ. Isso encerra a conexão PPP.

CONCLUINDO

Essa mensagem indica que uma conexão de PPP foi derrubada. Uma conexão de LCP ou NCP pode ser cortada:

  • em um fechamento administrativo (somente LCP).

  • quando o nível inferior vai para fora de serviço (linha de discagem, ISDN e assim por diante).

  • quando negociações fracassam.

  • detecção de circuito on-line.

LCP

ACCM (Asynchronous Control Character Map):

Essa é uma das opções negociadas para LCP dentro do quadro CONFREQ. O ACCM define as seqüências de escape do caractere. O ACCM diz à porta para ignorar os caracteres e controle especificados dentro do fluxo de dados. Se o roteador da outra extremidade da conexão não suportar a negociação do ACCM, a porta é forçada a usar FFFFFFFF. Nesse caso, execute este comando:

            ppp accm match 000a000
         

ACFC (Address and Control Field Compression):

O ACFC é uma opção de LCP que permite que os pontos de extremidade enviem mensagens para frente e para trás com mais eficiência.

AuthProto (Protocolo de Autenticação):

O AuthProto é o tipo de protocolo de autenticação negociado no quadro CONFREQ entre os correspondentes de discagem do PPP para uso na fase de autenticação. Se nenhuma autenticação de PPP for configurada, essa saída não será vista nos parâmetros negociados do quadro CONFREQ. Os valores possíveis são CHAP ou PAP.

Retorno de Chamada "#":

Esta mensagem no cliente indica que a opção de retorno de chamada está em negociação. O número na sintaxe do retorno de chamada indica qual opção de retorno de chamada é negociada. O número 0 é retorno de chamada de PPP normal, enquanto o número 6 indica a opção de retorno de chamada da Microsoft (disponível automaticamente no Cisco IOS® Software Release 11.3(2)T ou posterior).

CHAP (Challenge Handshake Authentication Protocol):

Esta mensagem indica que o protocolo de autenticação em negociação é o CHAP.

EndpointDisc (Discriminador de Ponto Final):

Esta é uma opção de LCP usada para identificar um correspondente PPP em uma conexão PPP Multilink. Para obter mais informações, consulte Critérios para Nomeações de Pacotes de PPP Multilink.

LCP: O estado é aberto

Essa mensagem indica que uma negociação de LCP foi concluída com sucesso.

LQM (Monitoramento de Qualidade de Link)

O LQM está disponível em todas as interfaces seriais que executam o PPP. O LQM monitora a qualidade do link e descarta o link quando a qualidade cai abaixo da porcentagem configurada. As porcentagens são calculadas para os sentidos de entrada e saída. A qualidade de saída é calculada pela comparação do número total de pacotes e bytes enviados com o número total de pacotes em bytes recebidos pelo correspondente de discagem. A qualidade de entrada é calculada pela comparação do número total de pacotes e bytes recebidos com o número total de pacotes em bytes enviados pelo correspondente de discagem.

Quando o LQM é habilitado, são enviados Link Quality Reports (LQRs) em todos os períodos de manutenção de atividade. Os LQRs são enviados no lugar de keepalives. Todos os keepalives são respondidos adequadamente. Se o LQM não estiver configurado, os keepalives serão enviados em todos os períodos de manutenção de atividade, e todos os LQRs serão respondidos com um LQR.

MagicNumber

O suporte a MagicNumber está disponível em todas as interfaces seriais. O PPP sempre tenta negociar MagicNumbers, que são usados para detectar redes com loopback. Uma seqüência de caracteres aleatória é enviada pelo link, caso o mesmo valor seja retornado, e, em seguida, o roteador determina se o link terá loop.

O link pode ou não ser derrubado depois de uma detecção de loopback; depende da utilização do comando down-when-looped .

PAP (Password Authentication Protocol)

Esta mensagem indica que o protocolo de autenticação em negociação para uso nos correspondentes de discagem é o PAP. Para obter informações relacionadas a PAP, consulte Configuring and Troubleshooting PPP Password Authentication Protocol (PAP) (Configurando e Solucionando Problemas do Password Authentication Protocol (PAP) do PPP)

PFC (Protocol Field Compression)

Essa opção liga ou desliga a compressão dos campos do protocolo.

MRRU (Max Receive Reconstructed Unit)

Essa é uma opção de LCP negociada no processo de configuração do LCP de multilink do PPP. Essa opção determina o número máximo de bytes que podem constituir um quadro. Se um MRRU for negociado em LCP, o Multilink PPP (MPPP) não poderá ser executado no link.

MRU (Unidade Máxima Recebida)

A MRU é uma opção de LCP negociada no quadro CONFREQ para negociar o tamanho dos pacotes trocados.

Autenticação

AUTH-REQ (Solicitação de Autenticação)

Esse quadro é enviado do correspondente de discagem do PPP local (em que a autenticação é habilitada) para o correspondente de discagem remoto. Ele pede que o correspondente de discagem remoto envie um nome de usuário e uma senha válidos para autenticação da conexão do PPP. Este quadro é usado somente com PAP.

AUTH-ACK (Reconhecimento da Autenticação)

Esse quadro é enviado no correspondente PPP autenticado para o correspondente PPP de autenticação. Este quadro transporta o par válido de nome de usuário e senha. Este quadro é usado somente quando o PAP é usado para autenticação da conexão do PPP.

AUTH-NAK ou FAILURE

Esse quadro é enviado do correspondente de discagem do PPP autenticado quando ocorre uma falha de autenticação no correspondente de discagem do PPP de autenticação.

CHALLENGE

Esse é o quadro de desafio CHAP que é enviado do peer PPP de autenticação ao peer PPP autenticado. O quadro de desafio consiste de uma ID, um número aleatório e o nome do host do servidor de comunicação local ou o nome do usuário no dispositivo remoto. Este quadro é usado somente quando o CHAP é usado para autenticação da conexão do PPP.

RESPONSE

Esse quadro é a resposta do CHAP enviada do correspondente PPP autenticado para o correspondente PPP de autenticação.

A resposta necessária consiste em duas partes.

  • Uma saída de hash MD5 do segredo compartilhado.

  • O nome do host do dispositivo compartilhado ou o nome de usuário do dispositivo remoto.

Este quadro é usado somente quando o CHAP é usado para autenticação da conexão do PPP.

NCP

Endereço a.b.c.d

  • Em uma mensagem CONFREQ de saída, esse valor indica o endereço IP que o roteador local deseja usar. Se o endereço incluído for 0.0.0.0, a máquina local solicita ao correspondente de discagem para fornecer um endereço de IP que possa usar.

  • Em uma mensagem CONFREQ de entrada, esse valor indica o endereço IP que o correspondente de discagem deseja usar. Se o endereço incluído for 0.0.0.0, o correspondente de discagem solicita à máquina local para fornecer um endereço de IP que possa usar.

  • Em uma mensagem CONFNAK de saída, esse valor indica o endereço IP que o peer deve utilizar, e não o endereço que o peer sugeriu na mensagem CONFREQ.

  • Em uma mensagem CONFNAK recebida, este valor indica o endereço IP que a máquina local deve usar, em vez daquele sugerido na mensagem CONFREQ anterior.

  • Em uma mensagem CONFACK de saída, este valor indica que o endereço IP solicitado pelo peer é aceitável para a máquina local.

  • Em uma mensagem CONFACK de saída, este valor indica que o endereço IP solicitado pela máquina local é aceitável para o correspondente de discagem.

CCP (Compression Control Protocol)

Esta mensagem indica que um protocolo de compressão está em negociação entre os dois correspondentes de discagem do PPP. O Cisco IOS Software suporta os seguintes protocolos de compressão a serem negociados em uma conexão PPP:

  • MS-Point-to-Point Compression (MS-PPC)

  • stacker

  • predictor

CDPCP (Cisco Discovery Protocol Control Protocol)

Essa mensagem indica que uma negociação de CDP ocorre na fase de NCP. Para desligar o CDP no roteador, execute o comandono cdp run.

CODEREJ (Rejeição de Código)

Um pacote de CODEREJ é enviado na recepção de um pacote impossível de interpretar do correspondente de discagem remoto do PPP.

Instalar a rota no a.b.c.d

Quando o roteador termina o IPCP (fase NCP para protocolo IP L3), ele deve instalar o endereço de IP fornecido ao correspondente de discagem do PPP remoto na tabela de roteamento e ser visto como uma rota conectada na tabela de roteamento. Se você não vir esta mensagem, verifique se o comando no peer neighbor-route não está configurado

IPCP (IP Control Protocol)

Esse valor indica que o IP é a camada de rede em negociação na fase de NCP.

O estado do IPCP é Aberto

Essa mensagem indica que o IPCP (fase de NCP para protocolo IP L3) foi concluído com sucesso.

PROTREJ (Rejeição de Protocolo)

O correspondente de discagem do PPP, diante do recebimento de um pacote de PPP com um campo de protocolo desconhecido, usa a mensagem PROTREJ para indicar que o correspondente de discagem tentou usar um protocolo sem suporte. Quando um dispositivo PPP recebe uma mensagem PROTREJ, ele deve, na primeira oportunidade, deixar de enviar pacotes do protocolo indicado.

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: 25440