ダイヤル技術接続のトラブルシューティング - IOS DDR初期コール

ダウンロード オプション

  • PDF     (371.1 KB)
    Adobe Reader を使ってさまざまなデバイスで表示
  • ePub     (91.8 KB)
    iPhone、iPad、Android、ソニーの Reader、または Windows Phone 上で、さまざまなアプリを使って表示
  • Mobi (Kindle)     (109.0 KB)
    Kindle デバイスで、または Kindle アプリを使って複数のデバイスで表示
Updated: 2007 年 7 月 9 日
Document ID:14954

偏向のない言語

この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブ ランゲージの取り組みの詳細は、こちらをご覧ください。

翻訳について

シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版（リンクからアクセス可能）もあわせて参照することを推奨します。

概要

このドキュメントでは、さまざまなダイヤル接続のタイプのトラブルシューティング方法を提供しており、最初から最後まで読むことを目的とはしていません。この構成は、読者が関心のある項に進めるように設計されており、それぞれが特定のケースの全体的なトラブルシューティングのテーマのバリエーションになっています。

前提条件

要件

このドキュメントでは、3 つの主要なシナリオについて説明します。トラブルシューティングを開始する前にどのようなタイプのコールが試みられているか特定し、対応する項に移動してください。

使用するコンポーネント

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

このマニュアルの情報は、特定のラボ環境に置かれたデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。実稼動中のネットワークで作業をしている場合、実際にコマンドを使用する前に、その潜在的な影響について理解しておく必要があります。

履歴

ダイヤルアップは、端末ユーザのためにデータを搬送する Public Switched Telephone Network（PSTN; 公衆電話交換網）のための機能です。ダイヤルアップには、接続の宛先となる電話番号を電話交換機に送信する Customer Premises Equipment（CPE; 顧客宅内機器）デバイスが含まれます。AS3600、AS5200、AS5300、AS5800 などは、一次群速度インターフェイス（PRI）を一連のデジタル モデムとともに実行できるルータです。一方、AS2511 は外部モデムと通信するルータです。

現在、通信事業の市場ではその規模の拡大とともに、より高いモデム密度が求められています。このニーズへの答えは、電話会社の機器とのインターオペラビリティの向上と、デジタル モデムの開発です。デジタル モデムには PSTN に直接デジタル アクセスする機能があります。結果として、現在ではデジタル モデムの特長である信号の明瞭さを利用した、より高速な CPE モデムが開発されています。デジタル モデムは PRI または基本速度インターフェイス（BRI）を通じて PSTN に接続し、V.90 通信規格を使用して 53k 超のデータを伝送できるので、理想を実現します。

最初のアクセスサーバはAS2509とAS2511です。AS2509は外部モデムを使用して8つの着信接続をサポートし、AS2511は16をサポートできます。AS5200は2で048デジタルモデムを使用しているユーザは、テクノロジーの大きな進歩を遂げています。AS5300 では PRI のサポートが 4 から 8 に増え、モデム密度が着実に増加していきました。最終的に、数十の T1 回線と数百のユーザ接続を処理する通信事業者クラスの設置ニーズに対応するため、AS5800 が導入されました。

ダイヤラ テクノロジーの歩みの中で、現在でも議論の対象にされる旧来のテクノロジーがいくつかあります。56Kflex は、Rockwell によって提唱された（V.90 以前の）古い 56k モデム規格です。Cisco では、バージョン 1.1 の 56Kflex 規格を Cisco 製の内部モデムでサポートしていますが、CPE をできるだけ速やかに V.90 に移行することを推奨しています。もう1つの旧式のテクノロジーはAS5100です。AS5100は、シスコとモデムメーカーの合弁会社でした。AS5100 は、クワッド モデム カードを使用してモデム密度を増やす手段として開発されました。AS5100 ではカードとして組み込まれた AS2511 が必要でした。これらのカードは、クワッド モデム カードとデュアル T1 カードによって共有されるバックプレーンに挿入されていました。

表記法

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

Cisco IOS DDR によるコール開始

着信コールのトラブルシューティングが下位層からアプローチを始めるのに対して、発信接続のトラブルシューティングは上位層からアプローチを始めます。

論理の全般的なフローは次のようになります。

  1. ダイヤルオンデマンド ルーティング（DDR）がコールを開始しましたか。（答えがはいの場合は、次の質問に進みます）。

  2. 非同期モデムの場合、チャット スクリプトから期待されるコマンドが発行されましたか。

  3. コールが PSTN の外部に達しましたか。

  4. リモート エンドがコールに応答しましたか。

  5. コールが完了しましたか。

  6. データがリンクを通過していますか。

  7. セッションが確立されましたか。（PPP または端末）

ダイヤラがリモートの宛先にコールを発信しようとしているかどうかを調べるには、debug dialer events コマンドを使用します。詳細については debug dialer packet を参照してください。ただし、debug dialer packet コマンドはリソースの消費が激しいため、ダイヤラ インターフェイスが複数動作しているビジー状態のシステムでは使用しないでください。

次の行は IP パケットに対する debug dialer events の出力行で、DDR インターフェイスの名前と、パケットの送信元アドレスおよび宛先アドレスが列挙されています。 

Dialing cause: Async1: ip (s=172.16.1.111 d=172.16.2.22)

トラフィックによってダイヤルが開始されない場合、最も可能性のある理由として不適切な設定（対象トラフィックの定義、ダイヤラ インターフェイスの状態、またはルーティングのいずれか）が考えられます。

表 1：トラフィックによってダイヤル試行が開始されない場合

考えられる原因 推奨される対策
「対象トラフィック」の定義がない、または正しくない
  1. show running-config コマンドを使用し、インターフェイスに dialer-group が設定されていること、および一致する番号で設定されたグローバル レベルの dialer-list が存在することを確認します。
  2. dialer-list コマンドが、プロトコル全体、またはアクセス リストに一致するトラフィックのどちらかを許可するように設定されていることを確認します。
  3. アクセス リストで、リンクを通過するパケットが「対象」として宣言されていることを確認します。これをテストするには、該当するアクセス リストの番号を指定して特権 exec コマンド debug ip packet [list number] を使用すると便利です。次に、リンクに対して ping を試すか、またはトラフィックを送信します。対象トラフィック フィルタが正しく定義されていれば、パケットがデバッグ出力に表示されます。このテストでデバッグ出力が表示されない場合は、アクセスリストとパケットが一致していません。
