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

ダイヤラ プロファイルの設定とトラブルシューティング

2009 年 7 月 17 日 - ライター翻訳版
その他のバージョン: PDFpdf | 機械翻訳版 (2013 年 8 月 21 日) | 英語版 (2005 年 9 月 15 日) | フィードバック

目次


概要

このドキュメントでは、ダイヤラ プロファイルの設定とトラブルシューティングのヒントを説明しています。



前提条件

要件

このドキュメントの読者は次の項目に関する知識が必要です。

  • レガシー DDR(ダイヤラ マップおよびダイヤラ ロータリーグループ)

  • PPP Challenge Handshake Authentication Protocol(CHAP; チャレンジ ハンドシェーク認証プロトコル)および Password Authentication Protocol(PAP; パスワード認証プロトコル)

  • Caller ID(CLID; 発信者 ID)および Dialed Number Identification Service(DNIS; 着信番号情報サービス)



使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づくものです。

  • ダイヤラ プロファイルが最初に導入されたのは、Cisco IOS(R) ソフトウェア リリース 11.2 です。

  • このドキュメントの説明は、Cisco IOS ソフトウェア リリース 12.0(7)T 以降を対象としています。それよりも前の Cisco IOS ソフトウェアのバージョンでのダイヤラ プロファイルの動作は、このドキュメントでは説明されていません。

  • ダイヤラ プロファイルに変更が加えられているため、Cisco IOS ソフトウェア リリース 12.1 以降を実行することを推奨いたします。ダイヤラ プロファイルは、ISDN インターフェイス装備のすべての Cicso ルータで使用できます。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。対象のネットワークが実稼働中である場合には、どのような作業についても、その潜在的な影響について確実に理解しておく必要があります。

Software Advisor ツール登録ユーザ専用)を使用すると、稼働中の Cisco IOS ソフトウェアのバージョンでこの機能がサポートされていることを確認できます。
一部ツールについては、ゲスト登録のお客様にはアクセスできない場合がありますことを、ご了承ください。

ヒント:Software Advisor ツールでは、「Dynamic Multiple Encapsulation for Dial-in over ISDN」という名前の機能を検索してください。



表記法

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



背景説明

レガシー Dial-on-Demand Routing(DDR; ダイヤルオンデマンド ルーティング)は多くのシナリオで有用ですが、さまざまなユーザにさまざまな特性を定義することによりユーザを差別化することが必要な場合には制限があります。これはレガシー DDR では実現できません。ダイヤラ プロファイルは、ユーザ固有のプロファイルをルータ上で設定できるようにするために、新しい DDR モデルとして設計されています。プロファイルは特定のユーザの特性を決定し、またプロファイルは着信/発信 DDR コールの物理インターフェイス(非同期インターフェイスや Basic Rate Interface [BRI; 基本速度インターフェイス] など)に動的にバインドされます。ダイヤラ プロファイルは、着信/発信ダイヤルで Point-to-Point Protocol(PPP; ポイントツーポイント プロトコル)、High-level Data Link Control(HDLC; 高レベル データリンク制御)、フレーム リレー、または X.25 のカプセル化をサポートしています。推奨される選択肢は PPP カプセル化で、このドキュメントでは PPP を中心に扱っています。



ダイヤラ プロファイルが適切であることの確認

ダイヤラ プロファイルが使用中の設定にとって最善のオプションであるかどうかを判断するには、次の質問に答えてください。回答が「どちらでもない」である場合は「いいえ」と解釈します。使用する最善の方法を決定するには、以下に示すフローチャートに対する次の質問に答える必要があります。

  1. ユーザごとの必要条件がありますか。つまり、圧縮、アイドル タイムアウト、レイヤ 3 アドレッシング、またはその他のサービスや機能など、ユーザ間で異なる機能を適用する必要がありますか。

  2. コールの方向に関係なく、200 を超えるサイトへの接続がありますか。

    注:200 のサイトとは任意の数で、この数を超えるとネットワークの拡張が大きな問題となる数です。

  3. 発信ダイヤルに必要条件はありますか。

最適な DDR の実装方法を決定するには、次のフローチャートを使用します。



DDR ソリューションの比較フローチャート

DDR ソリューションの比較フローチャート

レガシー DDR についての詳細は、『ダイヤルオンデマンド ルーティングの設定』の「Cisco IOS ダイヤル テクノロジーの設定ガイド」の章を参照してください。

Virtual Profile(VP; バーチャル プロファイル)についての詳細は、『バーチャル テンプレート、プロファイル、およびネットワーク』の「Cisco IOS ダイヤル テクノロジーの設定ガイド」の章を参照してください。

Large-Scale Dial-Out(LSDO; 大規模ダイヤル アウト)についての詳細は、『大規模ダイヤル アウトの設定』の「Cisco IOS ダイヤル テクノロジーの設定ガイド」の章を参照してください。



レガシー DDR と比べたダイヤラ プロファイルの利点

  • レガシー DDR とは異なり、ダイヤラ プロファイルはポイントツーポイント インターフェイスです。このことにより、レイヤ 3 からレイヤ 2 へのマップの要件と、複数のマップを管理する煩雑さが軽減されます。

  • さまざまなレイヤ 3 ネットワーク アドレスを持つ 1 つの物理インターフェイスのさまざまなメンバを設定します。

  • ダイヤラ プロファイルを使用すると、着信/発信コールの要件に基づいて、物理インターフェイスがさまざまな特性を持てるようになります。

  • プライマリ インターフェイスが動作中である場合、バックアップ インターフェイスを非専用のインターフェイスとして使用できるようにすることが可能です。

  • DDR インターフェイスを出入りする最大または最小の接続数を制御します。

  • さまざまな DDR パラメータを、ISDN インターフェイスの各 B チャネルに設定できます。



