Debug ppp negotiation что это

PPP — пример настройки и описание

PPP (Point-to-Point-Protocol) – протокол второго уровня модели OSI, использующийся на WAN линках. PPP – открытый протокол, что позволяет его использовать при необходимости соединения устройств Cisco с устройствами других производителей (в отличие от HDLC, в отношении спецификации которого у циски своё мнение).

Сразу стоит сделать важное замечание: протокол PPP – многофункциональный и широко распространённый, в то же время, в рамках курса CCNA рассматривается только один способ его применения: подключение двух маршрутизаторов друг к другу через serial кабель. На самом деле, сфера применения протокола не ограничивается этими случаями. PPP может работать через нуль-модемный кабель, телефонную линию, в сотовой связи. Другие популярные способы использования протокола PPP – инкапсуляция его в другие протоколы второго уровня. Поясню: сам PPP находится на втором уровне модели OSI и обеспечивает прямое соединение между двумя устройствами, но если его инкапсулировать в другой протокол второго уровня – Ethernet (PPP over Ethernet – PPPoE), то ethernet будет заниматься доставкой фреймов с мак адреса отправителя на мак адрес получателя, после получатель будет декапсулировать из Ethernet-а PPP фрейм и дальше для завёрнутых в PPP протоколов (IPv4, IPX, …) будет создаваться полная «иллюзия» того, что соединение точка-точка. Сам же PPP в этом случае будет заниматься такими вещами как аутентификация и сжатие траффика. Существуют другие способы использования PPP, например PPP over ATM – PPPoA, Microsoft Windows использует для создания VPN протокол PPTP, который так же является надстройкой над PPP. Но это всё лирическое отступление, чтобы было понятно, зачем вообще изучать PPP. В курсе «CCNA Accessing the WAN» PPP – это протокол для соединения двух маршрутизаторов через serial кабель.

Что умеет PPP в сравнении с HDLC?

1. Управление качеством линии (PPP отключает линк, если количество ошибок превысит заданное значение).
2. Аутентификация с помощью PAP или CHAP.
3. Multilink – технология напоминающая Etherchannel в Ethernet-е: несколько разных линков объединяются в один логический, со скоростью, равной сумме входящих в него линков.
4. PPP Callback – технология, использующаяся для повышения безопасности: клиент устанавливает соединение с сервером, сервер разрывает соединение и устанавливает со своей стороны новое – к клиенту.

На самом деле, при передачи данных с маршрутизатора на маршрутизатор, PPP инкапсулируется в HDLC, который выполняет «транспортные» функции для PPP фреймов. Подробнее про HDLC можно почитать в статье «Протокол HDLC – пример настройки и описание». PPP – обладает уровневой структурой, когда фрейм PPP приходит из сети он поднимается по внутренним подуровням PPP снизу вверх:

1. Первый подуровень HDLC – получает фрейм, проверяет адрес получателя, контрольную сумму и передаёт полезнуюинформацию дальше.
2. Подуровень LCP (Link Control Protocol), как видно из названия, занимается управлением соединением, отправляет и получает разные служебные флаги, следит за состоянием соединения (подключено/выключено), следит за качеством линии, следит за согласованностью параметров конфигурации между точками.
3. Подуровень NCP (Network Control Protocol) состоит из большого количества модулей, каждый из которых занимается связью с каким-то конкретным протоколом третьего уровня (IPv4, IPv6, IPX, AppleTalk, …). Благодаря этому, в рамках одного установленного PPP соединения с одним логином и паролем, можно передавать траффик разных протоколов сетевого уровня.

Установка связи между двумя маршрутизаторами по протоколу PPP происходит по уровням снизу вверх, разрыв связи – сверху вниз.

То есть устанавливается связь в таком порядке: LCP,NCP, полезные данные третьего уровня. А разрывается: конец передачи полезных данных, NCP, LCP. Как видно, HDLC не устанавливает и не разрывает соединения, так как в PPP используются HDLC фреймы без подтверждения доставки.

Структура PPP фрейма имеет следующий вид:

1. FLAG – признак начала фрейма, специальная последовательность нулей и единиц («01111110»), которая говорит получателю, что далее будет следовать тело фрэйма.
2. ADDRESS – адрес получателя, в протоколе PPP всегда используется широковещательный «11111111».
3. CONTROL – поле содержит значение «00000011»
4. PROTOCOL – поле, содержащее номер протокола третьего уровня, пакет которого «завёрнут» в данный фрейм.
5. DATA – поле с полезными данными вышестоящих протоколов.
6. FCS – контрольная сумма, которая считается при отправке фрейма и сравнивается с полученным пересчётом, который делается при получении фрейма. В результате, если суммы не совпадают, кадр считается «битым» и отбрасывается.
7. FLAG – признак окончания фрейма, содержит то же значение что и признак начала фрейма.

Настройка PPP на оборудовании cisco, как уже было сказано, в курсе CCNA не сложная. Выполняется она на интерфесе:

1. Выбираем алгоритм сжатия командой compress
2. Устанавливаем качество линии, которое будет считаться приемлемым (при количестве ошибок, больше заданного связь будет разрываться). Для этого служит команда ppp quality.
3. Выбираем способ аутентификации PAP или CHAP (подробнее об этом можно узнать из статьи «В чём разница между PAP и CHAP». Способ аутентификации задаётся командной ppp authentication.
4. Необходимо настроить пользователя под которым наш маршрутизатор будет подключаться к другому. Здесь команды разнятся для CHAP и PAP. Сам пользователь добавляется командой usernamepassword, причём делать это надо не на интерфейсе, а в режиме глобальной конфигурации, но в случае использования PAP, надо ещё использовать на интерфейсе команду ppp pap sent-usernamepassword.

Использование PAP в реальных конфигурациях не желательно, поэтому мы ограничимся примером настройки CHAP. Итак, предположим, что топология следующая, необходимо настроить PPP с аутентификацией CHAP. Настройка на первом маршрутизаторе:

Router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)#hostname R1 R1(config)#username R2 password 123456789 R1(config)#interface serial 0/3/0 R1(config-if)#en R1(config-if)#encapsulation ppp R1(config-if)#ppp authentication chap R1(config-if)#ip address 192.168.0.1 255.255.255.0 R1(config-if)#no shutdown %LINK-5-CHANGED: Interface Serial0/3/0, changed state to down

Настройка на втором маршрутизаторе:

Router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)#hostname R2 R2(config)#username R1 password 123456789 R2(config)#interface serial0/3/0 R2(config-if)#encapsulation ppp R2(config-if)#ppp authentication chap R2(config-if)#ip address 192.168.0.2 255.255.255.0 R2(config-if)#no shutdown %LINK-5-CHANGED: Interface Serial0/3/0, changed state to up %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/3/0, changed state to up

Обратите внимание, что пользователь, которого мы заводим на маршрутизаторе R1 имеет имя R2, а на R2 – R1. Это необходимо, так как когда один роутер подключается к другому, он указывает своё имя, соответственно, другой должен знать это имя (видеть его в своём списке локальных пользователей). Ещё одна немаловажная деталь: пароли к пользователям R1 и R2 обязательно должны совпадать.

Для проверки можем выполнить команду:

R2#sh ip inter brief Interface IP-Address OK? Method Status Protocol … Serial0/3/0 192.168.0.2 YES manual up up …

Если status будет «up», а протокол – «down», то это, как правило означает, что какие-то проблемы с PPP – не та аутентификация, не совпали пароли, качество линии ниже того, что мы заказывали и т.п. В этом случае придётся проверять конфиги и запускать debug ppp, чего я не пожелаю и врагу.