インターフェイスの状態 show interfaces <interface name> コマンドを使用し、インターフェイスが「アップ/アップ（スプーフィング）」状態にあることを確認します。
  • インターフェイスが「スタンバイ」モードにある
ルータのもう 1 つの（プライマリ）インターフェイスが、ダイヤラ インターフェイスをバックアップ インターフェイスとして使用するように設定されています。また、プライマリ インターフェイスが「ダウン/ダウン」の状態ではありません。ダイヤラ インターフェイスがスタンバイ モードから抜け出すためには「ダウン/ダウン」状態にあることが必要です。さらに、プライマリ インターフェイスで backup delay を設定する必要があります。これが設定されていないと backup interface コマンドが実行されません。ダイヤラ インターフェイスが「スタンバイ」から「アップ/アップ（スプーフィング）」に変わることを確かめるには、通常、プライマリ インターフェイスからケーブルを抜き取る必要があります。設定コマンド shutdown を使用してプライマリ インターフェイスをシャットダウンしただけでは、プライマリ インターフェイスは「ダウン/ダウン」にはならず、「管理上のダウン」になります。これらは同じではありません。加えて、プライマリ接続がフレームリレー経由の場合、フレームリレーの設定をポイントツーポイントのシリアル サブインターフェイスで行う必要があり、電話会社で「Active」ビットを渡している必要があります。この方法を「エンドツーエンド ローカル管理インターフェイス（LMI）」とも呼びます。
  • インターフェイスが「administratively down」にある
ダイヤラ インターフェイスに shutdown コマンドが設定されています。Cisco ルータを初めてブートしたときは、どのルータ インターフェイスでもこの状態がデフォルトです。これを解除するには、インターフェイス設定コマンド no shutdown を使用します。
ルーティングに誤りがある exec コマンド show ip route [a.b.c.d] を発行します。ここで a.b.c.d は、リモート ルータのダイヤラ インターフェイスのアドレスです。リモート ルータで ip unnumbered を使用している場合は、ip unnumbered コマンドでリストされるインターフェイスのアドレスを使用します。出力には、ダイヤラ インターフェイスを経由したリモート アドレスへのルートが示されます。ルートが存在しない場合は、show running-config の出力を調べて、スタティック ルートまたはフローティング スタティック ルートがすでに設定されていることを確認します。ダイヤラ インターフェイス以外のインターフェイスを経由するルートが存在する場合は、DDR がバックアップとして使用されています。ルータの設定を調べ、スタティック ルートまたはフローティング スタティック ルートがすでに設定されているかを確認します。この場合にルーティングをテストするには、プライマリ接続を無効にし、show ip route [a.b.c.d] コマンドを実行して、適切なルートがルーティング テーブルに設定されていることを確認するのが最も確実な方法です。

注：ライブネットワークの操作中にこの操作を行うと、ダイヤルイベントがトリガーされる場合があります。この種のテストはあらかじめスケジューリングされたメンテナンス時に行うのが最適です。

コールの送信

ルーティングと対象トラフィック フィルタが正しければ、コールが開始されます。これは debug dialer events を使用して確認できます。 

Async1 DDR: Dialing cause ip (s=10.0.0.1, d=10.0.0.2)



Async1 DDR: Attempting to dial 5551212

ダイヤリング理由が表示されるにもかかわらず、ダイヤル試行がなされない場合、通常はダイヤラ マップまたはダイヤラ プロファイルの設定の誤りが原因です。

表 2：コールが発信しない場合

考えられる問題 推奨する処置
ダイヤラ マップの設定の誤り show running-configコマンドを使用して、ダイヤリングインターフェイスに、リモートサイトのプロトコルアドレスと着信者番号を指す少なくとも1つのdialer map文が設定されていることを確認します。
ダイヤラ プロファイルの設定の誤り show running-config コマンドを使用し、Dialer インターフェイスに dialer pool X コマンドが設定されていて、対応する dialer pool-member X がルータのダイヤラ インターフェイスに設定されていることを確認します。ダイヤラ プロファイルが正常に設定されていない場合、次のようなデバッグ メッセージが表示されることがあります。 
Dialer1: Can't place call, no dialer pool set
dialer string が設定されていることを確認します。

次に、使用されているメディアのタイプを確認します。

外部非同期モデム DDR

  1. 外部非同期モデム DDR を確認するには、次のコマンドを使用してから、コール発信を試行します。 

    router# debug modem
router# debug chat line

  2. モデム コールの場合、コールを続行するためチャット スクリプトが実行される必要があります。ダイヤラ マップ ベース DDR の場合、チャット スクリプトはダイヤラ マップ コマンド内の modem-script パラメータによって起動されます。DDR がダイヤラ プロファイル ベースの場合は、TTY 回線で設定された script dialer コマンドによってチャット スクリプトが起動されます。どちらを使用する場合も、ルータのグローバル コンフィギュレーション内に存在する次のようなチャット スクリプトを利用します。 

    chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c

    どちらの場合でも、チャット スクリプトのアクティビティを表示するコマンドは debug chat です。たとえば dialer map または dialer string コマンド内のダイヤル文字列（つまり、電話番号）が 5551212 であれば、デバッグ出力は次のようになります。 

    CHAT1: Attempting async line dialer script


