Глобальная сеть (WAN) : Протокол PPP

Выходные данные команды "debug ppp negotiation"

8 февраля 2010 - Перевод, выполненный профессиональным переводчиком
Другие версии: PDF-версия:pdf | Машинный перевод (28 июля 2013) | Английский (4 февраля 2010) | Отзыв

Содержание

Введение
Предварительные условия
      Требования
      Используемые компоненты
      Условные обозначения
Этапы согласования PPP
Пакеты согласования PPP. Описание
Этап LCP, аутентификации и NCP
Устранение неполадок с помощью выходных данных команды debug ppp negotiation
Просмотр выходных данных команды debug ppp negotiation
Пример выходных данных команды debug ppp negotiation
Глоссарий и распространенные сообщения
      Общие
      LCP
      Аутентификация
      NCP
Связанные обсуждения сообщества поддержки Cisco

Введение

В приложениях, использующих удаленный доступ, как правило, используется тип инкапсуляции PPP. PPP позволяет двум компьютерам на канале связи типа «точка-точка» согласовывать различные параметры аутентификации, сжатия, а также протоколы 3 уровня (L3), например IP. Сбой в согласовании PPP между двумя маршрутизаторами может привести к сбою подключения.

Команда debug ppp negotiation позволяет просматривать транзакции согласования PPP, определять проблему или этап, на котором возникла проблема, и разрабатывать решение. Однако считается обязательным понимать выходные данные команды debug ppp negotiation. В этом документе описан метод полноценного чтения выходных данных команды debug ppp negotiation.

Предварительные условия

Требования

Читатели должны выполнить следующие требования:

  • PPP необходимо включить на интерфейсах обоих маршрутизаторов. Выполните команду encapsulation ppp для выполнения этой задачи.

  • Выполните эту команду, чтобы включить на маршрутизаторе штамп времени в миллисекундах:

    Router(config)# service timestamp debug datetime msec
    

    Дополнительные сведения о командах отладки см. в документе Важные сведения о командах отладки.

Примечание. Согласование PPP между двумя одноранговыми участниками не может начаться, если более низкие уровни (ISDN, физический интерфейс, линия коммутируемого доступа и т. д.), служащие основанием для PPP, не работают безотказно. Например, если следует использовать PPP по каналу ISDN, необходимо включить все уровни ISDN, иначе протокол PPP не будет функционировать.

Используемые компоненты

Настоящий документ не имеет жесткой привязки к каким-либо конкретным версиям программного обеспечения и оборудования.

Условные обозначения

Дополнительные сведения об условных обозначениях см. в документе Cisco Technical Tips Conventions.

Этапы согласования PPP

Согласование PPP на канале состоит из нескольких этапов, как показано в следующей таблице. В результате PPP либо начинает работать, либо нет.

Этап

Описание

DOWN

На этом этапе PPP отключен. Данное сообщение отображается после отключения канала и PPP:

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

ESTABLISHING

Переход PPP на этот этап происходит при получении уведомления о работающем состоянии физического уровня и готовности к его использованию. На этом этапе выполняется согласование LCP1.

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

AUTHENTICATING

Если на канале необходима аутентификация PPP (CHAP2 или PAP3), PPP переходит на этот этап. Помните, что аутентификация PPP не является обязательной.

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

UP

После завершения аутентификации PPP переходит на этап UP. На этом этапе выполняется согласование NCP4.

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

TERMINATING

На этом этапе PPP отключается.

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

1. LCP = протокол управления каналом

2. CHAP = протокол аутентификации связи с проверкой

3. PAP = протокол аутентификации пароля

4. NCP = протокол управления сетью

На следующей схеме показаны этапы переходов PPP.

debug_ppp_negotiation3.gif

Пакеты согласования PPP. Описание

В этой таблице содержится описание пакетов согласования PPP, которые используются как при согласовании LCP, так и при согласовании NCP.

Пакет

Код

Описание

CONFREQ

Configure-Request

