Cisco DSL ルータの設定とトラブルシューティング ガイド - PPPoE：PPPoE クライアントとして設定した DSL ルータのトラブルシューティング
内容
概要
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 つの問題のいずれかを示しています。
-
DSL ウォール ジャックのアクティブ ピンが誤っています。
-
該当のウォール ジャックには、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 用の正しい電源モジュールを使用していることを確認します。
注：827は、他の800シリーズルータと同じ電源を使用しません。
正しい電源アダプタを使用しているかどうかを確認するには、電源アダプタの背面で Output +12V 0.1A, -12V 0.1A, +5V 3A, -24V 0.12A, and -71V 0.12A の表記を確認します。電源装置に+12Vおよび–12Vフィードがない場合、これは別のCisco 800シリーズルータ用であり、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 のセッションがアクティブになっています。これは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 の両方のフィールドに値が設定されています。もう 1 つの関連フィールドは Vast です。このフィールドは、PPP が正しくネゴシエートされて認証されたかどうかを示しています。VastがUPの場合、PPPは正常にネゴシエートされ、認証されており、「Why can I access some web pages with PPPoE but not other?」に進むことができます。従ってください。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 commands コマンドを実行して、その出力を解釈する必要があります。主に使用する 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" 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 のパケットごとに 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 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
I パケットでも O パケットでも、Configure-Negative-Acknowledge（CONFNAK）が PPP 設定の不一致であることが示されています。つまり、PPP 接続の一方が、他方で使用できないか設定されていない PPP オプションを要求しています。（「O CONFNAK」で示されるように）Cisco DSL ルータが CONFNAK を送信している場合は、ISP から送られるオプションを Cisco DSL ルータで実行できないか、あるいは実行するように設定されていません。ISP が CONFNAK を送信している（「I 」と表示されている）場合は、ISP で実行できないオプションが Cisco DSL ルータに設定されています。
CONFNAK の次の行は、拒絶されたオプションを示しています。この出力例では、CHAP というオプションですが、他のオプションが表示される場合もあります。Cisco DSLルータでPPPオプションを設定できる唯一の場所は、インターフェイスダイヤラ1です。インターフェイスダイヤラ1の設定を表示するには、show run interface dialer 1コマンドを発行します。
ISP が I CONFNAK を送信している場合は、CONFNAK の次の行と一致するコマンドを dialer 1 インターフェイスで探してそれらのコマンドを削除します。Cisco DSL ルータが O CONFNAK を送信している場合は、ISP との間で PPP を正しくネゴシエートするためのコマンドをインターフェイス ダイヤラ 1 に追加します。パケットを送信するルータの場合は、Cisco DSLルータでどのコマンドを有効にする必要があるかを判断するために、Cisco TACに連絡する必要がある場合があります。
認証の失敗
認証の失敗は、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) !--- 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 の認証を再設定してください。
認証で発生する可能性のある問題の 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" 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 の状態が 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
password
Router(config-if)#end
Router#write memory
CHAP のユーザ名とパスワードが正しいことはどうすればわかりますか。
ISP が実際に CHAP を使用していることを確認した後、CHAP ユーザ名とパスワードが正しいことを確認するために debug ppp negotiation コマンドを発行します。
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
PAP の認証で問題がある場合は、CHAP の状態が 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
いつ 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 で一部の 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®ソフトウェアリリース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
!--- 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
0.0.255.255
!
Dr. TCP Utility による PC での PPPoE MTU サイズの調整
PC で MTU サイズを変更するには、次のステップを実行してください。レジストリの変更はこの手順が完了した時点で保存されます。
注： Dr. TCPユーティリティは、すべてのWindowsベースのPCと互換性があります。
-
最新バージョンの Dr. TCP ユーティリティ をダウンロードします。
-
最新のページが表示されるようにブラウザ ページを更新します。
-
Dr. TCPユーティリティを実行します。
-
メニューからイーサネット アダプタを選択します。
-
[MTU] フィールドに 1492 と入力します。
-
[Apply] をクリックして変更を保存した後、[Exit] をクリックします。
-
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 に達するまで、シスコの DSL ルータ上の MSS の調整では 1360 に達するまで MTU サイズを小さくします。
関連情報
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
1.0 |
08-Oct-2006 |
初版 |
フィードバック