CHAT1: Dialing using Modem script: callout & System script: none
CHAT1: process started
CHAT1: Asserting DTR
CHAT1: Chat script callout started
CHAT1: Sending string: AT
CHAT1: Expecting string: OK
CHAT1: Completed match for expect: OK
CHAT1: Sending string: atdt5551212
CHAT1: Expecting string: CONNECT
CHAT1: Completed match for expect: CONNECT
CHAT1: Chat script callout finished, status = Success

  3. チャット スクリプトが、「Sending string」に基づいて予期されるコール（正しい番号）を試行することを確認します。 チャット スクリプトが予期されるコールを発信しない場合は、チャット スクリプトの設定を確認します。exec プロンプトで start-chat コマンドを使用して、チャット スクリプトを手動で開始します。

  4. 「Timeout expecting:CONNECT」には、さまざまな原因が記述されています。

    • 原因 1：ローカル モデムが実際にコールを発信していません。モデムへのリバース Telnet を実行してダイヤルを手動で開始し、モデムがコールを発信できることを確認します。リモート エンドが応答しない場合は、発信元モデルからコールが発信されていることを確認するため、ATDT <number> コマンドを使用してローカル番号に手動で発信し、呼出音を聞きます。

    • 原因 2：リモート モデムが応答していません。通常の POTS 電話を使用してリモート モデムにダイヤリングし、動作をテストします。次の手順を試してください。

      1. コールした電話番号が正しいことを確認します。ハンドセットを使用して着信番号をコールします。モデムに使用していたものと同じ壁面接続ケーブルを使用していることを確認します。手動コールが着信非同期モデムに到達できる場合は、発信元モデムが正しく機能していない可能性があります。モデムを確認し、必要に応じて交換します。

      2. 手動コールが応答非同期モデムに到達できない場合は、着信側モデムの電話ケーブルを取り換えてから、着信側モデムの回線で通常の電話機を使って試してみます。通常の電話機でコールが受信できる場合は、着信側モデムに問題がある可能性があります。

      3. 手動コールが当該回線で通常の電話機に到達しない場合は、着信側施設の別の（確認済みの良好な）回線を使用してみます。正常に接続したら、着信側モデムに接続する電話回線の検査を電話会社に依頼します。

      4. 長距離コールの場合、発信元で別の（確認済みの良好な）長距離番号を試行します。この番号で通話できる場合は、着信側施設または回線が長距離コールを受信するようにプロビジョニングされていない可能性があります。発信側回線が他の長距離番号に到達できない場合は、長距離コールが有効になっていない可能性があります。別の長距離通話会社で 1010 コードを試行します。

      5. 最後に、発信元回線から（確認済みの良好な）別のローカル番号を試行します。それでも接続が失敗する場合は、発信元回線の検査を電話会社に依頼します。

    • 原因 3：ダイヤルしようとしている番号に誤りがあります。手動でダイヤリングを行い、番号を確認します。必要であれば設定を訂正します。

    • 原因 4：モデムの trainup に時間がかかりすぎているか、または TIMEOUT の値が小さすぎます。chat-script コマンドで TIMEOUT 値を大きくしてみます。TIMEOUT がすでに 60 秒以上の場合は、モデムと、モデムに接続している DTE の間のケーブルに問題がある可能性があります。trainup が失敗する場合は、回線の問題、またはモデムに互換性がないことが考えられます。

      個々のモデムの問題の根本的な原因を突き止めるには、reverse telnet を使用して発信元モデムで AT プロンプトに移動します。可能であれば、着信側モデムでも AT プロンプトに移動します。ほとんどのモデムは、各自の DTE 接続に接続された端末セッションの呼び出しを示します。ATM1 を使用して、モデムがそのスピーカに音声を送信するようにします。これにより、回線で何が起こっているかを両側で聞くことができます。

      音楽に雑音が混じっているかを確認します。雑音が混じっている場合は、回線をクリーンアップします。非同期モデムが trainup していない場合は、番号に発信してスタティックを聞きます。他の要素が trainup と干渉している可能性があります。非同期モデムへリバース Telnet を実行してデバッグします。

  5. すべてが正しく動作しているものの、CAS 非同期モデム DDR で接続できない場合は、PPP デバッグを試行します。次のコマンドを使用します。 

    router# debug ppp negotiation
     router# debug ppp authentication

    チャット スクリプトが正常に完了すると、モデムが接続されます。接続のトラブルシューティングで次に行う作業については、『インターネットワーク トラブルシューティング ガイド』の「第 17 章」の「PPP トラブルシューティング」を参照してください。

CAS T1/E1 非同期モデム DDR

  1. CAS T1/E1 非同期モデム DDR を確認するには、次のコマンドを使用してから、コール発信を試行します。

    warning 警告：  ビジー状態のシステムでデバッグを実行すると、CPU への過負荷またはコンソール バッファのオーバーランが原因でルータがクラッシュすることがあります。 

    router# debug modem
router# debug chat or debug chat line n

router# debug modem csm
router# debug cas

    注：debug casコマンドは、Cisco IOS??が稼働するCisco AS5200およびAS5300プラットフォームで使用できますソフトウェア リリース 12.0(7)T 以降が稼働する Cisco AS5200 および AS5300 プラットフォームで使用できます。以前のバージョンの IOS では、service internal コマンドをルータのコンフィギュレーションのメイン レベルに入力し、modem-mgmt csm debug-rbs を exec プロンプトで入力する必要がありました。Cisco AS5800 でデバッグを行うには、トランク カードに接続する必要があります。（デバッグをオフにするには modem-mgmt csm no-debug-rbs を使用します。）

  2. モデム コールの場合、コールを続行するためチャット スクリプトが実行される必要があります。ダイヤラ マップ ベース DDR の場合、チャット スクリプトはダイヤラ マップ コマンド内の modem-script パラメータによって起動されます。DDR がダイヤラ プロファイル ベースの場合は、TTY 回線で設定された script dialer コマンドによってチャット スクリプトが起動されます。どちらを使用する場合も、ルータのグローバル コンフィギュレーション内に存在する次のようなチャット スクリプトを利用します。 

    chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c

    どちらの場合でも、チャット スクリプトのアクティビティを表示するコマンドは debug chat です。たとえば dialer map または dialer string コマンド内のダイヤル文字列（つまり、電話番号）が 5551212 であれば、デバッグ出力は次のようになります。 

    CHAT1: Attempting async line dialer script


