ダイヤルとアクセス : ダイヤルオンデマンド ルーティング(DDR)

ダイヤル技術接続のトラブルシューティング - 非DDRコールアウト

2016 年 10 月 27 日 - 機械翻訳について
その他のバージョン: PDFpdf | 英語版 (2015 年 8 月 22 日) | フィードバック


目次


概要

このドキュメントでは、さまざまなダイヤル接続のタイプのトラブルシューティング方法を提供しており、最初から最後まで読むことを目的とはしていません。 この構成は、読者が関心のある項に進めるように設計されており、それぞれが特定のケースの全体的なトラブルシューティングのテーマのバリエーションになっています。 このドキュメントでは、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 の着信接続を処理できました。 2 つの PRI が導入された AS5200 はデジタル モデムを使用して 48 のユーザをサポート可能であり、収容効率が飛躍的に向上しました。 AS5300 では PRI のサポートが 4 から 8 に増え、モデム密度が着実に増加していきました。 最終的に、数十の T1 回線と数百のユーザ接続を処理する通信事業者クラスの設置ニーズに対応するため、AS5800 が導入されました。

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

表記法

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

非 DDR 呼び出し

Cisco access サーバからの非 DDR アウトバウンドコールをする少数の一般的 な 原因があります:

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

  • アクセス サーバを手動で ログインおよび開始する PPP 以降に別のサーバのキャラクタ セル ダイヤルアップセッションに、多分アクセスするのにターミナル サーバとして使用するため。

  • モデムを設定するためテストするか、または(逆 Telnet の設定を参照して下さい)。

DDR 引き出しの解決に類似した、非DDR コールアウトを解決するための推論の一般的なフローは次に類似しています:

  1. リスニングポートへの TCP 接続は正常ですか。 (A は次 の 質問にはい進みます)

  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. 画面の右下で Dialout ユーティリティ アイコンをダブルクリックして下さい。

    2. 『More』 をクリック して下さい。

    3. 『Configure Ports』 をクリック して下さい。

  3. PC をログオンするモデムを有効に してまた提案されます。 これは Start > Control Panel の順にクリック することによって > モデム実行されます。 Cisco ダイヤルアウト モデムを選択し、Properties ボタンをクリックして下さい。 Connection タブを選択し、そして Advanced ボタンをクリックして下さい。 Record a log file チェックボックスを選択して下さい。

  4. Cisco ダイヤルアウト COMポートを使用するために PC の Dial Up Networking を設定して下さい。

Ciscoダイヤルアウト ユーティリティ用のポート番号選択についての少数の必要な情報があります。 デフォルトで、それは TCPポート 6001 を使用するために試みます。 これはそれが発信 NAS の唯一のユーザであることを意味します。 これは普通事実ではないので、ロータリー機能を利用するのに 7001 を使用することがより適切です。 TCP リスナープロセスはラインコンフィギュレーションに transport input コマンドを置くことによって作成されます。 さまざまな IP ポート番号範囲がすることをの表はここにあります:

表 3: 「トランスポート入力」コマンドによる TCP リスナー ポート セットアップ

2000 Telnet プロトコル
3000 Telnet プロトコル、ロータリー付き
4000 ロー TCP プロトコル
5000 ロー TCP プロトコル、ロータリー付き
6000 Telnet プロトコル、バイナリ モード
7000 Telnet プロトコル、バイナリ モード、ロータリー付き
9000 Xremote プロトコル
10000 XRemote プロトコル、ロータリー付き

ロータリー割り当て特定のポートへの受信 TCP 接続をし、現在利用できるロータリグループ数を備えているモデムに接続を終了する誰か。 上の例では、ロータリグループは 3001、5001、7001、および 10001 のリスナーを設定しました。 Ciscoダイヤルアウト ユーティリティはバイナリモードを使用します、従って 7001 は PC で使用するためにクライアント プログラムを設定する正しい数です。

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

非 DDR ダイヤルアウトを解決するためにこれらのステップを試して下さい。

  1. 非DDR コールアウトの最初の成功を視聴するために(たとえば、設定逆 Telnet 呼び出し)、ルータへの着信Telnet 接続を見る debug telnet コマンドを使用して下さい。

  2. TCP 接続が拒否される場合、リスナーは特定のアドレスにないし、ポートか誰かはそのポートに既に接続されています。 接続している確認し、ポート番号を確認して下さいアドレスを。

    また、モデム inout (か modem dtr-active を)確認すれば transport input all コマンドは達するラインのためのラインコンフィギュレーションの下で現われます。 ロータリー機能を使用している場合、ロータリー 1 (またはどんな数を選択した)コマンドをまた現われますラインコンフィギュレーションに確認して下さい。 誰かが接続されるかどうか見るために、ルータに Telnet で接続し、show line コマンドを使用して下さい。 行が使用中であることを示すためにアスタリスクを探して下さい。 また、Clear To Send (CTS)を確認する show line n コマンドを高いです使用すれば Data Set Ready (DSR)はありません。 そのポート番号の現在のセッションを切断する clear line n コマンドを使用して下さい。

