内容

概要

前提条件

要件

使用するコンポーネント

履歴

表記法

非DDR 呼び出し

Cisco ダイヤルアウト ユーティリティについての注意

非DDR ダイヤルアウトのトラブルシューティング

外付け非同期モデムの非 DDR コールアウト

CAS T1/E1 非 DDR コールアウト

PRI 非DDRコール

BRI 非 DDR コールアウト

一般的な問題

デバッグセッションの確立

原因コードのフィールド

ISDN 原因値

関連情報

概要

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

- callin

- Cisco IOS ダイヤルオンデマンド ルーティング（DDR）

- 非 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 カードによって共有されるバックプレーンに挿入されていました。

表記法

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

非DDR 呼び出し

Cisco アクセス サーバから非 DDR 発信コールを行う一般的な理由がいくつかあります。

- Cisco ダイヤルアウト ユーティリティでアクセス サーバを使用する。

- アクセス サーバを、別のサーバの文字セル ダイヤルアップ セッションにアクセスするターミナル サーバとして使用する（後で手動でログインし PPP を開始する場合など）。

- モデムをテストまたは設定する（「リバース Telnet の設定」を参照）。

DDR コールアウトのトラブルシューティングと同様に、非 DDR コールアウトのトラブルシューティングで行う原因特定の一般的なフローは次のようになります。

1. リスニング ポートへの TCP 接続が成功しましたか。（「はい」の場合は次の質問に進みます。）

2. モデムが AT プロンプトを表示できますか。

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

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

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

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

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

Cisco ダイヤルアウト ユーティリティについての注意

Cisco ダイヤルアウト ユーティリティにより、Windows PC からなるコミュニティがアクセス サーバのモデム リソースを効果的に共有できます。ユーザ コミュニティに対して Cisco ダイヤルアウト ユーティリティをセットアップする一般的な手順は次のとおりです。

1. 回線設定で以下のコマンドを使用してネットワーク アクセス サーバ（NAS）をセットアップします。

line 1 16

modem InOut

rotary 1

transport input all

flowcontrol hardware

2. NAS のモデムを使用する PC に Cisco ダイヤルアウト ユーティリティをインストールします。設定を確認します。

1. 画面右下にあるダイヤルアウト ユーティリティ アイコンをダブルクリックします。

2. [More] をクリックします。

3. [Configure Port] をクリックします。

3. モデムが PC にログインできるようにしておくことも推奨されます。このためには、[Start] > [Control Panel] > [Modems] をクリックします。Cisco ダイヤルアウト モデムを選択し、[Properties] ボタンをクリックします。[Connection] タブを選択し、[Advanced] ボタンをクリックします。[Record a log file] チェックボックスをオンにします。

4. 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 ダイヤルアウトをトラブルシューティングするには、次の手順を実行します。

1. 非 DDR コールアウト（リバース Telnet の設定コールアウトなど）が初めて正常に実行されることを確認するには、debug telnet コマンドを使用して、ルータへの着信 Telnet 接続を確認します。

2. 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 コールアウト

- CAS T1/E1 非 DDR コールアウト

- PRI 非 DDR コールアウト

- BRI 非 DDR コールアウト

外付け非同期モデムの非 DDR コールアウト

外付け非同期モデムの非 DDR コールアウト（例：リバース Telnet の設定コールアウト）を確認するには、次を実行します。

1. AT コマンドを入力し、OK 応答が表示されることを確認します。OK 応答が表示されない場合は、AT&FE1Q0 コマンドを入力します。AT コマンドを再度入力し、OK 応答が表示されることを確認します。OK 応答が表示される場合、モデムの初期化が必要である可能性があります。OK 応答が表示されない場合は、ローカル非同期モデムからルータへの接続のケーブル配線、回線速度、およびパリティ設定を調べます。詳細については、『モデムとルータ間の接続ガイド』を参照してください。

2. ATM1 コマンドを使用してモデムのスピーカーの音量を上げ、ATDT <number> と入力します。

3. リモート エンドが応答しない場合は、発信元モデムからコールが発信されていることを確認するため、ATDT <number> コマンドを使用してローカル番号に手動で発信し、呼び出し音を聞きます。

4. 呼び出し音がない場合、コールは発信されていません。