状況の例

ダイヤラ プロファイルが有用である一般的な状況としては次のものがあります。

  • ルータが複数のサイトに接続する必要があり、異なるサブネットにピアが存在する場合。

  • 物理インターフェイスを通常の DDR に使用する必要があるだけでなく、物理インターフェイスが WAN リンクに対するバックアップを提供する必要がある場合。

  • 特定の接続用に一部の B チャネルを予約する必要がある場合。

  • 異なるカプセル化(HDLC や PPP など)をピアが実行する場合。

    注:この機能には Cisco IOS ソフトウェア バージョン 12.0(7)T 以降が必要です。

  • 複数のチャネルを必要とする接続もあれば、チャネルを 1 つだけ必要とする接続もある場合。

  • 各接続が異なるアイドル タイムアウトの値を必要とする場合。

  • 各接続が異なる対象トラフィックの定義を必要とする場合。

  • ピアの IP アドレスが不明である場合。

  • (PRI の)ISDN B チャネルがさまざまな設定を必要とする場合。

上記の状況の大部分は、ダイヤラ プロファイルが理想的な選択である個々のユーザに関する問題について述べています。上記のリストには、ダイヤラ プロファイルを使用可能な状況がすべて含まれているわけではないことに注意してください。



制約

ダイヤラ プロファイルには既知の制限があります。次に例を示します。

  • CLID ベースのバインディングがイネーブル(Cisco IOS ソフトウェア リリース 12.0(7)T 以降が必要)でなければ、物理インターフェイスとダイヤラ インターフェイスの両方で、PPP 認証およびマルチリンクをイネーブルにする必要があります。

  • 各ダイヤラ インターフェイスでは、インターフェイスを管理する内部構造である Interface Description Block(IDB; インターフェイス記述ブロック)を使用します。使用できる IDB の数は有限です(Cisco IOS ソフトウェア バージョンおよびプラットフォームに依存します)。これは、ダイヤラ プロファイルは大規模 DDR アプリケーション用には拡張できないことを意味します。さまざまなプラットフォームの IDB の制限についての詳細は、『Cisco IOS プラットフォームのインターフェイスおよびサブインターフェイスの最大数:IDB 制限』を参照してください。

  • ダイヤラ プロファイル内部では、同じ特性を共有するユーザのグループのために汎用のダイヤラ プロファイル(さらにデフォルトのプロファイルも)を設定する方法はありません。各ユーザには独自のプロファイルが必要です。

    ヒント:ダイヤラ プロファイルとバーチャル プロファイルを併用してください。バーチャル プロファイルは優れた「デフォルト プロファイル」を提供できます。

  • 着信接続に関しては、最初のコールへの応答とそれによる変更なしで、プロファイルへの着信コールの量を制限する方法はありません。



ダイヤラ プロファイルのコンポーネント

ダイヤラ プロファイルは次の要素で構成されています。

  • ダイヤラ インターフェイス:ユーザ固有のダイヤラ プロファイルを定義する論理エンティティです。ユーザに固有のすべての設定は、レイヤ 3 プロトコル アドレス、対象トラフィック、タイムアウトなど、ダイヤラ インターフェイスの設定の影響を受けます。このダイヤラ インターフェイスは、レガシー DDR とともにロータリー グループとして使用されるダイヤラ インターフェイスとは完全に異なることに注意してください。このドキュメントの説明では、ダイヤラ プロファイルとダイヤラ インターフェイスは同義語であると考えてください。

  • ダイヤラ プール:各ダイヤラ インターフェイスは 1 つのダイヤラ プールのメンバです。プールとは、1 つ以上の物理インターフェイスのグループです。プール内にはインターフェイス(非同期、ISDN、シリアル)の任意の組み合せが存在可能です。特定の物理インターフェイスの発信ダイヤルのコンテンションを解決するには、dialer pool-member priority コマンドを使用します。

  • 物理インターフェイス:(BRI や非同期などの)インターフェイスは、1 つ以上のプールのメンバとして設定されます。また少なくとも、インターフェイスが属するダイヤラ プールのカプセル化パラメータおよび識別用に設定されます。発信者 ID(CLID)ベースのバインディングがイネーブルである場合を除き、物理インターフェイス上では PPP 認証およびマルチリンク PPP(該当する場合)も設定する必要があります。

次のダイアグラムに、ダイヤラ プロファイルのさまざまな要素間の相互作用の例を示します。

ダイヤラ プロファイルのエレメント間での相互作用の例



ダイヤラ プロファイルを使用したバインディング プロセスについて

ここでは、コール単位で物理インターフェイスにダイヤラ プロファイルを動的にバインドするという概念を詳細に説明しています。

特定のピアに関する設定情報は、ダイヤラ プロファイル内に含まれています。その特定のピアが物理ポートを介してダイヤルインまたはダイヤルアウトされると、ルータは、リモートのダイヤラ プロファイルを物理インターフェイスにバインドする必要があります。ルータでは複数のダイヤラ プロファイルが設定されている場合が多いため、ルータは、特定のコール(着信または発信のいずれか)に関してどのプロファイルをバインドするかを適切に選択する必要があります。ダイヤルアウトまたはダイヤルインに関するこの問題を説明するため、フローチャートが付属するステップごとの手順を提示します。ステップごとの手順を使用する際には、フローチャートを参照してください。



ダイヤルアウト

