Технологии LRE и xDSL : Поддержка асимметричных цифровых абонентских линий (ADSL)

Руководство по настройке и устранению неисправностей для маршрутизатора Cisco DSL - параметры реализации PPPoE: Устранение неполадок маршрутизатора DSL, используемого в качестве клиента PPPoE

20 октября 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (22 августа 2015) | Отзыв


Содержание


Введение

Неисправность подключения по DSL может быть вызвана множеством причин. Этот документ призван помочь установить причину сбоя и устранить его. Первый шаг к устранению неисправности состоит в определении отказавшего уровня службы ADSL. Существует три уровня, на которых может произойти сбой.

  • Уровень 1 – физическое подключение DSL к Мультиплексору доступа к цифровой абонентской линии (DSLAM) (DSLAM) вашего интернет-провайдера

  • 2-й уровень. 1 – подключение ATM

  • 2-й уровень. 2 – протокол PPPoA через АТМ (PPPoA), протокол PPPoE, мостовое соединение RFC1483 или маршрутизация RFC1483

  • IP уровня 3

Самый легкий способ определить, какого уровня необходимо начать устранять неполадки, состоит в том, чтобы выполнить command show ip interface brief. Выходные данные этой команды отличаются немного в зависимости от вашей конфигурации.

827-ESC#show ip interface brief
Interface     IP-Address     OK?     Method    Status     Protocol
ATM0          unassigned     YES     manual 	   up         up
ATM0.1        unassigned     YES     unset  	   up         up
Ethernet0     10.10.10.1     YES     manual    up         up

Если статусы ATM0 и ATM0.1 подключены, и протокол подключен, начните устранять неполадки на Уровне 2.

Если ATM-интерфейсы не работают, или если они продолжают подходить и затем выключаться (они не не ложатся спать и), начните устранять неполадки на Уровне 1.

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

Требования

Для этого документа отсутствуют особые требования.

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

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

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

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

Проблемы уровня 1

Обнаружение несущей (CD) является светом на лицевой панели маршрутизатора Cisco DSL на или прочь?

Если световой сигнал CD идет, перейдите к разделу Проблем Уровня 2 этого документа.

Если световой сигнал CD выключен, продолжите следующий вопрос.

Ваш интернет-провайдер использует DSLAM, который поддерживает Набор микросхем Alcatel?

Проверьте эту информацию со своим интернет-провайдером.

Порт DSL в конце маршрутизатора Cisco DSL, включил настенную розетку DSL?

Если порт DSL не включен в настенную розетку DSL, подключите порт со стеной с 4-контактным или 6-контактным кабелем RJ-11. Это - кабель стандартного телефона.

ATM-интерфейс в административно выключенном состоянии?

Чтобы определить, административно выключен ли интерфейс ATM0, выполните эту команду в режиме включения на маршрутизаторе:

Router#show interface atm 0
ATM0 is administratively down, line protocol is down
<... snipped ...> 

Если статус интерфейса ATM0 административно выключен, выполните команду no shutdown под интерфейсом ATM0.

Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#interface atm 0
Router(config-if)#no shut
Router(config-if)#end
Router#write memory

Кабельный вывод корректен?

Если статус интерфейса ATM0 не работает и вниз, маршрутизатор не видит носитель на линии ADSL. Это обычно указывает на одну из двух проблем:

  1. Активные контакты на настенной розетке DSL являются неправильными.

  2. Ваш интернет-провайдер не включил услугу DSL на этой настенной розетке.

Расположения выводов порта xDSL маршрутизатора Cisco DSL

Разъём RJ-11 предоставляет подключение xDSL внешним носителям через стандартный RJ-11 6-контактный модульный разъем.

№ контакта Описание
3 XDSL_Tip
4 XDSL_Ring

Чтобы определить, не работает ли интерфейс ATM0 и вниз, выполните команду show interface ATM 0 от режима включения маршрутизатора:

Router#show interface atm 0
ATM0 is down, line protocol is down
<... snipped ...>

Если ATM-интерфейс не работает, и вниз — не административно выключенный — проверяют схему расположения выводов вашей настенной розетки DSL. Маршрутизатор DSL использует стандартный RJ-11 (4-контактный или 6-контактный) кабель для обеспечения соединения ADSL настенной розетке. Средняя пара контактов на кабеле RJ-11 используется для переноса сигнала ADSL (контакты 3 и 4 на 6-контактном кабеле или контакты 2 и 3 на 4-кабелях контакта).

Если вы уверены, что у вас есть правильные контакты на настенной розетке, и интерфейс ATM0 все еще не работает и вниз, замените кабель RJ-11 между портом DSL и вашей настенной розеткой. Если интерфейс все еще не работает и вниз после замены кабеля RJ-11 свяжитесь интернет-провайдером и сделайте, чтобы интернет-провайдер проверил, что услуга DSL была включена на настенной розетке, которую вы используете.