発信元モデムのケーブルを交換してから、再試行します。それでも動作しない場合は、回線のハンドセットを調べます。モデムに使用していたものと同じケーブルを使用していることを確認します。新しいケーブルを接続してもハンドセットで発信コールができない場合は、通信事業者に連絡して発信元の電話回線を調べるように依頼してください。

5. モデムが予期されているとおりに発信していると思われる場合は、発信先電話番号が正しいかどうかを確認します。

ハンドセットを使用して着信番号をコールします。モデムに使用していたものと同じケーブルを使用していることを確認します。手動コールが着信番号に到達できる場合は、リモート モデムからの応答トーン（ABT）を待ちます。 コールに応答がない場合や ABT が聞こえない場合は、受信モデムが自動応答に設定されていない可能性があります。ほとんどのモデムに自動応答を指示するコマンドはATS0=1です。受信側モデムを初期化するか、デバッグする必要がある場合があります。受信側モデムが Cisco ルータに接続している場合は、詳細については『モデムとルータ間の接続ガイド』を参照してください。モデムを確認し、必要に応じて交換します。

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

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

8. 手動コールが着信側施設に到達せず、これが長距離コールである場合は、発信側で別の（確認済みの良好な）長距離番号を試してみます。

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

9. 非同期モデムが 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>

10. データが転送されていることを確認します。Return キーを数回押して、データがリモート システムとローカルセッションの間で送受信されるかどうかを確認します。データが転送されない場合は、リモート非同期モデムがリモート DTE と通信しようとしたときにケーブルまたは信号の問題が発生している可能性があります。デバッグを行い、必要に応じて交換します。

入力データに対してもう一方の側から適切な応答がある場合は、モデム接続が機能しています。

CAS T1/E1 非 DDR コールアウト

CAS T1/E1 非 DDR コールアウトを実行するには、次の手順を実行します。

1. 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 を使用します。）

2. 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 のトラブルシューティングを行う必要があります。

3. モデムが予期されているとおりに発信していると思われる場合は、発信先電話番号が正しいかどうかを確認します。

ハンドセットを使用して着信番号をコールします。手動コールが着信番号に到達できる場合は、リモート モデムからの応答トーン（ABT）を待ちます。 コールに応答がない場合や ABT が聞こえない場合は、受信モデムが自動応答に設定されていない可能性があります。ほとんどのモデムに自動応答を指示するコマンドはATS0=1です。受信側モデムを初期化するか、デバッグする必要がある場合があります。受信側モデムが Cisco ルータに接続している場合は、詳細については『モデムとルータ間の接続ガイド』を参照してください。モデムを確認し、必要に応じて交換します。

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

5. 長距離コールの場合、発信元で別の（確認済みの良好な）長距離番号を試してみます。

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

6. 非同期モデムが 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>

7. データが転送されていることを確認します。

Return キーを数回押して、データがリモート システムとローカルセッションの間で送受信されるかどうかを確認します。データが転送されない場合は、リモート非同期モデムがリモート DTE と通信しようとしたときにケーブルまたは信号の問題が発生している可能性があります。デバッグを行い、必要に応じて交換します。

入力データに対してもう一方の側から適切な応答がある場合は、モデム接続が機能しています。

PRI 非DDRコール

PRI 非 DDR コールアウトを実行するには、次の手順を実行します。

1. PRI 非同期モデム非 DDR コールアウトを診断し、次のコマンドを使用してから、コール発信を試行します。

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

router# debug modem

router# debug modem csm

router# debug isdn q931

router# debug isdn

2. 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」を参照してください。

3. モデムが予期されているとおりに発信していると思われる場合は、発信先電話番号が正しいかどうかを確認します。

ハンドセットを使用して着信番号をコールします。手動コールが着信番号に到達できる場合は、リモート モデムからの応答トーン（ABT）を待ちます。 コールに応答がない場合や ABT が聞こえない場合は、受信モデムが自動応答に設定されていない可能性があります。ほとんどのモデムに自動応答を指示するコマンドはATS0=1です。受信側モデムを初期化するか、デバッグする必要がある場合があります。受信側モデムが Cisco ルータに接続している場合は、詳細については『モデムとルータ間の接続ガイド』を参照してください。モデムを確認し、必要に応じて交換します。

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

5. 長距離コールの場合、発信元で別の（確認済みの良好な）長距離番号を試してみます。

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

6. 非同期モデムが 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>

