ロング リーチ イーサネット(LRE)とデジタル加入者線(xDSL) : 非対称デジタル加入者線(ADSL)

Cisco DSL ルータの設定とトラブルシューティング ガイド - PPPoE: PPPoE クライアントとして設定した DSL ルータのトラブルシューティング

2008 年 5 月 26 日 - ライター翻訳版
その他のバージョン: PDFpdf | 機械翻訳版 (2013 年 8 月 21 日) | 英語版 (2006 年 10 月 8 日) | フィードバック

目次

概要
前提条件
      要件
      使用するコンポーネント
      表記法
レイヤ 1 の問題
      Cisco DSL ルータの前面パネルの Carrier Detect(CD; キャリア検知)ライトは点灯していますか、それとも消灯していますか。
      ISP では Alcatel チップセットをサポートする DSLAM が使用されていますか。
      Cisco DSL ルータの背面にある DSL ポートが、DSL ウォール ジャックへ接続されていますか。
      ATM インターフェイスが administratively down(管理上ダウン)状態になっていますか。
      ケーブルのピン配置は正しいですか。
      Cisco 827 用の正しい電源アダプタを使用していますか。
      DSL の動作モードは正しいですか。
      回線が正しくテストおよびプロビジョニングされていますか。
レイヤ 2 の問題
      PVC 値(VPI/VCI)は正しいですか。
      ISP からデータを受信していますか。
      PPPoE セッションはアップ状態ですか。
      集約ルータから PPPoE 応答を受信していますか。
      PPP は正しくネゴシエートしていますか。
      PAP のユーザ名とパスワードが正しいことはどうすればわかりますか。
      CHAP のユーザ名とパスワードが正しいことはどうすればわかりますか。
      いつ PPP の認証に成功したかはどうすればわかりますか。
      PPPoE で一部の Web ページにしかアクセスできないのはなぜですか。
Cisco DSL ルータでの PPPoE MTU サイズの調整
      Dr. TCP Utility による PC での PPPoE MTU サイズの調整
      MTU のその他のトラブルシューティング手順
関連するシスコ サポート コミュニティ ディスカッション
関連情報

概要

Digital Subscriber Line(DSL; デジタル加入者線)接続が正常に機能しない理由は、いろいろ考えられます。 このドキュメントの目的は、障害の原因を切り分けて修復することです。トラブルシューティングの最初のステップでは、Asymmetric Digital Subscriber Line(ADSL; 非対称デジタル加入者線)サービスで障害が発生しているレイヤを判別します。障害が発生する可能性があるレイヤは、3 層あります。

  • レイヤ 1 - ISP の Digital Subscriber Line Access Multiplexer(DSLAM; デジタル加入者線アクセス マルチプレクサ)に対する物理的な DSL 接続

  • レイヤ 2.1 - ATM 接続

  • レイヤ 2.2 - Point-to-Point Protocol over ATM(PPPoA)、Point-to-Point Protocol over Ethernet(PPPoE)、RFC1483 ブリッジング、または RFC1483 ルーティング

  • レイヤ 3 - IP

トラブルシューティングを開始する対象のレイヤを判別する最も簡単な方法は、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 のトラブルシューティングを開始します。

前提条件

要件

このドキュメントに関する特別な要件はありません。

使用するコンポーネント

このドキュメントは、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

表記法

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

レイヤ 1 の問題

Cisco DSL ルータの前面パネルの Carrier Detect(CD; キャリア検知)ライトは点灯していますか、それとも消灯していますか。

CD ライトが点灯している場合は、このドキュメントの「レイヤ 2 の問題」のセクションに進みます。

CD ライトが消灯している場合は、次の質問に進みます。

ISP では Alcatel チップセットをサポートする DSLAM が使用されていますか。

この情報を ISP に確認します。

Cisco DSL ルータの背面にある DSL ポートが、DSL ウォール ジャックへ接続されていますか。

DSL ポートが DSL ウォール ジャックへ接続されていない場合は、4 ピンまたは 6 ピン RJ-11 ケーブルを使用して、ポートとウォール ジャックを接続します。このケーブルは、一般的な電話ケーブルです。

ATM インターフェイスが administratively down(管理上ダウン)状態になっていますか。

ATM0 インターフェイスが管理上ダウンの状態になっているかどうかを確認するには、ルータの enable モードで次のコマンドを発行します。

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

ATM0 インターフェイスの状態が管理上ダウンになっている場合は、ATM0 インターフェイスで no shutdown コマンドを発行します。

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 回線のキャリアが検出されていません。この状態は、通常、次の 2 つの問題のいずれかを示しています。

  1. DSL ウォール ジャックのアクティブ ピンが誤っています。

  2. 該当のウォール ジャックには、ISP からの DSL サービスが提供されていません。