CHAT1: Dialing using Modem script: callout & System script: none
CHAT1: process started
CHAT1: Asserting DTR
CHAT1: Chat script callout started
CHAT1: Sending string: AT
CHAT1: Expecting string: OK
CHAT1: Completed match for expect: OK
CHAT1: Sending string: atdt5551212
CHAT1: Expecting string: CONNECT
CHAT1: Completed match for expect: CONNECT
CHAT1: Chat script callout finished, status = Success

  3. チャット スクリプトが「Sending string」に基づいて予期されるコール（正しい番号）を試行することを確認します。 チャット スクリプトが予期されるコールを発信しない場合は、チャット スクリプトの設定を確認します。exec プロンプトで start-chat コマンドを使用して、チャット スクリプトを手動で開始します。

  4. 「Timeout expecting:CONNECT」には、さまざまな原因が記述されています。

    • 原因 1：ローカル モデムが実際にコールを発信していません。モデムへのリバース Telnet を実行してダイヤルを手動で開始し、モデムがコールを発信できることを確認します。リモート エンドが応答しない場合は、モデムからコールが発信されていることを確認するため、ATDT<number> コマンドを使用してローカル番号に手動で発信し、呼出音を聞きます。

      CAS の T1 または E1 と組み込みデジタル モデムを経由した発信コールの場合、トラブルシューティングの大半は他の DDR のトラブルシューティングと同様です。PRI 回線を経由した組み込みモデムの発信コールの場合でも、同じことがいえます。この方式によるコール発信でコールが失敗した場合には、コール発信に関与している独自の機能について特別なデバッグが必要になります。

      他の DDR と同様に、コール試行が要求されたことを確認する必要があります。これには debug dialer events を使用します。前述の「IOS DDR 」を参照してください。

      コールを発信するには、その前にモデムをコール用に割り当てておく必要があります。このプロセスと以降のコールを確認するには、次のデバッグ コマンドを使用します。 

      router# debug modem
router# debug modem csm
router# debug cas

      注：debug casコマンドは、AS5200およびAS5300のIOSバージョン12.0(7)Tで初めて導入されました。以前のバージョンのIOSでは、システムレベルの設定コマンドservice internalをexec modem-debug mgmt rbs :

      デバッグのオン： 

      router#conf t 
Enter configuration commands, one per line.  End with CNTL/Z. 
router(config)#service internal 
router(config)#^Z 
router#modem-mgmt csm ? 
  debug-rbs     enable rbs debugging 
  no-debug-rbs  disable rbs debugging 
router#modem-mgmt csm debug-rbs 
router# 
neat msg at slot 0: debug-rbs is on 
neat msg at slot 0: special debug-rbs is on

      デバッグのオフ：

      router#modem-mgmt csm no-debug-rbs 
neat msg at slot 0: debug-rbs is off

      AS5800 でこれらの情報をデバッグするためには、トランク カードに接続する必要があります。次の例は、FXS グラウンド スタート用に設定された、CAS T1 経由の通常の発信コールです。 

      Mica Modem(1/0): Rcvd Dial String(5551111) 
[Modem receives digits from chat script]

CSM_PROC_IDLE: CSM_EVENT_MODEM_OFFHOOK at slot 1, port 0 

CSM_RX_CAS_EVENT_FROM_NEAT:(A003):  
EVENT_CHANNEL_LOCK at slot 1 and port 0 

CSM_PROC_OC4_DIALING: 
CSM_EVENT_DSX0_BCHAN_ASSIGNED at slot 1, port 0 

Mica Modem(1/0): Configure(0x1) 

Mica Modem(1/0): Configure(0x2) 

Mica Modem(1/0): Configure(0x5) 

Mica Modem(1/0): Call Setup 

neat msg at slot 0: (0/2): Tx RING_GROUND 

Mica Modem(1/0): State Transition to Call Setup 

neat msg at slot 0: (0/2): Rx TIP_GROUND_NORING 
[Telco switch goes OFFHOOK]

CSM_RX_CAS_EVENT_FROM_NEAT:(A003):  
EVENT_START_TX_TONE at slot 1 and port 0 

CSM_PROC_OC5_WAIT_FOR_CARRIER: 
CSM_EVENT_DSX0_START_TX_TONE at slot 1, port 0 

neat msg at slot 0: (0/2): 
Tx LOOP_CLOSURE [Now the router goes OFFHOOK]

Mica Modem(1/0): Rcvd Tone detected(2) 

Mica Modem(1/0): Generate digits:called_party_num=5551111 len=8 

Mica Modem(1/0): Rcvd Digits Generated 

CSM_PROC_OC5_WAIT_FOR_CARRIER: 
CSM_EVENT_ADDR_INFO_COLLECTED at slot 1, port 0 

CSM_RX_CAS_EVENT_FROM_NEAT:(A003):  
EVENT_CHANNEL_CONNECTED at slot 1 and port 0 

CSM_PROC_OC5_WAIT_FOR_CARRIER: 
CSM_EVENT_DSX0_CONNECTED at slot 1, port 0 

Mica Modem(1/0): Link Initiate 

Mica Modem(1/0): State Transition to Connect 

Mica Modem(1/0): State Transition to Link 

Mica Modem(1/0): State Transition to Trainup 

Mica Modem(1/0): State Transition to EC Negotiating 

Mica Modem(1/0): State Transition to Steady State 

Mica Modem(1/0): State Transition to Steady State Speedshifting 