Чтобы открыть подключение к одноранговому участнику, устройство передает это сообщение вместе с параметрами и значениями конфигурации, поддержку которых отправитель требует от однорангового участника. Все параметры и значения согласовываются одновременно. Если одноранговый участник отвечает сообщением CONFREJ или CONFNAK, маршрутизатор отправляет еще одно сообщение CONFREQ с другим набором параметров или значений.

CONFREJ

Configure-Reject

Если какие-либо параметры конфигурации, полученные в сообщении CONFREQ, являются недопустимыми или нераспознанными, маршрутизатор отвечает сообщением CONFREJ. Недопустимый параметр (из сообщения CONFREQ) включается в сообщение CONFREJ.

CONFNAK

Configure-NAK1

Если полученный параметр конфигурации определяется и считается допустимым, однако полученное значение не является допустимым, маршрутизатор передает сообщение CONFNAK. Маршрутизатор присоединяет этот параметр и значение, которое он может принять, к сообщению CONFNAK, так что одноранговый участник может включить этот параметр в следующее сообщение CONFREQ.

CONFACK

Configure-ACK2

Если все параметры в сообщении CONFREQ распознаны и все значения являются допустимыми, маршрутизатор передает сообщение CONFACK.

TERMREQ

Terminate-Request

Данное сообщение используется для инициации закрытия LCP.

TERMACK

Terminate-ACK

Это сообщение передается в ответ на сообщение TERMREQ.

1. NAK = отрицательное подтверждение

2. ACK = подтверждение

Примечание. Каждый одноранговый участник может отправлять сообщения CONFREQ с параметром и значением, поддержку которых можно требовать от других одноранговых участников. Это может привести к тому, что параметры, согласованные в обоих направлениях, будут отличаться. Например, одна сторона может требовать аутентификации одноранговых участников, другая сторона — нет.

Этап LCP, аутентификации и NCP

На некоторых ранее описанных этапах PPP выполняются специальные действия, такие как согласование LCP, аутентификация и согласование NCP. Дополнительные сведения см. в документах RFC 1548 leavingcisco.com и RFC 1661 leavingcisco.com.

LCP (обязательный этап)

LCP – это этап, на котором согласуются параметры, которые необходимы для создания, настройки и проверки подключения по каналу передачи данных. Открытое состояние LCP означает успешное завершение LCP, в то время как закрытое состояние LCP означает сбой на этапе LCP.

На следующей схеме приведена концепция установления связи LCP:

debug_ppp_negotiation1.gif

При согласовании LCP также используется параметр, называемый MagicNumber, который используется для определения, является ли канал связи возвратной петлей. Случайная строка отправляется по каналу, и если возвращается то же значение, то маршрутизатор определяет, что канал является возвратной петлей.

Аутентификация (по умолчанию необязательный этап)

На этом этапе выполняется аутентификация с помощью протокола аутентификации (CHAP или PAP), согласованного на этапе LCP. Сведения, связанные с PAP, см. в документе Настройка и устранение неполадок протокола PAP при использовании PPP.

Сведения, связанные с CHAP, см. в документе Общие сведения об аутентификации CHAP при использовании PPP.

Примечание. Аутентификация является необязательной, и PPP переходит на этот этап, только в случае необходимости аутентификации.

NCP (обязательный этап)

Этот этап используется для подключения и настройки других протоколов сетевого уровня. Наиболее распространенным согласуемым протоколом третьего уровня является IP. Маршрутизаторы обмениваются сообщениями протокола управления IP (IPCP) для согласования параметров, применимых к протоколу (в этом случае — IP).

В документе RFC 1332 leavingcisco.com говорится, что IPCP согласовывает два параметра: сжатие и назначение IP-адресов. Однако протокол IPCP также используется для передачи сетевых данных, таких как основные и резервные серверы WINS и DNS.

Согласование выполняется с помощью сообщений CONF, как описано в разделе Пакеты согласования PPP. Описание.

Устранение неполадок с помощью выходных данных команды debug ppp negotiation