この時点で、telnet ははたらく必要があります。 次に、アウトバウンド接続のために使用しているメディアの種類を識別して下さい:

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

外付け非同期モデム の 非DDR コールアウトを識別するために(たとえば、逆 Telnet 引き出しを設定します)、次を行って下さい:

  1. AT コマンドを入力し、OK 応答が表示されることを確認します。 良い応答が現われない場合、At&fe1q0 コマンドを入力して下さい。 良い応答が現われるかどうかもう一度見る AT コマンドを入力して下さい。 良い応答が現われる場合、モデムは初期化される必要がある場合もあります。 それでも良い応答がない場合、ルータ接続にローカル 非同期 モデムのケーブル接続、ラインスピードおよびパリティ設定を確認して下さい。 それ以上の参照に関しては、モデムとルータの接続ガイドを参照して下さい。

  2. ターンアップは Atm1 コマンドでモデムのスピーカーの音量 ATDT <number を > 入力し。

  3. リモート エンドが答えないようではない場合コールがローカル 番号を手動で呼出すことによる発信モデムによってリングをことを聞き取るコマンド ATDT <number >and と送信されていることを確認して下さい。

  4. リングがない場合、コールは出ていません。

    発信モデムのケーブルおよび試みを再度交換して下さい。 それがそれでもはたらかない場合、行の受話器を試みて下さい。 モデムが使用していたこと同じケーブルを使用することを忘れないでいて下さい。 受話器が新しいケーブルのアウトバウンドコールを作れなければ場合発生電話線をチェックするために電話会社に連絡して下さい。

  5. モデムが呼び出しを予想通り送信するようである場合呼出された電話番号が正しいことを確認して下さい。

    ハンドセットを使用して着信番号をコールします。 モデムが使用していたこと同じケーブルを使用することを忘れないでいて下さい。 マニュアルコールが受信数に連絡できれば場合応答トーン(ABT)を提供するためにリモートモデムを聞き取って下さい。 コールが未解答に行くかまたは ABT が聞かれなければ、受信モデムは自動応答するために設定 されないかもしれません。 自動応答するようにほとんどのモデムを言うコマンドは ATS0=1 です。 受信モデムは初期化されるか、またはデバッグされる必要がある場合もあります。 受信モデムが Ciscoルータに接続される場合、更に詳しい情報についてはモデムとルータの接続ガイドを参照して下さい。 モデムを確認し、必要に応じて取り替えて下さい。

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

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

  8. マニュアルコールが受信ファシリティに達できなければし、これが長距離電話場合、発信側を別の(既知よい)長距離番号を試みてもらって下さい。

    この番号で通話できる場合は、着信側施設または回線が長距離コールを受信するようにプロビジョニングされていない可能性があります。 起点 ラインが他のどの長距離番号にも連絡できない場合長距離を有効に してもらわないかもしれません。 別の長距離通話会社で 10-10 コードを試行します。

  9. 非同期モデムがトレインするようにして下さい。

    非同期モデムがトレインしない場合、手動で数を呼出し、スタティックを聞き取って下さい。 他の要素が trainup と干渉している可能性があります。 接続される DTE と受信モデム間にケーブル問題があるかもしれません。 トレインアップ障害は本当らしいです回線か非互換性問題。 これのいくつかはモデムのより少ない「積極的な」速度にそれらを制限する離調によって直すことができます。 手法の一例として、llet の試み Cisco のテストシステムの 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. データがフローしていることを確認して下さい。 リターン キーをデータがリモート システムからローカルセッションにあちこちにフローしているかどうか見る数回押して下さい。 データがフローしない場合、リモート非同期モデムがリモート 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?? ソフトウェア リリース 12.0(7)T 以降が稼働する Cisco AS5200 および AS5300 プラットフォームで使用できます。 以前のバージョンの IOS では、service internal コマンドをルータのコンフィギュレーションのメイン レベルに入力し、modem-mgmt csm debug-rbs を exec プロンプトで入力する必要がありました。 RBS Cisco AS5800 のデバッグはトランクカードに接続を必要とします。 (デバッグをオフにするには modem-mgmt csm no-debug-rbs を使用します。)

  2. AT コマンドを入力し、良い応答が現われるようにして下さい。

    良い応答が現われない場合、At&f コマンドを入力して下さい。 良い応答が現われるかどうかもう一度見る AT コマンドを入力して下さい。 良い応答が現われる場合、モデムは初期化される必要がある場合もあります。 それでも良い応答がない場合、モデムモジュールに問題があるかもしれません。 コールを発信するには、その前にモデムをコール用に割り当てておく必要があります。 このプロセスおよび後に続くコールを表示するために、これが起こっているかどうか判別するのにデバッグ 出力を使用して下さい。 次に、例を示します。

    デバッグをつけること:

    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 におけるデバッグも同様です。

    デバッグのこのポイントへの到達は呼出すことおよび応答モデムがトレインし、接続されたことを示します。 モデムが発信コール用に正しく割り当てられているにもかかわらず、この時点で接続が失敗する場合は、T1 を調べる必要があります。 show controller t1/e1 コマンドを使用して、T1/E1 が機能していることを確認します。 show controller 出力の explantion についてはトラブルシューティング シリアルラインを参照して下さい。 T1/E1 がきちんとはたらかない場合、T1/e1 のトラブルシューティングは必要です。

  3. モデムが呼び出しを予想通り送信するようである場合呼出された電話番号が正しいことを確認して下さい。

    ハンドセットを使用して着信番号をコールします。 マニュアルコールが受信数に連絡できれば場合応答トーン(ABT)を提供するためにリモートモデムを聞き取って下さい。 コールが未解答に行くかまたは ABT が聞かれなければ、受信モデムは自動応答するために設定 されないかもしれません。 自動応答するようにほとんどのモデムを言うコマンドは ATS0=1 です。 受信モデムは初期化されるか、またはデバッグされる必要がある場合もあります。 受信モデムが Ciscoルータに接続される場合、更に詳しい情報についてはモデムとルータの接続ガイドを参照して下さい。 モデムを確認し、必要に応じて取り替えて下さい。

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

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

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

  6. 非同期モデムがトレインするようにして下さい。

    非同期モデムがトレインしない場合、手動で数を呼出し、スタティックを聞き取って下さい。 他の要素が trainup と干渉している可能性があります。 接続される DTE と受信モデム間にケーブル問題があるかもしれません。 トレインアップ障害は本当らしいです回線か非互換性問題。 これのいくつかはモデムのより少ない「積極的な」速度にそれらを制限する離調によって直すことができます。 手法の一例として、Cisco のテストシステムの 1 つへの接続を試みよう。

    at
    OK 

    次に静的なラボにダイアルインします:

    at
    OK
    atdt914085703932
    NO CARRIER

    正常な接続は失敗するようです。 この場合それがノイズ多発回線でしたり、従ってにスピーカー(m1 を)始動させ、モデムを(S56=28800)次のコマンドと 28.8 でキャップするためモデムを工場出荷時状態(&f)置こうことをわかっています:

    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. データがフローしていることを確認して下さい。

    リターン キーをデータがリモート システムからローカルセッションにあちこちにフローしているかどうか見る数回押して下さい。 データがフローしない場合、リモート非同期モデムがリモート DTE と交信を行うことを試みるときケーブルまたはシグナルの問題があるかもしれません。 デバッグし、必要に応じて取り替えて下さい。