7. データが転送されていることを確認します。

Return キーを数回押して、データがリモート システムとローカルセッションの間で送受信されるかどうかを確認します。データが転送されない場合は、リモート非同期モデムがリモート DTE と通信しようとしたときにケーブルまたは信号の問題が発生している可能性があります。デバッグを行い、必要に応じて交換します。

入力データに対してもう一方の側から適切な応答がある場合は、モデム接続が機能しています。

BRI 非 DDR コールアウト

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

1. PRI 非同期モデム非 DDR コールアウトを診断し、次のコマンドを使用してから、コール発信を試行します。

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

router# debug modem

router# debug modem csm

router# debug isdn q931

router# debug isdn

2. 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」を参照してください。

3. モデムが予期されているとおりに発信していると思われる場合は、発信先電話番号が正しいかどうかを確認します。

ハンドセットを使用して着信番号をコールします。手動コールが着信番号に到達できる場合は、リモート モデムからの応答トーン（ABT）を待ちます。 コールに応答がない場合や ABT が聞こえない場合は、受信モデムが自動応答に設定されていない可能性があります。ほとんどのモデムに自動応答を指示するコマンドはATS0=1です。受信側モデムを初期化するか、デバッグする必要がある場合があります。受信側モデムが Cisco ルータに接続している場合は、詳細については『モデムとルータ間の接続ガイド』を参照してください。モデムを確認し、必要に応じて交換します。

4. 手動コールが当該回線で通常の電話機に到達しない場合は、着信側施設の別の（確認済みの良好な）回線を使用してみます。

正常に接続したら、着信側モデムに接続する電話回線の検査を電話会社に依頼します。

5. 長距離コールの場合、発信元で別の（確認済みの良好な）長距離番号を試してみます。

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

6. 非同期モデムが 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>

7. データが転送されていることを確認します。

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：モデムがデータを送信または受信できない場合

考えられる原因

推奨される対策

モデム速度の設定が固定されていない

1. アクセス サーバまたはルータで show line exec コマンドを使用します。補助ポートの出力は、現在設定されている Tx および Rx の速度を示します。show line コマンドの出力の詳細については、「debug コマンドの使用方法」を参照してください。

2. 回線が正しい速度に設定されていない場合は、speed 回線設定コマンドを使用し、アクセス サーバまたはルータの回線の回線速度を設定します。モデムと、アクセス サーバまたはルータのポートとの間で共通の最高速度に設定します。端末のボー レートを設定するには、speed 回線設定コマンドを使用します。このコマンドは、送信（端末へ）と受信（端末から）の両方の速度を設定します。構文：speed bps 構文の説明：bps?ビット/秒（bps）でのボーレート。 デフォルトは 9600 bps です。例：次の例は、Cisco 2509 アクセス サーバの回線 1 および 2 を 115200 bps に設定します。line 1 2 speed 115200
注：何らかの理由でフロー制御を使用できない場合は、回線速度を9600 bpsに制限してください。これ以上速い速度の場合、データが失われる可能性があります。

3. 再度 show line exec コマンドを使用し、回線速度が望ましい値に設定されたことを確認します。

4. アクセス サーバまたはルータの回線が望ましい速度に設定されていることを確認したら、その回線を経由してモデムへのリバース Telnet セッションを開始します。詳細については、「リバース Telnet の設定」を参照してください。

5. 使用しているモデム用の lock DTE speed コマンドを含むモデム コマンド文字列を使用します。設定コマンドの正確な構文については、使用中のモデムのドキュメントを参照してください。
注：lock DTE speedコマンドは、port rate adjustまたはbufferedモードとも呼ばれて、モデムによるエラー訂正の処理方法に関連することがよくあります。このコマンドはモデムによって大きく異なります。
モデム速度をロックすることにより、モデムは Cisco アクセス サーバまたはルータに対して、常に Cisco 補助ポートに設定された速度で通信します。このコマンドを使用しない場合、モデムはデータ リンク（電話回線）の速度に戻ります。アクセス サーバに設定された速度では通信しません。

ハードウェア フロー制御がローカルまたはリモートのモデムまたはルータで設定されていない

1. show line aux-line-number exec コマンドを使用し、Capabilities フィールドにある次の記述を探します。
Capabilities: Hardware Flowcontrol In,

