このドキュメントでは、さまざまなダイヤル接続のタイプのトラブルシューティング方法を提供しており、最初から最後まで読むことを目的とはしていません。この構成は、読者が関心のある項に進めるように設計されており、それぞれが特定のケースの全体的なトラブルシューティングのテーマのバリエーションになっています。このドキュメントでは、3 つの主要なシナリオについて説明します。トラブルシューティングを開始する前にどのようなタイプのコールが試みられているか特定し、対応する項に移動してください。
非 DDR コールアウト
このドキュメントに関しては個別の前提条件はありません。
このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
このマニュアルの情報は、特定のラボ環境に置かれたデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期(デフォルト)設定の状態から起動しています。実稼動中のネットワークで作業をしている場合、実際にコマンドを使用する前に、その潜在的な影響について理解しておく必要があります。
ダイヤルアップは、端末ユーザのためにデータを搬送する 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 アクセス サーバから非 DDR 発信コールを行う一般的な理由がいくつかあります。
Cisco ダイヤルアウト ユーティリティでアクセス サーバを使用する。
アクセス サーバを、別のサーバの文字セル ダイヤルアップ セッションにアクセスするターミナル サーバとして使用する(後で手動でログインし PPP を開始する場合など)。
モデムをテストまたは設定する(「リバース Telnet の設定」を参照)。
DDR コールアウトのトラブルシューティングと同様に、非 DDR コールアウトのトラブルシューティングで行う原因特定の一般的なフローは次のようになります。
リスニング ポートへの TCP 接続が成功しましたか。(「はい」の場合は次の質問に進みます。)
モデムが AT プロンプトを表示できますか。
コールが PSTN の外部に達しましたか。
リモート エンドがコールに応答しましたか。
コールが完了しましたか。
データがリンクを通過していますか。
セッションが確立されましたか。(PPP または端末)
Cisco ダイヤルアウト ユーティリティにより、Windows PC からなるコミュニティがアクセス サーバのモデム リソースを効果的に共有できます。ユーザ コミュニティに対して Cisco ダイヤルアウト ユーティリティをセットアップする一般的な手順は次のとおりです。
回線設定で以下のコマンドを使用してネットワーク アクセス サーバ(NAS)をセットアップします。
line 1 16 modem InOut rotary 1 transport input all flowcontrol hardware
NAS のモデムを使用する PC に Cisco ダイヤルアウト ユーティリティをインストールします。設定を確認します。
画面右下にあるダイヤルアウト ユーティリティ アイコンをダブルクリックします。
[More] をクリックします。
[Configure Port] をクリックします。
モデムが PC にログインできるようにしておくことも推奨されます。このためには、[Start] > [Control Panel] > [Modems] をクリックします。Cisco ダイヤルアウト モデムを選択し、[Properties] ボタンをクリックします。[Connection] タブを選択し、[Advanced] ボタンをクリックします。[Record a log file] チェックボックスをオンにします。
PC で、Cisco Dialout COM ポートを使用するようにダイヤルアップ ネットワークを設定します。
Cisco ダイヤルアウト ユーティリティのポート番号の選択について理解しておくべき点がいくつかあります。デフォルトでは TCP ポート 6001 が使用されます。これは、アウトバウンド NAS の唯一のユーザであることを意味します。これは一般的なケースではないため、7001 を使用してロータリー機能を利用する方が適切です。回線設定に transport input コマンドを組み込むことで、TCP リスナー プロセスが作成されます。各種 IP ポート番号範囲と設定されるプロトコルを次の表に示します。
表 3:「Transport Input」コマンドにより設定される TCP リスナー ポート2000 | Telnet プロトコル |
3,000 | Telnet プロトコル、ロータリー付き |
4000 | ロー TCP プロトコル |
5000 | ロー TCP プロトコル、ロータリー付き |
6000 | Telnet プロトコル、バイナリ モード |
7000 | Telnet プロトコル、バイナリ モード、ロータリー付き |
9000 | Xremote プロトコル |
10,000 | XRemote プロトコル、ロータリー付き |
ロータリーにより、ユーザは指定されたポートへのインバウンド TCP 接続を確立し、最終的にはロータリー グループ番号が指定されている現在使用可能なモデムに接続できます。上記の例では、ロータリーグループが3001、5001、7001、および10001にリスナーを設定しています。Cisco Dialout Utilityはバイナリモードを使用するため、7001がPCで使用するクライアントプログラムのの正の番号です。
非 DDR ダイヤルアウトをトラブルシューティングするには、次の手順を実行します。
非 DDR コールアウト(リバース Telnet の設定コールアウトなど)が初めて正常に実行されることを確認するには、debug telnet コマンドを使用して、ルータへの着信 Telnet 接続を確認します。
TCP 接続が拒否される場合、指定したアドレスおよびポートにリスナーが存在しないか、または他の何かがすでにそのポートに接続している可能性があります。接続しようとしているアドレスとポート番号を確認します。
また、modem inout コマンド(または modem dtr-active コマンド)と transport input all コマンドが、接続しようとしている回線の回線設定に含まれていることも確認します。ロータリー機能を使用する場合は、rotary 1(または選択した番号)コマンドも回線設定に含まれていることを確認します。何かがすでに接続しているかどうかを調べるには、ルータへの Telnet を実行し、show line コマンドを使用します。回線が使用中であることを示すアスタリスクを見つけます。また、show line n コマンドを使用して Clear to Send(CTS)が高く、Data Set Ready(DSR)が高くないことを確認します。clear line n コマンドを使用して、そのポート番号での現在のセッションを接続解除します。
この時点で Telnet が稼働しているはずです。次に、発信接続に使用されているメディアのタイプを確認します。
外付け非同期モデムの非 DDR コールアウト(例:リバース Telnet の設定コールアウト)を確認するには、次を実行します。
AT コマンドを入力し、OK 応答が表示されることを確認します。OK 応答が表示されない場合は、AT&FE1Q0 コマンドを入力します。AT コマンドを再度入力し、OK 応答が表示されることを確認します。OK 応答が表示される場合、モデムの初期化が必要である可能性があります。OK 応答が表示されない場合は、ローカル非同期モデムからルータへの接続のケーブル配線、回線速度、およびパリティ設定を調べます。詳細については、『モデムとルータ間の接続ガイド』を参照してください。
ATM1 コマンドを使用してモデムのスピーカーの音量を上げ、ATDT <number> と入力します。
リモート エンドが応答しない場合は、発信元モデムからコールが発信されていることを確認するため、ATDT <number> コマンドを使用してローカル番号に手動で発信し、呼び出し音を聞きます。
呼び出し音がない場合、コールは発信されていません。
発信元モデムのケーブルを交換してから、再試行します。それでも動作しない場合は、回線のハンドセットを調べます。モデムに使用していたものと同じケーブルを使用していることを確認します。新しいケーブルを接続してもハンドセットで発信コールができない場合は、通信事業者に連絡して発信元の電話回線を調べるように依頼してください。
モデムが予期されているとおりに発信していると思われる場合は、発信先電話番号が正しいかどうかを確認します。
ハンドセットを使用して着信番号をコールします。モデムに使用していたものと同じケーブルを使用していることを確認します。手動コールが着信番号に到達できる場合は、リモート モデムからの応答トーン(ABT)を待ちます。 コールに応答がない場合や ABT が聞こえない場合は、受信モデムが自動応答に設定されていない可能性があります。ほとんどのモデムに自動応答を指示するコマンドはATS0=1です。受信側モデムを初期化するか、デバッグする必要がある場合があります。受信側モデムが Cisco ルータに接続している場合は、詳細については『モデムとルータ間の接続ガイド』を参照してください。モデムを確認し、必要に応じて交換します。
手動コールが応答非同期モデムに到達できない場合は、着信側モデムの電話ケーブルを取り換えてから、着信側モデムの回線で通常の電話機を使って試してみます。通常の電話機でコールが受信できる場合は、着信側モデムに問題がある可能性があります。モデムを確認し、必要に応じて交換します。
手動コールが当該回線で通常の電話機に到達しない場合は、着信側施設の別の(確認済みの良好な)回線を使用してみます。正常に接続したら、着信側モデムに接続する電話回線の検査を電話会社に依頼します。
手動コールが着信側施設に到達せず、これが長距離コールである場合は、発信側で別の(確認済みの良好な)長距離番号を試してみます。
この番号で通話できる場合は、着信側施設または回線が長距離コールを受信するようにプロビジョニングされていない可能性があります。発信側回線が他の長距離番号に到達できない場合は、長距離コールが有効になっていない可能性があります。別の長距離通話会社で 10-10 コードを試行します。
非同期モデムが trainup していることを確認します。
非同期モデムが trainup していない場合は、手動で番号に発信して静かに待ちます。他の要素が trainup と干渉している可能性があります。着信側モデムと、そのモデムに接続している DTE の間のケーブルに問題がある可能性があります。trainup が失敗する場合、回線の問題または互換性がない問題が原因である可能性があります。場合によっては、モデムをそれほど速くない速度に制限するように調整することで、モデムを修復できます。この手法の例として、シスコのテスト システムの 1 つに接続してみます。最初にスピーカーをオンにし、DCE レート情報レポートを有効にします。
atm1 OK
次に、スタティック ラボにダイヤルインします。
at OK atdt914085703932 NO CARRIER
標準接続が失敗したように見えます。この場合、回線に雑音があるため、次のコマンドを使用して、モデムを工場出荷時の初期状態(&f)に設定し、スピーカーをオンにし(m1)、モデム速度を 28.8(USR モデムの場合は &n14)に制限します。
at&fm1&n14 OK
次に再度ダイヤルします。
atdt914085703932 CONNECT 28800/ARQ Welcome! Please login with username cisco, password cisco, and type the appropriate commands for your test: ppp - to start ppp slip - to start slip arap - to start arap access-3 line 29 MICA V.90 modems User Access Verification Username: cisco Password: access-3>
データが転送されていることを確認します。Return キーを数回押して、データがリモート システムとローカルセッションの間で送受信されるかどうかを確認します。データが転送されない場合は、リモート非同期モデムがリモート DTE と通信しようとしたときにケーブルまたは信号の問題が発生している可能性があります。デバッグを行い、必要に応じて交換します。
入力データに対してもう一方の側から適切な応答がある場合は、モデム接続が機能しています。
CAS T1/E1 非 DDR コールアウトを実行するには、次の手順を実行します。
CAS T1/E1 非同期モデム非 DDR コールアウトを診断し、次のコマンドを使用してから、コール発信を試行します。
警告:ビジー状態のシステムでデバッグを実行すると、CPUの過負荷またはコンソールバッファの過剰実行により、ルータがクラッシュする可能性があります。
router# debug modem 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 で RBS をデバッグするには、トランク カードに接続する必要があります。(デバッグをオフにするには modem-mgmt csm no-debug-rbs を使用します。)
AT コマンドを入力し、OK 応答が表示されることを確認します。
OK 応答が表示されない場合は、AT&F コマンドを入力します。AT コマンドを再度入力し、OK 応答が表示されることを確認します。OK 応答が表示される場合、モデムの初期化が必要である可能性があります。それでもまだ OK 応答が表示されない場合は、モデム モジュールに問題があると考えられます。コールを発信するには、その前にモデムをコール用に割り当てておく必要があります。このプロセスと以降のコールを確認するには、デバッグ出力からこのプロセスが行われているかどうかを判断します。以下に、いくつかの例を示します。
デバッグのオン:
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# 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 のトラブルシューティングを行う必要があります。
モデムが予期されているとおりに発信していると思われる場合は、発信先電話番号が正しいかどうかを確認します。
ハンドセットを使用して着信番号をコールします。手動コールが着信番号に到達できる場合は、リモート モデムからの応答トーン(ABT)を待ちます。 コールに応答がない場合や ABT が聞こえない場合は、受信モデムが自動応答に設定されていない可能性があります。ほとんどのモデムに自動応答を指示するコマンドはATS0=1です。受信側モデムを初期化するか、デバッグする必要がある場合があります。受信側モデムが Cisco ルータに接続している場合は、詳細については『モデムとルータ間の接続ガイド』を参照してください。モデムを確認し、必要に応じて交換します。
手動コールが当該回線で通常の電話機に到達しない場合は、着信側施設の別の(確認済みの良好な)回線を使用してみます。正常に接続したら、着信側モデムに接続する電話回線の検査を電話会社に依頼します。
長距離コールの場合、発信元で別の(確認済みの良好な)長距離番号を試してみます。
この番号で通話できる場合は、着信側施設または回線が長距離コールを受信するようにプロビジョニングされていない可能性があります。発信側(CAS)回線が他の長距離番号に到達できない場合は、長距離コールが有効になっていない可能性があります。別の長距離通話会社で 10-10 コードを試行します。
非同期モデムが trainup していることを確認します。
非同期モデムが trainup していない場合は、手動で番号に発信して静かに待ちます。他の要素が trainup と干渉している可能性があります。着信側モデムと、そのモデムに接続している DTE の間のケーブルに問題がある可能性があります。trainup が失敗する場合、回線の問題または互換性がない問題が原因である可能性があります。場合によっては、モデムをそれほど速くない速度に制限するように調整することで、モデムを修復できます。この手法の例として、シスコのテスト システムの 1 つに接続してみます。
at OK
次に、スタティック ラボにダイヤルインします。
at OK atdt914085703932 NO CARRIER
標準接続が失敗したように見えます。この場合、回線に雑音があるため、次のコマンドを使用して、モデムを工場出荷時の初期状態(&f)に設定し、スピーカーをオンにし(m1)、モデム速度を 28.8(S56=28800)に制限します。
at&fs56=28800 OK
次に再度ダイヤルします。
atdt914085703932 CONNECT 28800/ARQ Welcome! Please login with username cisco, password cisco, and type the appropriate commands for your test: ppp - to start ppp slip - to start slip arap - to start arap access-3 line 29 MICA V.90 modems User Access Verification Username: cisco Password: access-3>
データが転送されていることを確認します。
Return キーを数回押して、データがリモート システムとローカルセッションの間で送受信されるかどうかを確認します。データが転送されない場合は、リモート非同期モデムがリモート DTE と通信しようとしたときにケーブルまたは信号の問題が発生している可能性があります。デバッグを行い、必要に応じて交換します。
入力データに対してもう一方の側から適切な応答がある場合は、モデム接続が機能しています。
PRI 非 DDR コールアウトを実行するには、次の手順を実行します。
PRI 非同期モデム非 DDR コールアウトを診断し、次のコマンドを使用してから、コール発信を試行します。
警告: ビジー状態のシステムでデバッグを実行すると、CPU への過負荷またはコンソール バッファのオーバーランが原因でルータがクラッシュすることがあります。
router# debug modem router# debug modem csm router# debug isdn q931 router# debug isdn
AT コマンドを入力し、OK 応答が表示されることを確認します。
OK 応答が表示されない場合は、AT&F コマンドを入力します。AT コマンドを再度入力し、OK 応答が表示されることを確認します。OK 応答が表示される場合、modemcap の初期化が必要である可能性があります。このためには modem autoconfigure type xxx コマンドを使用します(xxx はモデム タイプです)。それでもまだ OK 応答が表示されない場合は、モデム モジュールに問題があると考えられます。手動でダイヤル開始することでモデムがコール発信できることを確認します。リモート エンドが応答しない場合は、モデムからコールが発信されていることを確認するため、ATDT <number> コマンドを使用してローカル番号に手動で発信し、呼び出し音を聞きます。コールが発信されない場合は、ISDN の問題が発生している可能性があります。BRI で ISDN の障害が最初に疑われる場合は、常に show isdn status からの出力をチェックしてください。ここで注意する重要な点は、レイヤ 1 が Active であり、レイヤ 2 が MULTIPLE_FRAME_ESTABLISHED の状態にあるということです。この出力の解釈と修正の方法については、「show isdn status 出力の解釈」を参照してください。
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」を参照してください。
モデムが予期されているとおりに発信していると思われる場合は、発信先電話番号が正しいかどうかを確認します。
ハンドセットを使用して着信番号をコールします。手動コールが着信番号に到達できる場合は、リモート モデムからの応答トーン(ABT)を待ちます。 コールに応答がない場合や ABT が聞こえない場合は、受信モデムが自動応答に設定されていない可能性があります。ほとんどのモデムに自動応答を指示するコマンドはATS0=1です。受信側モデムを初期化するか、デバッグする必要がある場合があります。受信側モデムが Cisco ルータに接続している場合は、詳細については『モデムとルータ間の接続ガイド』を参照してください。モデムを確認し、必要に応じて交換します。
手動コールが当該回線で通常の電話機に到達しない場合は、着信側施設の別の(確認済みの良好な)回線を使用してみます。正常に接続したら、着信側モデムに接続する電話回線の検査を電話会社に依頼します。
長距離コールの場合、発信元で別の(確認済みの良好な)長距離番号を試してみます。
この番号で通話できる場合は、着信側施設または回線が長距離コールを受信するようにプロビジョニングされていない可能性があります。発信側(BRI)回線が他の長距離番号に到達できない場合は、長距離コールが有効になっていない可能性があります。別の長距離通話会社で 10-10 コードを試行します。
非同期モデムが trainup していることを確認します。
非同期モデムが trainup していない場合は、手動で番号に発信して静かに待ちます。他の要素が trainup と干渉している可能性があります。着信側モデムと、そのモデムに接続している DTE の間のケーブルに問題がある可能性があります。trainup が失敗する場合、回線の問題または互換性がない問題が原因である可能性があります。場合によっては、モデムをそれほど速くない速度に制限するように調整することで、モデムを修復できます。この手法の例として、シスコのテスト システムの 1 つに接続してみます。
at OK
次に、スタティック ラボにダイヤルインします。
at OK atdt914085703932 NO CARRIER
標準接続が失敗したように見えます。この場合、回線に雑音があるため、次のコマンドを使用して、モデムを工場出荷時の初期状態(&f)に設定し、スピーカーをオンにし(m1)、モデム速度を 28.8(S56=28800)に制限します。
at&fs56=28800 OK
次に再度ダイヤルします。
atdt914085703932 CONNECT 28800/ARQ Welcome! Please login with username cisco, password cisco, and type the appropriate commands for your test: ppp - to start ppp slip - to start slip arap - to start arap access-3 line 29 MICA V.90 modems User Access Verification Username: cisco Password: access-3>
データが転送されていることを確認します。
Return キーを数回押して、データがリモート システムとローカルセッションの間で送受信されるかどうかを確認します。データが転送されない場合は、リモート非同期モデムがリモート DTE と通信しようとしたときにケーブルまたは信号の問題が発生している可能性があります。デバッグを行い、必要に応じて交換します。
入力データに対してもう一方の側から適切な応答がある場合は、モデム接続が機能しています。
この機能は、Cisco IOS ソフトウェア リリース 12.0(3)T 以降が稼働する Cisco 3640 プラットフォームでのみ動作します。この機能には、BRI ネットワーク モジュールの最新のハードウェア リビジョンが必要です。これは WAN インターフェイス カード(WIC)では機能しません。
PRI 非同期モデム非 DDR コールアウトを診断し、次のコマンドを使用してから、コール発信を試行します。
警告: ビジー状態のシステムでデバッグを実行すると、CPU への過負荷またはコンソール バッファのオーバーランが原因でルータがクラッシュすることがあります。
router# debug modem router# debug modem csm router# debug isdn q931 router# debug isdn
AT コマンドを入力し、OK 応答が表示されることを確認します。
AT コマンドを入力し、OK 応答が表示されることを確認します。OK 応答が表示されない場合は、AT&F コマンドを入力します。AT コマンドを再度入力し、OK 応答が表示されることを確認します。OK 応答が表示される場合、modemcap の初期化が必要である可能性があります。このためには modem autoconfigure type xxx コマンドを使用します(xxx はモデム タイプです)。それでもまだ OK 応答が表示されない場合は、モデム モジュールに問題があると考えられます。手動でダイヤル開始することでモデムがコール発信できることを確認します。リモート エンドが応答しない場合は、モデムからコールが発信されていることを確認するため、ATDT <number> コマンドを使用してローカル番号に手動で発信し、呼び出し音を聞きます。コールが発信されない場合は、ISDN の問題が発生している可能性があります。BRI で ISDN の障害が最初に疑われる場合は、常に show isdn status からの出力をチェックしてください。ここで注意する重要な点は、レイヤ 1 が Active であり、レイヤ 2 が MULTIPLE_FRAME_ESTABLISHED の状態にあるということです。この出力の解釈と修正の方法については、「show isdn status 出力の解釈」を参照してください。
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」を参照してください。
モデムが予期されているとおりに発信していると思われる場合は、発信先電話番号が正しいかどうかを確認します。
ハンドセットを使用して着信番号をコールします。手動コールが着信番号に到達できる場合は、リモート モデムからの応答トーン(ABT)を待ちます。 コールに応答がない場合や ABT が聞こえない場合は、受信モデムが自動応答に設定されていない可能性があります。ほとんどのモデムに自動応答を指示するコマンドはATS0=1です。受信側モデムを初期化するか、デバッグする必要がある場合があります。受信側モデムが Cisco ルータに接続している場合は、詳細については『モデムとルータ間の接続ガイド』を参照してください。モデムを確認し、必要に応じて交換します。
手動コールが当該回線で通常の電話機に到達しない場合は、着信側施設の別の(確認済みの良好な)回線を使用してみます。
正常に接続したら、着信側モデムに接続する電話回線の検査を電話会社に依頼します。
長距離コールの場合、発信元で別の(確認済みの良好な)長距離番号を試してみます。
この番号で通話できる場合は、着信側施設または回線が長距離コールを受信するようにプロビジョニングされていない可能性があります。発信側(BRI)回線が他の長距離番号に到達できない場合は、長距離コールが有効になっていない可能性があります。別の長距離通話会社で 10-10 コードを試行します。
非同期モデムが trainup していることを確認します。
非同期モデムが trainup していない場合は、手動で番号に発信して静かに待ちます。他の要素が trainup と干渉している可能性があります。着信側モデムと、そのモデムに接続している DTE の間のケーブルに問題がある可能性があります。trainup が失敗する場合、回線の問題または互換性がない問題が原因である可能性があります。場合によっては、モデムをそれほど速くない速度に制限するように調整することで、モデムを修復できます。この手法の例として、シスコのテスト システムの 1 つに接続してみます。
at OK
次に、スタティック ラボにダイヤルインします。
at OK atdt914085703932 NO CARRIER
標準接続が失敗したように見えます。この場合、回線に雑音があるため、次のコマンドを使用して、モデムを工場出荷時の初期状態(&F)に設定し、スピーカーをオンにし(m1)、モデム速度を 28.8(S56=28800)に制限します。
at&fs56=28800 OK
次に再度ダイヤルします。
atdt914085703932 CONNECT 28800/ARQ Welcome! Please login with username cisco, password cisco, and type the appropriate commands for your test: ppp - to start ppp slip - to start slip arap - to start arap access-3 line 29 MICA V.90 modems User Access Verification Username: cisco Password: access-3>
データが転送されていることを確認します。
Return キーを数回押して、データがリモート システムとローカルセッションの間で送受信されるかどうかを確認します。データが転送されない場合は、リモート非同期モデムがリモート DTE と通信しようとしたときにケーブルまたは信号の問題が発生している可能性があります。デバッグを行い、必要に応じて交換します。
入力データに対してもう一方の側から適切な応答がある場合は、モデム接続が機能しています。
ここまでの時点で、モデムは接続され trainup されています。次に、トラフィックが正しく送受信されているかどうかを調べます。
コールを受信している回線に autoselect ppp を設定していて、非同期インターフェイスに async mode interactive を設定している場合は、debug modem コマンドを使用して自動選択処理を確認します。トラフィックが非同期回線を経由して着信すると、アクセス サーバはトラフィックを調べ、トラフィックがキャラクタ ベースかパケット ベースかを判断します。次に、アクセス サーバはこの判断に応じて、PPP セッションを開始するか、または回線上で exec セッションを維持します。
PPP の着信 LCP パケットによる正常な自動選択シーケンスは次のようになります。
*Mar 1 21:34:56.958: TTY1: DSR came up *Mar 1 21:34:56.962: tty1: Modem: IDLE->READY *Mar 1 21:34:56.970: TTY1: EXEC creation *Mar 1 21:34:56.978: TTY1: set timer type 10, 30 seconds *Mar 1 21:34:59.722: TTY1: Autoselect(2) sample 7E (See Note 1) *Mar 1 21:34:59.726: TTY1: Autoselect(2) sample 7EFF *Mar 1 21:34:59.730: TTY1: Autoselect(2) sample 7EFF7D *Mar 1 21:34:59.730: TTY1: Autoselect(2) sample 7EFF7D23 *Mar 1 21:34:59.734: TTY1 Autoselect cmd: ppp negotiate (See Note 2) *Mar 1 21:34:59.746: TTY1: EXEC creation *Mar 1 21:34:59.746: TTY1: create timer type 1, 600 seconds *Mar 1 21:34:59.794: TTY1: destroy timer type 1 (OK) *Mar 1 21:34:59.794: TTY1: destroy timer type 0 *Mar 1 21:35:01.798: %LINK-3-UPDOWN: Interface Async1, changed state to up (See Note 3)
注 1:着信トラフィックは 16 進数の形式で表示されます。これは、ビットが ASCII 文字かパケットの要素かどうかにかかわらず、回線経由で着信するビットに基づいています。この例に示されているビットは、LCP パケットに対して適切です。それ以外のビットはすべて、不正なパケットまたは文字トラフィックです。
注 2:着信トラフィックが実際に LCP パケットであると判断されたため、アクセス サーバにより PPP ネゴシエーション プロセスが開始されます。
注 3:非同期インターフェイスの状態が up に変わり、PPP ネゴシエーション(表示されていません)が開始されます。
コールが PPP セッションで、非同期インターフェイスに async mode dedicated が設定されている場合は、debug ppp negotiation コマンドを使用して、リモート エンドから到着する設定要求パケットがあるかどうかを確認します。デバッグではこれらが CONFREQ と表示されます。着信および発信の両方の PPP パケットが観測される場合は、「PPP のトラブルシューティング」を参照してください。それ以外の場合は、コールの発信元である端末からキャラクタモード(または「exec」)セッション(つまり、非 PPP セッション)で接続します。
注:受信側が非同期インターフェイスの下にasync modem dedicatedと表示している場合、execダイヤルインはランダムなASCII文字が表示されるだけです。PPP 機能を有効にしたままでターミナル セッションを許可するには、非同期インターフェイス設定コマンド async mode interactive を使用します。関連する回線の設定で、autoselect pppコマンドを使用します。
モデムがターミナル セッションと接続していて、データがまったく到達しない場合は、次の点を確認してください。
表 4:モデムがデータを送信または受信できない場合考えられる原因 | 推奨される対策 |
---|---|
モデム速度の設定が固定されていない |
|
ハードウェア フロー制御がローカルまたはリモートのモデムまたはルータで設定されていない |
|
誤った dialer map コマンドの設定 |
|
ダイヤリング モデムに関する問題 | ダイヤリング モデムが稼働状態にあり、正しいポートに確実に接続していることを確認します。同じポートに接続している別のモデムが動作しているかどうかを調べます。 |
一般に、着信 exec セッションのデバッグは主として次のカテゴリに分けられます。
ダイヤルアップ クライアントに exec プロンプトが返されない場合。表 17-2 を参照。
ダイヤルアップ セッションに「無意味な文字」が表示される場合。 表 17-3 を参照。
ダイヤルアップが既存のセッションで開く場合。表 17-4 を参照。
ダイヤルアップ受信モデムが正常に接続解除しない場合。表 17-5 を参照。
考えられる原因 | 推奨される対策 |
---|---|
自動選択が回線で有効になっている | Enter キーを押して exec モードへのアクセスを試みます。 |
no exec コマンドが回線に設定されている |
|
フロー制御が有効にされていないまたは、フロー制御が1つのデバイス(DTEまたはDCE)でのみ有効になっている。または、フロー制御が誤って設定されている。 |
|
モデム速度の設定が固定されていない |
注:lock DTE speedコマンドは、port rate adjustまたはbufferedモードとも呼ばれ、モデムによるエラー訂正の処理方法に関連することがよくあります。このコマンドはモデムによって大きく異なります。 モデム速度をロックすることにより、モデムは Cisco アクセス サーバまたはルータに対して、常に Cisco 補助ポートに設定された速度で通信します。このコマンドを使用しない場合、モデムはデータ リンク(電話回線)の速度に戻ります。アクセス サーバに設定された速度では通信しません。 |
考えられる原因 | 推奨される対策 |
---|---|
モデム速度の設定が固定されていない |
注:lock DTE speedコマンドは、port rate adjustまたはbuffered modeとも呼ばれます。これは、モデムによるエラー訂正の処理方法によく関連しています。このコマンドはモデムによって大きく異なります。 モデム速度をロックすることにより、モデムは Cisco アクセス サーバまたはルータに対して、常に Cisco 補助ポートに設定された速度で通信します。このコマンドを使用しない場合、モデムはデータ リンク(電話回線)の速度に戻ります。アクセス サーバに設定された速度では通信しません。 |
症状:リモート ダイヤルイン セッションが、別のユーザによって開始された既存のセッション内で開きます。つまり、ログイン プロンプトを取得するのではなく、ダイヤルイン ユーザには、別のユーザによって確立されたセッションが表示されます(たとえば UNIX のコマンド プロンプト、テキスト エディタ セッション、またはその他の実行中の交換などです)。
表 7ダイヤルアップ セッションが既存のセッションで開く場合考えられる原因 | 推奨される対策 |
---|---|
モデムが DCD に対して常にハイに設定されている |
|
アクセス サーバまたはルータでモデム制御がイネーブルになっていない |
注:モデムの接続に問題がある場合は、modem ri-is-cdコマンドの代わりにmodem inoutコマンドを使用してください。後者のコマンドでは、回線で着信コールを受け取ることだけしか許可しません。発信コールは拒否されるため、モデムとの Telnet セッションを確立してモデムを設定できなくなります。modem ri-is-cd コマンドを有効にする場合は、必ずモデムが正常に機能していることを確認した上で行ってください。 |
ケーブル接続に誤りがある |
|
考えられる原因 | 推奨される対策 |
---|---|
モデムが DTR を検出していない | Hangup DTR modem コマンド文字列を入力します。このコマンドは、DTR 信号が受信されなくなったらキャリアをドロップするようにモデムに指示します。Hayes 互換モデムでは、一般に &D3 文字列を使用して、モデムで Hangup DTR を設定します。このコマンドの正確な構文については、モデムのドキュメントを参照してください。 |
ルータまたはアクセス サーバでモデム制御が有効ではない |
注:モデムの接続に問題がある場合は、modem dialinコマンドの代わりにmodem inoutコマンドを使用してください。後者のコマンドでは、回線で着信コールを受け取ることだけしか許可しません。発信コールは拒否されるため、モデムとの Telnet セッションを確立してモデムを設定できなくなります。modem dialin コマンドを有効にする場合は、必ずモデムが正常に機能していることを確認した上で行ってください。 |
表 9 は、次の形式でデバッグ コマンドに表示される ISDN 原因コードのフィールドを示したものです。
表 9ISDN の原因コードのフィールドi=0x y1 y2 z1 z2 [a1 a2]
フィールド | 値の説明 |
---|---|
0x | これに続く値は 16 進数です。 |
y1 | 8--ITU-T 標準符号化 |
y2 | 0—User 1—Private network serving local user 2—Public network serving local user 3—Transit network 4—Public network serving remote user 5—Private network serving remote user 7—International network A – インターネットワーキングポイントを超えるネットワーク |
z1 | 理由種別のクラス(上位側の 16 進数)。取り得る値の詳細については、次の表を参照してください。 |
z2 | 理由種別の値(下位側の 16 進数)。取り得る値の詳細については、次の表を参照してください。 |
a1 | (オプション)診断フィールド。常に 8 です。 |
a2 | (オプション)診断フィールド。次のいずれか 1 つの値をとります。0:不明 1:永続的 2:一時的 |
表 10 に、原因コードの第 3 バイトおよび第 4 バイトである原因情報要素の理由種別について、最もよく見られるものをいくつか説明します。
表 10ISDN 原因値値 | 原因 | 説明 |
---|---|---|
81 | 未割り当て番号 | ISDN 番号は正しい形式でスイッチに送信されました。しかし、番号がどの宛先装置にも割り当てられていません。 |
90 | 正常なコール クリア | 正常なコール クリアーが発生しました。 |
91 | ユーザ ビジー | コールされたシステムが接続要求の確認応答をしましたが、B チャネルがすべて使用中のためコールを受け入れることができません。 |
92 | ユーザ応答なし | 宛先がコールに応答しないため接続を完了できません。 |
93 | No answer from user (user alerted) | 宛先は接続要求に応答しますが、指示された時間内に接続を完了できません。接続のリモート端末に問題があります。 |
95 | コール拒否 | 宛先はコールを受け入れる余地がありますが、不明な理由のためコールを拒否しました。 |
9C | 番号形式が不正 | 宛先アドレスが認識不可能な形式で表現されていたか、または宛先アドレスが不完全だったため、接続を確立できませんでした。 |
9F | 正常、詳細不明 | 標準の原因が適用されないときの正常なイベントの発生を報告します。操作は不要です。 |
A2 | No circuit/channel available | コールを受け付けるために使用可能な適切なチャネルがないため、接続を確立できません。 |
A6 | ネットワーク故障 | ネットワークが正常に機能していない状態が一定時間以上続いたため、宛先に到達できません。今すぐ再接続しようとしても成功する可能性はほとんどありません。 |
AC | Requested circuit/channel not available | 不明な理由のため、リモート装置が要求されたチャネルを提供できません。一時的な問題である場合もあります。 |
B2 | 要求されたファシリティが未登録 | リモート装置は、登録されている場合のみ、要求された補助サービスをサポートします。多くの場合、これは長距離サービスへの参照です。 |
B9 | ベアラ機能が無許可 | ユーザはネットワークが提供する Bearer Capability を要求しましたが、ユーザにはその使用が許可されていません。登録の問題である場合もあります。 |
D8 | 互換性のない宛先 | ISDN 以外の装置(アナログ回線など)への接続が試行されたことを示します。 |
E0 | Mandatory information element is missing | 受信装置でメッセージを受信しましたが、必須情報要素の 1 つが含まれていませんでした。通常は D チャネルのエラーが原因です。このエラーがシステム的に発生する場合は、ISDN サービス プロバイダーに報告します。 |
E4 | Invalid information element contents | リモート装置でメッセージを受信しましたが、情報要素に無効な情報が含まれています。通常は D チャネルのエラーが原因です。 |
ISDN コードと値の完全な情報については、ご使用の IOS バージョンの『Cisco IOS Debug コマンド リファレンス』の ISDN スイッチ コードと値に関する章を参照してください。
改定 | 発行日 | コメント |
---|---|---|
1.0 |
09-Jul-2007 |
初版 |