При просмотре выходных данных команды debug ppp negotiation в целях устранения неполадок руководствуйтесь следующими инструкциями:

  1. Определите переходы на следующие этапы в выходных данных команды debug. Определите этап, на котором было выполнено подключение, то есть UP или AUTHENTICATING. Это поможет определить, на каком этапе произошел сбой подключения. Дополнительные сведения об этапах см. в разделе Этапы согласования PPP.

  2. Определив этап, на которой произошел сбой, найдите сообщения, которые указывают на успешное выполнение LCP, аутентификации или NCP:

    • Состояние LCP должно быть открытым. Можно также просмотреть последние входящие и исходящие сообщения CONFACK, чтобы проверить, согласованы ли требуемые параметры.

    • Аутентификация должна быть успешной. Если использовать двухстороннюю аутентификацию, то каждая транзакция должна завершиться успешно. Дополнительные сведения по устранению неполадок с аутентификацией PPP см. в документе Устранение неисправностей аутентификации PPP (CHAP и PAP).

    • Состояние IPCP должно быть открытым. Убедитесь, что адресация верна и маршрут к одноранговому участнику установлен.

Просмотр выходных данных команды debug ppp negotiation

Большинство строк в выходных данных команды debug ppp negotiation характеризуются следующими факторами:

  1. The timestamp. Используются штампы времени в миллисекундах. Дополнительные сведения см. в разделе этого документаПредварительные условия.

  2. Interface and Interface number. Это поле полезно при отладке подключений, использовании нескольких подключений или при переходе подключения на другие интерфейсы. Например, определенные подключения (такие как многоканальные вызовы) управляются сначала физическим интерфейсом, однако затем управление берет на себя интерфейс номеронабирателя или интерфейс виртуального доступа.

  3. Type of PPP message. Это поле указывает, является ли строка общим сообщением PPP, LCP, CHAP, PAP или IPCP.

  4. Direction of the message. I означает входящий пакет, а O – исходящий. Это поле может использоваться для определения, было ли сообщение создано или получено маршрутизатором.

  5. Message. Это поле содержит определенную согласуемую транзакцию.

  6. ID. Это поле используется для сопоставления и координации запросов с соответствующими ответами. Можно использовать это поле для сопоставления ответа со входящим сообщением. Этот параметр особенно полезен, если входящее сообщение и ответ на него находятся слишком далеко друг от друга в выходных данных отладки.

  7. Length. Это поле служит для определения длины поля сведений. Это поле не имеет значения при общем устранении неполадок.

Примечание. Поля 4–7 могут не отображаться во всех сообщениях PPP в зависимости от назначения сообщения.

Примечание. В этом примере приводятся поля

debug_ppp_negotiation2.gif

Пример выходных данных команды debug ppp negotiation

Ниже приведено выходные данные команды 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

!--- Физический уровень (интерфейс BRI) включен. Только теперь может начаться
!--- согласование PPP.

*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]

!--- PPP переходит на этап ESTABLISHING. Выполняется согласование LCP.

*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

!--- Это входящее сообщение CONFREQ. Поле ID равно 7.

*Mar  1 00:06:37.038: BR0:1 LCP:    AuthProto PAP (0x0304C023)
*Mar  1 00:06:37.042: BR0:1 LCP:    MagicNumber 0x507A214D (0x0506507A214D)
*Mar  1 00:06:37.046: BR0:1 LCP:    Callback 0  (0x0D0300)

!--- Одноранговый участник запросил следующее: 
!--- Параметр: протокол аутентификации, значение: PAP
!--- Параметр: MagicNumber (Используется для определения обратных петель; отправляется всегда.)
!--- Параметр: Callback, значение: 0 (для PPP Callback; для MS Callback используется 6.)

*Mar  1 00:06:37.054: BR0:1 LCP: O CONFREQ [Listen] id 4 len 15

!--- Это исходящее сообщение CONFREQ с параметрами, которые должен реализовать
!--- одноранговый участник. Обратите внимание, что поле ID равно 4,
!--- поэтому это сообщение не относится к предыдущему сообщению 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)

!--- Этот маршрутизатор требует следующих параметров: 
!--- Параметр: протокол аутентификации, значение: CHAP
!--- Параметр: MagicNumber (Используется для определения обратных петель; отправляется всегда.)