データを入力することが反対側から適度な応答がある場合、モデム接続ははたらいています。

PRI 非DDRコール

PRI 非DDR コールアウトを行うために次の手順に従って下さい。

  1. PRI async modem Non-DDR CallOut を診断して下さい、次のコマンドを使用し、そしてコールを作ることを試みて下さい:

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

    router# debug modem
    router# debug modem csm
    router# debug isdn q931
    router# debug isdn
    
  2. AT コマンドを入力し、良い応答が現われるようにして下さい。

    良い応答が現われない場合、At&f コマンドを入力して下さい。 良い応答が現われるかどうかもう一度見る AT コマンドを入力して下さい。 良い応答が現われる場合、モデムは modemcap を初期化されるのに使用する必要がある場合もあります。 これは xxx がモデムタイプであるところでコマンド modem autoconfigure type xxx を使用することを含みます。 それでも良い応答がない場合、モデムモジュールに問題があるかもしれません。 モデムが手動で ダイヤルをことを始めることによってコールを送信できることを確認して下さい。 リモート エンドが答えないようではない場合コールがローカル 番号を > 手動で呼出し、リングをことを聞き取ることによるモデムによってコマンド 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 と干渉している可能性があります。 接続される DTE と受信モデム間にケーブル問題があるかもしれません。 トレインアップ障害は本当らしいです回線か非互換性問題。 これのいくつかはモデムのより少ない「積極的な」速度にそれらを制限する離調によって直すことができます。 手法の一例として、Cisco のテストシステムの 1 つへの接続を試みよう。

    at
    OK

    次に静的なラボにダイアルインします:

    at
    OK
    atdt914085703932
    NO CARRIER

    正常な接続は失敗するようです。 この場合それがノイズ多発回線でしたり、従ってにスピーカー(m1 を)始動させ、モデムを(S56=28800)次のコマンドと 28.8 でキャップするためモデムを工場出荷時状態(&f)置こうことをわかっています:

    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. データがフローしていることを確認して下さい。

    リターン キーをデータがリモート システムからローカルセッションにあちこちにフローしているかどうか見る数回押して下さい。 データがフローしない場合、リモート非同期モデムがリモート DTE と交信を行うことを試みるときケーブルまたはシグナルの問題があるかもしれません。 デバッグし、必要に応じて取り替えて下さい。