このシナリオは、ダイヤラ ロータリー グループの動作に非常によく似ています。物理インターフェイスでは、特定の接続に関するダイヤラ プロファイルの特性を前提としています。バインディング プロセスを次に示します。

  1. 着信パケットがルータに到達します。ルーティング テーブルのルックアップには、ダイヤラ インターフェイス上の宛先アドレスが示されます。

  2. Cisco IOS ソフトウェアは、そのダイヤラ インターフェイスがダイヤラ プロファイルであることを検出します。このプロファイルの既存の接続が存在しない場合、ダイヤラ インターフェイスが関連付けられているプールが特定されます。

  3. 既存の接続が存在する場合は、パケットは物理インターフェイスにキューイングされ、トラフィックが「対象」トラフィックである場合、アイドル タイマーがリセットされます。

  4. 既存の接続が存在しない場合、対象トラフィックであるかどうかを判別するため、そのトラフィックは dialer-list と照合されます。対象トラフィックでない場合、そのパケットは廃棄されます。対象トラフィックである場合、ステップ 5 に進みます。

  5. 既存の接続が存在しない場合、Cisco IOS ソフトウェアは、ダイヤラ プールのプライオリティが最高であるダイヤラ インターフェイスに属する物理インターフェイスを検索します。これが、ダイヤリングに使用されるインターフェイスです。このインターフェイスはダイヤラ インターフェイスにバインドされ、これにより物理インターフェイスはダイヤラ インターフェイスの設定が存在すると見なします。

  6. Cisco IOS ソフトウェアはダイヤラ プロファイルの電話番号をダイヤルし、またこの時点で通常の DDR ステップが行われます。

  7. ピアの認証された名前が、発信ダイヤラ プロファイルの dialer remote-name と一致しない場合、そのコールは接続解除されます。



ダイヤルアウトのフローチャート

ダイヤルアウトのフローチャート

ダイヤラ プールが ISDN インターフェイス、非同期インターフェイス、または両者の混合から構成されているかどうかに関係なく、この一連の手順は同じです。

あるプロファイルからの発信コールの数は、最小と最大のしきい値で(dialer pool-member pool_number max-link number min-link number コマンドを使用して)管理できます。最小しきい値は予約システムとして機能するのに対し、最大しきい値はプロファイルの過剰な使用を防止します。しきい値に到達すると、そのプロファイル上ではそれ以上の発信コールは許可されません。



ダイヤルイン

着信インターフェイスは複数のプールのメンバになることが可能で、これらのプールは複数のダイヤラ プロファイルと関連付けることができるため、着信コールに関するダイヤラ プロファイルのバインディングはより複雑になります。ダイナミック バインディングが不可能である場合、そのコールは接続解除されます。バインディング プロセスを次に示します。

注:このプロセスは実行順に示されています。最初の一致が見つかった時点で、コールはダイヤラ インターフェイスにバインドされます。

  1. 物理インターフェイスが 1 つだけのプールのメンバであり、このダイヤリング プールに 1 つだけダイヤラ プロファイルが関連付けられている場合、物理インターフェイスをこのダイヤラ プロファイルにバインドします。

    注:このステップが実行されるのは、設定されている 1 つのダイヤラ プロファイルに dialer caller コマンドや dialer called コマンドがない場合だけです。いずれか一方のコマンドが設定されている場合、一致が成功した場合にだけバインディングが実行されます。

  2. ダイヤラ インターフェイスで dialer caller コマンドを使用して、コールからの発信者 ID(CLID)の照合を試みます。ここでチェックされるのは、物理インターフェイスがメンバになっているプールに関連付けられているプロファイルだけです。一致が見つかった場合、一致したダイヤラ プロファイルに物理インターフェイスをバインドします。何らかの理由によりこのチェックが失敗した場合、さらにバインドを試みる次のステップに進みます。dialer caller についての詳細は、ドキュメント『発信者番号による ISDN 認証とコールバック』を参照してください。電話会社から CLID が提供されていない場合、またはダイヤラ プロファイルで dialer caller が設定されていない場合、このステップはスキップされます。

  3. 着信コールの Q.931 SETUP メッセージで電話会社により提供された DNIS-plus-ISDN-subaddress 情報を使用してバインドを試みます。この着信コールの DNIS およびサブアドレス情報は、各ダイヤラ プロファイルで dialer called コマンドと照合されます。一致が見つかった場合、バインディングは成功し、見つからなかった場合は次の基準に移行します。

    注:DNIS バインディングが許可されるのは、ISDN サブアドレス情報が着信コールの Q.931 SETUP メッセージに存在し、ダイヤラ プロファイルで dialer called コマンドが適切に設定されている場合だけです。ISDN サブアドレスは主にヨーロッパとオーストラリアで使用され、北米では一般的ではありません。

  4. 物理インターフェイスが PPP 認証用に設定されている場合、コールに応答し、リモート ピアを認証します。認証された名前を使用して、(dialer remote-name コマンドを使用して)設定された同じ名前を持つダイヤラ プロファイルを特定します。物理インターフェイスがメンバであるプールと関連付けられたプロファイルだけがチェックされます。一致が見つかった場合、一致したダイヤラ インターフェイスに物理インターフェイスをバインドします。何らかの理由によりこのチェックが失敗した場合、バインド試行アルゴリズムは失敗し、コールは接続解除されます。

ダイヤルインのフローチャート

ダイヤルインのフローチャート

バインドが行われたことが、接続の成功を意味してはいないことに注意してください。これは単に、この時点で物理インターフェイスは使用できる設定を持っていることを意味します。ただし、その他の理由(IP Control Protocol(IPCP)の失敗など)により、コールが依然として接続解除されている可能性があります。

バインディングが成功し、デバイスの認証が終わると、ルータでは dialer remote-name が、ピアの認証されたユーザ名と一致するかどうかがチェックされます。名前が一致しない場合、コールは接続解除されます。

発信者 ID または DNIS を使用してバインドできるのは、同期 ISDN コールだけです。モデム コールが ISDN BRI または PRI 接続で配送された場合に、提供された CLID/DNIS をモデム コールのバインド用に使用する試みは、現時点では行われません。