Cisco DSL ルータの xDSL ポートのピン配置

RJ-11 コネクタでは、標準の RJ-11 6 ピン モジュラ ジャックを通じて、外部メディアへの xDSL 接続が提供されます。

ピン 説明

3

XDSL_Tip

4

XDSL_Ring


ATM0 インターフェイスがダウン/ダウンの状態になっているかどうかを確認するには、ルータの enable モードで show interface atm 0 コマンドを発行します。

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

ATM インターフェイスがダウン/ダウンの状態になっている(管理上ダウンではない)場合、DSL ウォール ジャックのピン配置を確認します。 DSL ルータでは、ウォール ジャックへ ADSL 接続するために標準の RJ-11(4 ピンまたは 6 ピン)ケーブルを使用します。ADSL 信号の伝送には、RJ-11 ケーブルの中央のペア ピンが使用されます(6 ピン ケーブルのピン 3 とピン 4、または 4 ピン ケーブルのピン 2 とピン 3)。

ウォール ジャックのピンが正しいにもかかわらず、ATM0 インターフェイスがダウン/ダウンの状態になっている場合は、DSL ポートとウォール ジャックを接続している RJ-11 ケーブルを交換してください。 RJ-11 ケーブルを交換してもなお、インターフェイスがダウン/ダウンの状態になっている場合は、ISP に連絡して、使用しているウォール ジャックで DSL サービスが使用可能であることを確認してもらってください。

ウォール ジャックのアクティブ ピンがわからない場合は、ISP に問い合せてください。

Cisco 827 用の正しい電源アダプタを使用していますか。

DSL ケーブルに問題が無く、ピン配置も正しいことが確認できた場合は、次のステップとして、Cisco 827 用の正しい電源アダプタを使用していることを確認します。

注:Cisco 827 に使用する電源アダプタは、他の Cisco 800 シリーズ ルータ用のものとは異なっています。

正しい電源アダプタを使用しているかどうかを確認するには、電源アダプタの背面で Output +12V 0.1A, -12V 0.1A, +5V 3A, -24V 0.12A, and -71V 0.12A の表記を確認します。 電源アダプタに +12V および -12V の給電が表記されていない場合は、他の Cisco 800 シリーズ ルータ用のものであるため、Cisco 827 では使用できません。間違った電源アダプタを使用した場合、Cisco 827 の電源は投入できますが、ISP の DSLAM へは接続できませんので、注意してください。

DSL の動作モードは正しいですか。

ここまでのレイヤ 1 のトラブルシューティング手順がすべて問題のない場合は、次のステップとして、DSL の動作モードが正しいことを確認します。 ISP が使用している DMT テクノロジーがわからない場合は、dsl operating-mode auto を使用することをお勧めします。 動作モードの自動検出を設定するコマンドは、次のとおりです。

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

回線が正しくテストおよびプロビジョニングされていますか。

この情報は、ISP または電話会社から入手します。

レイヤ 2 の問題

PVC 値(VPI/VCI)は正しいですか。

PPPoE の展開では、Permanent Virtual Circuit(PVC; 相手先固定接続)の Virtual Path Identifier/Virtual Channel Identifier(VPI/VCI; 仮想パス識別子/仮想チャネル識別子)の値をダイナミックに検出する簡単な方法はありません。 PVC の値がわからない場合は、ISP に問い合せてください。

ISP からデータを受信していますか。

正しい PVC の値がわかれば、次に ISP との間で 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

入力パケット カウンタが増加している場合は、ISP から PPPoE ネゴシエーション パケットを受信しています。 そうでない場合は、ISP に連絡してください。

出力方向のカウンタが増加している場合は、PPPoE ネゴシエーション パケットを送信しています。 そうでない場合は、ルータの設定をチェックしてください。 PPP が正しく設定されている場合は、PPP ネゴシエーション パケットが ATM0 インターフェイスから継続的に送出されています。

出力方向だけでパケットが増加している場合は、このドキュメントのトラブルシューティングの手順を続けてください。

PPPoE セッションはアップ状態ですか。

PPPoE は 2 段階で実行されます。 最初の段階は PPPoE セッションの確立で、2 番目の段階は PPP ネゴシエーションです。 PPP の標準パラメータのネゴシエーションの前に PPPoE が確立されている必要があります。 アクティブな 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 のセッションがアクティブになっています。 このことは、SID0RemMACLocMAC0000.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 がゼロ以外の数字になっており、RemMACLocMAC の両方のフィールドに値が設定されています。 もう 1 つの関連フィールドは Vast です。このフィールドは、PPP が正しくネゴシエートされて認証されたかどうかを示しています。 Vast が UP になっている場合、PPP は正しくネゴシエートされて認証されているので、このドキュメントの「PPPoE で一部の Web ページにしかアクセスできないのはなぜですか。」のセクションに進めます。 Vast が DOWN になっている場合は、次のセクションに進んでください。