データを入力することが反対側から適度な応答がある場合、モデム接続ははたらいています。

BRI 非DDR 呼び出し

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

  1. PRI async modem Non-DDR CallOut を診断して下さい、次のコマンドを使用し、そしてコールを作ることを試みて下さい:

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

    router# debug modem
    router# debug modem csm
    router# debug isdn q931
    router# debug isdn
    
  2. AT コマンドを入力し、良い応答が現われるようにして下さい。

    AT コマンドを入力し、良い応答が現われるようにして下さい。 良い応答が現われない場合、At&f コマンドを入力して下さい。 良い応答が現われるかどうかもう一度見る AT コマンドを入力して下さい。 良い応答が現われる場合、モデムは modemcap を初期化されるのに使用する必要がある場合もあります。 これは xxx がモデムタイプであるところでコマンド modem autoconfigure type xxx を使用することを含みます。 それでも良い応答がない場合、モデムモジュールに問題があるかもしれません。 モデムが手動で ダイヤルをことを始めることによってコールを送信できることを確認して下さい。 リモート エンドが答えないようではない場合コールがローカル 番号を手動で呼出すことによるモデムによってリングをことを聞き取っているコマンド ATDT<number>and で送信されていることを確認して下さい。 コールが出ない場合、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 と干渉している可能性があります。 接続される DTE と受信モデム間にケーブル問題があるかもしれません。 トレインアップ障害は本当らしいです回線か非互換性問題。 これのいくつかはモデムのより少ない「積極的な」速度にそれらを制限する離調によって直すことができます。 手法の一例として、Cisco のテストシステムの 1 つへの接続を試みよう。

    at
    OK 

    次に静的なラボにダイアルインします:

    at
    OK
    atdt914085703932
    NO CARRIER

    正常な接続は失敗するようです。 この場合それがノイズ多発回線でしたり、従ってにスピーカー(m1 を)始動させ、モデムを(S56=28800)次のコマンドと 28.8 でキャップするためモデムを工場出荷時状態(&F)置こうことをわかっています:

    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. データがフローしていることを確認して下さい。

    リターン キーをデータがリモート システムからローカルセッションにあちこちにフローしているかどうか見る数回押して下さい。 データがフローしない場合、リモート非同期モデムがリモート DTE と交信を行うことを試みるときケーブルまたはシグナルの問題があるかもしれません。 デバッグし、必要に応じて取り替えて下さい。

データを入力することが反対側から適度な応答がある場合、モデム接続ははたらいています。

一般的な問題

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

ここまでの時点で、モデムは接続され trainup されています。 この場合それか。どのトラフィックでも正しく現れているかどうか調べる s 時間。

コールを受信している回線に 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: 非同期インターフェイスはに状態を変更し、PPPネゴシエーションは(示されていない)始まります。

コールが PPP セッション、そして async mode dedicated が非同期インターフェイスで設定されたら、どのコンフィギュレーション要求 パケットでもリモート エンドから来ているかどうか見るのにコマンド debug ppp negotiation を使用して下さい。 デバッグではこれらが CONFREQ と表示されます。 受信および送信 PPP パケットを監視する場合、PPP のトラブルシューティングを参照して下さい。 それ以外の場合は、コールの発信元である端末からキャラクタモード(または「exec」)セッション(つまり、非 PPP セッション)で接続します。

受信側の非同期インターフェイスの基に async modem dedicated が表示されている場合、exec ダイヤルインには無意味な ASCII 文字が表示されるだけです。 PPP 機能を有効にしたままでターミナル セッションを許可するには、非同期インターフェイス設定コマンド async mode interactive を使用します。 関連する行の下か。s 設定は、コマンド autoselect ppp を使用します。