あるプロファイルからの着信コールの数は、最大しきい値(dialer pool-member コマンドの max-link オプション)で管理できます。最大しきい値はプロファイルの過剰な使用を防止します。ルータはコールに応答し、どのプロファイルがコールの対象であるか、およびプロファイルの最大接続上限に達したかどうかを判別します。最大値に到達している場合、コールは接続解除されます。



ダイヤラ プロファイルの設定作業の概要

ダイヤラ プロファイルを設定するには、次のタスクを実行します。

  1. 1 つ以上のダイヤラ インターフェイスを設定します。宛先に固有のすべての設定は、ダイヤラ インターフェイスの設定に送られます。

    ステップ コマンド 目的

    1.

    interface dialer number

    ダイヤラ インターフェイスを作成します。

    2.

    ip address ip_address subnet_mask または ip unnumbered interface または ip address negotiated

    ダイヤラ インターフェイスの IP アドレスとマスクを、コールされる宛先ネットワーク内のノードとして指定します。また、ルータ上の別の Up/Up インターフェイスにインターフェイスの番号変更を行ったり、IPCP ネゴシエーション中に取得されたアドレスを使用することもできます。

    3.

    encapsulation ppp

    PPP カプセル化を指定します。

    4.

    (オプション)ppp authentication chap | pap [callin]

    PPP 認証方式を指定します。

    これが必要であるのは、CLID または DNIS ベースのバインディングを行っていない場合だけです。詳細は、「ダイヤルイン」のセクションを参照してください。

    5.

    dialer caller number

    (バインディングに使用される)ピアの発信者 ID(CLID)を設定します。電話会社が着信コールの SETUP メッセージで CLID を提供していることを確認します。

    6.

    (オプション)dialer called DNIS:subaddress

    バインディングに使用可能な DNIS およびサブアドレス情報を指定します。これは主にヨーロッパとオーストラリアで使用されています。

    注:DNIS とサブアドレスの両方を設定してください。一方でも設定されていないと、このプロファイルへの DNIS バインディングの試行がすべて失敗します。

    7.

    dialer remote-name username

    リモート ルータの認証名を指定します。ユーザ名が正しく指定されていない場合、コールは接続解除されます。

    8.

    dialer string dial-string class class-name

    コールするリモートの宛先と、この宛先へのコールの特性を定義するマップ クラスを指定します。マップ クラスはオプションです。

    このコマンドが必要であるのは、ルータが発信コールを行っている場合だけです。

    9.

    dialer pool pool-number

    この宛先へのコールに使用するダイヤリング プールを指定します。

    10.

    dialer-group group-number

    ダイヤラ インターフェイスをダイヤラ グループに割り当てます。これは、対象トラフィックの定義をインターフェイスに適用します。

    11.

    dialer-list group-number protocol protocol-name {permit | deny | list} access-list-number

    コールをトリガーできる「対象」パケットを定義するための、リスト番号別アクセス リスト、またはプロトコルおよびリスト番号別アクセス リストを(グローバル設定モードで)指定します。グループ番号はステップ 9 での番号と同じである必要があります。

  2. (オプション)マップ クラスを設定して、コール/宛先単位でさまざまな種類のコールのさまざまな特性を指定します。詳細は、「Configuring the map-class dialer コマンドの設定」セクションを参照してください。

  3. 物理インターフェイスを設定します。

    ステップ コマンド 説明

    1.

    interface interface_type number

    ダイヤラ プロファイルの物理インターフェイスのパラメータを設定します。

    2.

    (オプション)encapsulation ppp

    PPP カプセル化をデフォルトに指定します。x.25、フレームリレー、HDLC などを設定することもできます。

    物理インターフェイスは PPP カプセル化を使用しますが、B チャネルで実行される実際のカプセル化は、このインターフェイスにバインドされたダイヤラ プロファイルで設定されたカプセル化により決定されます。

    3.

    (オプション)ppp authentication chap | pap [callin]

    PPP 認証方式を指定します。

    これが必要であるのは、CLID または DNIS ベースのバインディングを行っていない場合だけです。詳細は、「ダイヤルイン」のセクションを参照してください。

    4.

    (オプション)ppp multilink

    この物理インターフェイス上で PPP マルチリンクを許可します。

    これが必要であるのは、CLID または DNIS ベースのバインディングを行っていない場合だけです。詳細は、「ダイヤルイン」のセクションを参照してください。

    5.

    dialer pool-member pool-number

    物理インターフェイスをダイヤラ プールに割り当てます。このプール番号は、上記の表のステップ 9 で設定されたものと同じである必要があります。


    注:この物理インターフェイスを通過するすべての着信接続が CLID または DNIS を使用してバインドされているわけではない場合、この物理インターフェイス上で encapsulation pppppp authentication および ppp multilink(該当する場合)を設定する必要があります。 

  4. CHAP または PAP 認証のユーザ名とパスワードを設定します。PAP の設定についての詳細は、『PPP パスワード認証プロトコル(PAP)の設定とトラブルシューティング』を参照してください。CHAP についての詳細は、『PPP CHAP 認証の説明と設定』を参照してください。

  5. ダイヤラ インターフェイスを持つスタティック ルートをネクストホップとして設定します。



構成例

構成例

上記の図では次のようになっています。

  • ダイヤラ インターフェイス Dialer1 はダイヤラ プール 10 を使用しています。

  • ダイヤラ インターフェイス Dialer2 はダイヤラ プール 20 を使用しています。

  • ダイヤラ インターフェイス Dialer3 はダイヤラ プール 30 を使用しています。

  • BRI 0、BRI 1、BRI 2 はダイヤラ プール 10 に属しています。

  • BRI 1、BRI 2 はダイヤラ プール 20 に属しています。

  • BRI 2 はダイヤラ プール 30 に属しています。