Mica Modem(1/0): State Transition to Steady State

      他のシグナリング タイプの T1 および E1 におけるデバッグも同様です。

      デバッグでこの時点にまで達した場合は、発信側モデムと応答側モデムの train と接続が完了し、より上位層のプロトコルがネゴシエートを開始できることを示しています。モデムが発信コール用に正しく割り当てられているにもかかわらず、この時点で接続が失敗する場合は、T1 を調べる必要があります。show controller t1/e1 コマンドを使用して、T1/E1 が機能していることを確認します。show controller の出力の説明については、「シリアル回線のトラブルシューティング」を参照してください。T1/E1 が正しく機能していない場合は、T1/E1 のトラブルシューティングを行う必要があります。

    • 原因 2：リモート モデムが応答していません。通常の電話機を使用してリモート モデムにダイヤルし、動作をテストします。次の手順を試してください。

      1. コールした電話番号が正しいことを確認します。ハンドセットを使用して着信番号をコールします。

      2. 手動コールが応答側の非同期モデムに到達できることを確認します。手動コールが応答側の非同期モデムに到達できる場合は、発信音声コールを許可するように CAS 回線がプロビジョニングされていない可能性があります。

      3. 手動コールが応答非同期モデムに到達できない場合は、着信側モデムの電話ケーブルを取り換えてから、着信側モデムの回線で通常の電話機を使って試してみます。通常の電話機でコールが受信できる場合は、着信側モデムに問題がある可能性があります。

      4. 手動コールが当該回線で通常の電話機に到達しない場合は、着信側施設の別の（確認済みの良好な）回線を使用してみます。正常に接続したら、着信側モデムに接続する電話回線の検査を電話会社に依頼します。

      5. 長距離コールの場合、発信元で別の（確認済みの良好な）長距離番号を試してみます。この番号で通話できる場合は、着信側施設または回線が長距離コールを受信するようにプロビジョニングされていない可能性があります。発信側（CAS）回線が他の長距離番号に到達できない場合は、長距離コールが有効になっていない可能性があります。別の長距離通話会社で 10-10 コードを試行します。

      6. 最後に、発信元 CAS 回線から（確認済みの良好な）別のローカル番号を試行します。それでも接続が失敗する場合は、電話会社に CAS の検査を依頼してください。

    • 原因 3：ダイヤルしようとしている番号に誤りがあります。手動でダイヤリングを行い、番号を確認します。必要であれば設定を訂正します。

    • 原因 4：モデムの trainup に時間がかかりすぎているか、または TIMEOUT の値が小さすぎます。chat-script コマンドで TIMEOUT 値を大きくしてみます。TIMEOUT がすでに 60 秒以上の場合は、モデムと、モデムに接続している DTE の間のケーブルに問題がある可能性があります。trainup が失敗する場合は、回線の問題、またはモデムに互換性がないことが考えられます。

      個々のモデムの問題の根本的な原因を突き止めるには、reverse telnet を使用して発信元モデムで AT プロンプトに移動します。可能であれば、リバース Telnet を使用して着信側モデムでも AT プロンプトに移動します。ATM1 を使用して、モデムがそのスピーカに音声を送信するようにします。これにより、回線で何が起こっているかを両側で聞くことができます。

      音楽に雑音が混じっているかを確認します。雑音が混じっている場合は、回線をクリーンアップします。非同期モデムが trainup していない場合は、番号に発信してスタティックを聞きます。他の要素が trainup と干渉している可能性があります。非同期モデムへリバース Telnet を実行してデバッグします。

  5. すべてが正しく動作しているものの、CAS 非同期モデム DDR で接続できない場合は、PPP デバッグを試行します。チャット スクリプトが正常に終了し、PPP デバッグが障害を示す場合は、『インターネットワーク トラブルシューティング ガイド』の第 17 章にある「PPP のトラブルシューティング」セクションを参照してください。

PRI 非同期モデムDDR

  1. PRI 非同期モデム DDR を確認するには、次のコマンドを使用してから、コール発信を試行します。

    warning 警告：  ビジー状態のシステムでデバッグを実行すると、CPU への過負荷またはコンソール バッファのオーバーランが原因でルータがクラッシュすることがあります。 

    router# debug modem
router# debug chat
router# debug modem csm
router# debug isdn q931
router# debug isdn
router# debug ppp negotiate
router# debug ppp authenticate

  2. モデム コールの場合、コールを続行するためチャット スクリプトが実行される必要があります。ダイヤラ マップ ベース DDR の場合、チャット スクリプトはダイヤラ マップ コマンド内の modem-script パラメータによって起動されます。DDR がダイヤラ プロファイル ベースの場合は、TTY 回線で設定された script dialer コマンドによってチャット スクリプトが起動されます。どちらの方法でも、ルータのグローバル コンフィギュレーション内に存在する次のようなチャット スクリプトを利用します。 

    chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c

    どちらの場合でも、チャット スクリプトのアクティビティを表示するコマンドは debug chat です。たとえば dialer map または dialer string コマンド内のダイヤル文字列（電話番号）が 5551212 であれば、デバッグ出力は次のようになります。 

    CHAT1: Attempting async line dialer script


CHAT1: Dialing using Modem script: callout & System script: none
CHAT1: process started
CHAT1: Asserting DTR
CHAT1: Chat script callout started
CHAT1: Sending string: AT
CHAT1: Expecting string: OK
CHAT1: Completed match for expect: OK
CHAT1: Sending string: atdt5551212
CHAT1: Expecting string: CONNECT
CHAT1: Completed match for expect: CONNECT
CHAT1: Chat script callout finished, status = Success

  3. チャット スクリプトが「Sending string」に基づいて予期されるコール（正しい番号）を試行することを確認します。 チャット スクリプトが予期されるコールを発信しない場合は、チャット スクリプトの設定を確認します。exec プロンプトで start-chat コマンドを使用して、チャット スクリプトを手動で開始します。

  4. 「Timeout expecting:CONNECT」には、さまざまな原因が記述されています。

    • 原因 1：ローカル モデムが実際にコールを発信していません。モデムへのリバース Telnet を実行してダイヤルを手動で開始し、モデムがコールを発信できることを確認します。リモート エンドが応答しない場合は、モデルからコールが発信されていることを確認するため、ATDT<number> コマンドを使用してローカル番号に手動で発信し、呼出音を聞きます。コールがアウトになったら、ISDN デバッグを有効にします。BRI で ISDN の障害が最初に疑われる場合は、常に show isdn status からの出力をチェックしてください。ここで注意する重要な点は、レイヤ 1 が Active であり、レイヤ 2 が MULTIPLE_FRAME_ESTABLISHED の状態にあるということです。この出力の読み方と修正措置については、『インターネットワーク トラブルシューティング ガイド』の「第 16 章」の「show ISDN ステータスの解釈」を参照してください。

      ISDN 発信コールの場合、debug isdn q931 および debug isdn events が最適なツールです。幸い、発信コールのデバッグは着信コールのデバッグと非常によく似ています。コールが成功すると通常は次のようになります。 

      *Mar 20 21:07:45.025: ISDN SE0:23: Event: 
Call to 5553759 at 64 Kb/s

*Mar 20 21:07:45.033: ISDN SE0:23: TX ->  SETUP pd = 8  
callref = 0x2C
*Mar 20 21:07:45.037:         Bearer Capability i = 0x8890
*Mar 20 21:07:45.041:         Channel ID i = 0x83
*Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539
*Mar 20 21:07:45.141: ISDN SE0:23: RX <-  CALL_PROC pd = 8  
callref = 0xAC
*Mar 20 21:07:45.145:         Channel ID i = 0x89
*Mar 20 21:07:45.157: ISDN SE0:23: received HOST_PROCEEDING
        Channel ID i = 0x0101
*Mar 20 21:07:45.161:   -------------------
        Channel ID i = 0x89