集約ルータから 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 Active Discovery Initiation(PADI)フレームを継続的に ISP に送信していますが、応答がありません。 PADI フレームは、一連の PPPoE コールセットアップ フレームの最初に送信されます。 ISP から PPPoE Active Discovery Offer(PADO)の応答がなければ、PPPoE のネゴシエーションは正しく行われません。 この問題を解決するには、ISP に連絡するしかありません。

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 コマンドを実行して、その出力を解釈する必要があります。 主に使用する debug コマンドは、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 のネゴシエーションには、主に次の 4 つの障害ポイントがあります。

  • リモート デバイス(ISP)からの応答がない

  • Link Control Protocol(LCP; リンク制御プロトコル)が開かない

  • 認証の失敗

  • IP Control Protocol(IPCP; IP コントロール プロトコル)の障害

ISP からの応答がない

着信方向の ATM0 インターフェイスでパケットが増加していることはすでに確認済みなので、ISP が応答していないことが問題ではありません。 しかし、着信方向の ATM0 でパケットの増加が見られる場合に、debug ppp negotiation を実行して次のような出力が得られる場合は、ISP に連絡して 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」は発信パケットを示しています。

*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」は発信パケットを示しています。

*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」は発信パケットを示しています。

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

この出力には、出力パケットを示す O のパケットしかありません。 PPP を正しくネゴシエートするためには、送信した O のパケットごとに ISP からの着信を示す I のパケットが必要です。 着信側のパケットが増加しているのに I のパケットが表示されない場合は、ISP に連絡して、パケットが Cisco DSL ルータ宛に送信されていることを確認してください。

LCP が開かない

通常、LCP が開かないのは、PPP のオプションの不一致が原因です。 このような不一致は、ISP でサポートされていない PPP パラメータが Cisco DSL ルータに設定されている場合や、Cisco DSL ルータでサポートされていないパラメータが ISP で設定されている場合に起こります。 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 オプションの拒否

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

!--- 拒否された PPP オプション

*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 オプションの拒否

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

!--- 拒否された PPP オプション

*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

I パケットでも O パケットでも、Configure-Negative-Acknowledge(CONFNAK)が PPP 設定の不一致であることが示されています。 つまり、PPP 接続の一方が、他方で使用できないか設定されていない PPP オプションを要求しています。 Cisco DSL ルータが CONFNAK を送信している(「O CONFNAK」と表示されている)場合は、ISP が送信するオプションが Cisco DSL ルータでは実行できないか、あるいは実行できるように設定されていません。 ISP が CONFNAK を送信している(「I CONFNAK」と表示されている)場合は、ISP で実行できないオプションが Cisco DSL ルータに設定されています。

CONFNAK の次の行は、拒絶されたオプションを示しています。 この出力例では、CHAP というオプションですが、他のオプションが表示される場合もあります。 Cisco DSL ルータで PPP オプションを設定できる場所は dialer 1 というインターフェイスだけです。dialer 1 インターフェイスの設定を表示するには、show run interface dialer 1 コマンドを発行します。

ISP が I CONFNAK を送信している場合は、CONFNAK の次の行と一致するコマンドを dialer 1 インターフェイスで探してそれらのコマンドを削除します。 Cisco DSL ルータが O CONFNAK を送信している場合は、ISP と PPP を正しくネゴシエートするためのコマンドを dialer 1 インターフェイスに追加します。 ルータがパケットを送信している場合は、Cisco TAC に連絡して、Cisco DSL ルータでどのコマンドを有効にする必要があるかを判別する必要がある場合があります。

認証の失敗

認証の失敗は、PPP のユーザ名とパスワードを ISP が認証できないときに発生します。 この問題が発生するシナリオは 2 つあります。 最初のシナリオは、認証タイプの不一致で、ルータの設定が正しくない場合に発生します。 このドキュメントに示されているすべての認証設定は、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)

!--- CHAP 要求を送信

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)

!--- サービス プロバイダーから PAP 要求を受信

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)

!--- サービス プロバイダーから CHAP 要求を受信

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) 

!--- PAP 要求を送信

Router#undebug all

!--- ppp debug をオフ


認証の不一致の問題を両方とも修正するには、PPPoA の適切な実装オプションの設定を参照して、PPP の認証を再設定してください。