インターフェイス Dialer1 が DDR 接続を確立する必要がある場合、ダイヤラ プール 10 の BRI のいずれかを使用します。この場合、BRI 0、BRI 1、または BRI 2 からの B チャネルがコールに使用されます。

ダイヤラ インターフェイス Dialer2 が DDR 接続を確立する必要がある場合は、ダイヤラ プール 20(および拡張により BRI 1 または BRI 2)を使用します。

ダイヤラ プール内でのコンテンションを回避するため、ダイヤラ プールの物理インターフェイスにプライオリティを設定できます。



ダイヤラ インターフェイスの設定

ダイヤラ インターフェイスの設定作業を、次の設定例に示します。

interface Dialer1 
 ip address 1.1.1.1 255.255.255.0

 ! -- IP アドレス。  
 ! -- 分かりやすくするため、同じネットワーク内のこのアドレスをピアに保ちます。


 ! -- 必要に応じて、代わりにこれを別のインターフェイスに番号変更できます。

 encapsulation ppp
 dialer remote-name Smalluser

 ! -- ピアの認証されたリモート名。 


 ! -- この名前がリモートの認証された名前と正確に一致すること確認します。

 dialer string 5554540

 ! -- 発信コールの番号です。着信コールの場合、これは必要ありません。


 ! -- 同じダイヤラ インターフェイスに、複数のダイヤル文字列を指定できます。

 dialer caller 5554540

 ! -- バインディングに使用される CLID 情報です。 

 dialer pool 10

 !-- ダイヤラ プール 10 のメンバです。


 !-- ダイヤラ インターフェイスは 1 つのプールだけのメンバになることができます(逆は真ではありません)。

 dialer-group 1

 ! -- 対象トラフィックは dialer-list 1 により定義されています。

!
interface Dialer2
 ip address 2.2.2.2 255.255.255.0
 encapsulation ppp
 dialer remote-name Mediumuser

 !-- remote-name はその他のプロファイルとは異なることに注意してください。


 !-- 2 つのダイヤラ プロファイルの設定には同じ remote-name を使用しないでください。

 dialer string 5554541
 dialer caller 5554541
 dialer load-threshold 50 either

 ! -- マルチリンク PPP の負荷しきい値(50/255=20 %)。

 dialer pool 20
 dialer-group 2
 ppp multilink

 ! -- Dialer 2 はマルチリンク PPP を実行できます。

!
interface Dialer3
 ip address 3.3.3.3 255.255.255.0
 encapsulation ppp
 dialer remote-name Poweruser
 dialer string 5554542 class Eng

 !--- 5554542 をダイヤルし、「Eng」という名前の map-class(定義は下にあります)を使用します。

 dialer caller 5554542
 dialer hold-queue 10
 dialer load-threshold 80

 ! -- マルチリンク PPP の負荷しきい値(80/255=32 %)。

 dialer pool 30
 dialer-group 2
 ppp multilink

 ! -- Dialer 3 はマルチリンク PPP を実行できます。

!
map-class dialer Eng

!-- Dialer3 のダイヤラ ストリングとともに使用された、「Eng」という名前の map-class。

 isdn speed 56

注:接続する必要があるすべてのリモート デバイスのダイヤラ インターフェイスを設定します。



ダイヤラ インターフェイスの設定に必要な最小限のコマンド

  • リモートの宛先を指定するには、dialer remote-name user-name コマンドを使用します。これは、認証のために渡されるリモート ルータの名前です。

  • (発信コールの場合)ダイヤルする番号を指定するには、dialer string string コマンドを使用します。必要に応じてマップクラスを設定できます。

  • ピアの CLID を指定するには、dialer caller lookup コマンドを使用します。

  • ダイヤラ インターフェイスをダイヤラ プールにバインドするには、dialer pool number コマンドを使用します。ダイヤラ インターフェイスは 1 つのダイヤラ プールだけに関連付けることができますが、ダイヤラ プールは多くのダイヤラ インターフェイスに関連付けることができる点に注意してください。

  • dialer-group group-number コマンドは、「対象」トラフィックを定義するダイヤラ リストの参照に使用します。

注:dialer-list dialer-group protocol protocol-name {permit | deny | list access-list-number} コマンドは、コールをトリガーするために「対象」パケットを定義する、プロトコルまたはアクセス リスト番号を指定します。



map-class dialer コマンドの設定

map-class dialer class-name コマンドを使用すると、マップクラスを指定し、マップクラスの設定モードに入ることができます。次の表にオプションを示します。

コマンド 説明

dialer isdn [speed <56>] | [no-spc]

ISDN 回線速度 56 Kbps を指定します。

注:デフォルトは 64 Kbps です。速度のパラメータは 56 Kbps の回線速度でだけ使用します。64 は有効なオプションではありません。

注:これが必要であるかどうかを判断するには、電話会社に連絡してください。

dialer idle-timeout number

コールの発信時に使用するアイドル タイマーの値を指定します。デフォルトは、120 秒です。

注:ダイヤラ インターフェイスでもアイドルタイムアウトを設定できます。

dialer fast-idle number

コールの発信時に使用するファースト アイドル タイマーの値を指定します。これは、物理インターフェイスの輻輳が発生した場合に使用されます。デフォルトは、20 秒です。

dialer wait-for-carrier-time number

コールの発信時に使用するキャリア時間の値を指定します。


注:上記のダイヤラ コマンドの一部は、ダイヤラ インターフェイスまたはマップクラスで直接設定できます。同じコマンドが複数回出現する場合があり、またパラメータが異なる可能性があります。優先順位の順序は、最高から最低まで次のようにならんでいます。

  • マップクラスのパラメータ

  • インターフェイスのパラメータ