Если вы не уверены, какие контакты на настенной розетке активны, спросите ISP.

У вас есть корректный источник питания для Cisco 827?

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

Примечание: Эти 827 не используют тот же источник питания в качестве других маршрутизаторов серии "800".

Чтобы определить, есть ли у вас корректный источник питания, в конце адаптера питания ищут Выходные данные +12V 0.1A, - 12V 0.1 А, +5V 3 А, - 24V 0.12 А, и - 71V 0.12 А. Если ваш источник питания пропускает +12V и - подача 12V, то это для другого маршрутизатора Cisco серии 800 и не работает на 827. Обратите внимание на то, что, если вы используете неправильный источник питания, Cisco 827 включается, но неспособен обучаться, (соединяются) с DSLAM интернет-провайдера.

DSL operating-mode корректен?

Если все до этой точки в процедуре устранения проблем Уровня 1 корректно, следующий шаг должен удостовериться, что у вас есть корректный рабочий режим DSL. Cisco рекомендует использовать dsl operating-mode, автоматического, если вы не уверены, какую технологию DMT ваш интернет-провайдер использует. Это команды для настройки автоматического обнаружения operating-mode:

Router#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#interface atm 0
Router(config-if)#dsl operating-mode auto
Router(config-if)#end
Router#write memory

Канал, тестировал/настраивал правильно?

Получите эту информацию из своего интернет-провайдера или телефонной компании.

Проблемы уровня 2

У вас есть корректные значения PVC (VPI/VCI)?

С развертываниями PPPoE нет никакого простого способа для динамичного обнаружения идентификатора виртуального тракта Постоянной виртуальной цепи (PVC)/виртуальный идентификатор канала (VPI/VCI) значения. Свяжитесь со своим интернет-провайдером, если вы не уверены в своих значениях PVC.

Вы получаете данные от своего интернет-провайдера?

Если у вас есть корректные значения PVC, следующий шаг должен проверить, что вы пытаетесь выполнить согласование о PPP со своим интернет-провайдером. Чтобы сделать это, выполните команду show interface atm0 и проверьте пакеты ввод/вывода.

Router#show interface atm0
ATM0 is up, line protocol is up
Hardware is DSLSAR (with Alcatel ADSL Module)
MTU 4470 bytes, sub MTU 4470, BW 128 Kbit, DLY 16000 usec, 
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ATM, loopback not set
Encapsulation(s): AAL5, PVC mode
24 maximum active VCs, 256 VCS per VP, 1 current VCCs
VC idle disconnect time: 300 seconds
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Queueing strategy: fifo
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
5 minute input rate 5 bits/sec, 0 packets/sec
5 minute output rate 7 bits/sec, 0 packets/sec
100 packets input, 5600 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
250 packets output, 1400 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets
0 output buffer failures, 0 output buffers swapped out

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

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

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

Сеанс PPPoE?

PPPoE выполняется в двух фазах. Первая фаза является установлением Сеанса PPPoE, и вторая фаза является согласованием PPP. PPPoE должен быть установлен до согласования стандартных параметров PPP. Самый легкий способ определить, есть ли у вас активный Сеанс PPPoE, состоит в том, чтобы выполнить команду show vpdn.

Router#show vpdn
%No active L2TP tunnels
%No active L2F tunnels
%No active PPTP tunnels
PPPoE Tunnel and Session Information Total tunnels 1 sessions 1
PPPoE Tunnel Information
Session count: 1
PPPoE Session Information
SID  RemMAC          LocMAC          Intf   Vast   OIntf   VP/VC
0    0000.0000.0000  0000.0000.0000         UNKN   ATM0    8/35

В данном примере никакие Сеансы PPPoE не активны. Это обозначено SID 0, и RemMAC и LocMAC 0000.0000.0000. Если вы находитесь в этом состоянии, продолжаетесь к следующему разделу.

Сеанс PPPoE, о котором успешно выполняют согласование, похож на это:

Router#show vpdn
%No active L2TP tunnels 
%No active L2F tunnels 
PPPoE Tunnel and Session Information Total tunnels 1 sessions 1
PPPoE Tunnel Information
Session count: 1

PPPoE Session Information
SID  RemMAC           LocMAC          Intf    Vast   OIntf   VP/VC
1    0050.7359.35b7   0001.96a4.84ac  Vi1     UP     ATM0    8/35

В данном примере вы видите, что SID является ненулевым номером, и что оба поля RemMAC и LocMAC заполнены. Другая интересующая область является Обширным, которое указывает, выполнили ли о PPP успешно согласование и аутентифицировали. Если Обширное подключено UP, о PPP успешно выполнили согласование и аутентифицировали, и можно ли продолжиться к, Почему я могу обратиться к некоторым веб-страницам с PPPoE, но не другими? раздел этого документа. Если Обширное не работает, продолжите следующий раздел.