*Mar 20 21:07:45.313: ISDN SE0:23: RX <-  CONNECT pd = 8  
callref = 0xAC
*Mar 20 21:07:45.325: ISDN SE0:23: received HOST_CONNECT

      CONNECT メッセージは、成功を示す主要なインジケータであることに注意してください。CONNECT を受信しない場合は、DISCONNECT または RELEASE_COMP （解放完了）メッセージとその後に理由種別コードが表示されます。 

      *Mar 20 22:11:03.212: ISDN SE0:23: 
RX <-RELEASE_COMP pd = 8 callref = 0x8F
*Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected

      この理由種別は 2 つのことを示しています。

      • 4 バイトまたは 6 バイト値の第 2 バイトは、エンドツーエンドのコール パス内のどこから DISCONNECT または RELEASE_COMP を受信したかを示しています。これを問題の特定に役立てることができます。

      • 第 3 バイトおよび第 4 バイトは、障害の実際の理由を示しています。それぞれの値の意味については、「表 9」を参照してください。

    • 原因 2：リモート モデムが応答していません。通常の電話機を使用してリモート モデムにダイヤルし、動作をテストします。次の手順を試してください。

      1. コールした電話番号が正しいことを確認します。ハンドセットを使用して着信番号をコールします。

      2. 手動コールが応答側の非同期モデムに到達できることを確認します。手動コールが応答側の非同期モデムに到達できる場合は、発信音声コールを許可するように BRI 回線がプロビジョニングされていない可能性があります。

      3. 手動コールが応答非同期モデムに到達できない場合は、着信側モデムの電話ケーブルを取り換えてから、着信側モデムの回線で通常の電話機を使って試してみます。通常の電話機でコールが受信できる場合は、着信側モデムに問題がある可能性があります。

      4. 手動コールが当該回線で通常の電話機に到達しない場合は、着信側施設の別の（確認済みの良好な）回線を使用してみます。正常に接続したら、着信側モデムに接続する電話回線の検査を電話会社に依頼します。

      5. 長距離コールの場合、発信元で別の（確認済みの良好な）長距離番号を試してみます。この番号で通話できる場合は、着信側施設または回線が長距離コールを受信するようにプロビジョニングされていない可能性があります。発信側（BRI）回線が他の長距離番号に到達できない場合は、長距離コールが有効になっていない可能性があります。別の長距離通話会社で 1010 コードを試行します。

      6. 最後に、発信元 BRI 回線から（確認済みの良好な）別のローカル番号を試行します。それでも接続が失敗する場合は、電話会社に BRI の検査を依頼してください。

    • 原因 3：ダイヤルしようとしている番号に誤りがあります。手動でダイヤリングを行い、番号を確認します。必要であれば設定を訂正します。

    • 原因 4：モデムの trainup に時間がかかりすぎているか、または TIMEOUT の値が小さすぎます。chat-script コマンドで TIMEOUT 値を大きくしてみます。TIMEOUT がすでに 60 秒以上の場合は、モデムと、モデムに接続している DTE の間にケーブルの問題がある可能性があります。trainup が失敗する場合は、回線の問題、またはモデムに互換性がないことが考えられます。

      個々のモデムの問題の根本的な原因を突き止めるには、reverse telnet を使用して発信元モデムで AT プロンプトに移動します。可能であれば、リバース Telnet を使用して着信側モデムでも AT プロンプトに移動します。ATM1 を使用して、モデムがそのスピーカに音声を送信するようにします。これにより、回線で何が起こっているかを両側で聞くことができます。

      音楽に雑音が混じっているかを確認します。雑音が混じっている場合は、回線をクリーンアップします。非同期モデムが trainup していない場合は、番号に発信してスタティックを聞きます。他の要素が trainup と干渉している可能性があります。非同期モデムへリバース Telnet を実行してデバッグします。

  5. すべてが正しく動作しているものの、BRI 非同期モデム DDR で接続できない場合は、PPP デバッグを試行します。チャット スクリプトが正常に終了し、PPP デバッグが障害を示す場合は、『インターネットワーク トラブルシューティング ガイド』の第 17 章にある「PPP のトラブルシューティング」セクションを参照してください。

BRI 非同期モデム DDR

この機能は、Cisco IOS ソフトウェア リリース 12.0(3)T 以降が稼働する Cisco 3640 プラットフォームでのみ動作します。この機能には、BRI ネットワーク モジュールの最新のハードウェア リビジョンが必要です。これは WAN インターフェイス カード（WIC）では機能しません。

  1. show modem コマンドで国番号が正しいことを確認します。次のコマンドを使用してから、コール発信を試行します。

    warning 警告：  ビジー状態のシステムでデバッグを実行すると、CPU への過負荷またはコンソール バッファのオーバーランが原因でルータがクラッシュすることがあります。 

    router# debug modem
router# debug chat
router# debug modem csm
router# debug isdn q931
router# debug bri
router# debug ppp negotiate
router# debug ppp authenticate

  2. モデム コールの場合、コールを続行するためチャット スクリプトが実行される必要があります。ダイヤラ マップ ベース DDR の場合、チャット スクリプトはダイヤラ マップ コマンド内の modem-script パラメータによって起動されます。DDR がダイヤラ プロファイル ベースの場合は、TTY 回線で設定された script dialer コマンドによってチャット スクリプトが起動されます。どちらを使用する場合も、ルータのグローバル コンフィギュレーション内に存在する次のようなチャット スクリプトを利用します。 

    chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c

    どちらの場合でも、チャット スクリプトのアクティビティを表示するコマンドは debug chat です。たとえば dialer map または dialer string コマンド内のダイヤル文字列（電話番号）が 5551212 であれば、デバッグ出力は次のようになります。 

    CHAT1: Attempting async line dialer script