Отладка PPPoE в Cisco

Успех процесса поиска неисправности практически всегда основывается на знании процесса установки соединения и умении использовать инструменты отладки. Далее рассмотрим процесс установки соединения с использованием команды debug с различными опциями. Первым этапом в установке соединения идет установка pppoe сессии. Ниже приведен процесс установки сессии с вырезками из вывода debug-команд:

debug pppoe events

Nov 2 07:38:12.495: PPPoE 0: I PADI R:0800.27da.d2e0 L:ffff.ffff.ffff Fa0/0
*Nov 2 07:38:12.495: Service tag: NULL Tag
*Nov 2 07:38:12.495: PPPoE 0: O PADO, R:0019.56d6.d5f4 L:0800.27da.d2e0 Fa0/0
*Nov 2 07:38:12.495: Service tag: NULL Tag
*Nov 2 07:38:12.495: PPPoE 0: I PADR R:0800.27da.d2e0 L:0019.56d6.d5f4 Fa0/0
*Nov 2 07:38:12.495: Service tag: NULL Tag
*Nov 2 07:38:12.495: PPPoE : encap string prepared
*Nov 2 07:38:12.495: [5]PPPoE 5: Access IE handle allocated
*Nov 2 07:38:12.495: [5]PPPoE 5: pppoe SSS switch updated
*Nov 2 07:38:12.495: [5]PPPoE 5: AAA get retrieved attrs
*Nov 2 07:38:12.495: [5]PPPoE 5: AAA get nas port details
*Nov 2 07:38:12.495: [5]PPPoE 5: AAA get dynamic attrs
*Nov 2 07:38:12.495: [5]PPPoE 5: AAA get dynamic attrs
*Nov 2 07:38:12.495: [5]PPPoE 5: AAA unique ID allocated
*Nov 2 07:38:12.499: [5]PPPoE 5: No AAA accounting method list
*Nov 2 07:38:12.499: [5]PPPoE 5: Service request sent to SSS
*Nov 2 07:38:12.499: [5]PPPoE 5: Created, Service: None R:0019.56d6.d5f4 L:0800.27da.d2e00
*Nov 2 07:38:12.499: [5]PPPoE 5: State NAS_PORT_POLICY_INQUIRY Event SSS_LOCAL
*Nov 2 07:38:12.499: [5]PPPoE 5: O PADS R:0800.27da.d2e0 L:0019.56d6.d5f4 Fa0/0
*Nov 2 07:38:12.499: [5]PPPoE 5: State PPP_START Event DYN_BIND
*Nov 2 07:38:12.499: [5]PPPoE 5: data path set to PPP
*Nov 2 07:38:12.571: [5]PPPoE 5: State LCP_NEGOTIATION Event PPP_LOCAL
*Nov 2 07:38:12.571: PPPoE 5/SB: Sent vtemplate request on base Vi1
*Nov 2 07:38:12.575: [5]PPPoE 5: State VACCESS_REQUESTED Event VA_RESP
*Nov 2 07:38:12.575: [5]PPPoE 5: Vi1.1 interface obtained
*Nov 2 07:38:12.575: [5]PPPoE 5: State PTA_BINDING Event STAT_BIND
*Nov 2 07:38:12.575: [5]PPPoE 5: data path set to Virtual Acess
*Nov 2 07:38:12.575: [5]PPPoE 5: Connected PTA
*Nov 2 07:38:12.579: [5]PPPoE 5: AAA get dynamic attrs
*Nov 2 07:38:12.579: [5]PPPoE 5: AAA get dynamic attrs

debug pppoe packets:
*Nov 2 07:39:46.999: PPPoE 0: I PADI R:0800.27da.d2e0 L:ffff.ffff.ffff Fa0/0
FF FF FF FF FF FF 08 00 27 DA D2 E0 88 63 11 09
00 00 00 10 01 01 00 00 01 03 00 08 02 00 00 00 …
*Nov 2 07:39:46.999: PPPoE 0: O PADO, R:0019.56d6.d5f4 L:0800.27da.d2e0 Fa0/0
*Nov 2 07:39:46.999: Service tag: NULL Tag
08 00 27 DA D2 E0 00 19 56 D6 D5 F4 88 63 11 07
00 00 00 31 01 01 00 00 01 03 00 08 02 00 00 00 …
*Nov 2 07:39:47.003: PPPoE 0: I PADR R:0800.27da.d2e0 L:0019.56d6.d5f4 Fa0/0
00 19 56 D6 D5 F4 08 00 27 DA D2 E0 88 63 11 19
00 00 00 24 01 01 00 00 01 03 00 08 02 00 00 00 …
*Nov 2 07:39:47.003: [6]PPPoE 6: O PADS R:0800.27da.d2e0 L:0019.56d6.d5f4 Fa0/0
08 00 27 DA D2 E0 00 19 56 D6 D5 F4 88 63 11 65
00 06 00 24 01 01 00 00 01 03 00 08 02 00 00 00 …

Теперь подробнее о debug pppoe events:

*Nov 2 07:39:46.999: PPPoE 0: I PADI R:0800.27da.d2e0 L:ffff.ffff.ffff Fa0/0

FF FF FF FF FF FF 08 00 27 DA D2 E0 88 63 11 09
00 00 00 10 01 01 00 00 01 03 00 08 02 00 00 00 …

Говорит на что-то откуда-то приходит на интерфейс FastEthernet0/0. Теперь разберемся что, куда и зачем.

debug pppoe pack

*Nov 2 07:39:46.999: PPPoE 0: I PADI R:0800.27da.d2e0 L:ffff.ffff.ffff Fa0/0
FF FF FF FF FF FF 08 00 27 DA D2 E0 88 63 11 09
00 00 00 10 01 01 00 00 01 03 00 08 02 00 00 00 …

Первым шагом PPPoE клиент рассылает PADI(PPPoE Active Discovery Initiation) пакеты целью обнаружения PPPoE серверов (очень схоже с работой DHCP). Пакет посылается клиентом на широковещательный адрес: FF FF FF FF FF FF. Так же здесь же можно видеть mac адрес клиента, который подключается — 0800.27da.d2e0. После того как PPPoE сервер получает запрос PADI, который он может обслуживать, сервер посылает PADO (PPPoE Active Discovery Offer) пакет, так сказать, предлагая свои услуги. В результате чего сервере доступа видно следующее:

debug pppoe packets:
*Nov 2 07:39:46.999: PPPoE 0: O PADO, R:0019.56d6.d5f4 L:0800.27da.d2e0 Fa0/0
*Nov 2 07:39:46.999: Service tag: NULL Tag
08 00 27 DA D2 E0 00 19 56 D6 D5 F4 88 63 11 07
00 00 00 31 01 01 00 00 01 03 00 08 02 00 00 00 …

О PADO – говорит о том что пакет PADO был исходящий (О=Output). R:0019.56d6.d5f4 L:0800.27da.d2e0 – указывает mac удаленного сервера(R=remote) и локального интерфейса, через который был получен пакет. При получении PADO пакета, клиент выбирает сервер с которым будет работать (так как PADI был отправлен широковещательно, то может придти несколько PADO), и отправляет PADR (PPPoE Active Discovery Request). Данный пакет уже отправляется на unicast адрес, взятый из PADO:

*Nov 2 07:39:47.003: PPPoE 0: I PADR R:0800.27da.d2e0 L:0019.56d6.d5f4 Fa0/0
00 19 56 D6 D5 F4 08 00 27 DA D2 E0 88 63 11 19
00 00 00 24 01 01 00 00 01 03 00 08 02 00 00 00 …