*Mar  1 00:06:37.066: BR0:1 LCP: O CONFREJ [Listen] id 7 len 7

!--- Это исходящее сообщение CONFREJ для сообщения с полем ID 7.
!--- Это ответ на первое сообщение CONFREQ.

*Mar  1 00:06:37.070: BR0:1 LCP:    Callback 0  (0x0D0300)

!--- Параметр, отклоненный этим маршрутизатором — Callback.
!--- Если маршрутизатор потребовал бы MS Callback, а не PPP Callback, то
!--- было бы послано сообщение CONFNAK.

*Mar  1 00:06:37.098: BR0:1 LCP: I CONFACK [REQsent] id 4 len 15

!--- Это входящее сообщение CONFACK для сообщения с полем ID 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)

!--- Одноранговый участник может поддерживать все запрошенные параметры.

*Mar  1 00:06:37.114: BR0:1 LCP: I CONFREQ [ACKrcvd] id 8 len 14

!--- Это входящее сообщение CONFREQ; поле ID равно 8.
!--- Это новое сообщение CONFREQ от однорангового участника в ответ на CONFREJ id:7.

*Mar  1 00:06:37.117: BR0:1 LCP:    AuthProto PAP (0x0304C023)
*Mar  1 00:06:37.121: BR0:1 LCP:    MagicNumber 0x507A214D (0x0506507A214D)

!--- Одноранговый участник запросил следующее: 
!--- Параметр: протокол аутентификации, значение: PAP
!--- Параметр: MagicNumber (используется для определения обратных петель; отправляется всегда.)

*Mar  1 00:06:37.125: BR0:1 LCP: O CONFNAK [ACKrcvd] id 8 len 9

!--- Это исходящее сообщение CONFACK для сообщения с полем ID 8.

*Mar  1 00:06:37.129: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)

!--- Этот маршрутизатор распознает параметр протокола аутентификации, однако
!--- не принимает значение PAP. В сообщении CONFNAK
!--- предлагается CHAP.

*Mar  1 00:06:37.165: BR0:1 LCP: I CONFREQ [ACKrcvd] id 9 len 15

!--- Это входящее сообщение CONFREQ для сообщения с полем ID 9.

*Mar  1 00:06:37.169: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 00:06:37.173: BR0:1 LCP:    MagicNumber 0x507A214D (0x0506507A214D)

!--- Запрошена аутентификация CHAP.

*Mar  1 00:06:37.177: BR0:1 LCP: O CONFACK [ACKrcvd] id 9 len 15

!--- Это исходящее сообщение CONFACK для сообщения с полем ID 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: State is Open

!--- Это указывает на открытое состояние LCP.

*Mar  1 00:06:37.193: BR0:1 PPP: Phase is AUTHENTICATING, by both [0 sess, 0 load]

!--- Этап PPP — AUTHENTICATING. Происходит аутентификация PPP.
!--- Выполняется двухсторонняя аутентификация (обозначается ключевым словом both).

*Mar  1 00:06:37.201: BR0:1 CHAP: O CHALLENGE id 4 len 33 from "maui-soho-01"

!--- Это исходящий CHAP-вызов. 
!--- При согласовании LCP маршрутизаторы согласились на использование CHAP в качестве протокола аутентификации.

*Mar  1 00:06:37.225: BR0:1 CHAP: I CHALLENGE id 3 len 33 from "maui-soho-03"

!--- Это входящий CHAP-вызов от однорангового участника.

*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"

!--- Это входящий ответ от однорангового участника.

*Mar  1 00:06:37.244: BR0:1 CHAP: O SUCCESS id 4 len 4

!--- Этот маршрутизатор успешно аутентифицировал однорангового участника.

*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

!--- Это входящее сообщение об успешном выполнении аутентификации. Каждая сторона
!--- успешно аутентифицировала другую.

*Mar  1 00:06:37.296: BR0:1 PPP: Phase is UP [0 sess, 0 load]