モデムがターミナルセッションと接続し、データが出くわさなかったら、次をチェックして下さい:

表 4: モデムがデータを送信または受信できない場合

考えられる原因 推奨される対策
モデム速度の設定が固定されていない
  1. アクセス サーバまたはルータで show line exec コマンドを使用します。 補助ポートの出力は、現在設定されている Tx および Rx の速度を示します。 show line コマンドの出力の説明に関しては、参照しま Debug コマンドを使用します
  2. 回線が正しい速度に設定されていない場合は、speed 回線設定コマンドを使用し、アクセス サーバまたはルータの回線の回線速度を設定します。 モデムと、アクセス サーバまたはルータのポートとの間で共通の最高速度に設定します。 端末のボー レートを設定するには、speed 回線設定コマンドを使用します。 このコマンドは、送信(端末へ)と受信(端末から)の両方の速度を設定します。 構文: 速度ビット/秒シンタクスの記述: ビット/秒か。 ビット/秒(ビット/秒)のボーレート。 デフォルトは 9600 bps です。 例: 次の例は、Cisco 2509 アクセス サーバの回線 1 および 2 を 115200 bps に設定します。 Line 1 2 つの速度 115200

    何らかの理由でフロー制御を使用できない場合は、回線速度を 9600 bps に制限します。 これ以上速い速度の場合、データが失われる可能性があります。

  3. show line exec コマンドを再度使用し、ラインスピードが希望値に設定されることを確認して下さい。
  4. アクセス サーバかルータラインは望ましい速度のために設定されることをとき、その行によってモデムに逆 Telnetセッションを始めて下さい。 詳細については、逆 Telnet の設定を参照して下さい。
  5. 使用しているモデム用の lock DTE speed コマンドを含むモデム コマンド文字列を使用します。 設定コマンドの正確な構文については、使用中のモデムのドキュメントを参照してください。

    lock DTE speed コマンドは、多くの場合、モデムによるエラー訂正の処理方法に関連して port rate adjust あるいは buffered mode と呼ばれることもあります。 このコマンドはモデムによって大きく異なります。

    モデム速度をロックすることにより、モデムは 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 形式を使用します。 構文: フロー制御{どれも | ソフトウェア[ロック] [で | out] | ハードウェア[で | ]}シンタクスの記述: なしか。フロー制御を消します。 ソフトウェアか。ソフトウェアフローコントロールを設定 します。 オプションのキーワードは方向を指定します。 in を指定すると、Cisco IOS ソフトウェアは接続デバイスからのフロー制御を受信します。out を指定すると、Cisco IOS ソフトウェアはフロー制御情報を接続デバイスに送信します。 方向を指定しない場合は両方向と見なされます。 ロックして下さいか。接続装置がソフトウェアフローコントロールを必要とするときリモートホストからのフロー制御を消すこと不可能にします。 このオプションは Telnet または rlogin のプロトコルを使用した接続に適用されます。 ハードウェアか。ハードウェアフロー制御を設定 します。 オプションのキーワードは方向を指定します。 in を指定すると、ソフトウェアは接続デバイスからのフロー制御を受信します。out を指定すると、ソフトウェアはフロー制御情報を接続デバイスに送信します。 方向を指定しない場合は両方向と見なされます。 ハードウェア フロー制御の詳細については、ルータに付属しているハードウェアのマニュアルを参照してください。 例: 次の例は、回線 7 でハードウェア フロー制御を設定します。 7 ライン フロー制御ハードウェア

    何らかの理由でフロー制御を使用できない場合は、回線速度を 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] [ブロードキャスト] [ダイヤル ストリング]シンタクスの記述: プロトコルか。 マッピングに応じるプロトコル。 IP、IPX、ブリッジ、およびスナップショットから選択できます。 next-hop-address か。 反対サイトの非同期インターフェイスのプロトコル アドレス。 name hostname か。 PPP認証で使用される必須パラメータ。 ダイヤラ マップの作成対象となるリモート サイトの名前を指定します。 この名前は大文字小文字が区別され、リモート ルータのホスト名と一致する必要があります。 ブロードキャストか。Optional キーワード ブロードキャストパケット(たとえば、IP RIP または IPX RIP/SAP アップデート)リモート宛先に転送される。 スタティック ルーティングの設定例では、ルーティング アップデートは必要とされておらず、broadcast キーワードは省略されています。 ダイヤル ストリングか。 リモートサイトの電話番号。 アクセス コード(外線につなぐための 9、国際局番、市内局番など)をすべて含める必要があります。
  3. dialer map コマンドが正しいネクストホップ アドレスを規定 することを確かめて下さい。
  4. ネクストホップ アドレスが正しくない場合は、dialer map コマンドを使用して変更します。
  5. dialer map コマンド内にある他のすべてのオプションが、使用しているプロトコルに対して正しく指定されていることを確認します。