Когда сервер PPPoE получает PADR, он генерирует уникальный ключ PPPoE сессии и отвечает клиенту путем передачи PADS (PPPoE Active Discovery Session-confirmation):

*Nov 2 07:39:47.003: [6]PPPoE 6: O PADS R:0800.27da.d2e0 L:0019.56d6.d5f4 Fa0/0
08 00 27 DA D2 E0 00 19 56 D6 D5 F4 88 63 11 65
00 06 00 24 01 01 00 00 01 03 00 08 02 00 00 00 …

Из вышеприведенной строки, видно, что сессии был присвоен номер 6, этот номер и будет далее вставляться во все пакеты до тех пор, пока PPPoE сессия не будет терминирована. Этот же ID будет показан в выводе команды show pppoe session:

pppoe-nas#sh pppoe session
1 session in LOCALLY_TERMINATED (PTA) State
1 session total

Uniq ID PPPoE RemMAC Port Source VA State
SID LocMAC VA-st
6 6 0800.27da.d2e0 Fa0/0 Vt1 Vi1.1 PTA
0019.56d6.d5f4 UP

В колонке VA-St можно увидеть значение UP – это означает, что PPPoE сессия установлена. После того как, будет поднята PPPoE сессия, начнется процесс установки PPP соединения, который будет проходить в стандартном режиме.

Отладка

Перед началом настройки PPPoE рекомендуется проверить версию IOS, проверить физическое соединение модема с сетью.

Шаг 1: Если после того, как маршрутизатор был полностью сконфигурирован, и соединение не поднялось, в первую очередь необходимо проверить физическое соединение маршрутизатора и физическое соединение с модемом, работает ли модем, индикацию на СРЕ устройстве со стороны клиента. Только после проверки наличия физической связи следует приступать к проверке правильности настроек маршрутизатора.

Шаг 2: Проверили физическое соединение, проверили настройки, теперь можно приступать к проверке 2-го уровня. Здесь уже понадобится умение разбираться в выводе debug и show команд. Первое с чего следует начать – это проверка, есть ли связь между сервером PPPoE и клиентским устройством. При работе с сервером доступа рекомендуется использовать команду debug pppoe events, так как она имеет более дружественный вывод.

Предположим первую ситуацию, когда debug выдает повторяющиеся через некоторое время строки типа:

debug pppoe events
*Nov 2 07:38:12.495: PPPoE 0: I PADI R:0800.27da.d2e0 L:ffff.ffff.ffff Fa0/0
*Nov 2 07:38:12.495: Service tag: NULL Tag
или

debug pppoe packets
pppoe-nas#
*Nov 2 07:39:46.999: PPPoE 0: I PADI R:0800.27da.d2e0 L:ffff.ffff.ffff Fa0/0
FF FF FF FF FF FF 08 00 27 DA D2 E0 88 63 11 09
00 00 00 10 01 01 00 00 01 03 00 08 02 00 00 00 …

Это означает, что PADI пакеты не доходят до PPPoE сервера. В данном случае рекомендуется ещё раз проверить соединение на физическом уровне, и если не выявлено никаких проблем, то проверить настройки vlan.

Шаг 3: Наиболее часто встречаемые проблемы при установке PPP соединения лежат в несоответствии типа аутентификации или неправильно заданных имени пользователя или пароля.

Первым примером рассмотрим ситуацию, когда произошла ошибка в выборе метода аутентификации CHAP или PAP (согласование метода происходит в 1 фазе установки соединения). Предположим, что с клиентской стороны настроен на метод PAP. При данной ошибке, в отличие от ошибки в пароле или пользователе, можно на основании вывода debug команд произвести нужные изменения в настройках клиентского устройства. Рассмотрим вывод команды debug ppp negotiation:

pppoe-nas#
*Nov 2 08:01:04.643: ppp15 PPP: Send Message[Dynamic Bind Response]
*Nov 2 08:01:04.643: ppp15 PPP: Using vpn set call direction
*Nov 2 08:01:04.643: ppp15 PPP: Treating connection as a callin
*Nov 2 08:01:04.643: ppp15 PPP: Session handle[57000011] Session id[15]
*Nov 2 08:01:04.643: ppp15 PPP: Phase is ESTABLISHING, Passive Open
*Nov 2 08:01:04.643: ppp15 LCP: State is Listen
*Nov 2 08:01:04.659: ppp15 LCP: I CONFREQ [Listen] id 0 len 17
*Nov 2 08:01:04.659: ppp15 LCP: MRU 1480 (0x010405C8)
*Nov 2 08:01:04.659: ppp15 LCP: MagicNumber 0x010A4CCA (0x0506010A4CCA)
*Nov 2 08:01:04.659: ppp15 LCP: Callback 6 (0x0D0306)
*Nov 2 08:01:04.659: ppp15 LCP: O CONFREQ [Listen] id 1 len 19
*Nov 2 08:01:04.659: ppp15 LCP: MRU 1492 (0x010405D4)
*Nov 2 08:01:04.659: ppp15 LCP: AuthProto CHAP (0x0305C22305)
*Nov 2 08:01:04.659: ppp15 LCP: MagicNumber 0x1D33F9D9 (0x05061D33F9D9)
*Nov 2 08:01:04.659: ppp15 LCP: O CONFREJ [Listen] id 0 len 7
*Nov 2 08:01:04.659: ppp15 LCP: Callback 6 (0x0D0306)
*Nov 2 08:01:04.659: ppp15 LCP: I CONFNAK [REQsent] id 1 len 8
*Nov 2 08:01:04.659: ppp15 LCP: AuthProto PAP (0x0304C023)
*Nov 2 08:01:04.659: ppp15 LCP: O CONFREQ [REQsent] id 2 len 19
*Nov 2 08:01:04.659: ppp15 LCP: MRU 1492 (0x010405D4)
*Nov 2 08:01:04.659: ppp15 LCP: AuthProto MS-CHAP (0x0305C22380)
*Nov 2 08:01:04.659: ppp15 LCP: MagicNumber 0x1D33F9D9 (0x05061D33F9D9)
*Nov 2 08:01:04.663: ppp15 LCP: I CONFREQ [REQsent] id 1 len 14
*Nov 2 08:01:04.663: ppp15 LCP: MRU 1480 (0x010405C8)
*Nov 2 08:01:04.663: ppp15 LCP: MagicNumber 0x010A4CCA (0x0506010A4CCA)
*Nov 2 08:01:04.663: ppp15 LCP: O CONFNAK [REQsent] id 1 len 8
*Nov 2 08:01:04.663: ppp15 LCP: MRU 1492 (0x010405D4)
*Nov 2 08:01:04.671: ppp15 LCP: I CONFNAK [REQsent] id 2 len 8
*Nov 2 08:01:04.671: ppp15 LCP: AuthProto PAP (0x0304C023)
*Nov 2 08:01:04.671: ppp15 LCP: O CONFREQ [REQsent] id 3 len 19
*Nov 2 08:01:04.671: ppp15 LCP: MRU 1492 (0x010405D4)
*Nov 2 08:01:04.671: ppp15 LCP: AuthProto CHAP (0x0305C22305)
*Nov 2 08:01:04.671: ppp15 LCP: MagicNumber 0x1D33F9D9 (0x05061D33F9D9)
*Nov 2 08:01:04.671: ppp15 LCP: I CONFREQ [REQsent] id 2 len 14
*Nov 2 08:01:04.671: ppp15 LCP: MRU 1480 (0x010405C8)
*Nov 2 08:01:04.671: ppp15 LCP: MagicNumber 0x010A4CCA (0x0506010A4CCA)
*Nov 2 08:01:04.671: ppp15 LCP: O CONFNAK [REQsent] id 2 len 8
*Nov 2 08:01:04.671: ppp15 LCP: MRU 1492 (0x010405D4)
*Nov 2 08:01:04.679: ppp15 LCP: I CONFNAK [REQsent] id 3 len 8
*Nov 2 08:01:04.679: ppp15 LCP: AuthProto PAP (0x0304C023)
*Nov 2 08:01:04.679: ppp15 LCP: O CONFREQ [REQsent] id 4 len 19
*Nov 2 08:01:04.679: ppp15 LCP: MRU 1492 (0x010405D4)
*Nov 2 08:01:04.679: ppp15 LCP: AuthProto MS-CHAP (0x0305C22380)
*Nov 2 08:01:04.679: ppp15 LCP: MagicNumber 0x1D33F9D9 (0x05061D33F9D9)
*Nov 2 08:01:04.711: ppp15 LCP: I CONFREQ [REQsent] id 3 len 14
*Nov 2 08:01:04.711: ppp15 LCP: MRU 1492 (0x010405D4)
*Nov 2 08:01:04.711: ppp15 LCP: MagicNumber 0x010A4CCA (0x0506010A4CCA)
*Nov 2 08:01:04.711: ppp15 LCP: O CONFACK [REQsent] id 3 len 14
*Nov 2 08:01:04.711: ppp15 LCP: MRU 1492 (0x010405D4)
*Nov 2 08:01:04.711: ppp15 LCP: MagicNumber 0x010A4CCA (0x0506010A4CCA)
*Nov 2 08:01:04.723: ppp15 LCP: I CONFNAK [ACKsent] id 4 len 8
*Nov 2 08:01:04.723: ppp15 LCP: AuthProto PAP (0x0304C023)
*Nov 2 08:01:04.723: ppp15 LCP: O CONFREQ [ACKsent] id 5 len 19
*Nov 2 08:01:04.723: ppp15 LCP: MRU 1492 (0x010405D4)
*Nov 2 08:01:04.723: ppp15 LCP: AuthProto CHAP (0x0305C22305)
*Nov 2 08:01:04.723: ppp15 LCP: MagicNumber 0x1D33F9D9 (0x05061D33F9D9)
*Nov 2 08:01:04.731: ppp15 LCP: I CONFNAK [ACKsent] id 5 len 8
*Nov 2 08:01:04.731: ppp15 LCP: AuthProto PAP (0x0304C023)
*Nov 2 08:01:04.731: ppp15 LCP: O CONFREQ [ACKsent] id 6 len 19
*Nov 2 08:01:04.731: ppp15 LCP: MRU 1492 (0x010405D4)
*Nov 2 08:01:04.731: ppp15 LCP: AuthProto MS-CHAP (0x0305C22380)
*Nov 2 08:01:04.731: ppp15 LCP: MagicNumber 0x1D33F9D9 (0x05061D33F9D9)
*Nov 2 08:01:04.739: ppp15 LCP: I CONFNAK [ACKsent] id 6 len 8
*Nov 2 08:01:04.739: ppp15 LCP: AuthProto PAP (0x0304C023)
*Nov 2 08:01:04.739: ppp15 LCP: O CONFREQ [ACKsent] id 7 len 19
*Nov 2 08:01:04.739: ppp15 LCP: MRU 1492 (0x010405D4)
*Nov 2 08:01:04.739: ppp15 LCP: AuthProto CHAP (0x0305C22305)
*Nov 2 08:01:04.739: ppp15 LCP: MagicNumber 0x1D33F9D9 (0x05061D33F9D9)
*Nov 2 08:01:04.751: ppp15 LCP: I CONFNAK [ACKsent] id 7 len 8
*Nov 2 08:01:04.751: ppp15 LCP: AuthProto PAP (0x0304C023)
*Nov 2 08:01:04.751: ppp15 LCP: O CONFREQ [ACKsent] id 8 len 19
*Nov 2 08:01:04.751: ppp15 LCP: MRU 1492 (0x010405D4)
*Nov 2 08:01:04.751: ppp15 LCP: AuthProto MS-CHAP (0x0305C22380)
*Nov 2 08:01:04.751: ppp15 LCP: MagicNumber 0x1D33F9D9 (0x05061D33F9D9)
*Nov 2 08:01:04.759: ppp15 LCP: I CONFNAK [ACKsent] id 8 len 8
*Nov 2 08:01:04.759: ppp15 LCP: AuthProto PAP (0x0304C023)
*Nov 2 08:01:04.759: ppp15 LCP: O CONFREQ [ACKsent] id 9 len 19
*Nov 2 08:01:04.759: ppp15 LCP: MRU 1492 (0x010405D4)
*Nov 2 08:01:04.759: ppp15 LCP: AuthProto CHAP (0x0305C22305)
*Nov 2 08:01:04.759: ppp15 LCP: MagicNumber 0x1D33F9D9 (0x05061D33F9D9)
*Nov 2 08:01:04.771: ppp15 LCP: I CONFNAK [ACKsent] id 9 len 8
*Nov 2 08:01:04.771: ppp15 LCP: AuthProto PAP (0x0304C023)
*Nov 2 08:01:04.771: ppp15 LCP: O CONFREQ [ACKsent] id 10 len 19
*Nov 2 08:01:04.771: ppp15 LCP: MRU 1492 (0x010405D4)
*Nov 2 08:01:04.771: ppp15 LCP: AuthProto MS-CHAP (0x0305C22380)
*Nov 2 08:01:04.771: ppp15 LCP: MagicNumber 0x1D33F9D9 (0x05061D33F9D9)
*Nov 2 08:01:04.779: ppp15 LCP: I CONFNAK [ACKsent] id 10 len 8
*Nov 2 08:01:04.779: ppp15 LCP: AuthProto PAP (0x0304C023)
*Nov 2 08:01:04.779: ppp15 LCP: Failed to negotiate with peer
*Nov 2 08:01:04.779: ppp15 PPP: Sending Acct Event[Down] id[15]
*Nov 2 08:01:04.779: ppp15 LCP: O TERMREQ [ACKsent] id 11 len 4
*Nov 2 08:01:04.779: ppp15 PPP: Phase is TERMINATING
*Nov 2 08:01:04.791: ppp15 LCP: I TERMACK [TERMsent] id 11 len 4
*Nov 2 08:01:04.791: ppp15 LCP: State is Closed
*Nov 2 08:01:04.791: ppp15 PPP: Phase is DOWN
*Nov 2 08:01:04.791: ppp15 PPP: Send Message[Disconnect]

*Nov 2 08:01:04.771: ppp15 LCP: AuthProto PAP (0x0304C023) – означает что поступил запрос содержащий в себе параметры соединения, которые предлагает предлагает клиент. В этих параметрах значится, что метод аутентификации предлагается – PAP.

Теперь рассмотрим пример, когда PPP соединение не устанавливается из-за несоответствия типа имени пользователя или пароля. Дело в том, что вывод debug команд при неправильно заданном имени пользователя или пароля одинаковы, поэтому не имеет смысла рассматривать эти случаи по отдельности.