Вы получаете ответ PPPoE от маршрутизатора с поддержкой агрегирования?

Если вам не установили активный Сеанс PPPoE, необходимо выполнить команду debug vpdn pppoe-events для определения, какой PPPoE не подходит.

Router#debug vpdn pppoe-events
*Mar  3 21:49:38.030: Sending PADI: vc=8/35
*Mar  3 21:49:38.030: padi timer expired
*Mar  3 21:50:10.030: Sending PADI: vc=8/35
*Mar  3 21:50:10.030: padi timer expired
*Mar  3 21:50:42.030: Sending PADI: vc=8/35
*Mar  3 21:50:42.030: padi timer expired
*Mar  3 21:51:14.030: Sending PADI: vc=8/35
*Mar  3 21:51:14.030: padi timer expired
*Mar  3 21:51:46.030: Sending PADI: vc=8/35
*Mar  3 21:51:46.030: padi timer expired
Router#undebug all

В данном примере маршрутизатор Cisco DSL постоянно передает кадры Инициирования быстрого развертывания PPPoE (PADI) в интернет-провайдера без ответа. Кадр PADI является первым в серии кадров настройки вызова PPPoE. Если ваш интернет-провайдер не отвечает Предложением быстрого развертывания PPPoE (PADO), согласование PPPoE не успешно выполняется. Единственное решение для этой проблемы состоит в том, чтобы связаться с вашим интернет-провайдером.

При успешном согласовании о PPPoE выходные данные debug vpdn pppoe-events похожи на эти выходные данные:

Router#debug vpdn pppoe-events
*Mar  3 21:49:38.030: Sending PADI: vc=8/35
*Mar  3 21:50:10.030: PPPOE: we've got our pado and the pado timer went off
*Mar  3 21:50:35.030: OUT PADR from PPPoE tunnel
*Mar  3 21:50:50.030: IN PADS from PPPoE tunnel
Router#undebug all

Если о PPPoE успешно выполняют согласование, продолжите следующий раздел об устранении проблем PPP.

PPP выполняет согласование должным образом?

Если Уровень 1 подключен, и у вас есть корректный VPI/VCI, следующий шаг должен удостовериться, что PPP подходит должным образом. Для выполнения этого необходимо выполнить серию команд отладки на маршрутизаторе Cisco DSL и интерпретировать выходные данные. Основная отладка, которую вы используете, является debug ppp negotiation. Эти выходные данные команды являются примером успешного согласования PPP:

Router#debug ppp negotiation

PPP protocol negotiation debugging is on

Router#
2w3d: Vi1 PPP: No remote authentication for call-out
2w3d: Vi1 PPP: Phase is ESTABLISHING
2w3d: Vi1 LCP: O CONFREQ [Open] id 146 len 10
2w3d: Vi1 LCP: MagicNumber 0x8CCF0E1E (0x05068CCF0E1E)
2w3d: Vi1 LCP: O CONFACK [Open] id 102 Len 15
2w3d: Vi1 LCP: AuthProto CHAP (0x0305C22305)
2w3d: Vi1 LCP: MagicNumber 0xD945AD0A (0x0506D945AD0A)
2w3d: Di1 IPCP: Remove route to 20.20.2.1
2w3d: Vi1 LCP: I CONFACK [ACKsent] id 146 Len 10
2w3d: Vi1 LCP: MagicNumber 0x8CCF0E1E (0x05068CCF0E1E)
2w3d: Vi1 LCP: State is Open
2w3d: Vi1 PPP: Phase is AUTHENTICATING, by the peer
2w3d: Vi1 CHAP: I CHALLENGE id 79 Len 33 from "6400-2-NRP-2"
2w3d: Vi1 CHAP: O RESPONSE id 79 Len 28 from "John"
2w3d: Vi1 CHAP: I SUCCESS id 79 Len 4
2w3d: Vi1 PPP: Phase is UP
2w3d: Vi1 IPCP: O CONFREQ [Closed] id 7 Len 10
2w3d: Vi1 IPCP: Address 0.0.0.0 (0x030600000000)
2w3d: Vi1 IPCP: I CONFREQ [REQsent] id 4 Len 10
2w3d: Vi1 IPCP: Address 20.20.2.1 (0x030614140201)
2w3d: Vi1 IPCP: O CONFACK [REQsent] id 4 Len 10
2w3d: Vi1 IPCP: Address 20.20.2.1 (0x030614140201)
2w3d: Vi1 IPCP: I CONFNAK [ACKsent] id 7 Len 10
2w3d: Vi1 IPCP: Address 40.1.1.2 (0x030628010102)
2w3d: Vi1 IPCP: O CONFREQ [ACKsent] id 8 Len 10
2w3d: Vi1 IPCP: Address 40.1.1.2 (0x030628010102)
2w3d: Vi1 IPCP: I CONFACK [ACKsent] id 8 Len 10
2w3d: Vi1 IPCP: Address 40.1.1.2 (0x030628010102)
2w3d: Vi1 IPCP: State is Open
2w3d: Di1 IPCP: Install negotiated IP interface address 40.1.1.2
2w3d: Di1 IPCP: Install route to 20.20.2.1
Router#