!--- Состояние PPP меняется на UP. Начинается согласование NCP (IPCP).

*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)

!--- Это исходящее сообщение CONFREQ. Это указывает, что
!--- адрес локального компьютера равен 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

!--- Эти сообщения предназначены для протокола управления CDP (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)

!--- Это входящее сообщение CONFREQ, которое указывает, что IP-адрес
!--- равен 172.22.1.2.  Адрес 0.0.0.0 указывает, что одноранговый участник не
!--- имеет адреса и запрашивает у локального маршрутизатора 
!--- адрес при согласовании 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

!--- Состояние IPCP становится открытым. Обратите внимание, что при согласовании IPCP каждая сторона
!--- приняла IP-адрес однорангового участника и адрес был назначен одноранговому участнику.

*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: State is Open

!--- Это указывает на открытое состояние CDPCP.

*Mar  1 00:06:37.387: BR0 IPCP: Install route to 172.22.1.2

!--- Установлен маршрут до однорангового участника.

*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

Глоссарий и распространенные сообщения

Общие

CONFREQ (Configure-Request):

Когда более низкий уровень становится доступным (Up), отправляется сообщение CONFREQ для запуска этапа PPP (этап LCP). Оно используется на этапах LCP и NCP как попытка настройки подключения. Чтобы открыть подключение к одноранговому участнику, устройство передает это сообщение вместе с параметрами и значениями конфигурации, поддержку которых отправитель требует от однорангового участника. Все параметры и значения согласовываются одновременно. Если одноранговый участник отвечает сообщением CONFREJ или CONFNAK, маршрутизатор отправляет еще одно сообщение CONFREQ с другим набором параметров или значений.

CONFACK (Configure-Acknowledge):

Если все параметры в сообщении CONFREQ распознаны и все значения являются допустимыми, маршрутизатор передает сообщение CONFACK.

CONFREJ (Configure Reject):

Если какой-либо параметр конфигурации, полученный в сообщении CONFREQ, является недопустимым или не распознается, маршрутизатор отвечает сообщением CONFREJ. Недопустимый параметр (из сообщения CONFREQ) включается в сообщение CONFREJ.

CONFNAK (Configure Negative Acknowledge):

Если полученный параметр конфигурации определяется и считается допустимым, однако полученное значение не является допустимым, маршрутизатор передает сообщение CONFNAK. Маршрутизатор присоединяет этот параметр и значение, которое он может принять, к сообщению CONFNAK, так что одноранговый участник может включить этот параметр в следующее сообщение CONFREQ.

ECHOREQ (Echo Request) и ECHOREP (Echo Reply):

PPP использует сообщения keepalive, чтобы поддерживать целостность подключения. Эти сообщения являются фреймом ECHOREQ, который отправляется удаленному одноранговому участнику PPP, а этот участник должен ответить фреймом ECHOREP при получении фрейма ECHOREQ. Если маршрутизатор пропускает пять фреймов ECHOREP (значение по умолчанию), то канал считается отключенным, и протокол PPP отключается.

TERMREQ (запрос завершения):

Этот фрейм указывает на то, что одноранговый участник PPP, отправивший этот фрейм, прерывает PPP-подключение.

TERMACK (оповещение о завершении):

Это сообщение передается в ответ на сообщение TERMREQ. Это приводит к отключению PPP-подключения.

TERMINATING

Это сообщение указывает на отключение PPP-подключения. Подключение LCP или NCP может отключиться по следующим причинам:

  • административное закрытие (только LCP);

  • прекращается обслуживание более низкого уровня (линия коммутируемого доступа, ISDN и т. д.);

  • при неудаче согласования;.

  • при обнаружении возвратной петли.

LCP

ACCM (Asynchronous Control Character Map):

Это один из параметров, согласованных на этапе LCP, в фрейме CONFREQ. ACCM задает последовательность символов выхода. ACCM заставляет порт игнорировать указанные символы управления в потоке данных. Если маршрутизатор на другом конце подключения не поддерживает согласование ACCM, порт принудительно использует FFFFFFFF. В этом случае выполните команду