物理インターフェイスの設定

物理インターフェイスをダイヤラ プールに割り当てるには、dialer pool-member number コマンドを使用します。このインターフェイス設定コマンドを使用して複数のダイヤラ プール番号を指定することで、1 つのインターフェイスを複数のダイヤラ プールに割り当てることができます。

ダイヤラ プール内でのインターフェイスのプライオリティを設定するには、このコマンドの priority オプションを使用します。

interface BRI0
   no ip address
   encapsulation ppp
  
 ! -- このインターフェイスのデフォルトのカプセル化が PPP であることを指定します。
   ! -- BRI0 は PPP カプセル化を使用していますが、B チャネルで動作している実際のカプセル化は、
   ! -- このインターフェイスにバインドされたダイヤラ プロファイルで設定された 
   ! -- カプセル化によって決定されます。

   dialer pool-member 10 priority 100

   ! -- BRI 0 はプール 10 のメンバです。

  !
  interface BRI1
   no ip address
   encapsulation ppp
   dialer pool-member 10 priority 50
   
! -- BRI 1 はプール 10 のメンバです。
   ! -- プライオリティは BRI 0 よりも低いことに注意してください。

   dialer pool-member 20 priority 100
   
! -- BRI 1 はプール 20 のメンバです。
   ! -- プライオリティは BRI 2 よりも高いことに注意してください。

  !  
  interface BRI2
   no ip address
   encapsulation x25
  
 ! -- BRI2 は X.25 カプセル化を使用していますが、 
   ! -- B チャネルでチャネルで動作している実際のカプセル化は、 
   ! -- このインターフェイスにバインドされたダイヤラ プロファイルで設定された
   ! -- カプセル化によって決定されます。

   dialer pool-member 10 priority 10

   ! -- BRI 1 はプール 10 のメンバです。
   ! -- プライオリティは BRI 0 および BRI 1 よりも低いことに注意してください。

   dialer pool-member 20 priority 50

   ! -- BRI 2 はプール 20 のメンバです。
   ! -- プライオリティは BRI 1 よりも低いことに注意してください。

   dialer pool-member 30
   ...
   ...
   ...

注:CLID または DNIS ベースのバインディングを実行できない場合、物理インターフェイスでコマンド encapsulation pppppp authentication chap | pap [callin] および ppp multilink(該当する場合)を設定する必要があります。 

dialer pool-member オプション コマンドのパラメータには次のものがあります。

パラメータ 説明

number

ダイヤラ プーリング番号を設定します。1 〜 255 の 10 進数の値です。

priority number

ダイヤラ プール内の物理インターフェイスのプライオリティを設定します。ダイヤルアウトにはプライオリティの高い番号のインターフェイスが最初に選択されます。1 〜 255 の 10 進数の値です。値が大きければ、プライオリティが高いことを示します。

これが必要であるのは、発信コールに関して物理インターフェイスでコンテンションが存在する場合だけです。

min-link number

インターフェイス上の ISDN B チャネルは、このダイヤラ プール用に予約されています。1 〜 255 の数値です。シンプルなチャネル予約システムとして使用できます。

max-link number

このダイヤラ プール用に予約されているインターフェイス上の ISDN B チャネルの最大数を設定します。1 〜 255 の数値です。




ダイヤラ プロファイルの設定例

ダイヤラ プロファイルを使用した包括的な設定例については、『ダイヤラ プロファイルを使用した ISDN 用 DDR バックアップの設定』を参照してください。

PPP 以外の設定例については、次のドキュメントを参照してください。



チューニングとオプションのコマンド

チューニングとオプションのコマンドの詳細は、ドキュメント『ダイヤラ プロファイルのコマンドを使用したピアツーピア DDR』を参照してください。



ダイヤラ プロファイルの動作の確認

show interface dialer1 コマンドを使用すると、着信および発信コールに関する次のような情報が表示されます。

Router# show interfaces dialer1
Dialer1 is up, line protocol is up (spoofing)

! -- ダイヤラ インターフェイスは up/up(スプーフィング)です。
! -- ダイヤラ インターフェイスへの経路がルーティング テーブルに残るように、 
! -- ダイヤラ インターフェイスは常に up(スプーフィング)になっています。
! -- 以下の注を参照してください。

  Hardware is Unknown
  Internet address is 1.1.1.1/24

  ! -- ダイヤラ インターフェイスの IP アドレス。

  MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255
  Encapsulation PPP, loopback not set

  ! -- ダイヤラ インターフェイス上のカプセル化。

  DTR is pulsed for 1 seconds on reset
  Interface is bound to BRI0:1

  ! -- このダイヤラは 1 B-channel にバインドされます。 

  Last input 00:00:38, output never, output hang never
  Last clearing of "show interface" counters 00:05:36
  Queueing strategy: fifo
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     38 packets input, 4659 bytes
     34 packets output, 9952 bytes
Bound to:
BRI0:1 is up, line protocol is up


! -- Dialer1 のバインド先である B-channel。

  Hardware is BRI
  MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255
  Encapsulation PPP, loopback not set, keepalive not set
  Interface is bound to Dialer1 (Encapsulation PPP)

  ! -- ダイヤラ プロファイルにより適用されたカプセル化。

  LCP Open, multilink Open
  Last input 00:00:39, output 00:00:11, output hang never
  Last clearing of "show interface" counters never
  Queueing strategy: FIFO
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     78 packets input, 9317 bytes, 0 no buffer
     Received 65 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     93 packets output, 9864 bytes, 0 underruns
     0 output errors, 0 collisions, 7 interface resets
     0 output buffer failures, 0 output buffers swapped out
     4 carrier transitions