Существует четыре сути сбоя на согласовании PPP:

  • Никакой ответ от удаленного устройства (ваш интернет-провайдер)

  • Протокол управления каналом (LCP), не открытый

  • Ошибка проверки подлинности

  • IP Control Protocol (IPCP) сбой

Никакой ответ от вашего интернет-провайдера

Ваш интернет-провайдер, не отвечающий, не должен быть проблемой, так как вы уже проверили, что пакеты инкрементно увеличиваются на интерфейсе ATM0 во входящем направлении. Однако, если вы видите, что пакеты инкрементно увеличиваются на ATM0 во входящем направлении, и когда вы выполняете debug ppp negotiation, вы получаете эти выходные данные, связываетесь с вашим интернет-провайдером, чтобы проверить, что пакеты переданы к маршрутизатору Cisco DSL.

Router#debug ppp negotiation
*Mar 1 04:04:50.718: Vi1 PPP: Treating connection as a callout
*Mar 1 04:04:50.718: Vi1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 0 load]
*Mar 1 04:04:50.718: Vi1 PPP: No remote authentication for call-out
*Mar 1 04:04:50.722: Vi1 LCP: O CONFREQ [Closed] id 1 Len 10 

!--- "O" specifies an outbound packet.

*Mar 1 04:04:50.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4)
*Mar 1 04:04:52.722: Vi1 LCP: TIMEout: State REQsent
*Mar 1 04:04:52.722: Vi1 LCP: O CONFREQ [REQsent] id 2 Len 10 

!--- "O" specifies an outbound packet.

*Mar 1 04:04:52.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4)
*Mar 1 04:04:54.722: Vi1 LCP: TIMEout: State REQsent
*Mar 1 04:04:54.722: Vi1 LCP: O CONFREQ [REQsent] id 3 Len 10 
*Mar 1 04:04:54.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4)
*Mar 1 04:04:56.722: Vi1 LCP: TIMEout: State REQsent
*Mar 1 04:04:56.722: Vi1 LCP: O CONFREQ [REQsent] id 4 Len 10
*Mar 1 04:04:56.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4)
*Mar 1 04:04:58.722: Vi1 LCP: TIMEout: State REQsent
*Mar 1 04:04:58.722: Vi1 LCP: O CONFREQ [REQsent] id 5 Len 10
*Mar 1 04:04:58.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4)
*Mar 1 04:05:00.722: Vi1 LCP: TIMEout: State REQsent
*Mar 1 04:05:00.722: Vi1 LCP: O CONFREQ [REQsent] id 6 Len 10
*Mar 1 04:05:00.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4)
*Mar 1 04:05:02.722: Vi1 LCP: TIMEout: State REQsent 
*Mar 1 04:05:02.722: Vi1 LCP: O CONFREQ [REQsent] id 7 Len 10 

!--- "O" specifies an outbound packet.

*Mar 1 04:05:02.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4)
Router#undebug all

В этих выходных данных существуют только O пакеты, которые являются исходящими пакетами. Для успешного согласования о PPP должен быть я входящий пакет от интернет-провайдера для каждого переданного пакета O. Если пакеты инкрементно увеличиваются входящий, но вы не видите меня пакеты, свяжитесь со своим интернет-провайдером для проверки пакетов, которые переданы к маршрутизатору Cisco DSL.

LCP, не открытый

LCP, не являющийся открытым, обычно вызывается несоответствием в опциях PPP. Это несоответствие происходит, когда маршрутизатору Cisco DSL настроили параметр PPP, который ваш интернет-провайдер не поддерживает, или когда вашему интернет-провайдеру настроили параметр, который не поддерживает маршрутизатор Cisco DSL. Эти выходные данные показывают пример несоответствия опции PPP:

Router#debug ppp negotiation
*Mar 1 04:52:43.254: Vi1 PPP: Treating connection as a callout
*Mar 1 04:52:43.258: Vi1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 1 load] 
*Mar 1 04:52:43.258: Vi1 PPP: No remote authentication for call-out 
*Mar 1 04:52:43.258: Vi1 LCP: O CONFREQ [Closed] id 3 len 10
*Mar 1 04:52:43.262: Vi1 LCP: MagicNumber 0x31A2F808 (0x050631A2F808)
*Mar 1 04:52:43.310: Vi1 LCP: I CONFREQ [REQsent] id 180 Len 14
*Mar 1 04:52:43.310: Vi1 LCP: AuthProto PAP (0x0304C023)
*Mar 1 04:52:43.310: Vi1 LCP: MagicNumber 0x39D50E9B (0x050639D50E9B)
*Mar 1 04:52:43.314: Vi1 LCP: O CONFNAK [REQsent] id 180 Len 9