Hardware Flowcontrol Out
詳細については「show line 出力の解釈」を参照してください。このフィールドにハードウェア フロー制御に関する記述がない場合、ハードウェア フロー制御が回線で有効にされていません。アクセス サーバからモデムへの接続については、ハードウェア フロー制御を使用することをお勧めします。show line コマンドの出力の詳細については、「debug コマンドの使用方法」を参照してください。

2. 回線のハードウェア フロー制御を設定するには、flowcontrol hardware 回線設定コマンドを使用します。端末またはその他のシリアル デバイスとルータとの間におけるデータのフロー制御の方式を設定するには、flowcontrol 回線設定コマンドを使用します。フロー制御を無効にするには、このコマンドの no 形式を使用します。構文：flowcontrol {none | software [lock] [in] |送信] | hardware [in] | out]}構文の説明:なし：フロー制御をオフにします。ソフトウェア：ソフトウェアフロー制御を設定します。オプションのキーワードは方向を指定します。in を指定すると、Cisco IOS ソフトウェアは接続デバイスからのフロー制御を受信します。out を指定すると、Cisco IOS ソフトウェアはフロー制御情報を接続デバイスに送信します。方向を指定しない場合は両方向と見なされます。ロック：接続されたデバイスがソフトウェアフロー制御を必要とするときに、リモートホストからのフロー制御をオフにできないようにします。このオプションは Telnet または rlogin のプロトコルを使用した接続に適用されます。ハードウェア：ハードウェアフロー制御を設定します。オプションのキーワードは方向を指定します。in を指定すると、ソフトウェアは接続デバイスからのフロー制御を受信します。out を指定すると、ソフトウェアはフロー制御情報を接続デバイスに送信します。方向を指定しない場合は両方向と見なされます。ハードウェア フロー制御の詳細については、ルータに付属しているハードウェアのマニュアルを参照してください。例：次の例は、回線 7 でハードウェア フロー制御を設定します。line 7 flowcontrol hardware
注：何らかの理由でフロー制御を使用できない場合は、回線速度を9600 bpsに制限してください。これ以上速い速度の場合、データが失われる可能性があります。

3. アクセス サーバまたはルータの回線でハードウェア フロー制御を有効にした後、その回線を経由してモデムへのリバース Telnet セッションを開始します。詳細については、「リバース Telnet の設定」を参照してください。

4. 使用しているモデム用の RTS/CTS Flow コマンドを含むモデム コマンド文字列を使用します。このコマンドにより、モデムは Cisco アクセス サーバまたはルータと同じフロー制御方式（つまり、ハードウェア フロー制御）を使用します。設定コマンドの正確な構文については、使用中のモデムのドキュメントを参照してください。

誤った dialer map コマンドの設定

1. show running-config privileged exec コマンドを使用してルータの設定を表示します。dialer map コマンドのエントリを調べ、broadcast キーワードが指定されているかどうかを調べます。

2. キーワードがない場合は設定に追加します。構文：dialer map protocol next-hop-address [name hostname] [broadcast] [dial-string] 構文の説明：protocol：マッピングの対象となるプロトコルです。IP、IPX、ブリッジ、およびスナップショットから選択できます。next-hop-address：相手サイトの非同期インターフェイスのプロトコル アドレスです。name hostname：PPP 認証で使用される必須パラメータです。ダイヤラ マップの作成対象となるリモート サイトの名前を指定します。この名前は大文字小文字が区別され、リモート ルータのホスト名と一致する必要があります。broadcast：リモート接続先に転送されるパケット（IP RIPやIPX RIP/SAPのアップデートなど）をブロードキャストするオプションのキーワード。スタティック ルーティングの設定例では、ルーティング アップデートは必要とされておらず、broadcast キーワードは省略されています。dial-string：リモート サイトの電話番号です。アクセス コード（外線につなぐための 9、国際局番、市内局番など）をすべて含める必要があります。

3. dialer map コマンドで正しいネクストホップ アドレスを指定していることを確認します。

4. ネクストホップ アドレスが正しくない場合は、dialer map コマンドを使用して変更します。

5. dialer map コマンド内にある他のすべてのオプションが、使用しているプロトコルに対して正しく指定されていることを確認します。

ダイヤラ マップの設定の詳細については、『Cisco IOS Wide-Area Networking 設定ガイド』および『Wide-Area Networking コマンド リファレンス』を参照してください。