CHAT1: Dialing using Modem script: callout & System script: none
CHAT1: process started
CHAT1: Asserting DTR
CHAT1: Chat script callout started
CHAT1: Sending string: AT
CHAT1: Expecting string: OK
CHAT1: Completed match for expect: OK
CHAT1: Sending string: atdt5551212
CHAT1: Expecting string: CONNECT
CHAT1: Completed match for expect: CONNECT
CHAT1: Chat script callout finished, status = Success

  3. チャット スクリプトが「Sending string」に基づいて予期されるコール（正しい番号）を試行することを確認します。 チャット スクリプトが予期されるコールを発信しない場合は、チャット スクリプトの設定を確認します。exec プロンプトで start-chat コマンドを使用して、チャット スクリプトを手動で開始します。

  4. 「Timeout expecting:CONNECT」には、さまざまな原因が記述されています。

    • 原因 1：ローカル モデムが実際にコールを発信していません。モデムへのリバース Telnet を実行してダイヤルを手動で開始し、モデムがコールを発信できることを確認します。リモート エンドが応答しない場合は、モデルからコールが発信されていることを確認するため、ATDT<number> コマンドを使用してローカル番号に手動で発信し、呼出音を聞きます。コールがアウトになったら、ISDN デバッグを有効にします。BRI で ISDN の障害が最初に疑われる場合は、常に show isdn status からの出力をチェックしてください。ここで注意する重要な点は、レイヤ 1 が Active であり、レイヤ 2 が MULTIPLE_FRAME_ESTABLISHED の状態にあるということです。この出力の読み方と修正措置については、『インターネットワーク トラブルシューティング ガイド』の「第 16 章」の「show ISDN ステータスの解釈」を参照してください。

      ISDN 発信コールの場合、debug isdn q931 および debug isdn events が最適なツールです。幸い、発信コールのデバッグは着信コールのデバッグと非常によく似ています。コールが成功すると通常は次のようになります。 

      *Mar 20 21:07:45.025: ISDN BR0: Event: 
Call to 5553759 at 64 Kb/s

*Mar 20 21:07:45.033: ISDN BR0: TX ->  SETUP pd = 8  
callref = 0x2C
*Mar 20 21:07:45.037:         Bearer Capability i = 0x8890
*Mar 20 21:07:45.041:         Channel ID i = 0x83
*Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539
*Mar 20 21:07:45.141: ISDN BR0: RX <-  CALL_PROC pd = 8  
callref = 0xAC
*Mar 20 21:07:45.145:         Channel ID i = 0x89
*Mar 20 21:07:45.157: ISDN BR0: received HOST_PROCEEDING
        Channel ID i = 0x0101
*Mar 20 21:07:45.161:   -------------------
        Channel ID i = 0x89
*Mar 20 21:07:45.313: ISDN BR0: RX <-  CONNECT pd = 8  
callref = 0xAC
*Mar 20 21:07:45.325: ISDN BR0: received HOST_CONNECT

      CONNECT メッセージは、成功を示す主要なインジケータであることに注意してください。CONNECT を受信しない場合は、DISCONNECT または RELEASE_COMP （解放完了）メッセージとその後に理由種別コードが表示されます。 

      *Mar 20 22:11:03.212: ISDN BR0: RX <-  RELEASE_COMP pd = 8  
callref = 0x8F
*Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected

      この理由種別は 2 つのことを示しています。

      • 4 バイトまたは 6 バイト値の第 2 バイトは、エンドツーエンドのコール パス内のどこから DISCONNECT または RELEASE_COMP を受信したかを示しています。これを問題の特定に役立てることができます。

      • 第 3 バイトおよび第 4 バイトは、障害の実際の理由を示しています。それぞれの値の意味については、「表 9」を参照してください。

    • 原因 2：リモート モデムが応答していません。通常の電話機を使用してリモート モデムにダイヤルし、動作をテストします。次の手順を試してください。

      1. コールした電話番号が正しいことを確認します。ハンドセットを使用して着信番号をコールします。

      2. 手動コールが応答側の非同期モデムに到達できることを確認します。手動コールが応答側の非同期モデムに到達できる場合は、発信音声コールを許可するように BRI 回線がプロビジョニングされていない可能性があります。

      3. 手動コールが応答非同期モデムに到達できない場合は、着信側モデムの電話ケーブルを取り換えてから、着信側モデムの回線で通常の電話機を使って試してみます。通常の電話機でコールが受信できる場合は、着信側モデムに問題がある可能性があります。

      4. 手動コールが当該回線で通常の電話機に到達しない場合は、着信側施設の別の（確認済みの良好な）回線を使用してみます。正常に接続したら、着信側モデムに接続する電話回線の検査を電話会社に依頼します。

      5. 長距離コールの場合、発信元で別の（確認済みの良好な）長距離番号を試してみます。この番号で通話できる場合は、着信側施設または回線が長距離コールを受信するようにプロビジョニングされていない可能性があります。発信側（BRI）回線が他の長距離番号に到達できない場合は、長距離コールが有効になっていない可能性があります。別の長距離通話会社で 10-10 コードを試行します。

      6. 最後に、発信元 BRI 回線から（確認済みの良好な）別のローカル番号を試行します。それでも接続が失敗する場合は、電話会社に BRI の検査を依頼してください。

    • 原因 3：ダイヤルしようとしている番号に誤りがあります。手動でダイヤリングを行い、番号を確認します。必要であれば設定を訂正します。

    • 原因 4：モデムの trainup に時間がかかりすぎているか、または TIMEOUT の値が小さすぎます。chat-script コマンドで TIMEOUT 値を大きくしてみます。TIMEOUT がすでに 60 秒以上の場合は、モデムと、モデムに接続している DTE の間にケーブルの問題がある可能性があります。trainup が失敗する場合は、回線の問題、またはモデムに互換性がないことが考えられます。

      個々のモデムの問題の根本的な原因を突き止めるには、reverse telnet を使用して発信元モデムで AT プロンプトに移動します。可能であれば、リバース Telnet を使用して着信側モデムでも AT プロンプトに移動します。ATM1 を使用して、モデムがそのスピーカに音声を送信するようにします。これにより、回線で何が起こっているかを両側で聞くことができます。

      音楽に雑音が混じっているかを確認します。雑音が混じっている場合は、回線をクリーンアップします。非同期モデムが trainup していない場合は、番号に発信してスタティックを聞きます。他の要素が trainup と干渉している可能性があります。非同期モデムへリバース Telnet を実行してデバッグします。

  5. すべてが正しく動作しているものの、BRI 非同期モデム DDR で接続できない場合は、PPP デバッグを試行します。チャット スクリプトが正常に終了し、PPP デバッグが障害を示す場合は、『インターネットワーク トラブルシューティング ガイド』の第 17 章にある「PPP のトラブルシューティング」セクションを参照してください。

