 |
||
|
■Novell NetWare in DDR Environments
November 1995
概要
ルーティングテーブルの生成やシステムのアップデートのような通常のネットワークの動作によって、トラフィックが増加し、帯域が消費されます。LANではこのようなトラフィックを扱うのに十分な帯域を持っています。しかし、ISDN(Integrated Services Digital NetWork)のようなWANを使うときは好ましくありません。オン・ディマンドルーティングのソフトウェアがせっかくWAN サービスを効率よく利用しようとしているのに、正常なネットワークによって生み出されたトラフィックが過度の発呼を招いたり、回線を使うなど、コスト効果が破られてしまいかねません。DDR(dial-on-demand)を使ってノベルNetWareのLAN間接続をしようとする人が直面するそれら問題をシスコはよく認識しています。シスコはこれらの問題を解決することではパイオニア的な存在であり、Cisco IOS(Internetwork Operating Systems)ソフトウェアによって解決策を提供いたします。この資料は、ダイアルアップ環境におけるノベルNetWareの動作について考察し、ダイアルアップ時に回線が接続し続ける原因となるNetWare独自の問題とシスコによる解決策について説明します。序論
ノベルNetWareをDDRを使用したWAN上で動作させる場合、幾つかの考慮すべき問題があります。１つはルーティングの問題で、ルーティングアップデートが起因しています。ノベルNetWareは頻繁にルーティングやサービスに関するアップデートをブロードキャストします。そのため回線は接続し続けてしまいます。ISDNのような高い回線を使用した時、回線が接続し続けると回線コストはかなり高くなります。他のトラフィックでも不必要にDDRのトリガーになり、問題を引き起こします。NetWareは接続している端末に対して定期的に、接続がアクティブであるかとか不正コピーからNetWareのライセンスを守るなどといったチェックをするパケットを送信します。また、ノベルは定期的にマネージメントステーション間で同期を取るためにパケットを送信するという新しいマネージメント構造も導入してきました。シスコはこれらがそれぞれに引き起こす可能性のある諸問題までをも、すべてを認識しています。この資料ではそれぞれの解決方法を記述し、最も適切な解決策を提言します。ルーティングでの問題
RIP(Routing Infornmation Protocol)とSAP(ServiceAdvertisement Protocol)は、ノベルNetWareの構成やIPXプロトコル群において重要なコンポーネントです。ノベルNetWare 3.xや4.xは、デフォルトでRIPとSAPを60秒間隔でブロードキャストします。NetWareはルーティングやサービステーブル情報を収集するために、このブロードキャストを使用するのです。しかしながら、そのブロードキャストはDDRを接続し、回線が接続し続けます。さらに、それらブロードキャストは回線の帯域を意外と大きく消費するのです。下記で図や例を用いて説明しています。図１はRIPSDLCパケットの構成を示しています。
図１：RIP SDLC Packet Format
フルのRIPシリアルパケットにはそれぞれ、40バイトの決められたヘッダーとSDLC identification情報、そして50個までのネットワーク数（1エントリ当たり8バイト）が含まれます。（もし合計が50で割り切れない時は、一連の最後のパケットは50個のネットワーク数より少ないかもしれません。）
50個のネットワーク数を持つフルのRIPパケットは、40バイトのヘッダーとindentificationに加えて400 （50*8）バイトのデータで、トータル440バイトになります。ビットに変換し、ネットワーク上で動作するパケット数を掛けることにより、いかにそれらのパケットがネットワークの帯域を消費しているかが簡単に読み取れます。
下記の例は、50, 200, 1000個のルート（ネットワーク）における帯域の消費の増加を説明しています。ただし、60秒間隔でフルのRIPをベースにしています。
例１：50個のRIPルート（1個のフルRIPパケットの場合）
ビット換算：440×8 = 3520
BPS（Bits Per Second）：3520/60 = 59 bps
例２：200個のRIPルート（4個のフルRIPパケットの場合）
59×4 = 236 bps
例３：1000個のRIPルート（２０個のフルRIPパケットの場合）
59×20 = 1180 bps
図２はSAP SDLCパケットの構成を示しています。
図２：SAP SDLC Packet Format
SAP SDLCパケットは7個のSAP（1エントリ当たり64バイト）とヘッダーが含まれています。7個のSAPエントリを持つフルのSAPパケットは、40バイトのヘッダーとidentificationデータと合わせてトータル488バイトとなります。RIPパケットと同様にSAPパケットはこの最大バイト数一杯か、あるいは7で割り切れない場合は、部分的に詰まったパケットになります。
下記に示す例はSAPパケットをバイトからビットへ変換し、ネットワーク上で50, 200, 1000個のSAPサービスごとに帯域消費の増加について示しています。そして、高速回線上でパケットを送信するためにかかる時間を示しています。
例１：50個のSAPサービス
50個のSAPパケット = 7個のフルパケットと1エントリのSAPを持つ1個のパケット
7個のフルパケット：7 × 488 = 3416
1個のSAPを持つ１パケット：40 + （1×64） = 104
トータルバイト数：3420
ビット換算：3420 × 8 = 28,160
トータルBPS：28,160/60 = 469 bps
例２：200個のSAPサービス
200個のSAPパケット = 28個のフルパケットと4エントリのSAPを持つ1個のパケット
28個のフルパケット：28 × 488 = 13,664
4エントリのSAPを持つ１個のパケット：40 + （4×64） = 296
トータルバイト数：13,960
ビット換算：13,960 × 8 = 111,680
トータルBPS：111,680/60 = 1861 bps
例３：1000個のSAPサービス
1000個のSAPパケット = 142個のフルパケットと6エントリのSAPを持つ1個のパケット
142個のフルパケット：142 × 488 = 69,296
6エントリのSAPを持つ1個のパケット：40 + （6×64） = 424
トータルバイト数：69,720
ビット換算：69,720 × 8 = 557,760
トータルBPS：557,760/60 = 9296 bps
RIPとSAPのアップデートはそれぞれ１分毎に発生することから、WAN回線に与える影響というものを考えるもう一つの手法として、毎分発生する送信に費やされる時間に着目してみましょう。次の例は、19.2kbps、56kbps、64kbpsでの回線速度で、60秒間隔で1000個のSAPを送信したときに係る時間を算出しています。
例４：19.2 kbps上で1000個のSAPを送信した場合
557,760/19.2 kbps = 29 秒
この例では、19.2kbpsで1000個のSAPを送信するのに、およそ１分の半分かかることを示しています。
例５：56kbps上で1000個のSAPを送信した場合
557,760/56 kbps = 10 秒
この例では、56kbpsで1000個のSAPを送信するのに、およそ10秒間かかることを示しています。
例６：64kbps上で1000個のSAPを送信した場合
557,760/64 kbps = 8.7 秒
この最後の例は、64kbpsで1000個のSAPを送信するのに、およそ8秒を越える時間がかかることを示しています。
これらの例はRIPやSAPにより増加したパケット数やパケット送信時間を考えた回線上の帯域の必要性を示しています。例４では、19.2kbps上で1000個のSAPを送信した場合、回線のおよそ半分がSAP情報の送信で占められています。
しかし、それらプロトコルの動作を緩和できるなら、DDR上でのノベルIPXを使うコストを抑えられます。シスコでは、DDRのトリガーになるルーティングのアップデートを減少あるいは削除する以下の解決策を提供しています。
- ルーティングアップデート間隔を延ばす。
- スタティックルーティングテーブルを作成し、ルーティングアップデートのためのパケットを不要とする。
- スナップショットルーティングによって動的な経路学習（ダイナミックルーティング）は実現するが、任意の一定時間毎に短い時間でアップロード情報を交換するようにする。
- フローティングスタティックルートを設定する。この解決策は、スタティックルーティングテーブルを構成するのと一見似ていますが、そうではなくダイナミックルーティングで動作している回線に対してDDR回線をバックアップや迂回経路として用いる時に使用する機能です。
IPX RIPのブロードキャストの送信間隔を延ばす
ノベルIPX RIPが動作しているルータやNetWareサーバはルートが生きているかどうか確認するためにブロードキャストメッセージを使います。デフォルトで、このブロードキャストは60秒間隔で送信されます。RIPブロードキャストメッセージの送信間隔を延ばすことはWANの帯域確保の1つの方法であり、DDR回線の使用率を減少させます。Cisco IOSはブロードキャストの送信間隔を変更できる機能があります。DDR回線の両端でこの送信間隔を延ばすことで回線使用率が減少します。Cisco IOSのipx update-timeコマンドがこの機能を提供します。なお、DDRの両側で同じIPXアップデート間隔を設定してください。しかしながらこの解決策は、ネットワークの動的変化への追従という面では否定的です。なぜなら、ネットワークにあるすべてのルータがネットワーク構成の変化を学習するためにかかる時間が増加するからです。ゆっくりとした収束は、ルーティングのループ状態のような問題を起こしかねません。
IPX SAPのアップデート間隔を延ばす
通常のRIPブロードキャストと同様に、SAPアップデートでもサーバとルータが各々ブロードキャストします。NetWareはインターネットワークを通して知られているサービスの情報を提供するためにSAPアップデートを使います。デフォルトで、サーバとルータは各々60秒毎にサービスのリストをブロードキャストします。Cisco IOSはSAPアップデートの送信間隔を変える機能を提供します。SAPアップデート間隔を延ばす増やすことは、有効なサービスの変化を学習する時間も増えることになります。そして、早くネットワークを通じて新しいサービスを知らせるには否定的です。ipx sap-intervalコマンドでこの機能が使えます。SAP間隔はDDR回線の両側で同じ間隔を延ばしてください。間隔を均一な値にしないと、あるサービスはサービステーブルから落ち、そして、使えなくなります。
スタティックルーティングテーブルの作成
RIPやSAPのブロードキャストメッセージから回線を接続させないようにする１つの方法として、スタティックルーティングテーブルを使う方法があります。これはダイナミックルーティングテーブルを作る機能であるRIPブロードキャストやSAPアップデートの必要性をなくします。Cisco IOSはルートやサービスをスタティックルーティングテーブルに定義する機能を提供します。これは、ipx routeとipx sapコマンドを使います。この解決策は、ルートやサービスの変更が重要な意味を持たないような小さなネットワークに効果があります。しかし、それが欠点でもあります。許されるすべてのルートやサービスの手動による登録は面倒な作業であり、それらのテーブルをメンテナンスすることはネットワーク管理上のオーバヘッドとなります。さらに、スタティックRIPやSAPのルーティングテーブルはしばしば、すべての有効なネットワークやサービスの正しい状態を正確に反映できません。例えば、スタティックに設定されたネットワークがアン・リーチゃブルになっても、ルーティングテーブルを手動でアップデートするまでは、届くと認識され続けてしまいます。
スナップショットルーティングを実行する
スナップショットルーティングは、時間をトリガーにしたルーティングとサービスのアップデート手法です。ある一定のアクティブ時間（図３のT1）内に中央のクライアントルータからダイナミックルーティングやサービス情報を送り、リモートサーバルータがそれを学習することでルーティングやサービスのアップデートを行うのです。このルーティングやサービス情報のスナップショットは、次のアクティブ時間が来るまでの、ユーザが定義したクワイエット時間（図３のT2）は情報を保持しています。もし、ルーティングのアップデート情報が次のアクティブ時間に交換されなかったら、ユーザが設定したリトライ時間（図３のT3）がカウントを開始し、再びルーティング情報を交換する前にもう1回クワイエット時間が過ぎてしまうことを防ぎます。例えば、相手の回線がふさがったり、インタフェースが他への接続で使えない状態であったりした時、T3カウンタがスタートするのです。
図３．スナップショットルーティング
スナップショットルーティングは下記にあるルーティングプロトコルで使えます。
- ノベルRIP、SAP
- IP RIPとIGRP
- アップルトーク RTMP
- バニヤンVINES RTP
スナップショットルーティングはDDRの一方の側でsnapshot clientコマンドを使い、もう一方の側ではsnapshot serverコマンドを使います。さらに、active, quiet, retry時間のパラメータを設定する必要があります。
イベントトリガールーティング
スナップショットルーティングはタイムスケジュールを使ってアクティブ時間を起動し、その間にルーティングアップデート情報を収集するやり方です。一方、イベントトリガールーティングとして知られる別のアプローチは、ネットワークの状態をベースにしています。これは、RIPやSAPのアップデートをルートやサービスに変化があったときだけWANを越えて送るやり方です。この技術はCisco IOSでは現在提供されていません。しかし、いくつかのニッチベンダーによって提供されています。このソリューションが、どのように動作するか、スナップショットルーティングと比較するとどうなのかを理解することは重要なことです。
イベントトリガールーティングでは、ネットワークにおけるルートやサービスに変化がある度に、RIPやSAPの交換を行うためにDDR回線を接続します。スナップショットルーティングはクライアントによってアクティブにされる時間をユーザがコントロールできますが、イベントトリガールーティングにはこのコントロールはできません。とはいえ、イベントトリガールーティングは、スナップショットルーティングより早くネットワークの変更を反映することができるという特長を持つものの、比較的不安定なネットワークでは、頻繁にトリガーを発生してしまうという問題点があります。イベントトリガールーティングは変化する傾向のないネットワークには最もコスト効果が高く適合する方式です。
フローティング・スタテックルート
伝統的にスタティックルートは同じ宛て先ネットワークへのいかなる動的ルートよりも優先的に扱われるインプリメンテーションが普通でした。これに対して、フローティングスタティックルートは固定的に経路を定義してますが、ダイナミックに学習されたルーティング情報より優先位を下げることができるのです。その結果、フローティングスタティックルートはダイナミックルートが一切存在しなくなった時の最終手段としての経路を提供するのです。フローティングスタティックルートはとても柔軟で確実にルーティングトポロジーを構築することを可能にします。フローティングスタティックルーティングが効を奏するアプリケーションの一例として、DDRを使ったトポロジーにおけるバックアップルートを提供できることがあります。図４はバックアップルートのための構成を説明しています。
図４．ノベルIPXでのバックアップルート
このシナリオで、ネットワーク１からネットワーク２への好ましいパスは、ルータＡとＢにある専用回線です。しかし、ルータＡからルータＣと通ってISDNを使ったダイアルアップを使用してルータＢに届く代替パスも持ちます。
フローティングスタティックルートをルータＡに設定することで、ルータＡとＢ間の専用回線上に障害が発生した場合、ルータＡがネットワーク１からのトラフィックをルータCに転送するようになります。やはりフローティングスタティックルートが設定されたルータＣは、その受信したトラフィックをルータBそしてネットワーク2へと転送するためにISDN回線をダイヤルアップ接続します。
ルータＡとルータＢ間の専用回線が回復すると、ダイナミックルーティング情報はフローティングスタティックルートより優先度が高くなり、トラフィックは再び最初の専用回線のパスを使うようになります。Cisco IOSは、ipx routeコマンドのオプションでフローティングスタティックルートを提供します。
接続時の問題
ノベルNetWareは、ネットワークのオペレーションや効率を維持するための情報を頻繁にアップデートするタイプのネットワークオぺレーティングシステムです。同様にルータによるルーティング情報のアップデートパケットも頻繁に送信されます。それらの周期的なアップデートも交換回線のトリガーになり、そしてそれらを使うことは通信コストを割高なものにします。このようなアップデートにもう１つNetWare IPX Watchdogがあります。これは、NetWareクライアントの接続状態を監視するためのプロトコルでレスポンスに失敗したときはレポートも送信します。
パケットの順番の到着保証を要求するネットワーク・アプリケーションには、ノベルSPXプロトコルが使われます。このプロトコルでもクライアントとサーバ間でKeep aliveメッセージを送信します。さらに、NetWareオぺレーティングシステムはソフトウェアを不正コピーして、複数のサーバを運用することからNetWareのライセンスを守るために、ユニークなシリアライゼーテョン番号を含んだパケットを送信するコピープロテクション機構が組み込まれています。
ネットワークのコストを減少させるためにこれらの課題は以下のように解決できます。
- NetWare Watchdog のアップデートパケット間隔を延ばす
- SPXプロトコルのkeepaliveタイマーを変更する
- IPX Watchdogの代理応答を可能にする
- SPX keepaliveの代理応答を可能にする
- NetWareシリアライゼーテョンパケットをフィルターする
ウォッチドック・アップデートパケットの送信間隔を延ばす
ノベルNetWareオぺレーティングシステムには、NCP(NetWareCoreProtocol)の１つであるウォッチドックプロトコルがあり、ステーションのコネクションがアクティブか周期的に確認し、コネクションがレスポンスを返さないと、システムにアップデートを送信します。そのシステムはウォッチドックのレポートから相手が動いていないとしてコネクションをクローズします。それらアップデートパケットは、回線交換の使用時間を増やし、その結果コストも増えます。回線を接続する時間を減少させる方法の１つとして、ウォッチドックアップデートパケットの数を減少させることであります。ウォッチドックプロトコルは３つのパラメータを持ち、それはファイルサーバのコンソールから設定できます。
set delay bedore first watchdog packet = n
set delay between watchdog packets = n
set number of watchdog packets = n
デフォルトでは、ウォッチドックのサーバとクライアント間での送信間隔は４分56.6秒です。これは、ウォッチドックアップデートパケットを送信した後からカウントします。もし、ワークステーションが決められた間隔に応答しなかったなら、ウォッチドックパケット間の送信間隔はデフォルトで59.3秒となりますが、この値は15.7～２0分52.3秒の間で変更できます。この時、デフォルトで10個のパケットを送信しますが、この値も５から100個まで変更できます。
IPXウォッチドックの代理応答を可能にする
NetWareのパラメータを再設定する代わりに、Cisco IOSではルータがリモートクライアントのために、サーバのウォッチドックのリクエストに対してレスポンスする機能を提供しています。このプロセスはNCPあるいはIPX代理応答と呼ばれてます。IPX代理応答のメリットを下記に示します。- 問い合わせに対するローカルアクノリッジ
- レスポンスで接続しない
- リンクの効果的な利用
- 最小限のオぺレーション
図５．IPXウォッチドック代理応答
あるケースではIPX代理応答を使うと、NetWareサーバは実際はそうでなくてもセッションがまだ生きていると信じてしまうというケースが起きます。そしてIPXあるいはSPXのセッション数が上限に達してしまい、本当のユーザにログインを与えられないという接続上の問題が起こります。NetWareが持つ自動ログオフ機能がこの可能性を減少させてくれるので、安心してipx watchdog spoofコマンドによるIPX代理応答機能を使ってください。
SPXコネクションが確立していて送信するデータがない時、接続の両側でkeepaliveリクエストを交換します。
デフォルトでは、keepaliveはNetWare3.xでは３秒ごと、Netware4.Xでは６秒ごとに交換します。サーバ上のタイマーは変えることはできません。しかし、クライアント側のkeepaliveタイマーはNET.CFGを編集することとSPX Verify TimeoutやSPX Abort Timeoutのパラメータをいじることで変更できます。
SPX Abort Timeoutのデフォルトの値は、540ティック、IPX Verify Timeoutは54ティックです。１ティックは1/18秒と同じです。それらのパラメータは65,000ティックまで、あるいは約１時間毎に１つのkeepaliveを送信するようにできます。
SPX Keepaliveの代理応答を可能にする
重要な帯域を消費し、パケット毎に回線使用料が高くなる SPX Keepaliveの交換から防ぐもう１つの方法は、SPX代理応答を使用することです。これは、Cisco IOSの機能で、ルータはSPXアプリケーションに代わり、keepaliveパケットに応答します。SPX代理応答機能は、まだNetWareの接続があるのにWANにパケットを送りません。図６の構成はルータＡにNetwork100のイーサネットとNetwork1のISDNがつながっています。
図６：SPX代理応答
ルータＡとルータＢの両方とも、SPX keepaliveの代理応答が必要です。ルータＡはNetwork100の代理応答をし、ルータＢはNetwork200の代理応答をします。ISDNインタフェースはルータＢとそのクライアントをルータＡに接続します。
SPX代理応答はipx spx-spoofコマンドを使います。ルータのキャッシュはこの機能を有効にする前にルートキャッシングをoffにしておくことに注意してください。ipx spx-idle-timeコマンドはkeepaliveパケットの代理応答を始めるまでの時間をセットするために使います。
NetWareシリアライゼーションパケットをフィルターする
NetWareには不正にコピーによる複数のサーバが存在しないようにするコピープロテクト機構が組み込まれてます。それぞれのNetWareサーバはおおよそ66秒間隔でユニークなシリアライゼーション番号が含まれている１つのパケットを送信します（すべてのサーバにユニキャストする）。サーバが同一番号を検知すると、すべてのユーザとコンソールログにコピーライト違反メッセージをブロードキャストします。シリアライゼーションパケットが回線を接続し続ける問題の解決策はそれをフィルターすることです。この解決策はユーザにノベルのライセンス機構の回避策を認めるという欠点があります。無粋な方法ではありますが、フィルターはCisco IOSでサポートしているNetWareシリアライゼーションパケットの問題のたった１つの解決策です。Cisco IOSのaccess-listコマンドを使ってフィルターします。NetWare4.1とそのマネージメントストラクチャ
Novell NetWare4 は、そのオペレーティング・システムの中でディレクトリーサービスの概念を使います。ディレクトリーサービスは、 NetWare4 がネットワーク環境に関する情報のデータベースを造り出すのを可能にしています。NDS(NetWare Directory Services)は、全てのネットワークリソースへのグローバルアクセスを認めるという分散管理機構を供給します。DNSはITU-TX X.500規格に基づいてます。この規格は、インターネットの上で利用できる情報サービスのような、グローバルベースでトランスペアレントにアクセスされる情報を組織化する方法を定義しています。NDSは階層的な、オブジェクト指向アーキテクチャに基づきます。このアーキテクチャは、オブジェクトをノベルがオブジェクトツリーと呼ぶマルチレベル構造で組織し、ディレクトリツリーは極めて構造的で、情報が蓄えられたディレクトリオブジェクトを定義するディレクトリスキーマによって定められています。ディレクトリオブジェクトは実際の、そして論理的なリソースであり、コンテナオブジェクトに蓄えられています。階層構造をもちつづけながら、コンテナオブジェクトはディレクトリツリーのアイテムに関連付けてストアされたグループにさらに分割されています。それぞれのタイプのオブジェクトには、ある特性や値が割り付けられ、ログインネームやe-mailアドレス、サーバーアドレスやその他の情報の検索や管理が容易になっています。ディレクトリオブジェクトは管理ユーティリティやディレクトリパーティションの概念によって管理されています。ディレクトリパーティションは階層構造を持ち、ディレクトリの情報を蓄えたりレプリカするためにディレクトリツリーの中で独自のデータユニットとされます。パーティションは、重なり合うことや他のパーティションに存在することができない関連したデータのユニークな塊を入れます。オブジェクトは１つのパーティションにだけしか存在できませんが、制限なくコピーやパーティションのレプリカを持つことができます。レプリカは、ネットワークで NetWare4 サーバーでも蓄えられることができます。
あるパーティションのオブジェクトに変化が生じたなら、特にネットワーク全体に多くのパーティションのレプリカがあるような場合は何が起きるでしょう。答えは単純です。変化は、全てのレプリカに反映されます。難しいのは、同期を保証することです。時間同期をセットアップすることは NDS の中の重要な作業です。
NDSは変化が起こったかどうかを個々のサーバのレプリカリストを定期的にモニタすることで監視し、イベントを認識するユニークなコードでそれぞれのイベントにタイムスタンプします。タイムスタンプを使うことで、イベントの正しい順序を確立し、期限日付をセットし、時刻を記録します。４種類のタイムサーバがあります。
- レファレンスタイムサーバ(Reference Time Server)
- 自分のハードウェアクロックから時間を手に入れて、セカンダリタイムサーバやクライアントに渡す。
- プライマリタイムサーバ(Primary Time Server)
- 少なくとも1つの他のプライマリタイムサーバかレファレンスタイムサーバからの時間を使って、ネットワークの時刻を同期させる。
- セカンダリタイムサーバ(Secondary Time Server)
- レファレンスタイムサーバかプライマリタイムサーバから時間を受け取り、クライアントに渡す。
- シングルレファレンスタイムサーバ(Single Reference Time Server)
- 自分のハードウェアクロックから時間を手に入れて、セカンダリタイムサーバやクライアントに渡す。シングルレファレンスタイムサーバはネットワーク上でだた１つのサーバとして存在し、プライマリタイムサーバやレファレンスタイムサーバと共存はできない。
時間同期のトラフィックを減少する
時間同期パケットトラフィクを減少させるには、ユーザはTIMESYSNC.NLMのTimeSyncポーリング間隔を減少させます。しかしながら、ネットワーク構成を変更してDDR回線をまたがって同期をとる必要のあるサーバの数を減らすという作業も必要です。図７ではサーバＥとＡだけが時間同期パケットを交換します。それゆえDDR回線を通したトラフィックを最適していると言えます。下記に時間同期プロセスの概要を示します。サーバはノベルNetWare4.xが動作してます。
図７．時間同期トラフィックを減少させる推奨構成
- サーバＢはセカンダリタイムサーバであり、サーバＡから時間をもらう
- サーバＣとサーバＤはセカンダリタイムサーバであり、プライマリタイムサーバであるサーバＥから時間をもらう。
- サーバＥとサーバＡは両方のネットワークを同期させつづけるため、DDR回線を通して時間同期パケットを交換する。
- タイムサーバタイプはAUTOEXEC.NCFに設定する。
ノベルはインストールやTIMESYNC.NLMやAUTOEXEC.NCFの構成についての手順のためにドキュメントを提供してます。
レプリカ同期トラフィックを減少する 複製やパーティションの配布はNDSを使った同期構造の重要な部分です。この構造は、ネットワークのすべてのサーバに内部ネットワークアドレスを広めることを要求します。トラフィックを減少させるには、ユーザはDSFILTER.NLMやPINGFILTER.NLMにある情報を編集することでできます。DSFILTER.NLMはNDSトラフィックをいつDDR回線上で行うかをコントロールするタイムウィンドを設定します。このファイルはDDRの両側にあるリモートサーバの内部アドレスを要求します。PINGFILT.NLMもどのNDSサーバファイ ルをフィルターするか決めるために、それらのアドレスを使います。
図８はDDRネットワーク上で時間同期パケットを減少するための推奨構成で、レプリカ同期トラフィックをどのようにして減少するか説明しています。 PINGFILT.NLMはサーバA,B,C,DとEで動作しています。
図８：レプリカ同期トラフィックを減少させる推奨構成
次にレプリカ同期プロセスの概要です。
- サーバA,B,C,D,Eは同じディレクトリツリー上にある。
- サーバＥはマスタNDSエントリを含む。
- 他のすべてのサーバはレプリカを持ち、そのレプリカはマスタと同期をとる。
DSFILTER.NLMはNDSトラフィックがいつDDR上を通すか（時間や曜日）を設定します。サーバC,D,Eの内部ネットワーク番号はサーバA,Bのフィルターアドレスのリストに含まれています。サーバC,D,Eの内部ネットワーク番号はサーバA,Bのアドレスフィルターのリストに含まれています。サーバA,Bの内部ネットワーク番号はサーバC,D,Eのアドレスフィルターのリストに含まれています。ノベルのアプリケーションノートには、DSFILTER.NLMやPINGFILT.NLMをどのようにロードするか、そしてどのように変更する必要があるかが説明されています。
リンクステートルーティング－将来あり得るNLSPの拡張
ノベルの新しいルーティングプロトコル、NLSPはIPX RIPやSAPで混雑したネットワークに関する問題に対応しています。あいにく、DDR上の効果はありません。NSLPは隣接していてリザーブしているルートを保持するために、デフォルトで20秒ごとにハローパケットを送信します。ハローパケットはDDR回線を常にアクティブにします。TCP/IPのルーティングプロトコル、OSPFのリンクステートで起こる同じような動作についてRFCでその問題の取り扱いを提唱しています。NLSPはISOのIS-ISやOSPFに密接に関係しています。RFC1793は「デマンドサーキットをサポートするOSPFの拡張」と題して、DDR上でOSPFプロトコルの効果的なオペレーションを可能にする解決策を示しています。それらの強化はDDR回線があるときはOSPFハローパケットやOSPFルーティング情報のリフレッシュの伝達方法や蓄積方法を変えて、アプリケーショントラフィックがなければ 回線をクローズしていられるようにするというものです。
幾つかのルータベンダーはDDR上でのNLSPにおける取り扱いを発表しています。それらの解決策のほとんどが単純にハローパケットの代理応答で、かなり実現的なプロセスと言えます。しかし、NLSPの標準はノベルによって行われてますが、DDR用NLSP拡張の標準化は公にされていません。それら解決策のすべては、独自に定義しており相互互換性はありません。
シスコは、DDR上で効果的に動作するために拡張されたNLSPの標準化が重要であると考えています。標準が定義されて、互換が確認されたならば、シスコはそのソリューションをインプリメントする予定です。その時まで、互換性の問題はスタティックルートを利用することで回避できると考えています。シスコベースのネットワークでは、IPX RIPやスナップショットルーティングでダイナミックルーティングを使うことができます。
結論
ISDNのようなWANサービスでノベルのNetWareのようなおしゃべりなネットワークオペレーティングシステムを使うことは手が出ないほど高価であると考えるかもしれませんが、そうでもないのです。シスコはツ ールと情報とサポートを提供することで効果的なネットワークのデザインと運用についてユーザを支援しま す。ネットワークマネージャーは、NetWareにおける過度なトラフィックがいつ不必要にDDRのスイッチを入れているか認識し、そしてトラフィックを減少させる必要なステップを決定するために、このペーパーの情報を利用してください。