注:ダイヤラ インターフェイスは常に少なくとも up/up(スプーフィング)になります。「スプーフィング」という言葉は、回線は実際にはアップにはなっていませんが、上位レベルのプロトコルが期待どおり動作し続けるように、回線が「アップ」であると装うようにダイヤラが強制していることを意味します。スプーフィングは、DDR の動作を許可するために追加された状態です。インターフェイスは、ルーティングされるパケットに応答して「ダイヤルオンデマンド」を行います。「ダウン」のインターフェイスにはパケットはルーティングされないため、たとえインターフェイスが接続されていない場合であっても、インターフェイスにパケットがルーティングされるよう、インターフェイスはアップを装う(スプーフする)必要があります。スプーフィングは、ダイヤルオンデマンド インターフェイス上では通常の状態です。



ダイヤラ プロファイルのトラブルシューティング

症状 debug
コマンド
解決策

ダイヤルが行われない

debug dialer

対象トラフィック、ルーティング設定、ダイヤラの電話番号およびダイヤラ プールの設定を確認します。

着信コールが正しく接続されない

debug dialer

3 つのバインディング ステップのいずれかが成功するかどうかを確認します。

コールの接続解除が早すぎるか、またはコールの接続がまったく解除されない

debug dialer packet

対象パケットの設定を確認します。


レガシー DDR と同じように、ダイヤラ プロファイルの問題をデバッグするための最も適切なコマンドは debug dialer です。コールが成功した場合、デバッグでは、記録されているメッセージ以外のものは表示されません。失敗した場合は、原因になり得る数多くの問題が存在します。



ダイヤルが行われない

debug dialer をオンにして、ピアへの対象トラフィックを生成します。ルータはダイヤルを試行する必要があります。出力例を次に示します。

maui-soho-01#ping 10.1.1.1

     Type escape sequence to abort.
     Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:

     *Mar 1 00:24:47.242: BR0 DDR: rotor dialout [priority]
     *Mar 1 00:24:47.250: BR0 DDR: Dialing cause ip (s=192.168.1.1, d=10.1.1.1)
     *Mar 1 00:24:47.250: BR0 DDR: Attempting to dial 5551111

debug dialer によりデバッグ出力が生成されているかどうかを確認します。debug dialer 出力がまったくない場合、またはバインディングが失敗する場合、最も可能性の高い原因として、送信している IP パケットがダイヤラ インターフェイスにルーティングされていないことが考えられます。次の手順に従ってください。バインディングについての詳細は、このドキュメントの「ダイヤルアウト」セクションを参照してください。



発信コールのバインディング問題のトラブルシューティング

発信コールのバインディング問題のトラブルシューティングを行うには、次のステップに従います。

  1. ダイヤラ プロファイルがダイヤラ プールと関連付けられていない場合、debug dialer は発信コールに関して次のように出力します。

    *Mar 1 07:20:45.676: Di15: Cannot place call, no dialer pool set
    

    ソリューション:ダイヤラ インターフェイスで dialer pool コマンドを設定します。

  2. 物理インターフェイスがどのプールとも関連付けられていない場合、発信側ルータのデバッグ メッセージは、これ以上物理インターフェイスが使用できない場合と同じになり、ファースト アイドル タイマーのトリガーの原因になります。

    *Mar 1 11:54:14.937: Di15: No free dialer - starting fast idle timer
    

    ソリューション:物理インターフェイスで dialer pool-member コマンドを設定し、物理インターフェイスをダイヤラ プールに関連付けます。



発信コールのルーティング問題のトラブルシューティング

ダイヤラ プールの設定が正しいことを確認してから、次の作業を行います。

  1. ダイヤラ インターフェイスに IP が設定されていることを確認します。インターフェイス上の IP アドレス、ip unnumbered type numbertype number は、ルータが割り当て済み IP アドレスを持っている別のインターフェイス)または ip address negotiated のいずれかが必要です。

  2. コマンド ip routing が設定されているかどうかを確認します。show running-config コマンドを使用して設定を調べた際には、コマンド no ip routing が設定されているとは表示されないはずです。

  3. ダイヤラ インターフェイスに向かうスタティック ルートが存在することを確認します。次の例は、ネクストホップ Dialer 1 を持つ 172.22.53.0/24 へのスタティック ルートです。

    maui-soho-01(config)#ip route 172.22.53.0 255.255.255.0 dialer 1
    
  4. ダイヤラ インターフェイスがシャットダウン状態ではないことを確認します。show interface dialer interface コマンドを使用してインターフェイスが up/up であることを確認するか、ダイヤラ インターフェイスの設定に no shutdown が存在するかどうかを確認します。



デバッグは出力されても、「Attempting to Dial」メッセージがない

このケースでは、おそらく IP パケットはインターフェイスにルーティングされていますが、なんらかの理由でルータがそのパケットを廃棄するため、コールが開始されません。コールが試行されない原因を突き止めるために、debug dialer 出力を確認します。次に debug dialer により示される問題と考えられる原因をいくつか示します。

例 1

*Mar  1 00:07:22.255: Di1 DDR: ip (s=10.1.0.1, d=192.168.201.1), 
       100 bytes, outgoing uninteresting (no dialer-group defined).

ダイヤラ インターフェイスに dialer-group が設定されていません。次の例のように dialer-group を追加します。

 interface Dialer1
       dialer-group 1

例 2

*Mar  1 00:08:24.919: Di1 DDR: ip (s=10.1.0.1, d=192.168.201.1), 
       100 bytes, outgoing uninteresting (dialer-list 1 not defined).

ダイヤラ インターフェイスに dialer-group 文がありますが、参照されている dialer-list が存在しません。次の例のように dialer-list を設定します。