!--- PPP option reject

*Mar 1 04:52:43.314: Vi1 LCP: AuthProto CHAP (0x0305C22305)

!--- PPP option that is rejected

*Mar 1 04:52:43.314: Vi1 LCP: I CONFACK [REQsent] id 3 Len 10
*Mar 1 04:52:43.318: Vi1 LCP: MagicNumber 0x31A2F808 (0x050631A2F808)
*Mar 1 04:52:43.366: Vi1 LCP: I CONFREQ [ACKrcvd] id 181 Len 14
*Mar 1 04:52:43.366: Vi1 LCP: AuthProto PAP (0x0304C023)
*Mar 1 04:52:43.366: Vi1 LCP: MagicNumber 0x39D50E9B (0x050639D50E9B)
*Mar 1 04:52:43.370: Vi1 LCP: O CONFNAK [ACKrcvd] id 181 Len 9 

!--- PPP option reject

*Mar 1 04:52:43.370: Vi1 LCP: AuthProto CHAP (0x0305C22305) 

!--- PPP option that is rejected

*Mar 1 04:52:43.418: Vi1 LCP: I CONFREQ [ACKrcvd] id 182 Len 14
*Mar 1 04:52:43.418: Vi1 LCP: AuthProto PAP (0x0304C023)
*Mar 1 04:52:43.418: Vi1 LCP: MagicNumber 0x39D50E9B (0x050639D50E9B)
Router#undebug all

Показательно ли я или пакет O, Настраивать-отрицательное-квитирование (CONFNAK) из несоответствия конфигурации PPP. То, что это означает, - то, что одна сторона PPP - подключения просит опцию PPP, чтобы другая сторона была неспособна или не настроенная для выполнения. Если маршрутизатор Cisco DSL передает CONFNAK (обозначенный "O CONFNAK"), маршрутизатор Cisco DSL не в состоянии выполнить или не настроенный для опции, которую передает интернет-провайдер. Если CONFNAK передается вашим интернет-провайдером (обозначенный "мной CONFNAK"), вы настроили опцию на маршрутизаторе Cisco DSL, который ваш интернет-провайдер не готов выполнить.

Линия после CONFNAK описывает опцию, которая отклонена. В выходных данных данного примера опция является CHAP, но это могла быть любая опция. Единственное место на маршрутизаторе Cisco DSL, где опции PPP могут быть настроены, является interface dialer 1. Выполните команду show run interface dialer 1 для просмотра конфигурации interface dialer 1.

Если ваш интернет-провайдер передает мне CONFNAK, ищите команды под interface dialer 1, которые совпадают с линией после CONFNAK и удаляют их. Если маршрутизатор Cisco DSL передает CONFNAK O, добавьте команду к interface dialer 1 для надлежащего согласования о PPP с интернет-провайдером. В случае передающего пакеты маршрутизатора вы, возможно, должны были бы вызвать Центр технической поддержки Cisco для определения, какая команда (команды) должна быть выполнена на маршрутизаторе Cisco DSL.

Ошибка проверки подлинности

Когда ваш интернет-провайдер неспособен аутентифицировать ваше имя пользователя или пароль PPP, ошибка проверки подлинности происходит. Существует два сценария, в которых это может произойти. Первый сценарий является несоответствующим типом аутентификации, который вызван, когда вы должным образом не настраиваете маршрутизатор. Все конфигурации аутентификации, перечисленные в этом документе, составляют и PAP и типы Аутентификации CHAP. Для гибкости конфигурации у вас должны быть и CHAP и настроенный PAP. Если у вас нет обоих настроенными, вы могли бы видеть выходные данные от команды debug ppp как эти выходные данные:

Router#debug ppp negotiation
00:34:29: Vi1 LCP:O CONFREQ [REQsent] id 53 Len 15 
00:34:29: Vi1 LCP: AuthProto CHAP (0x0305C22305)

!--- Sends CHAP requests

00:34:29: Vi1 LCP: MagicNumber 0x01B63483 (0x050601B63483)
00:34:29: Vi1 LCP: I CONFREQ [REQsent] id 252 Len 14
00:34:29: Vi1 LCP: AuthProto PAP (0x0304C023)

!--- Receives PAP requests from the service provider

00:34:29: Vi1 LCP: MagicNumber 0xBC5233F9 (0x0506BC5233F9)
00:34:29: Vi1 LCP: O CONFREJ [REQsent] id 252 Len 8
Router#undebug all

или