PRI ISDN DDR

  1. PRI で ISDN の障害が最初に疑われる場合は、常に show isdn status からの出力をチェックしてください。ここで注意する重要な点は、レイヤ 1 が Active であり、レイヤ 2 が MULTIPLE_FRAME_ESTABLISHED の状態にあるということです。この出力の読み方と修正措置については、『インターネットワーク トラブルシューティング ガイド』の「第 16 章」の「show ISDN ステータスの解釈」を参照してください。

    ISDN 発信コールの場合、debug isdn q931 および debug isdn events が最適なツールです。幸い、発信コールのデバッグは着信コールのデバッグと非常によく似ています。コールが成功すると通常は次のようになります。 

    *Mar 20 21:07:45.025: ISDN SE0:23: Event: 
Call to 5553759 at 64 Kb/s

*Mar 20 21:07:45.033: ISDN SE0:23: TX ->  SETUP pd = 8  
callref = 0x2C
*Mar 20 21:07:45.037:         Bearer Capability i = 0x8890
*Mar 20 21:07:45.041:         Channel ID i = 0x83
*Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539
*Mar 20 21:07:45.141: ISDN SE0:23: RX <-  CALL_PROC pd = 8  
callref = 0xAC
*Mar 20 21:07:45.145:         Channel ID i = 0x89
*Mar 20 21:07:45.157: ISDN SE0:23: received HOST_PROCEEDING
        Channel ID i = 0x0101
*Mar 20 21:07:45.161:   -------------------
        Channel ID i = 0x89
*Mar 20 21:07:45.313: ISDN SE0:23: RX <-  CONNECT pd = 8  
callref = 0xAC
*Mar 20 21:07:45.325: ISDN SE0:23: received HOST_CONNECT

    CONNECT メッセージは、成功を示す主要なインジケータであることに注意してください。CONNECT を受信しない場合は、DISCONNECT または RELEASE_COMP （解放完了）メッセージとその後に理由種別コードが表示されます。 

    *Mar 20 22:11:03.212: ISDN SE0:23: RX <-  RELEASE_COMP pd = 8  
callref = 0x8F
*Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected

    この理由種別は 2 つのことを示しています。

    • 4 バイトまたは 6 バイト値の第 2 バイトは、エンドツーエンドのコール パス内のどこから DISCONNECT または RELEASE_COMP を受信したかを示しています。これを問題の特定に役立てることができます。

    • 第 3 バイトおよび第 4 バイトは、障害の実際の理由を示しています。それぞれの値の意味については、「表 9」を参照してください。

    注：次の出力は、より高いプロトコルの障害を示しています。

    Cause i = 0x8090 - Normal call clearing

    PPP 認証の失敗が典型的な理由です。接続障害が必ず ISDN の問題であると見なす前に、debug ppp negotiation および debug ppp authentication をオンにします。

  2. ISDN CONNECT メッセージが表示され、PPP デバッグが障害を示す場合は、『インターネットワーク トラブルシューティング ガイド』の 「第 17 章」にある「PPP のトラブルシューティング」セクションを参照してください。

BRI ISDN DDR

  1. BRI で ISDN の障害が最初に疑われる場合は、常に show isdn status からの出力をチェックしてください。ここで注意する重要な点は、レイヤ 1 が Active であり、レイヤ 2 が MULTIPLE_FRAME_ESTABLISHED の状態にあるということです。この出力の読み方と修正措置については、『インターネットワーク トラブルシューティング ガイド』の「第 16 章」の「show ISDN ステータスの解釈」を参照してください。

    ISDN 発信コールの場合、debug isdn q931 および debug isdn events が最適なツールです。幸い、発信コールのデバッグは着信コールのデバッグと非常によく似ています。コールが成功すると通常は次のようになります。 

    *Mar 20 21:07:45.025: ISDN BR0: Event: Call to 5553759 at 64 Kb/s

*Mar 20 21:07:45.033: ISDN BR0: TX ->  SETUP pd = 8  callref = 0x2C
*Mar 20 21:07:45.037:         Bearer Capability i = 0x8890
*Mar 20 21:07:45.041:         Channel ID i = 0x83
*Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539
*Mar 20 21:07:45.141: ISDN BR0: RX <-  CALL_PROC pd = 8  callref = 0xAC
*Mar 20 21:07:45.145:         Channel ID i = 0x89
*Mar 20 21:07:45.157: ISDN BR0: received HOST_PROCEEDING
        Channel ID i = 0x0101
*Mar 20 21:07:45.161:   -------------------
        Channel ID i = 0x89
*Mar 20 21:07:45.313: ISDN BR0: RX <-  CONNECT pd = 8  callref = 0xAC
*Mar 20 21:07:45.325: ISDN BR0: received HOST_CONNECT

    CONNECT メッセージは、成功を示す主要なインジケータであることに注意してください。CONNECT を受信しない場合は、DISCONNECT または RELEASE_COMP （解放完了）メッセージとその後に理由種別コードが表示されます。 

    *Mar 20 22:11:03.212: ISDN BR0: RX <-  RELEASE_COMP pd = 8  
callref = 0x8F
*Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected

    この理由種別は 2 つのことを示しています。

    • 4 バイトまたは 6 バイト値の第 2 バイトは、エンドツーエンドのコール パス内のどこから DISCONNECT または RELEASE_COMP を受信したかを示しています。これを問題の特定に役立てることができます。

    • 第 3 バイトおよび第 4 バイトは、障害の実際の理由を示しています。それぞれの値の意味については、「表 9」を参照してください。

      注：次の出力は、より高いプロトコルの障害を示しています。 

      Cause i = 0x8090 - Normal call clearing

      PPP 認証の失敗が典型的な理由です。接続障害が必ず ISDN の問題であると見なす前に、debug ppp negotiation および debug ppp authentication をオンにします。

  2. ISDN CONNECT メッセージが表示され、PPP デバッグが障害を示す場合は、『インターネットワーク トラブルシューティング ガイド』の 「第 17 章」にある「PPP のトラブルシューティング」セクションを参照してください。

関連情報

更新履歴

改定 発行日 コメント
1.0
09-Jul-2007
初版

このドキュメントは役に立ちましたか?

Feedbackフィードバック

シスコに問い合わせ

このドキュメントは次の製品に対応しています