debug ppp negotiation
pppoe-nas#
*Nov 2 07:58:59.987: ppp12 PPP: Send Message[Dynamic Bind Response]
*Nov 2 07:58:59.987: ppp12 PPP: Using vpn set call direction
*Nov 2 07:58:59.987: ppp12 PPP: Treating connection as a callin
*Nov 2 07:58:59.987: ppp12 PPP: Session handle[F400000E] Session id[12]
*Nov 2 07:58:59.987: ppp12 PPP: Phase is ESTABLISHING, Passive Open
*Nov 2 07:58:59.987: ppp12 LCP: State is Listen
*Nov 2 07:58:59.999: ppp12 LCP: I CONFREQ [Listen] id 0 len 17
*Nov 2 07:58:59.999: ppp12 LCP: MRU 1480 (0x010405C8)
*Nov 2 07:58:59.999: ppp12 LCP: MagicNumber 0x4AFF688E (0x05064AFF688E)
*Nov 2 07:58:59.999: ppp12 LCP: Callback 6 (0x0D0306)
*Nov 2 07:58:59.999: ppp12 LCP: O CONFREQ [Listen] id 1 len 19
*Nov 2 07:58:59.999: ppp12 LCP: MRU 1492 (0x010405D4)
*Nov 2 07:58:59.999: ppp12 LCP: AuthProto CHAP (0x0305C22305)
*Nov 2 07:58:59.999: ppp12 LCP: MagicNumber 0x1D3212E1 (0x05061D3212E1)
*Nov 2 07:58:59.999: ppp12 LCP: O CONFREJ [Listen] id 0 len 7
*Nov 2 07:58:59.999: ppp12 LCP: Callback 6 (0x0D0306)
*Nov 2 07:59:00.003: ppp12 LCP: I CONFACK [REQsent] id 1 len 19
*Nov 2 07:59:00.003: ppp12 LCP: MRU 1492 (0x010405D4)
*Nov 2 07:59:00.003: ppp12 LCP: AuthProto CHAP (0x0305C22305)
*Nov 2 07:59:00.007: ppp12 LCP: MagicNumber 0x1D3212E1 (0x05061D3212E1)
*Nov 2 07:59:00.007: ppp12 LCP: I CONFREQ [ACKrcvd] id 1 len 14
*Nov 2 07:59:00.007: ppp12 LCP: MRU 1480 (0x010405C8)
*Nov 2 07:59:00.007: ppp12 LCP: MagicNumber 0x4AFF688E (0x05064AFF688E)
*Nov 2 07:59:00.007: ppp12 LCP: O CONFNAK [ACKrcvd] id 1 len 8
*Nov 2 07:59:00.007: ppp12 LCP: MRU 1492 (0x010405D4)
*Nov 2 07:59:00.015: ppp12 LCP: I CONFREQ [ACKrcvd] id 2 len 14
*Nov 2 07:59:00.015: ppp12 LCP: MRU 1480 (0x010405C8)
*Nov 2 07:59:00.015: ppp12 LCP: MagicNumber 0x4AFF688E (0x05064AFF688E)
*Nov 2 07:59:00.015: ppp12 LCP: O CONFNAK [ACKrcvd] id 2 len 8
*Nov 2 07:59:00.015: ppp12 LCP: MRU 1492 (0x010405D4)
*Nov 2 07:59:00.023: ppp12 LCP: I CONFREQ [ACKrcvd] id 3 len 14
*Nov 2 07:59:00.023: ppp12 LCP: MRU 1492 (0x010405D4)
*Nov 2 07:59:00.023: ppp12 LCP: MagicNumber 0x4AFF688E (0x05064AFF688E)
*Nov 2 07:59:00.023: ppp12 LCP: O CONFACK [ACKrcvd] id 3 len 14
*Nov 2 07:59:00.027: ppp12 LCP: MRU 1492 (0x010405D4)
*Nov 2 07:59:00.027: ppp12 LCP: MagicNumber 0x4AFF688E (0x05064AFF688E)
*Nov 2 07:59:00.027: ppp12 LCP: State is Open
*Nov 2 07:59:00.027: ppp12 PPP: Phase is AUTHENTICATING, by this end
*Nov 2 07:59:00.027: ppp12 CHAP: O CHALLENGE id 1 len 30 from «pppoe-nas»
*Nov 2 07:59:00.035: ppp12 LCP: I IDENTIFY [Open] id 4 len 18 magic 0x4AFF688E MSRASV5.10
*Nov 2 07:59:00.035: ppp12 LCP: I IDENTIFY [Open] id 5 len 31 magic 0x4AFF688E MSRAS-0-2-4
*Nov 2 07:59:00.035: ppp12 CHAP: I RESPONSE id 1 len 30 from «pppoeuser»
*Nov 2 07:59:00.035: ppp12 PPP: Phase is FORWARDING, Attempting Forward
*Nov 2 07:59:00.035: ppp12 PPP: Phase is AUTHENTICATING, Unauthenticated User
*Nov 2 07:59:00.039: ppp12 CHAP: O FAILURE id 1 len 25 msg is «Authentication failed»
*Nov 2 07:59:00.039: ppp12 PPP: Sending Acct Event[Down] id[12]
*Nov 2 07:59:00.039: ppp12 PPP: Phase is TERMINATING
*Nov 2 07:59:00.039: ppp12 LCP: O TERMREQ [Open] id 2 len 4
*Nov 2 07:59:00.139: ppp12 LCP: I TERMACK [TERMsent] id 2 len 4
*Nov 2 07:59:00.139: ppp12 LCP: State is Closed
*Nov 2 07:59:00.139: ppp12 PPP: Phase is DOWN
*Nov 2 07:59:00.139: ppp12 PPP: Send Message[Disconnect]

Видим, что только что закончилась 1 фазы установки PPP соединения(LCP). Начиная со второй строки мы можем отследить процесс аутентификации.

*Nov 2 07:59:00.027: ppp12 CHAP: O CHALLENGE id 1 len 30 from «pppoe-nas» – данное сообщение означает, что сервер доступа получил входящий запрос содержащий в себе запрос, который клиент должен захешировать совместно с соответствующем паролем алгоритмом MD5 и отправить в ответ на challenge запрос, что мы и видим в следующих 3-ех строках:

*Nov 2 07:59:00.035: ppp12 LCP: I IDENTIFY [Open] id 4 len 18 magic 0x4AFF688E MSRASV5.10
*Nov 2 07:59:00.035: ppp12 LCP: I IDENTIFY [Open] id 5 len 31 magic 0x4AFF688E MSRAS-0-2-4
*Nov 2 07:59:00.035: ppp12 CHAP: I RESPONSE id 1 len 30 from «pppoeuser»
Следует заметить, что в сообщении об отправке ответа в кавычках стоит имя пользователя, которое указанно в настройках chap.

*Nov 2 07:59:00.039: ppp12 CHAP: O FAILURE id 1 len 25 msg is «Authentication failed» – это сообщение уже говорит, что сервер доступа признал ответ неправильным и начинает процедуру разрыва соединения.

В случае же когда аутентификация прошла успешно, в debug ppp negotiation появится следующее сообщение:

*Nov 2 08:08:04.383: ppp22 PPP: Phase is FORWARDING, Attempting Forward
*Nov 2 08:08:04.383: ppp22 PPP: Phase is AUTHENTICATING, Unauthenticated User
*Nov 2 08:08:04.387: ppp22 PPP: Phase is FORWARDING, Attempting Forward
*Nov 2 08:08:04.387: ppp22 PPP: Send Message[Connect Local]
*Nov 2 08:08:04.391: ppp22 PPP: Bind to [Virtual-Access1.1]

1. PPPoE клиент — часть 5: Cisco
2. Cisco PPPoE NAS
3. PPPoE клиент — часть 1: Windows XP
4. DHCP клиент в Cisco
5. PPPoE клиент — часть 3: Vyatta

Получение DNS IP адреса от провайдера с помощью PPP