ダイヤリング モデムに関する問題

ダイヤリング モデムが稼働状態にあり、正しいポートに確実に接続していることを確認します。同じポートに接続している別のモデムが動作しているかどうかを調べます。

一般に、着信 exec セッションのデバッグは主として次のカテゴリに分けられます。

- ダイヤルアップ クライアントに exec プロンプトが返されない場合。表 17-2 を参照。

- ダイヤルアップ セッションに「無意味な文字」が表示される場合。 表 17-3 を参照。

- ダイヤルアップが既存のセッションで開く場合。表 17-4 を参照。

- ダイヤルアップ受信モデムが正常に接続解除しない場合。表 17-5 を参照。

表 5ダイヤルアップ クライアントに exec プロンプトが返されない場合

考えられる原因

推奨される対策

自動選択が回線で有効になっている

Enter キーを押して exec モードへのアクセスを試みます。

no exec コマンドが回線に設定されている

1. show line exec コマンドを使用し、該当する回線のステータスを表示します。[Capabilities] フィールドに「exec suppressed」と表示されているかどうかを調べます。 表示がある場合は、no exec 回線設定コマンドが有効にされています。

2. 回線で exec 回線設定コマンドを設定し、exec セッションを開始できるようにします。このコマンドには引数やキーワードはありません。

例：
次の例は、回線 7 で exec をオンにします。line 7 exec

フロー制御が有効にされていないまたは、フロー制御が1つのデバイス（DTEまたはDCE）でのみ有効になっている。または、フロー制御が誤って設定されている。

1. show line aux-line-number exec コマンドを使用し、Capabilities フィールドにある次の記述を探します。
Capabilities: Hardware Flowcontrol In,

Hardware Flowcontrol Out

詳細については「show line 出力の解釈」を参照してください。このフィールドにハードウェア フロー制御に関する記述がない場合、ハードウェア フロー制御が回線で有効にされていません。アクセス サーバからモデムへの接続については、ハードウェア フロー制御を使用することをお勧めします。show line コマンドの出力の詳細については、「debug コマンドの使用方法」を参照してください。

2. 回線のハードウェア フロー制御を設定するには、flowcontrol hardware 回線設定コマンドを使用します。例：次の例は、回線 7 でハードウェア フロー制御を設定します。line 7 flowcontrol hardware
注：何らかの理由でフロー制御を使用できない場合は、回線速度を9600 bpsに制限してください。これ以上速い速度の場合、データが失われる可能性があります。

3. アクセス サーバまたはルータの回線でハードウェア フロー制御を有効にした後、その回線を経由してモデムへのリバース Telnet セッションを開始します。詳細については、「リバース Telnet の設定」を参照してください。

4. 使用しているモデム用の RTS/CTS Flow コマンドを含むモデム コマンド文字列を使用します。このコマンドにより、モデムは Cisco アクセス サーバまたはルータと同じフロー制御方式（ハードウェア フロー制御）を使用します。設定コマンドの正確な構文については、使用中のモデムのドキュメントを参照してください。

モデム速度の設定が固定されていない

1. アクセス サーバまたはルータで show line exec コマンドを使用します。補助ポートの出力は、現在設定されている Tx および Rx の速度を示します。show line コマンドの出力の詳細については、15 章の「debug コマンドの使用方法」の項を参照してください。

2. 回線が正しい速度に設定されていない場合は、speed 回線設定コマンドを使用し、アクセス サーバまたはルータの回線の回線速度を設定します。モデムと、アクセス サーバまたはルータのポートとの間で共通の最高速度に設定します。端末のボー レートを設定するには、speed 回線設定コマンドを使用します。このコマンドは、送信（端末へ）と受信（端末から）の両方の速度を設定します。構文：speed bps 構文の説明：bps：ビット/秒(bps)単位のボーレート。 デフォルトは 9600 bps です。例：次の例は、Cisco 2509 アクセス サーバの回線 1 および 2 を 115200 bps に設定します。line 1 2 speed 115200
注：何らかの理由でフロー制御を使用できない場合は、回線速度を9600 bpsに制限してください。これ以上速い速度の場合、データが失われる可能性があります。

3. 再度 show line exec コマンドを使用し、回線速度が望ましい値に設定されたことを確認します。