ダイヤラ マップの設定の詳細については、『Cisco IOS Wide-Area Networking 設定ガイド』および『Wide-Area Networking コマンド リファレンス』を参照してください。
ダイヤリング モデムに関する問題 ダイヤリング モデムが稼働状態にあり、正しいポートに確実に接続していることを確認します。 同じ ポートに接続された場合かどうか別のモデム作業判別して下さい。

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

  • ダイヤルアップクライアントは no exec プロンプトを受け取ります。 表 17-2 を参照して下さい。

  • ダイヤルアップセッションは参照します「ガーベージ」。を 表 17-3 を参照して下さい。

  • ダイヤル式は既存 の セッションで開きます。 表 17-4 を参照して下さい。

  • ダイヤル式受信モデムはきちんと切断しません。 表 17-5 を参照して下さい。

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

考えられる原因 推奨される対策
自動選択が回線で有効になっている Enter キーを押して exec モードへのアクセスを試みます。
no exec コマンドが回線に設定されている
  1. show line exec コマンドを使用し、該当する回線のステータスを表示します。 「exec」。が抑制したことを言うかどうか Capabilities フィールドをチェックして下さい 表示がある場合は、no exec 回線設定コマンドが有効にされています。
  2. 回線で exec 回線設定コマンドを設定し、exec セッションを開始できるようにします。 このコマンドには引数やキーワードはありません。
例: 次の例は、回線 7 で exec をオンにします。 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 でハードウェア フロー制御を設定します。 7 ライン フロー制御ハードウェア

    何らかの理由でフロー制御を使用できない場合は、回線速度を 9600 bps に制限します。 これ以上速い速度の場合、データが失われる可能性があります。

  3. アクセス サーバまたはルータラインのハードウェアフロー制御を有効に した後、その行によってモデムに逆 Telnetセッションを始めて下さい。 詳細については、逆 Telnet の設定を参照して下さい。
  4. 使用しているモデム用の RTS/CTS Flow コマンドを含むモデム コマンド文字列を使用します。 このコマンドはモデムが Cisco access サーバかルータと同じフロー制御 の 方法(ハードウェアフロー制御)を使用していることを確認します。 設定コマンドの正確な構文については、使用中のモデムのドキュメントを参照してください。
モデム速度の設定が固定されていない
  1. アクセス サーバまたはルータで show line exec コマンドを使用します。 補助ポートの出力は、現在設定されている Tx および Rx の速度を示します。 show line コマンドの出力の説明に関しては、章の第 15 使用 Debug コマンド セクションを参照して下さい。
  2. 回線が正しい速度に設定されていない場合は、speed 回線設定コマンドを使用し、アクセス サーバまたはルータの回線の回線速度を設定します。 モデムと、アクセス サーバまたはルータのポートとの間で共通の最高速度に設定します。 端末のボー レートを設定するには、speed 回線設定コマンドを使用します。 このコマンドは、送信(端末へ)と受信(端末から)の両方の速度を設定します。 構文: 速度ビット/秒シンタクスの記述: ビット/秒か。ビット/秒(ビット/秒)のボーレート。 デフォルトは 9600 bps です。 例: 次の例は、Cisco 2509 アクセス サーバの回線 1 および 2 を 115200 bps に設定します。 Line 1 2 つの速度 115200

    何らかの理由でフロー制御を使用できない場合は、回線速度を 9600 bps に制限します。 これ以上速い速度の場合、データが失われる可能性があります。

  3. 再度 show line exec コマンドを使用し、回線速度が望ましい値に設定されたことを確認します。
  4. アクセス サーバかルータラインは望ましい速度のために設定されることをとき、その行によってモデムに逆 Telnetセッションを始めて下さい。 詳細については、逆 Telnet の設定を参照して下さい。
  5. 使用しているモデム用の lock DTE speed コマンドを含むモデム コマンド文字列を使用します。 設定コマンドの正確な構文については、使用中のモデムのドキュメントを参照してください。

lock DTE speed コマンドは、多くの場合、モデムによるエラー訂正の処理方法に関連して port rate adjust あるいは buffered mode と呼ばれることもあります。 このコマンドはモデムによって大きく異なります。

モデム速度をロックすることにより、モデムは Cisco アクセス サーバまたはルータに対して、常に Cisco 補助ポートに設定された速度で通信します。 このコマンドを使用しない場合、モデムはデータ リンク(電話回線)の速度に戻ります。アクセス サーバに設定された速度では通信しません。