В этой статье описывается конфигурация, необходимая на маршрутизаторе Cisco для получения сведений о системе доменных имен (DNS) от поставщика услуг и передачи их внутренним пользователям с помощью DHCP. Протокол DNS используется для разрешения полного доменного имени (FQDN) на его соответствующий IP-адрес.

Получение DNS IP адреса от провайдера с помощью PPP

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

Рис. 1.1 DNS IP-адрес от провайдера с использованием PPP

Настройка локального DHCP-сервера на маршрутизаторе Cisco

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

Во-первых, включите службу DHCP на маршрутизаторе Cisco.

R1(config)#service dhcp

Затем создайте пул DHCP, определяющий сетевую подсеть, которая будет передана в аренду DHCP-клиентам в локальной сети.

ip dhcp pool LAN_MY network 192.168.1.0 255.255.255.0 default-router 192.168.1.1 dns-server 192.168.1.1

Здесь пул DHCP был назван как LAN_MY.

• Оператор network задает подсеть и маску пула адресов DHCP
• default-router указывает IP-адрес маршрутизатора по умолчанию для DHCP-клиента. Это должен быть IP-адрес в той же подсети, что и клиент
• DNS-сервер задает IP-адрес DNS-сервера, который доступен для DHCP-клиента

Включите DNS-сервер на маршрутизаторе Cisco

В режиме глобальной конфигурации включите службу DNS на маршрутизаторе.

R1(config)#ip dns server

Конфигурация для ретрансляции публичной службы DNS от провайдера через PPP

Для того, чтобы получить Public DNS от провайдера, необходимо настроить ppp ipcp dns request на Dialer интерфейсе.

R1(config)#interface dialer 1 R1(config-if)#ppp ipcp dns request

Когда все вышеперечисленные конфигурации будут выполнены:

• Команда ppp ipcp dns request сначала помогает получить информацию о публичном DNS-сервере от провайдера через ipcp-фазу согласования PPP.
• Затем команда ip dns server позволяет маршрутизатору начать действовать в качестве самого DNS-сервера. Однако маршрутизатор в конечном итоге использует Public DNS service от провайдера для разрешения доменных имен
• Кроме того, когда локальный DHCP-сервер раздаст IP-адреса клиентам, он будет представлять себя как DNS-сервер. Все входящие запросы разрешения DNS от клиентов будут обрабатываться маршрутизатором с использованием Public DNS

Проверка

Шаг 1: Запустите debug ppp negotiation и внимательно прочитайте информацию о IPCP, чтобы проверить, предоставляется ли информация о DNS-сервере провайдером.

Шаг 2: выполните команду show ppp interface virtual-access , чтобы узнать о различных параметрах, успешно согласованных во время настройки PPP.

R1# show ppp interface virtual-access 3

Understanding debug ppp negotiation Output

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Contents

Introduction

In dial-related applications, PPP is the most commonly used encapsulation type. PPP allows two machines on a point-to-point communication link to negotiate various parameters for authentication, compression, and the Layer 3 (L3) protocols, such as IP. A failure in the PPP negotiation between two routers causes the connection to fail. The debug ppp negotiation command enables you to view the PPP negotiation transactions, identify the problem or stage when the error occurs, and develop a resolution. However, it is imperative that you understand the debug ppp negotiation command output. This document provides a comprehensive method to read debug ppp negotiation command output.

Prerequisites

Requirements

• PPP must be enabled on the interfaces on both routers. Issue the encapsulation ppp command to accomplish this.
• Issue this command to enable Millisecond timestamps on the router:

Router(config)# service timestamp debug datetime msec 

Note: PPP negotiation between two peers cannot start unless the lower layer (ISDN, physical interface, dial-up line, and so on) under PPP functions perfectly. For example, if you want to run PPP over ISDN, then all ISDN layers must be up; otherwise PPP does not start.

Components Used

This document is not restricted to specific software and hardware versions.

Conventions

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Phases of PPP Negotiation

The link goes through several phases in the process of PPP negotiation, as shown in this table. The end result is that PPP is either up or down.

Phase	Description
DOWN	In this phase, PPP is down. This message is seen after the link and PPP are completely brought down:

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

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

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

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

*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

This diagram shows the PPP phase transitions:

PPP Negotiation Packets: A Description

This table includes description of PPP negotiation packets that are used in both LCP and NCP negotiation:

Packet	Code	Description
CONFREQ	Configure-Request	To open a connection to the peer, the device transmits this message along with the configuration options and values the sender wishes the peer to support. All options and values are negotiated simultaneously. If the peer responds with a CONFREJ or CONFNAK message, then the router sends another CONFREQ with another set of options or values.
CONFREJ	Configure-Reject	If some configuration option received in the CONFREQ message is not acceptable or not recognizable, the router responds with a CONFREJ message. The unacceptable option (from the CONFREQ message) is included in the CONFREJ message.
CONFNAK	Configure-NAK 1	If the received configuration option is recognizable and acceptable, but some value is not acceptable, the router transmits a CONFNAK message. The router appends the option and value that it can accept in the CONFNAK message so that the peer can include that option in the next CONFREQ message.
CONFACK	Configure-ACK 2	If all options in the CONFREQ message are recognizable and all values are acceptable, then the router transmits a CONFACK message.
TERMREQ	Terminate-Request	This message is used to initiate an LCP close.
TERMACK	Terminate-ACK	This message is transmitted in response to the TERMREQ message.

1. NAK = Negative Acknowledge

2. ACK = Acknowledge

Note: Each peer can send CONFREQs with the option or value it wants the peer to support. This can cause the options negotiated in each direction to be different. For example, one side may wish to authenticate the peer, while the other may not.

LCP, Authentication, and NCP Stage

Within some of the PPP phases described previously, PPP also goes into specific stages such as LCP negotiation, authentication, and NCP negotiation. For more information, refer to RFC 1548 and RFC 1661 .

LCP (Mandatory Phase)

LCP is a phase in which parameters to establish, configure, and test the data-link connection are negotiated. An LCP state of open means that LCP was successfully completed, while an LCP state of closed indicates an LCP failure.

This diagram shows a conceptual view of an LCP handshake:

The LCP negotiation also uses a parameter called MagicNumber, which is used to determine if the link is looped back. A random string is sent across the link and, if the same value is returned, then the router determines that the link is looped back.

Authentication (Optional Phase by Default)

In this stage, the authentication is performed with the authentication protocol (CHAP or PAP) agreed upon in LCP negotiation. For PAP related information, refer to Configuring and Troubleshooting PPP Password Authentication Protocol (PAP).

Note: Authentication is optional and PPP only enters this stage if it needs to authenticate.

NCP (Mandatory Phase)

This phase is used to establish and configure different network-layer protocols. The most common L3 protocol negotiated is IP. The routers exchange IP Control Protocol (IPCP) messages to negotiate options specific to the protocol (IP in this example).

RFC 1332 says that IPCP negotiates two options: compression and IP address assignments. However, IPCP is also used to pass network related information such as primary and backup Windows Name Service (WINS) and Domain Name System (DNS) servers.

The negotiation occurs with the use of CONF messages, as described in the PPP Negotiation Packets: A Description section of this document.

Troubleshooting with debug ppp negotiation Output

When you read the debug ppp negotiation command output for troubleshooting purposes, follow these instructions:

1. Identify the phase transitions in the debug command output. Determine the furthest phase the connection achieved, such as UP or AUTHENTICATING. This can help you identify the phase in which the connection failed. For more information on the phases, see the Phases of PPP Negotiation section.
2. For the phase in which the failure occurred, look for messages that indicate that LCP, authentication, or NCP (as appropriate) are successful:
   • The LCP state should be open. You can also look at the last incoming and outgoing CONFACK messages to verify that the parameters you require have been negotiated.
   • Authentication should be successful. If you use two-way authentication, then each transaction must be successful. For more information on troubleshooting PPP authentication failures, refer to Troubleshooting PPP (CHAP or PAP) Authentication.
   • The IPCP state should be open. Verify that the addressing is correct and that a route to the peer is installed.