認証で発生する可能性のある問題の 2 番目のシナリオは、PAP のユーザ名またはパスワードが正しくないという問題です。 この問題が発生しているかどうかを判断するには、debug ppp negotiation コマンドを発行します。 Challenge Handshake Authentication Protocol(CHAP; チャレンジ ハンドシェーク認証プロトコル)と Password Authentication Protocol(PAP; パスワード認証プロトコル)の両方が、このガイドで前述したようにルータに設定されていると仮定すると、ISP が PAP による認証を使用していない可能性があります。

ISP が使用している認証を判別するには、ISP から送信される I CONFREQ パケットのオプションを調べます。 このパケットの次に AuthProto PAP というオプションがあれば、PAP が使用されています。 I CONFREQ の次に AuthProto CHAP というオプションがあれば、CHAP が使用されているので、「CHAP のユーザ名とパスワードが正しいことはどうすればわかりますか」に進んでください。

PAP のユーザ名とパスワードが正しいことはどうすればわかりますか。

ISP が 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」が、この DSL ルータに設定されている PAP のユーザ名です。

*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 の状態が Open に移行していることが表示されます。 LCP の状態が変更されたすぐ後には、PPP が Authenticating 段階に移行していることが表示されます。. それに続く 2 行のどちらかに I 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 のユーザ名とパスワードが正しいことはどうすればわかりますか。

ISP が 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」が、この DSL ルータに設定されている CHAP のユーザ名です。

*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 の状態が Open に移行していることが表示されます。 LCP の状態が変更されたすぐ後には、PPP が Authenticating 段階に移行していることが表示されます。. ここから一連の CHAP という行が表示されます。 これらの行の最後に I FAILURE と表示されていれば、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 のネゴシエーションに成功。

*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 のネゴシエーションに成功。

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

PPPoE で一部の Web ページにしかアクセスできないのはなぜですか。

ルータで PPPoE クライアントを実行している際に、一部の Web ページにしかアクセスできないというのはよくある問題です。 PPPoE は最大 1492 バイトまでの MTU をサポートできる設計になっています。 そのため、1492 バイトを超えるフレームをエンド デバイスが送出しないことを確認する必要があります。 ほとんどの PC やエンドユーザ ワークステーションのデフォルトの MTU は 1500 バイトになっているので、MTU が 1492 バイトに制限されていることが問題になる場合があります。

MTU サイズを調整する方法には、次の 2 つがあります。 つまり、ルータで MTU サイズを調整するか、PC で MTU サイズを調整するかです。

Cisco DSL ルータでの PPPoE MTU サイズの調整

特記事項:

次の設定コマンドが正しく動作するのは、Cisco DSL ルータで Network Address Translation(NAT; ネットワーク アドレス変換)か Port Address Translation(PAT; ポート アドレス変換)を実行している場合だけです。

Cisco IOS(R) ソフトウェア リリース 12.2(2)XH の ip adjust-mss コマンドは ip tcp adjust-mss <mss value> に変更されています。 この変更については、『Cisco IOS リリース 12.2(2)XH 用 Cisco 800 シリーズ ルータおよび Cisco 820 シリーズ ルータのリリース ノート』に説明されています。

!
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
 
!--- TCP MSS コマンドには、1492 ではなく 1452 という MSS を指定する必要があります。

 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 
!

Dr. TCP Utility による PC での PPPoE MTU サイズの調整

PC で MTU サイズを変更するには、次のステップを実行してください。 この手順が終わったらレジストリの変更が保存されます。

注:Dr. TCP utility は、Windows ベースのすべての PC と互換性があります。

  1. 最新バージョンの Dr. TCP utility leavingcisco.com をダウンロードします。

  2. 最新の情報がページに表示されるようにブラウザをリフレッシュします。

  3. Dr.TCP utility を実行します。

  4. メニューから、イーサネット アダプタを選択します。

  5. MTU フィールドに 1492 と入力します。

  6. Apply をクリックして変更を保存してから、Exit をクリックします。

  7. PPPoE PC クライアントをリブートします。

このユーティリティを実行する必要があるのは、PPPoE のクライアント PC ごとに 1 回だけです。

MTU のその他のトラブルシューティング手順

Dr. TCP で MTU サイズを変更するか、Cisco DSL ルータの MTU サイズを変更してもまだ特定の Web サイトを表示できない場合は、MTU サイズを再度調整します。 Dr. TCP で MTU サイズを 1452 に変更するか、Cisco DSL ルータの MSS 調整値を 1412 に変更します。これらのサイズが大きすぎる場合は、Dr. TCP では 1400、Cisco ルータの MSS 調整では 1360 のベースラインに到達するまで MTU サイズを引き続き下げてください。


関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


関連情報


Document ID: 71124