表 6 ダイヤルアップセッションは参照します「ガーベージ」を

考えられる原因 推奨される対策
モデム速度の設定が固定されていない
  1. アクセス サーバまたはルータで show line exec コマンドを使用します。 補助ポートの出力は、現在設定されている Tx および Rx の速度を示します。 show line コマンドの出力の説明に関しては、章の第 15 使用 Debug コマンド セクションを参照して下さい。
  2. 回線が正しい速度に設定されていない場合は、speed 回線設定コマンドを使用し、アクセス サーバまたはルータの回線の回線速度を設定します。 モデムと、アクセス サーバまたはルータのポートとの間で共通の最高速度に設定します。 端末のボー レートを設定するには、speed 回線設定コマンドを使用します。 このコマンドは、送信(端末へ)と受信(端末から)の両方の速度を設定します。 構文: 速度ビット/秒シンタクスの記述: ビット/秒か。ビット/秒(ビット/秒)のボーレート。 デフォルトは 9600 bps です。 例: 次の例は、Cisco 2509 アクセス サーバの回線 1 および 2 を 115200 bps に設定します。 Line 1 2 つの速度 115200

    何らかの理由でフロー制御を使用できない場合は、回線速度を 9600 bps に制限します。 これ以上速い速度の場合、データが失われる可能性があります。

  3. 再度 show line exec コマンドを使用し、回線速度が望ましい値に設定されたことを確認します。
  4. アクセス サーバかルータラインは望ましい速度のために設定されることをとき、その行によってモデムに逆 Telnetセッションを始めて下さい。 詳細については、逆 Telnet の設定を参照して下さい。
  5. 使用しているモデム用の lock DTE speed コマンドを含むモデム コマンド文字列を使用します。 設定コマンドの正確な構文については、使用中のモデムのドキュメントを参照してください。

ポートレート調節するまたはバッファ モードがであるようにまた参照されるかもしれない lock DTE speed コマンドは頻繁にモデムがエラー修正を処理する方法に、関連していました。 このコマンドはモデムによって大きく異なります。

モデム速度をロックすることにより、モデムは Cisco アクセス サーバまたはルータに対して、常に Cisco 補助ポートに設定された速度で通信します。 このコマンドを使用しない場合、モデムはデータ リンク(電話回線)の速度に戻ります。アクセス サーバに設定された速度では通信しません。

症状: リモート ダイヤルイン セッションが、別のユーザによって開始された既存のセッション内で開きます。 すなわち、ログインプロンプトが表示されるかわりに、ダイヤルイン ユーザは(セッションを設定する Unix コマンド プロンプト、テキストエディタセッション、または他のどの進行中の交換もであるかもしれない)他のユーザ見ます。

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

考えられる原因 推奨される対策
モデムが DCD に対して常にハイに設定されている
  1. 1 つの CD に対してだけ、DCD がハイになるようにモデムを再設定します。 これは通常 &C1 モデムコマンドストリングの使用によって達成されますが、モデムの正しい 構文があるようにモデム解説書を確認します。
  2. no exec 回線設定コマンドを使用して、モデムが接続されているアクセス サーバ回線を設定する必要がある場合があります。 DCD が CD でだけ高いように clear line privileged exec コマンドでラインを消去し、モデムを持つ逆 Telnetセッションを始め、モデムを再構成して下さい。
  3. Telnetセッションを接続解除の入力によって終了し、exec line configuration コマンドでアクセス サーバ行を再構成して下さい。
アクセス サーバまたはルータでモデム制御がイネーブルになっていない
  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 ポートについて、このケーブル構成を推奨およびサポートしています。 これらのコネクタは一般的に分類されます: モデム。 RJ 45 ケーブル接続には 2 つの型があります: まっすぐにおよび転送される。 RJ-45 ケーブルの 2 つの端子を並べると、8 個の色付きのピンが双方の端子にあります 色の付いたピンの順番が両端で同一である場合には、そのケーブルはストレートです。 色の付いたピンの順番が両端で反対であれば、それはロール型ケーブルになります。 Cisco 2500/CS500 では、ロール型ケーブル(CAB-500RJ)が標準です。
  2. show line exec コマンドを使用してケーブル接続が正しいことを確認します。 Debug コマンドの使用show line コマンド出力の説明を参照して下さい。

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