Read debug ppp negotiation Output

Most lines in the debug ppp negotiation command output are characterized by:

1. The timestamp—Millisecond timestamps are useful. See the Prerequisites section of this document for more information.
2. Interface and Interface number—This field is useful when debug connections use multiple connections, or when the connection transitions through several interfaces. For example, certain connections (such as multilink calls) are controlled by the physical interface at the beginning, but are later controlled by the dialer interface or virtual-access interface.
3. Type of PPP message—This field indicates whether the line is a general PPP, LCP, CHAP, PAP, or IPCP message.
4. Direction of the message—An I indicates an incoming packet, and an O indicates an outgoing packet. This field can be used to determine if the message was generated or received by the router.
5. Message—This field includes the particular transaction under negotiation.
6. ID—This field is used to match and coordinate request messages to the appropriate response messages. You can use the ID field to associate a response with an incoming message. This option is especially useful when the incoming message and the response are far apart in the debug output.
7. Length—The length field defines the length of the information field. This field is not important for general troubleshooting.

Note: Fields 4 through 7 may not appear in all PPP messages, depending on the purpose of the message.

Note: This example illustrates the fields:

Sample debug ppp negotiation Output

This is an annotated description of debug ppp negotiation command output:

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 !--- The Physical Layer (BRI Interface) is up. Only now can PPP !--- negotiation begin.  *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] !--- The PPP Phase is ESTABLISHING. LCP negotiation now occurs.  *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 !--- This is the incoming CONFREQ. The ID field is 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) !--- The peer has requested: !--- Option: Authentication Protocol, Value: PAP !--- Option: MagicNumber (This is used to detect loopbacks and is always sent.) !--- Option: Callback, Value: 0 (This is for PPP Callback; MS Callback uses 6.)  *Mar 1 00:06:37.054: BR0:1 LCP: O CONFREQ [Listen] id 4 len 15 !--- This is an outgoing CONFREQ, with parameters for the peer to implement. !--- Note that the ID Field is 4, so this is not related to the previous !--- CONFREQ message.  *Mar 1 00:06:37.058: BR0:1 LCP: AuthProto CHAP (0x0305C22305) *Mar 1 00:06:37.062: BR0:1 LCP: MagicNumber 0x1081E7E1 (0x05061081E7E1) !--- This router requests: !--- Option: Authentication Protocol, Value: CHAP !--- Option: MagicNumber (This is used to detect loopbacks and is always sent.)  *Mar 1 00:06:37.066: BR0:1 LCP: O CONFREJ [Listen] id 7 len 7 !--- This is an outgoing CONFREJ for message with Field ID 7. !--- This is the response to the CONFREQ received first.  *Mar 1 00:06:37.070: BR0:1 LCP: Callback 0 (0x0D0300) !--- The option that this router rejects is Callback. !--- If the router wanted to do MS Callback rather than PPP Callback, it !--- would have sent a CONFNAK message instead.  *Mar 1 00:06:37.098: BR0:1 LCP: I CONFACK [REQsent] id 4 len 15 !--- This is an incoming CONFACK for a message with Field 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) !--- The peer can support all requested parameters.  *Mar 1 00:06:37.114: BR0:1 LCP: I CONFREQ [ACKrcvd] id 8 len 14 !--- This is an incoming CONFREQ message; the ID field is 8. !--- This is a new CONFREQ message from the peer in response to the 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) !--- The peer has requested: !--- Option: Authentication Protocol, Value: PAP !--- Option: MagicNumber (This is used to detect loopbacks and is always sent.)  *Mar 1 00:06:37.125: BR0:1 LCP: O CONFNAK [ACKrcvd] id 8 len 9 !--- This is an outgoing CONFNACK for a message with Field ID 8.  *Mar 1 00:06:37.129: BR0:1 LCP: AuthProto CHAP (0x0305C22305) !--- This router recognizes the option Authentication Protocol, !--- but does not accept the value PAP. In the CONFNAK message, !--- it suggests CHAP instead.  *Mar 1 00:06:37.165: BR0:1 LCP: I CONFREQ [ACKrcvd] id 9 len 15 !--- This is an incoming CONFREQ message with Field 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 authentication is requested.  *Mar 1 00:06:37.177: BR0:1 LCP: O CONFACK [ACKrcvd] id 9 len 15 !--- This is an outgoing CONFACK for a message with Field 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 !--- This indicates that the LCP state is Open.  *Mar 1 00:06:37.193: BR0:1 PPP: Phase is AUTHENTICATING, by both [0 sess, 0 load] !--- The PPP Phase is AUTHENTICATING. PPP Authentication occurs now. !--- Two-way authentication is now performed (indicated by the both keyword).  *Mar 1 00:06:37.201: BR0:1 CHAP: O CHALLENGE id 4 len 33 from "maui-soho-01" !--- This is the outgoing CHAP Challenge. !--- In LCP the routers had agreed upon CHAP as the authentication protocol.  *Mar 1 00:06:37.225: BR0:1 CHAP: I CHALLENGE id 3 len 33 from "maui-soho-03" !--- This is an incoming Challenge message from the peer.  *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" !--- This is an incoming response from the peer.  *Mar 1 00:06:37.244: BR0:1 CHAP: O SUCCESS id 4 len 4 !--- This router has successfully authenticated the peer.  *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 !--- This is an incoming Success message. Each side has !--- successfully authenticated the other.  *Mar 1 00:06:37.296: BR0:1 PPP: Phase is UP [0 sess, 0 load] !--- The PPP status is now UP. NCP (IPCP) negotiation begins.  *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) !--- This is an outgoing CONFREQ message. It indicates that !--- the local machine address is 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 !--- These messages are for 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) !--- This is an incoming CONFREQ message that indicates that the peer !--- address is 172.22.1.2. An address of 0.0.0.0 indicates that the peer !--- does not have an address and requests the local router to provide it !--- with an address in IPCP negotiation.  *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 !--- The IPCP state is Open. Note that in the IPCP negotiation, each side !--- accepted the IP address of the peer, and one was assigned to the peer.  *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 !--- This indicates that the CDPCP state is Open.  *Mar 1 00:06:37.387: BR0 IPCP: Install route to 172.22.1.2 !--- A route to the peer is installed.  *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

Glossary and Common Messages

General

CONFREQ (Configure-Request):

When the lower layer becomes available (Up), a CONFREQ is sent to start the first PPP phase (LCP phase). It is used in LCP and NCP phases as an attempt to configure the connection. To open a connection to the peer, the device transmits this message along with the configuration options and values the sender wishes the peer to support. All options and values are negotiated simultaneously. If the peer responds with a CONFREJ or CONFNAK message, then the router sends another CONFREQ with another set of options or values.

CONFACK (Configure-Acknowledge):

If all options in the CONFREQ message are recognizable and all values are acceptable, then the router transmits a CONFACK message.

CONFREJ (Configure Reject):

If some configuration option received in the CONFREQ is not acceptable or not recognizable, the router responds with a CONFREJ message. The unacceptable option (from the CONFREQ) is included in the CONFREJ message.

CONFNAK (Configure Negative Acknowledge):

If the received configuration option is recognizable and acceptable, but some value is not acceptable, the router transmits a CONFNAK message. The router appends the option and value that it can accept in the CONFNAK message so that the peer can include that option in the next CONFREQ message.

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