4. アクセス サーバまたはルータの回線が望ましい速度に設定されていることを確認したら、その回線を経由してモデムへのリバース Telnet セッションを開始します。詳細については、「リバース Telnet の設定」を参照してください。

5. 使用しているモデム用の lock DTE speed コマンドを含むモデム コマンド文字列を使用します。設定コマンドの正確な構文については、使用中のモデムのドキュメントを参照してください。

注：lock DTE speedコマンドは、port rate adjustまたはbufferedモードとも呼ばれ、モデムによるエラー訂正の処理方法に関連することがよくあります。このコマンドはモデムによって大きく異なります。
モデム速度をロックすることにより、モデムは Cisco アクセス サーバまたはルータに対して、常に Cisco 補助ポートに設定された速度で通信します。このコマンドを使用しない場合、モデムはデータ リンク（電話回線）の速度に戻ります。アクセス サーバに設定された速度では通信しません。

表 6ダイヤルアップ セッションに「無意味な文字」が表示される場合

考えられる原因

推奨される対策

モデム速度の設定が固定されていない

1. アクセス サーバまたはルータで show line exec コマンドを使用します。補助ポートの出力は、現在設定されている Tx および Rx の速度を示します。show line コマンドの出力の詳細については、15 章の「debug コマンドの使用方法」の項を参照してください。

2. 回線が正しい速度に設定されていない場合は、speed 回線設定コマンドを使用し、アクセス サーバまたはルータの回線の回線速度を設定します。モデムと、アクセス サーバまたはルータのポートとの間で共通の最高速度に設定します。端末のボー レートを設定するには、speed 回線設定コマンドを使用します。このコマンドは、送信（端末へ）と受信（端末から）の両方の速度を設定します。構文：speed bps 構文の説明：bps：ビット/秒(bps)単位のボーレート。 デフォルトは 9600 bps です。例：次の例は、Cisco 2509 アクセス サーバの回線 1 および 2 を 115200 bps に設定します。 line 1 2 speed 115200
注：何らかの理由でフロー制御を使用できない場合は、回線速度を9600 bpsに制限してください。これ以上速い速度の場合、データが失われる可能性があります。

3. 再度 show line exec コマンドを使用し、回線速度が望ましい値に設定されたことを確認します。

4. アクセス サーバまたはルータの回線が望ましい速度に設定されていることを確認したら、その回線を経由してモデムへのリバース Telnet セッションを開始します。詳細については、「リバース Telnet の設定」を参照してください。

5. 使用しているモデム用の lock DTE speed コマンドを含むモデム コマンド文字列を使用します。設定コマンドの正確な構文については、使用中のモデムのドキュメントを参照してください。

注：lock DTE speedコマンドは、port rate adjustまたはbuffered modeとも呼ばれます。これは、モデムによるエラー訂正の処理方法によく関連しています。このコマンドはモデムによって大きく異なります。
モデム速度をロックすることにより、モデムは Cisco アクセス サーバまたはルータに対して、常に Cisco 補助ポートに設定された速度で通信します。このコマンドを使用しない場合、モデムはデータ リンク（電話回線）の速度に戻ります。アクセス サーバに設定された速度では通信しません。

症状：リモート ダイヤルイン セッションが、別のユーザによって開始された既存のセッション内で開きます。つまり、ログイン プロンプトを取得するのではなく、ダイヤルイン ユーザには、別のユーザによって確立されたセッションが表示されます（たとえば UNIX のコマンド プロンプト、テキスト エディタ セッション、またはその他の実行中の交換などです）。

表 7ダイヤルアップ セッションが既存のセッションで開く場合

考えられる原因

推奨される対策

モデムが DCD に対して常にハイに設定されている

1. 1 つの CD に対してだけ、DCD がハイになるようにモデムを再設定します。通常は &C1 モデム コマンド文字列を使用しますが、ご使用のモデムに対応する正確な構文については、モデムのマニュアルを参照してください。

2. no exec 回線設定コマンドを使用して、モデムが接続されているアクセス サーバ回線を設定する必要がある場合があります。clear line 特権 EXEC コマンドで回線をクリアし、モデムとのリバース Telnet セッションを開始して、DCD が CD に対してだけハイになるようにモデムを再設定します。

3. disconnect と入力して Telnet セッションを終了し、exec 回線設定コマンドでアクセス サーバ回線を再設定します。

