このフローチャートは、マルチアクセス テクノロジー ソリューションに幅広く使用されている Point-to-Point Protocol(PPP)をトラブルシューティングする際に役立ちます。
下記のフローチャートと出力例では、レガシー Dialer-on-Demand Routing(DDR)を使用して、Integrated Services Digital Network(ISDN)Basic Rate Interface(BRI; 基本インターフェイス)PPP 接続を設定しています。 ただし、ダイヤラ ロータリーグループ、ダイヤラ プロファイル、またはシリアル リンク経由の PPP を使用する場合は、PPP 接続を持つ他のルータ(ブランチ オフィスなど)への接続にも同じトラブルシューティング手順が適用されます。
Point-to-Point Protocol(PPP;ポイントツーポイントプロトコル)およびCisco IOS®ソフトウェアでサポートされている機能の詳細については、Cisco Learning Connection(登録ユーザのみ)を参照し、Search for trainingフィールドでキーワードpppを使用して検索します。
PPPネゴシエーションのさまざまなフェーズとdebug ppp negotiationの出力の詳細な説明については、『PPPパスワード認証プロトコル(PAP)の設定とトラブルシューティング』を参照してください。
次の前提条件を満たしていることを確認してください。
debug ppp negotiation および debug ppp authentication をイネーブルにします。
debug ppp negotiationの出力を読み、理解する必要があります。詳細は、『debug ppp negotiation の出力について』を参照してください。
PPP認証フェーズは、Link Control Protocol(LCP)フェーズが完了して「オープン」状態になるまで開始されません。debug ppp negotiationがLCPがオープンであることを示していない場合は、先に進む前に、この問題をトラブルシューティングしてください。
このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
ローカル マシン(またはローカル ルータ):デバッグ セッションが現在実行されているシステムを指します。デバッグ セッションをあるルータから他のルータへ移動させた場合、「ローカル マシン」という用語は、新たに対象となったルータに対して適用されます。
ピア:ポイントツーポイント リンクの他方の端を意味します。したがって、このデバイスはローカル マシンではありません。
たとえば、RouterA で debug ppp negotiation コマンドを実行する場合は、このルータがローカル マシンで、RouterB がピアになります。ただし、デバッグの対象を RouterB に変更した場合は、RouterB がローカル マシンになり、RouterA がピアになります。
注:ローカルマシンとピアという用語は、クライアントとサーバの関係を意味するものではありません。デバッグ セッションがどこで実行されているかによって、ダイヤルイン クライアントはローカル マシンまたはピアになります。
ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。
この文書には、トラブルシューティングに役立つように、いくつかのフローチャートを掲載しています。
注:問題を解決するには、次のフローチャートに示す手順を省略しないでください。
PPP 接続に使用される非同期モデム
このセクションでは、非同期モデムの PPP 接続への使用方法を説明します。ローカル ルータで発信 LCP フレームは確認できるが、着信 LCP フレームが見当たらない。
この場合、次の 2 つのうちのいずれかが原因と考えられます。
ローカル ルータとリモート ルータ両方のモデムがトレイン アップしているが、PPP がリモート ルータで起動しない。この問題をトラブルシューティングするには、『トラブルシューティング:モデム』のセクション「モデムは正常にトレイン アップするが、PPP が開始しない」を参照してください。
ローカルとリモート両方のルータのモデムがトレイン アップし、PPP が両方のルータで開始するが、コールがすぐにドロップする。このため、リモート ルータからの着信 LCP フレームを受信できません。この問題のトラブルシューティングには、『モデムのトラブルシューティング』のセクション「モデムは正常にトレイン アップし、PPP が開始するが、その後コールがドロップする」を参照してください。
モデムのトラブルシューティングの詳細については、「モデムのトラブルシューティング」を参照してください。
次のフローチャートは、LCP フェーズでネゴシエートされる最も一般的な PPP LCP パラメータのいくつかを取り上げたものです。このフローチャートは、PPP ローカル マシンが PPP リモート ピアとネゴシエートしていない LCP パラメータを特定するのに役立ちます。
ポイントツーポイント プロトコルには、ネットワーク ユーザにセキュアなデータ伝送を保証して、ネットワーク セキュリティを強化するオプションのフェーズがあります。リンクによっては、ネットワークレイヤ プロトコルのパケット交換を許可する前に、PPP ピアに自身の認証を要求するのが望ましい場合があります。どの PPP 実装でも、デフォルトでは認証フェーズはオプションになっています。PPP ネットワーク管理者が PPP ピアに対して特定の認証プロトコルを使用させる場合は、PPP LCP フェーズでその認証プロトコルを使用するように要求する必要があります。つまり、使用する認証プロトコルは、両 PPP ピア間でネゴシエートされる PPP LCP オプションの 1 つである必要があります。
この段階では、PPP LCP、認証プロトコル、およびリンク品質監視パケットだけが認証フェーズで認められています。このセクションのトラブルシューティング手順を実行する前に、この段階で PPP LCP がネゴシエートするパラメータに問題がないか確認します。
PPP 認証フェーズの問題のトラブルシューティングに関する詳細は、『PPP(CHAP または PAP)認証のトラブルシューティング』を参照してください。
ネゴシエートされるデータによって Network Control Protocol(NCP; ネットワーク コントロール プロトコル)は大きく異なりますが、どのプロトコルが使用されていても交信の全体的な構造は似ています。このセクションでは IP (IPCP) NCP プロトコルのネゴシエーションだけを取り上げています。
次の出力は、PPP NCP ネゴシエーション時に IP ネゴシエーションが成功した場合のデバッグ出力を示しています。
As4 PPP: Phase is UP As4 IPCP: O CONFREQ [Not negotiated] id 1 len 10 As4 IPCP: Address 10.1.2.1 (0x03060A010201) As4 IPCP: I CONFREQ [REQsent] id 1 len 28 As4 IPCP: CompressType VJ 15 slots CompressSlotID (0x0206002D0F01) As4 IPCP: Address 0.0.0.0 (0x030600000000) As4 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000) As4 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000) As4 IPCP: O CONFREJ [REQsent] id 1 len 10 As4 IPCP: CompressType VJ 15 slots CompressSlotID (0x0206002D0F01) As4 CCP: I CONFREQ [Not negotiated] id 1 len 15 As4 CCP: MS-PPC supported bits 0x00000001 (0x120600000001) As4 CCP: Stacker history 1 check mode EXTENDED (0x1105000104) As4 LCP: O PROTREJ [Open] id 3 len 21 protocol CCP As4 LCP: (0x80FD0101000F12060000000111050001) As4 LCP: (0x04) As4 IPCP: I CONFACK [REQsent] id 1 len 10 As4 IPCP: Address 10.1.2.1 (0x03060A010201) %LINEPROTO-5-UPDOWN: Line protocol on Interface Async4, changed state to up As4 IPCP: I CONFREQ [ACKrcvd] id 2 len 22 As4 IPCP: Address 0.0.0.0 (0x030600000000) As4 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000) As4 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000) As4 IPCP: O CONFNAK [ACKrcvd] id 2 len 22 As4 IPCP: Address 10.1.2.2 (0x03060A010202) As4 IPCP: PrimaryDNS 10.2.2.3 (0x81060A020203) As4 IPCP: SecondaryDNS 10.2.3.1 (0x83060A020301) As4 IPCP: I CONFREQ [ACKrcvd] id 3 len 22 As4 IPCP: Address 10.1.2.2 (0x03060A010202) As4 IPCP: PrimaryDNS 10.2.2.3 (0x81060A020203) As4 IPCP: SecondaryDNS 10.2.3.1 (0x83060A020301) ip_get_pool: As4: validate address = 10.1.2.2 ip_get_pool: As4: using pool default ip_get_pool: As4: returning address = 10.1.2.2 set_ip_peer_addr: As4: address = 10.1.2.2 (3) is redundant As4 IPCP: O CONFACK [ACKrcvd] id 3 len 22 As4 IPCP: Address 10.1.2.2 (0x03060A010202) As4 IPCP: PrimaryDNS 10.2.2.3 (0x81060A020203) As4 IPCP: SecondaryDNS 10.2.3.1 (0x83060A020301) As4 IPCP: State is Open As4 IPCP: Install route to 10.1.2.2
下記のフローチャートに示すように、この時点でリンクはアップしてパケットの受け渡しを行っていますが、行うべき動作を行っていません。
次の出力は、コールが正常に終了し、PPP接続を介してIPパケットをリモートピアに送信できる場合のshow caller userおよびshow ip interface briefコマンドの出力を示しています。
maui-soho-01#show caller user maui-soho-02 detail User: maui-soho-02, line BR0:1, service PPP Active time 00:02:21, Idle time 00:00:57 Timeouts: Absolute Idle Limits: - 00:02:00 Disconnect in: - 00:01:02 PPP: LCP Open, CHAP (local <--> local), IPCP LCP: -> peer, AuthProto, MagicNumber <- peer, AuthProto, MagicNumber NCP: Open IPCP IPCP: <- peer, Address -> peer, Address Dialer: Connected to #, inbound Idle timer 120 secs, idle 57 secs Type is ISDN, group BRI0 IP: Local 10.0.1.1/24, remote 10.0.1.2 Counts: 123 packets input, 3246 bytes, 0 no buffer 0 input errors, 0 CRC, 0 frame, 0 overrun 119 packets output, 2940 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets maui-soho-01#show ip interface brief Interface IP-Address OK? Method Status Protocol BRI0 10.0.1.1 YES NVRAM up up BRI0:1 unassigned YES unset up up BRI0:2 unassigned YES unset down down Ethernet0 172.22.53.160 YES NVRAM up up Serial0 unassigned YES NVRAM administratively down down
改定 | 発行日 | コメント |
---|---|---|
1.0 |
18-Dec-2007 |
初版 |