ppp accm match 000a000

ACFC (Address and Control Field Compression):

ACFC — это параметр LCP, которые позволяет конечным точкам эффективно обмениваться сообщениями.

AuthProto (Authentication Protocol):

AuthProto — это тип протокола аутентификации, согласованный в фрейме CONFREQ между одноранговыми участниками PPP-подключения для использования на этапе аутентификации. Если аутентификация PPP не настроена, выходные данные не отображаются в согласованных параметрах фрейма CONFREQ. Возможные значения — CHAP или PAP.

Callback "#":

Это сообщение указывает, что согласуется параметр обратного вызова. Номер после синтаксиса обратного вызова указывает, согласование какого параметра обратного вызова выполняется. Номер 0 — это обычный обратный вызов PPP, а номер 6 указывает на использование параметра обратного вызова Microsoft (который автоматически доступен в ПО Cisco IOS® версии 11.3(2)T и выше).

CHAP (Challenge Handshake Authentication Protocol):

Это сообщение указывает, что согласованным протоколом аутентификации является CHAP.

EndpointDisc (End Point Discriminator):

Это параметр LCP, используемый для идентификации узла PPP на многоканальном соединении PPP. Дополнительные сведения см. в документе Критерий для именования пучков Multilink PPP.

LCP: открытое состояние

Это сообщение указывает на то, что согласование LCP было успешно завершено.

LQM (Link Quality Monitoring)

Мониторинг качества канала LQM доступен на всех последовательных интерфейсах, на которых работает PPP. LQM отслеживает качества канала и отключает канал, если качество снижается ниже указанного процентного соотношения. Процентное соотношение вычисляется для входящего и исходящего направлений. Качество на исходящем направлении вычисляется путем сравнения общего количества отправленных пакетов и байтов с общим количеством пакетов и байтов, полученных одноранговым участником. Качество на входящем направлении вычисляется путем сравнения общего количества полученных пакетов и байтов с общим количеством пакетов и байтов, отправленных одноранговым участником.

При работе LQM отчеты LQR отправляются через интервал keepalive. Отчеты LQR отправляются вместо пакетов keepalive. Все входящие пакеты keepalive получают допустимый ответ. Если функция LQM не настроена, сообщения keepalive отправляются через интервал keepalive, а все входящие отчеты LQR получают ответ в виде LQR.

MagicNumber

Поддержка Magic Number доступна на всех последовательных интерфейсах. При использовании PPP всегда производится попытка согласовать параметр Magic Numbers, который используется для определения сетей с возвратной петлей. Случайная строка отправляется по каналу, и если возвращается то же значение, то маршрутизатор определяет, что канал является возвратной петлей.

Канал может отключиться при обнаружении возвратной петли, а может и остаться активным. Это зависит от использования команды down-when-looped .

PAP (Password Authentication Protocol)

Это сообщение указывает, что согласуемым протоколом аутентификации, который будет использоваться одноранговыми участниками PPP, является PAP. Дополнительные сведения о PAP см. в документе Настройка и устранение неполадок протокола PAP при использовании PPP.

PFC (Protocol Field Compression)

Этот параметр включает сжатие для полей протокола (on или off).

MRRU (Max Receive Reconstructed Unit)

Это параметр LCP, согласованный при настройке LCP для PPP Multilink. Он определяет максимальное количество байтов, из которого может состоять фрейм. Если MRRU не согласовывается на этапе LCP, протокол Multilink PPP (MPPP) может не работать на канале.

MRU (Maximum Received Unit)

MRU — это параметр LCP, который согласовывается в фрейме CONFREQ для согласования размера обмениваемых пакетов.

Аутентификация

AUTH-REQ (Authentication Request)

Этот фрейм передается с локального однорангового участника PPP (на котором включена аутентификация) на удаленного однорангового участника. В нем запрашивается отправка удаленным участником допустимого имени пользователя и пароля для аутентификации PPP-подключения. Этот фрейм используется только для PAP.

AUTH-ACK (Authentication Acknowledge)