dialer-list group-number protocol ip permit

注:group-number の値は、dialer-group group-number で設定されている値と同じである必要があります。 この例では、dialer-list 1 を設定します。

例 3

*Mar  1 00:25:32.551: Di1 DDR: ip (s=10.1.0.1, d=192.168.201.1), 
       100 bytes, outgoing interesting (ip PERMIT)
     *Mar  1 00:25:32.555: Di1 DDR: No free dialer - starting fast idle timer.

このケースでは、発信パケットはリンクをアップする対象トラフィックと見なされていますが、コールの発信に利用できる物理インターフェイスがありません。物理インターフェイスで dialer pool-member number が設定されていて、ダイヤラ インターフェイスでは dialer pool number が設定されていることを確認します。例:

interface BRI0
      dialer pool-member 1
     !
     interface Dialer1
      dialer pool 1

また、物理インターフェイスがシャットダウン状態にないことも確認します。その物理インターフェイスで no shutdown コマンドを使用します。

例 4

*Mar  1 00:37:24.235: Di1 DDR: ip (s=10.1.0.1, d=192.168.201.1), 
       100 bytes, outgoing interesting (ip PERMIT)
     *Mar  1 00:37:24.239: Di1 DDR: Cannot place call, no dialer string set.

このケースでは、ダイヤラ インターフェイスで dialer string dial-string が設定されていません。ルータはコールを発信しようとしますが、発信する番号が不明です。次のように dialer-string を定義します。

interface Dialer1
      dialer string 8134


着信コールが正しく接続されない

ダイヤラ プロファイルに伴うコールの失敗の原因は、物理インターフェイスを、そのコールのダイヤラ インターフェイスにバインドする際の問題である場合があります。上記の「ダイヤルイン」セクションで説明されているバインディングの条件のいずれかを、ルータが満たしていることを確認します。次の手順に従ってください。

  1. ダイヤラ プロファイルがダイヤラ プールと関連付けられていない場合、debug dialer では着信コールに関して次のように出力されます。

    *Mar 1 11:51:24.873: BRI0:1: 
    Authenticated host HQ-NAS with no matching dialer profile
    

    ソリューション:ダイヤラ インターフェイスで dialer pool コマンドを設定します。

  2. バインドの試行は 4 回行われることに注意してください。複数のダイヤラ プロファイルが存在すると想定すると、CLID および DNIS のバインドの試行は失敗し、PPP 認証は設定されません(これで 4 回目のテストの可能性が高まります)。着信側ルータでは、次の debug dialer メッセージが生成されます。

    *Mar 1 11:59:36.521: ISDN BR0:1: Incoming call rejected, unbindable
    

    ソリューション:物理インターフェイスで ppp authentication chap | pap [callin] を設定します。

  3. 物理インターフェイスで PPP 認証がイネーブルになっている場合、4 回目のバインドの試行は進行します。ルータは、認証されたユーザ名を使用して、ダイヤラ プールにあるダイヤラ インターフェイスのいずれかへのバインドを試行します。その試行が失敗した場合、着信側ルータでは次のデバッグが表示されます。

    *Mar 1 12:03:32.227: BRI0:1: 
    Authenticated host HQ-NAS with no matching dialer profile
    

    ソリューション:ダイヤラ インターフェイスで dialer remote-name コマンドを設定します。指定された名前は、リモート ルータから認証のために提示されるユーザ名と正確に一致する必要があります。この例では、認証されるユーザ名は HQ-NAS です。



コールの接続解除が早すぎるか、またはコールの接続がまったく解除されない

コールの接続が不意に解除されるか、またはコールの接続がまったく解除されない場合は、ダイヤラのアイドル タイムアウトおよび対象トラフィック定義をチェックします。特定のパケットが対象かどうかを確認するには、debug dialer packet コマンドを使用します。次に例を示します。

Apr 26 01:57:24.483: Di1 DDR: ip (s=192.168.1.1, d=224.0.0.5), 64 bytes,
  outgoing uninteresting (list 101)
Apr 26 01:57:26.225: Di1 DDR: ip (s=192.168.1.1, d=10.1.1.1), 100 bytes,
  outgoing interesting (list 101)

上記の例では、Open Shortest Path First(OSPF) hello は access-list 101 によると非対象となりますが、2 番目のパケットは access-list 101 によると対象となります。

  1. ダイヤラ インターフェイス設定の dialer idle-timeout を調整します。デフォルトは 120 秒ですが、必要に応じてこの値を大きくしたり小さくできます。

  2. dialer-list コマンドで設定される)対象トラフィック定義を変更します。コールの接続解除が早すぎる場合は、対象トラフィックの定義を緩和します。コールの接続がまったく解除されない場合は、対象トラフィックの定義をより限定的なものに変更します。たとえば、ルーティング プロトコル トラフィックを非対象として定義できます。次に対象トラフィック定義の例を示します。

    access-list 101 remark Interesting traffic for dialer-list 1
    access-list 101 deny ospf any any
    
    !--- 対象外として OSPF をマーキングします。これで、OSPF hello によって
    !--- リンクがアップに保たれません。
    
    access-list 101 deny udp any any eq ntp
    
    !--- NTP トラフィックを非対象として定義します。
    !--- これにより、周期的な NTP トラフィックによってリンクが無期限にアップに
    !--- 保たれることはありません。
    
    access-list 101 permit ip any any
    
    !--- その他の IP トラフィックはすべて対象とします。トラフィックのニーズに応じて
    !--- これを変更してください。
    
    dialer-list 1 protocol ip list 101
    

詳細は、ドキュメント『ダイヤルアップ テクノロジー:概要と説明』を参照してください。




関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


関連情報




Document ID: 10219