Router#debug ppp negotiation
00:45:44: Vi1 LCP: I CONFREQ [Listen] id 141 Len 15
00:45:44: Vi1 LCP: AuthProto CHAP (0x0305C22305)

!--- Receives CHAP requests from the service provider

00:45:44: Vi1 LCP: MagicNumber 0xBC5C7DDC (0x0506BC5C7DDC)
00:45:44: Vi1 LCP: O CONFREQ [Listen] id 255 Len 14
00:45:44: Vi1 LCP: AuthProto PAP (0x0304C023) 

!--- Sends out PAP requests

Router#undebug all

!--- Turn off ppp debug


Для исправления и опознавательных проблем несоответствия обратитесь к соответствующей конфигурации параметра реализации PPPoA и реконфигурируйте проверку подлинности PPP.

Второй сценарий проблемы аутентификации, с которым можно встретиться, является неправильным именем пользователя PAP или паролем. Чтобы определить, является ли это проблемой, выполните debug ppp negotiation команды. Принятие вашего маршрутизатора настроено и для Протокола аутентификации по квитированию вызова (CHAP) и для Протокола аутентификации пароля (PAP), поскольку конфигурация, выделенная ранее в этом руководстве, показывает, ваш интернет-провайдер не мог бы использовать Аутентификацию PAP.

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

Как я знаю, корректны ли мое имя пользователя PAP и пароль?

После того, как вы подтвердили, что ваш интернет-провайдер использует PAP, выполните команду debug ppp negotiation, чтобы подтвердить, что ваше имя пользователя PAP и пароль корректны.

Router#debug ppp negotiation 
*Mar 2 00:50:15.741: Vi1 PPP: Treating connection as a callout
*Mar 2 00:50:15.745: Vi1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 1 load]
*Mar 2 00:50:15.745: Vi1 PPP: No remote authentication for call-out
*Mar 2 00:50:15.745: Vi1 LCP: O CONFREQ [Closed] id 177 Len 10
*Mar 2 00:50:15.745: Vi1 LCP: MagicNumber 0x35EB5D4F (0x050635EB5D4F)
*Mar 2 00:50:15.789: Vi1 LCP: I CONFACK [REQsent] id 177 Len 10
*Mar 2 00:50:15.793: Vi1 LCP: MagicNumber 0x35EB5D4F (0x050635EB5D4F)
*Mar 2 00:50:17.241: Vi1 LCP: I CONFREQ [ACKrcvd] id 203 Len 14
*Mar 2 00:50:17.241: Vi1 LCP: AuthProto PAP (0x0304C023)
*Mar 2 00:50:17.241: Vi1 LCP: MagicNumber 0x3E1D1E5E (0x05063E1D1E5E)
*Mar 2 00:50:17.245: Vi1 LCP: O CONFACK [ACKrcvd] id 203 Len 14
*Mar 2 00:50:17.245: Vi1 LCP: AuthProto PAP (0x0304C023)
*Mar 2 00:50:17.245: Vi1 LCP: MagicNumber 0x3E1D1E5E (0x05063E1D1E5E)
*Mar 2 00:50:17.249: Vi1 LCP: State is Open
*Mar 2 00:50:17.249: Vi1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 1 load]
*Mar 2 00:50:17.249: Vi1 PAP: O AUTH-REQ id 9 Len 14 from "cisco" 

!--- "cisco" is the PAP username configured on this DSL router.

*Mar 2 00:50:17.297: Vi1 PAP: I AUTH-NAK id 9 Len 27 msg is "Authentication failure"
*Mar 2 00:50:17.301: Vi1 LCP: I TERMREQ [Open] id 204 Len 4
*Mar 2 00:50:17.301: Vi1 LCP: O TERMACK [Open] id 204 Len 4
*Mar 2 00:50:17.305: Vi1 PPP: Phase is TERMINATING [0 sess, 1 load]u
*Mar 2 00:50:19.305: Vi1 LCP: TIMEout: State TERMsent
*Mar 2 00:50:19.305: Vi1 LCP: State is Closed
*Mar 2 00:50:19.305: Vi1 PPP: Phase is DOWN [0 sess, 1 load]

Если у вас есть проблема Аутентификации PAP, необходимо видеть, что состояние LCP переходит Открытый. Непосредственно после изменения состояния LCP необходимо видеть, что PPP входит в Аутентифицирующуюся фазу. Если одна из следующих двух линий содержит меня AUTH-NAK, или ваше имя пользователя PAP или пароль PAP являются неправильными. На этом этапе необходимо реконфигурировать имя пользователя PAP и пароль с помощью этой последовательности команд. Обратите внимание на то, что ваше имя пользователя PAP и пароль учитывают регистр.

Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#interface dialer 1
Router(config-if)#ppp pap sent-username <username> password <password>
Router(config-if)#end
Router#write memory

Как я знаю, корректно ли мое имя пользователя и пароль CHAP?