考えられる原因 推奨される対策
モデムが DTR を検出していない Hangup DTR modem コマンド文字列を入力します。 このコマンドは、DTR 信号が受信されなくなったらキャリアをドロップするようにモデムに指示します。 モデムのハングアップ DTR を設定するためにヘイズ互換モデムで &D3 ストリングは広く使われています。 このコマンドの正確な構文については、モデムのドキュメントを参照してください。
ルータまたはアクセス サーバでモデム制御が有効ではない
  1. アクセス サーバまたはルータで show line exec コマンドを使用します。 補助ポートの出力の Modem のカラムには inout または RIisCD と表示されます。 これは、アクセス サーバまたはルータの回線でモデム制御がイネーブルになっていることを示します。 show line 出力の説明に関しては、参照しま Debug コマンドを使用します
  2. modem inout 回線設定コマンドを使用して、回線をモデム制御用に設定します。 これで、アクセス サーバでモデム制御がイネーブルになります。

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

原因コードフィールド

表 9 は debug コマンド内の次の形式で表示する ISDN 原因 コード フィールドをリストしたものです:

i=0x y1 y2 z1 z2 [a1 a2]
表 9: ISDN の原因コードのフィールド

フィールド 値の説明
0x これに続く値は 16 進数です。
y1 8--ITU-T 標準符号化
y2 0 ユーザ 1 Private ネットワーク サービング ローカルユーザ 2 パブリック ネットワーク サービング ローカルユーザ 3 中継ネットワーク 4 パブリック ネットワーク サービング リモートユーザ 5 Private ネットワーク サービング リモートユーザ 7 国際的なネットワーク A--インターネットワーキングポイントを越えるネットワーク
z1 理由種別のクラス(上位側の 16 進数)。 取り得る値の詳細については、次の表を参照してください。
z2 理由種別の値(下位側の 16 進数)。 取り得る値の詳細については、次の表を参照してください。
a1 (オプション)診断フィールド。常に 8 です。
a2 (オプション)診断フィールド。次のいずれか 1 つの値をとります。 2 一時 0 未知 1 パーマネント

ISDN原因値

表 10 はいくつかの原因 情報 要素のほとんどのよく見られる原因値の説明を-原因コードの第 3 および第 4 バイト リストしたものです。

表 10: ISDN原因値

原因 説明
81 Unallocated (unassigned) number ISDN 番号は正しい形式のスイッチに送られました; ただし、数はあらゆる宛先装置に割り当てられません。
90 正常なコール クリア 正常なコール クリアーが発生しました。
91 ユーザ ビジー コールされたシステムが接続要求の確認応答をしましたが、B チャネルがすべて使用中のためコールを受け入れることができません。
92 ユーザ応答なし 宛先がコールに応答しないため接続を完了できません。
93 ユーザからの応答なし(ユーザ アラート) 宛先は接続要求に応答しますが、指示された時間内に接続を完了できません。 接続のリモート端末に問題があります。
95 コール拒否 宛先はコールを受け入れる余地がありますが、不明な理由のためコールを拒否しました。
9C 番号形式が不正 宛先アドレスが認識不可能な形式で表現されていたか、または宛先アドレスが不完全だったため、接続を確立できませんでした。
9F 正常、詳細不明 標準の原因が適用されないときの正常なイベントの発生を報告します。 特に対処する必要はありません。
A2 利用可能な回路/チャネルなし コールを受け付けるために使用可能な適切なチャネルがないため、接続を確立できません。
A6 ネットワーク故障 ネットワークが正常に機能していない状態が一定時間以上続いたため、宛先に到達できません。 今すぐ再接続しようとしても成功する可能性はほとんどありません。
AC リクエストされた回路/チャネルの利用不可 不明な理由のため、リモート装置が要求されたチャネルを提供できません。 一時的な問題である場合もあります。
B2 要求されたファシリティが未登録 リモート装置は、登録されている場合のみ、要求された補助サービスをサポートします。 多くの場合、これは長距離サービスへの参照です。
B9 ベアラ機能が無許可 ユーザはネットワークが提供する Bearer Capability を要求しましたが、ユーザにはその使用が許可されていません。 登録の問題である場合もあります。
D8 互換性のない宛先 試みが非ISDN機器に接続するために試みられたアナログ回線のようなことを示します。
E0 必須の情報要素が欠如 受信装置でメッセージを受信しましたが、必須情報要素の 1 つが含まれていませんでした。 通常は D チャネルのエラーが原因です。 このエラーがシステム的に発生する場合は、ISDN サービス プロバイダーに報告します。
E4 無効な情報要素コンテンツ リモート装置でメッセージを受信しましたが、情報要素に無効な情報が含まれています。 通常は D チャネルのエラーが原因です。

ISDNコードおよび値に関する完全情報詳細については、ISDNスイッチ コードを参照し、IOSバージョンのための Cisco IOS Debug コマンド レファレンスの章を評価します。


関連情報


Document ID: 14955