アクセス サーバまたはルータでモデム制御がイネーブルになっていない

1. アクセス サーバまたはルータで show line exec コマンドを使用します。補助ポートの出力の Modem のカラムには inout または RIisCD と表示されます。これは、アクセス サーバまたはルータの回線でモデム制御がイネーブルになっていることを示します。show line の出力の詳細については、「debug コマンドの使用方法」を参照してください。

2. modem inout 回線設定コマンドを使用して、回線をモデム制御用に設定します。これで、アクセス サーバでモデム制御が有効になります。

注：モデムの接続に問題がある場合は、modem ri-is-cdコマンドの代わりにmodem inoutコマンドを使用してください。後者のコマンドでは、回線で着信コールを受け取ることだけしか許可しません。発信コールは拒否されるため、モデムとの Telnet セッションを確立してモデムを設定できなくなります。modem ri-is-cd コマンドを有効にする場合は、必ずモデムが正常に機能していることを確認した上で行ってください。

ケーブル接続に誤りがある

1. モデムとアクセス サーバまたはルータ間のケーブル接続をチェックします。モデムがロール型 RJ-45 ケーブルと MMOD DB-25 アダプタを通じてアクセス サーバまたはルータの補助ポートに接続されていることを確認します。Cisco では RJ-45 ポートについて、このケーブル構成を推奨およびサポートしています。（これらのコネクタには通常「Modem」というラベルが付いています。）RJ-45 ケーブルには、次の 2 つのタイプがあります。ストレート型とロール型です。RJ-45 ケーブルの 2 つの端子を並べると、8 個の色付きのピンが双方の端子にあります色の付いたピンの順番が両端で同一である場合には、そのケーブルはストレートです。色の付いたピンの順番が両端で反対であれば、それはロール型ケーブルになります。Cisco 2500/CS500 では、ロール型ケーブル（CAB-500RJ）が標準です。

2. show line EXEC コマンドを使用してケーブル接続が正しいことを確認します。show line コマンド出力の説明は、「debug コマンドの使用方法」を参照してください。

表 8：ダイヤルアップ受信モデムが正常に接続解除しない場合

考えられる原因

推奨される対策

モデムが DTR を検出していない

Hangup DTR modem コマンド文字列を入力します。このコマンドは、DTR 信号が受信されなくなったらキャリアをドロップするようにモデムに指示します。Hayes 互換モデムでは、一般に &D3 文字列を使用して、モデムで Hangup DTR を設定します。このコマンドの正確な構文については、モデムのドキュメントを参照してください。

ルータまたはアクセス サーバでモデム制御が有効ではない

1. アクセス サーバまたはルータで show line exec コマンドを使用します。補助ポートの出力の [Modem] カラムには inout または RIisCD と表示されます。これは、アクセス サーバまたはルータの回線でモデム制御がイネーブルになっていることを示します。show line の出力の詳細については、「debug コマンドの使用方法」を参照してください。

2. modem inout 回線設定コマンドを使用して、回線をモデム制御用に設定します。これで、アクセス サーバでモデム制御が有効になります。

注：モデムの接続に問題がある場合は、modem dialinコマンドの代わりにmodem inoutコマンドを使用してください。後者のコマンドでは、回線で着信コールを受け取ることだけしか許可しません。発信コールは拒否されるため、モデムとの Telnet セッションを確立してモデムを設定できなくなります。modem dialin コマンドを有効にする場合は、必ずモデムが正常に機能していることを確認した上で行ってください。

原因コードのフィールド

表 9 は、次の形式でデバッグ コマンドに表示される ISDN 原因コードのフィールドを示したものです。

i=0x y1 y2 z1 z2 [a1 a2]

表 9ISDN の原因コードのフィールド

フィールド

値の説明

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：一時的

ISDN 原因値

表 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 スイッチ コードと値に関する章を参照してください。

関連情報

- Cisco IOS ダイヤル サービス クイック コンフィギュレーション ガイド

- Cisco IOS ダイヤル サービス コンフィギュレーション ガイド：ネットワーク サービス

- Cisco IOS ダイヤル サービス コンフィギュレーション ガイド：Terminal Services

- Cisco IOS ダイヤル サービス コマンド リファレンス

- ダイヤル ケース スタディの概要

- テクノロジー ページへのアクセス

- テクニカル サポートとドキュメント – Cisco Systems