После того, как вы подтвердили, что ваш интернет-провайдер использует CHAP, выполните команду debug ppp negotiation, чтобы подтвердить, что ваше имя пользователя и пароль CHAP корректно.

Router#debug ppp negotiation
*Mar 3 02:51:47.287: Vi1 PPP: Treating connection as a callout
*Mar 3 02:51:47.287: Vi1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 1 load]
*Mar 3 02:51:47.291: Vi1 PPP: No remote authentication for call-out
*Mar 3 02:51:47.291: Vi1 LCP: O CONFREQ [Closed] id 188 Len 10
*Mar 3 02:51:47.291: Vi1 LCP: MagicNumber 0x3B821FF1 (0x05063B821FF1)
*Mar 3 02:51:47.339: Vi1 LCP: I CONFREQ [REQsent] id 204 Len 15
*Mar 3 02:51:47.343: Vi1 LCP: AuthProto CHAP (0x0305C22305)
*Mar 3 02:51:47.343: Vi1 LCP: MagicNumber 0x43B3F393 (0x050643B3F393)
*Mar 3 02:51:47.343: Vi1 LCP: O CONFACK [REQsent] id 204 Len 15
*Mar 3 02:51:47.347: Vi1 LCP: AuthProto CHAP (0x0305C22305)
*Mar 3 02:51:47.347: Vi1 LCP: MagicNumber 0x43B3F393 (0x050643B3F393)
*Mar 3 02:51:47.347: Vi1 LCP: I CONFACK [ACKsent] id 188 Len 10
*Mar 3 02:51:47.351: Vi1 LCP: MagicNumber 0x3B821FF1 (0x05063B821FF1)
*Mar 3 02:51:47.351: Vi1 LCP: State is Open
*Mar 3 02:51:47.351: Vi1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 1 load]
*Mar 3 02:51:47.395: Vi1 CHAP: I CHALLENGE id 1 Len 32 from "6400-2-NRP3"
*Mar 3 02:51:47.395: Vi1 CHAP: Using alternate hostname cisco
*Mar 3 02:51:47.399: Vi1 CHAP: Username 6400-2-NRP3 not found
*Mar 3 02:51:47.399: Vi1 CHAP: Using default password
*Mar 3 02:51:47.399: Vi1 CHAP: O RESPONSE id 1 Len 26 from "cisco"  

!--- "cisco" is the CHAP username configured on this DSL router.

*Mar 3 02:51:47.447: Vi1 CHAP: I FAILURE id 1 Len 26 MSG is "Authentication failure"
*Mar 3 02:51:47.447: Vi1 LCP: I TERMREQ [Open] id 205 Len 4
*Mar 3 02:51:47.451: Vi1 LCP: O TERMACK [Open] id 205 Len 4
*Mar 3 02:51:47.451: Vi1 PPP: Phase is TERMINATING [0 sess, 0 load]
*Mar 3 02:51:49.451: Vi1 LCP: TIMEout: State TERMsent
*Mar 3 02:51:49.451: Vi1 LCP: State is Closed
*Mar 3 02:51:49.451: Vi1 PPP: Phase is DOWN [0 sess, 0 load]
Router#undebug all

Если у вас есть проблема Аутентификации CHAP, необходимо видеть, что состояние LCP переходит Открытый. Непосредственно после изменения состояния LCP необходимо видеть, что PPP входит в Аутентифицирующуюся фазу. От этой точки вы видите серию линий CHAP. Если последняя из этих линий показывает мне СБОЙ, у вас есть неправильное имя пользователя и пароль CHAP. Используйте эту последовательность команд для исправления имени пользователя и пароля CHAP. Обратите внимание на то, что ваше имя пользователя и пароль учитывает регистр.

Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#interface dialer 1
Router(config-if)#ppp chap hostname <username> 
Router(config-if)#ppp chap password <password>
Router(config-if)#end
Router#write memory

Когда проверка подлинности PPP успешна, как я знаю?

Данный пример показывает успешное согласование CHAP.

Router#debug ppp negotiation
<... snipped ...>
*Mar 3 03:30:09.335: Vi1 LCP: State is Open
*Mar 3 03:30:09.335: Vi1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 1 load]
*Mar 3 03:30:09.379: Vi1 CHAP: I CHALLENGE id 41 len 32 from "6400-2-NRP3"
*Mar 3 03:30:09.379: Vi1 CHAP: Using alternate hostname cisco
*Mar 3 03:30:09.379: Vi1 CHAP: Username 6400-2-NRP3 not found
*Mar 3 03:30:09.383: Vi1 CHAP: Using default password
*Mar 3 03:30:09.383: Vi1 CHAP: O RESPONSE id 41 Len 26 from "cisco"
*Mar 3 03:30:09.431: Vi1 CHAP: I SUCCESS id 41 Len 4