PPP uses keepalives in order to maintain the integrity of the connection. These keepalives are the ECHOREQ frame that is sent to remote PPP peer, and the remote PPP peer should respond with an ECHOREP frame upon receipt of an ECHOREQ frame. By default, if the router misses five ECHOREP frames, then the link is considered down and PPP is brought down.

TERMREQ (Termination Request):

This frame indicates that the PPP peer that sent this frame terminates the PPP connection.

TERMACK (Termination Acknowledge):

This message is transmitted in response to the TERMREQ message. This closes down the PPP connection.

TERMINATING

This message indicates that the PPP connection has been brought down. An LCP or NCP connection can be cut off:

• on administrative close (LCP only).
• when the lower level goes out of service (dial-up line, ISDN, and so on).
• when negotiations fall through.
• on line loop detection.

LCP

ACCM (Asynchronous Control Character Map):

This is one of the LCP-negotiated options within the CONFREQ frame. ACCM sets the character escape sequences. ACCM tells the port to ignore specified control characters within the data stream. If the router at the other end of the connection does not support ACCM negotiation, the port is forced to use FFFFFFFF. In that case, issue this command:

ppp accm match 000a000 

ACFC (Address and Control Field Compression):

ACFC is an LCP option that allows endpoints to send messages back and forth more efficiently.

AuthProto (Authentication Protocol):

AuthProto is the authentication protocol type negotiated in the CONFREQ frame between both PPP connection peers for use in the authentication phase. If no PPP authentication is configured, this output is not seen in CONFREQ frame negotiated parameters. The possible values are CHAP or PAP.

Callback «#»:

This message indicates that the callback option is under negotiation. The number after the callback syntax indicates which callback option is negotiated. The number 0 is normal PPP callback, while the number 6 indicates the Microsoft callback option (which is automatically available in Cisco IOS® Software Release 11.3(2)T or later).

CHAP (Challenge Handshake Authentication Protocol):

This message indicates that the authentication protocol under negotiation is CHAP.

EndpointDisc (End Point Discriminator):

This is an LCP option used to identify a PPP peer in PPP multilink connection. For more information, refer to Criteria for Naming Multilink PPP Bundles.

LCP: State is Open

This message indicates that the LCP negotiation has been completed successfully.

LQM (Link Quality Monitoring)

LQM is available on all serial interfaces that run PPP. LQM monitors the link quality and takes the link down when the quality drops below a configured percentage. The percentages are calculated for both the incoming and outgoing directions. The outgoing quality is calculated by comparison of the total number of packets and bytes sent with the total number of packets and bytes received by the peer. The incoming quality is calculated by comparison of the total number of packets and bytes received with the total number of packets and bytes sent by the peer.

When LQM is enabled, Link Quality Reports (LQRs) are sent every keepalive period. LQRs are sent in place of keepalives. All incoming keepalives are responded to properly. If LQM is not configured, keepalives are sent every keepalive period, and all incoming LQRs are responded to with an LQR.

MagicNumber

Magic Number support is available on all serial interfaces. PPP always attempts to negotiate for Magic Numbers, which are used to detect looped-back networks. A random string is sent across the link and if the same value is returned, then the router determines that the link is looped back.

The link might or might not be taken down upon looped-back detection; it depends on the use of the down-when-looped command.

PAP (Password Authentication Protocol)

This message indicates that the authentication protocol under negotiation for use by PPP peers is PAP. For more information on PAP, refer to Configuring and Troubleshooting PPP Password Authentication Protocol (PAP).

PFC (Protocol Field Compression)

This option turns compression for the protocol fields either on or off.

MRRU (Max Receive Reconstructed Unit)

This is an LCP option negotiated in the process of PPP multilink LCP setup. This option determines the maximum number of bytes that can constitute a frame. If MRRU is not negotiated in LCP, then Multilink PPP (MPPP) cannot run on the link.

MRU (Maximum Received Unit)

MRU is an LCP option negotiated in the CONFREQ frame to negotiate the size of the exchanged packets.

Authentication

AUTH-REQ (Authentication Request)

This frame is sent from the local PPP peer (on which authentication is enabled) to the remote peer. It asks the remote peer to send a valid username and password for PPP connection authentication. This frame is used only with PAP.

AUTH-ACK (Authentication Acknowledge)

This frame is sent out from the authenticated PPP peer to the authenticating PPP peer. This frame carries the valid username and password pair. This frame is used only when PAP is used for PPP connection authentication.

AUTH-NAK or FAILURE

This frame is sent out from the authenticating PPP peer when the authentication failed on the authenticating PPP peer.

CHALLENGE

This is the CHAP challenge frame that is sent from the authenticating PPP peer to the authenticated PPP peer. The challenge frame consists of an ID, a random number, and either the host name of the local communication server or the name of the user on the remote device. This frame is used only when CHAP is used for PPP connection authentication.

RESPONSE

This frame is the CHAP response sent from the authenticated PPP peer to the authenticating PPP peer.

The required response consists of two parts:

• An MD5 hash output of the shared secret.
• Either the host name of the remote device or the name of the user on the remote device.

This frame is used only when CHAP is used for PPP connection authentication.

NCP

Address a.b.c.d

• On an outgoing CONFREQ message, this value indicates the IP address the local router wishes to use. If the address included is 0.0.0.0, the local machine requests the peer to supply it an IP address it can use.
• On an incoming CONFREQ message, this value indicates the IP address the peer wishes to use. If the address included is 0.0.0.0, the peer requests the local machine to supply it an IP address it can use.
• On an outgoing CONFNAK message, this value indicates the IP address the peer should use rather than the one the peer suggested in the CONFREQ message.
• On an incoming CONFNAK message, this value indicates the IP address the local machine should use, instead of the one it suggested in the previous CONFREQ message.
• On an outgoing CONFACK message, this value indicates that the IP address requested by the peer is acceptable to the local machine.
• On an incoming CONFACK message, this value indicates that the IP address requested by the local machine is acceptable to the peer.

CCP (Compression Control Protocol)

This message indicates that a compression protocol is under negotiation between both PPP peers. Cisco IOS Software supports these compression protocols to be negotiated over a PPP connection:

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

CDPCP (Cisco Discovery Protocol Control Protocol)

This message indicates that CDP negotiation occurs in the NCP phase. To turn off CDP on the router, issue the no cdp run command.

CODEREJ (Code Reject)

A CODEREJ packet is sent upon receipt of an uninterpretable packed from the remote PPP peer.

Install route to a.b.c.d

When the router finishes IPCP (NCP phase for IP L3 protocol), it must install the given IP address to the remote PPP peer in the routing table and be seen as a connected route in the routing table. If you do not see this message, verify that the no peer neighbor-route command is not configured.

IPCP (IP Control Protocol)

This value indicates that IP is the network layer under negotiation in the NCP phase.

IPCP State is Open

This message indicates the IPCP (NCP phase for IP L3 protocol) has been completed successfully.

PROTREJ (Protocol Reject)

The PPP peer, upon receipt of a PPP packet with an unknown protocol field, uses the PROTREJ message to indicate that the peer has attempted to use a protocol that is unsupported. When a PPP device receives a PROTREJ message, it must at the earliest opportunity cease to send packets of the indicated protocol.

Related Information

• Configuring and Troubleshooting PPP Password Authentication Protocol (PAP)
• PPP Authentication Using the ppp chap hostname and ppp authentication chap callin Commands
• Understanding and Configuring PPP CHAP Authentication
• Troubleshooting PPP (CHAP or PAP) Authentication
• Dial Technology Support Pages
• Technical Support — Cisco Systems