Данный фрейм отправляется с аутентифицированного однорангового участника РРР на аутентифицируемого однорангового участника РРР. Этот фрейм содержит корректное имя пользователя и пароль. Фрейм используется только при использовании PAP для аутентификации PPP-подключения.

AUTH-NAK или FAILURE

Этот фрейм отправляется с аутентифицируемого однорангового участника PPP при сбое аутентификации на аутентифицируемом участнике PPP.

CHALLENGE

Это фрейм CHAP-вызова, который отправляется с аутентифицируемого однорангового участника PPP на аутентифицированного участника PPP. Фрейм CHAP-вызова состоит из идентификатора, случайного числа и имени хоста локального сервера связи или имени пользователя на удаленном устройстве. Фрейм используется только при использовании CHAP для аутентификации PPP-подключения.

RESPONSE

Данный фрейм является CHAP-ответом, который отправляется с аутентифицированного однорангового участника РРР на аутентифицируемого однорангового участника РРР.

Обязательный ответ состоит из двух частей:

  • выходные данных хэша MD5 общего секретного ключа;

  • имя хоста удаленного устройства или имя пользователя на удаленном устройстве.

Фрейм используется только при использовании CHAP для аутентификации PPP-подключения.

NCP

Адрес a.b.c.d

  • Данное значение в исходящем сообщении CONFREQ означает IP-адрес, выбранный для использования локальным маршрутизатором. Если этот адрес равен 0.0.0.0, локальный компьютер запрашивает участника о предоставлении IP-адреса, который можно использовать.

  • Данное значение во входящем сообщении CONFREQ означает IP-адрес, выбранный для использования одноранговым участником. Если этот адрес равен 0.0.0.0, одноранговый участник запрашивает локальный компьютер о предоставлении IP-адреса, который можно использовать.

  • В исходящем сообщении CONFNAK это значение указывает IP-адрес, который одноранговый участник должен использовать вместо адреса, предложенного этому участнику в сообщении CONFREQ.

  • Данное значение во входящем сообщении CONFNAK означает IP-адрес, который должен использовать локальный компьютер вместо предложенного в предыдущем сообщении CONFNAK.

  • В исходящем сообщении CONFACK это значение указывает, что IP-адрес, запрашиваемый одноранговым участником, разрешен локальным компьютером.

  • Во входящем сообщении CONFACK это значение указывает, что IP-адрес, запрашиваемый локальным компьютером, разрешен локальным компьютером.

CCP (Compression Control Protocol)

Это сообщение указывает, что протокол сжатия согласовывается обоими одноранговыми участниками PPP. В ПО Cisco IOS поддерживаются следующие протоколы сжатия для PPP-подключения:

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

  • stacker

  • predictor

CDPCP (Cisco Discovery Protocol Control Protocol)

Это сообщение указывает, что согласование CDP происходит на этапе NCP. Чтобы отключить CDP на маршрутизаторе, выполните команду no cdp run.

CODEREJ (Code Reject)

Пакет CODEREJ отправляется при получении неопознанного пакета от удаленного однорангового участника PPP.

Создание маршрута до a.b.c.d

После завершения маршрутизатором согласования IPCP (этап NCP для протокола IP L3) данный IP-адрес удаленного участника PPP должен быть прописан в таблице маршрутизации вместе с допустимым маршрутом. Если это сообщение не отображается, убедитесь, что не выполнялась команда no peer neighbor-route.

IPCP (IP Control Protocol)

Это значение указывает, что IP — это согласуемый сетевой уровень на этапе NCP.

IPCP State is Open

Это сообщение указывает, что согласование IPCP (этап NCP для протокола IP L3) завершено успешно.

PROTREJ (Protocol Reject)

Одноранговый участник PPP при получении пакета PPP с неизвестным протоколом в соответствующем поле использует сообщение PROTREJ для указания того, что другой участник попытался использовать неподдерживаемый протокол. Если устройство PPP получает сообщение PROTREJ, оно должно как можно быстрее приостановить отправку пакетов, относящихся к указанному протоколу.


Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.


Document ID: 25440