!--- CHAP negotiation was a success.

*Mar 3 03:30:09.431: Vi1 PPP: Phase is UP [0 sess, 1 load] 
<... snipped ...>
Router#undebug all

Данный пример показывает успешное согласование PAP.

Router#debug ppp negotiation
<... snipped ...>
*Mar 3 03:33:19.491: Vi1 LCP: State is Open
*Mar 3 03:33:19.491: Vi1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 0 load]
*Mar 3 03:33:19.495: Vi1 PAP: O AUTH-REQ id 255 Len 16 from "cisco"
*Mar 3 03:33:19.539: Vi1 PAP: I AUTH-ACK id 255 Len 5
*Mar 3 03:33:19.539: Vi1 PPP: Phase is UP [0 sess, 0 load] 

!--- PAP negotiation was a success.

<... snipped ...>
Router#undebug all

Почему я могу обратиться к некоторым веб-страницам с PPPoE, но не другими?

Доступ только к некоторым веб-страницам является типичной проблемой при выполнении PPPoE-клиента на маршрутизаторе. Дизайном PPPoE может поддержать MTU до 1492 байтов. Поэтому необходимо гарантировать, что конечные устройства отсылают, структурирует не больше, чем 1492 байта. Ограничение MTU к 1492 байтам может быть проблемой, потому что большинство PC и Рабочих станций конечного пользователя имеют MTU по умолчанию 1500 байтов.

Существует две опции для регулировки максимального размера передаваемого блока данных: отрегулируйте максимальный размер передаваемого блока данных в маршрутизаторе и отрегулируйте максимальный размер передаваемого блока данных в ПК.

Отрегулируйте максимальный размер передаваемого блока данных PPPoE на маршрутизаторе Cisco DSL

Важные примечания:

Эти команды настройки работают, только если вы выполняете Технологию NAT или Преобразование адресов портов (PAT) на маршрутизаторе Cisco DSL.

Команда ip adjust-mss в Cisco Выпуск ПО IOS� 12.2 (2) XH изменила на ip tcp adjust-mss <mss значение>. Это изменение задокументировано в Комментарии к выпуску для маршрутизаторов Cisco серии 800 и Маршрутизаторы серии Cisco 820 для Cisco IOS Release 12.2 (2) XH.

!
vpdn enable
no vpdn logging
!
vpdn-group pppoe
request-dialin 
protocol pppoe 
!
interface ethernet0
 no shut
 ip address <ip address> <subnet mask>
 ip adjust-mss 1452
 
!--- The TCP MSS command requires an MSS of 1452, not 1492.

 ip nat inside 
 no ip directed-broadcast
!
interface atm0
 no shut
 no ip address
 no ip directed-broadcast
 no atm ilmi-keepalive
 bundle-enable
!
interface atm0.1 point-to-point
 no ip directed-broadcast
 pvc <vpi/vci>
 pppoe-client dial-pool-number 1 
 !
!
interface dialer1
 ip address negotiated
 mtu 1492
 ip nat outside 
 encapsulation ppp
 dialer pool 1
 ppp chap hostname <username>
 ppp chap password <password>
 ppp pap sent-username <username> password <password>
! 
ip nat inside source list 1 interface dialer1 overload 
!
ip classless 
ip route 0.0.0.0 0.0.0.0 dialer1 
access-list 1 permit <ip address of ethernet0> 0.0.255.255 
!

Отрегулируйте максимальный размер передаваемого блока данных PPPoE на ПК Использование утилиты Dr. TCP доктора

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

Примечание: Утилита Dr. TCP Доктора совместима со всеми PC на базе Windows.

  1. Загрузите последнюю версию утилиты Dr. TCP Доктора leavingcisco.com.

  2. Обновите свою страницу браузера, чтобы гарантировать, что страница является текущей.

  3. Выполните утилиту Dr. TCP Доктора.

  4. Из меню выбирают ваш Адаптер ethernet.

  5. В поле MTU введите 1492.

  6. Нажмите кнопку "Apply" для сохранения изменений, после чего нажмите кнопку "Exit".

  7. Перезагрузите ПК - клиента PPPoE.

Необходимо выполнить утилиту только один раз в ПК PPPoE-клиента.

Дополнительные действия по устранению проблем MTU

Если на маршрутизаторе Cisco DSL можно изменить размер MTU с помощью Dr. TCP, но невозможно просмотреть некоторые веб-узлы, настройте размер MTU еще раз. Измените размер MTU на 1452 с помощью Dr. TCP или значение настройки MSS на DSL-маршрутизаторе Cisco на 1412. Если эти размеры слишком велики, продолжайте снижать MTU, пока не будет достигнут базовый уровень 1400 для Dr. TCP или 1360 для MSS, настроенный на маршрутизаторе Cisco DSL.


Дополнительные сведения


Document ID: 71124