ネットワーク - みる会図書館

1. UNIX MAGAZINE 1998年10月号

連載 /UNIX Communication Notes を簡単に収集できるようにはなっていない。とくに、 RMON ネットワークカ冓築できる。このように、ネットワーク機器へて構成すれば、簡単かっ安価に、しかも古郊章の少ない安定したアクセス・ネットワークを単一の Ethernét セグメントトワークとう隹できる。けることによって、 RMON へのアクセスを運用中のネッと上交すれば分かるように、アクセス・ネットワークを設図 2 は、 out-band 型の RMON システムである。図 1 果的である。一般に out-band 型のシステムとして構築するはうが効用できる。しかし、この種のプロープを利用する場合は、接続すれば out-band 型のシステムとして RMON を利として、ネットワーク管理用のアクセス・ネットワークにクに接続すれば in-band 型のネットワーク管理システム NMS との通信に使われる。これを監視対象のネットワーある。ネットワーク・インターフェイスは、プロープとルのアドレス ()P アドレスなど ) を割り当てない場合もインターフェイスには、ネットワーク・プロトコルレベクに接続する。たんにモニタリングするだけなので、このタリング用のインターフェイスは、尉寸象のネットワーンターフェイスをもっプロープもよく使われている。モニもちろん、モニタリング用とネットワーク用の 2 つのイないプロープでもとくに間題はない。であれは、ネットワーク・インターフェイスが 1 つしかほうがよい。一方、トラフィックの中長期的な観測が目的ティングにあるのなら、このようなプロープは利用しないからである。 RMON のおもな用途がトラブル・シュー生じると RMON にアクセスできなくなるおそれがある理方式になるので、管理対象のネットワークにトラブルがトワークを使う、いわゆる in-band 型のネットワーク管うのも、 NMS から RMON へのアクセスに運用中のネッ密にいえは言 t 測データに誤差か生しる可能がある。といの両方に同しインターフェイスカ硬われる。この場合、厳は、 NMS とのデータのやりとりと、ネットワークの監視イスが 1 つしかないものもある。このようなプロープで RMON のプロープには、ネットワーク・インターフェするのはほは不可能である。プル間の関係も複雑なので、意味のあるデータを手イ 1 喋で収集 MIB ではさまざまなテープルが数多く定義されており、テー 12 図 2 out-band 型 R 、 10N 構成監視対象のネットワーク運用中のネットワーク RMON プローブ RMON MIB アクセスネットワーク SNMP ロ NMS のアクセス糸習各を別に用意しておくと、障害の発生時にもネットワーク管ま叫幾器にアクセスしやすくなる。ネットワーク機器のコンソールを ANNEX などのターミナル・サーバー経由で孑にしておけは、ネットワーク経由でのアクセスも可能である。 RMON てイ可ができるのか現在、市販されている RMON は、 Ethernet ( 10 / IOOMbps) 、 TokenRing 、 FDDI にヌ寸応している製品がはとんどである。こオ LJ 外のネットワークに対応した製品はまだ少ない。従来のネットワーク・モニタリング機器でできることの大半は、 RMON システムで実行できる。たとえは、各プロトコルごとのバケット数、データ量などの糸兤日青報や、ホスト間での通信量を示すマトリックス表の生成なども可能である。また、特定の条件でフィルタを設定し、それに応したバケットの耳石ムみも可能である。 RMON には、いかにも SNMP らしい機能がある。たとえば、モニタリングする項目について閾値を設定し、計測結果がその閾値を超えたり、下回った場合に、アラームとして SNMP トラップを発生させる。あるいは、複数の NMS からのアクセスを前提としたアクセス制御のオ冓や、排他処理欟冓をもつ RMON も多い。ただし、現在の多くのネットワーク・モニタリング機器カ蒲えているトラフィック生成機能は、 RMON のアーキテクチャでは考慮されていない。ネットワーク・モニタリング機器には、ネットワーク・システムを育証加勺に試験する機能力球められる。しかし、 RMON ではこの機能は UNIX MAGAZINE 1998.10

2. UNIX MAGAZINE 1998年10月号

UNIX Communication Notes RMON ネットワーク管理 ( 8 ) 山口英ネットワークのモニタリンク 10 トワーク・モニタリング機器が数多く市場に出回るよう 1980 年代半はから、 Ethernet などを対象としたネック・モニターから生まれた技術である。 RMON は、ネットワークを茁妾監視するネットワー RM ON の歴史適 ; 融也からのネットワークのモニタリングも可能になる。から SNMP 経由でアクセスする。 RMON を導入すれば、グの結果には、 NMS (Network Management Station れはバケットの町石ムみ (capture) もできる。モニタリント間のマトリックス表などを生成する。さらに、必要があ分布や多三量 ( バケット数、バイト数 ) 、通信量を示すホスワークをモニタリングし、各階層ごと ( ンヾケットの不頁の術に RMON (Remote MONitoring) がある。ネット一方、ネットワークのトラフィックを精密に監視する技用途が考えられる。に、数カ月にわたって帯域使用の状態を監視するといった状態を謌ヾる際に便利である。回線を拡張したい場合などツールである。この種のツーノレは、長期間、継続的に運用ターフェイスごとに定期的に収集し、それをグラフ化するイッチなど ) か処理したバケット数をネットワーク・イン pher) は、 SNMP 対応のルータやネットワーク機器 ( スは、前回紹介した MRTG (Multi Router Traffic Gra- これには SNMP に対応したシステムを利用する。たとえうに各種機器の設定、管理をおこなうことである。通常、は、ネットワークの運用状態を孑当屋し、正常に下力するよこれまでにも繰り返し述べてきたように、構成管理とになった。その代表的な製品が、 Network General の「 sniffer 」 1 である。これらの機器を購入する目的の 1 つは、ネットワーク機器の開発に利用することにあった。モニタリンク饑器を用いて、自社で開発したネットワーク機器やドライバか正しいフォーマットの Ethernet フレームを出しているかを石忍していたのである。その一方で、・モニタリング機器をネットワーク管理に使う人も多かった。たとえば、 TCP/IP と AppleTalk などの複数のプロトコルか混在するマルチプロトコル・ネットワークにおいて、どのプロトコルのバケットがどのくらい流れているかを知るために利用されていた。当時は、モニタリンク饑器を使う以外に、マルチプロトコル環境でトラフィックの状態を把握する手段がなかったからだ。さらに、ネットワーク上で発生したトラブルの原因を突き止めるためにも使われていた。たとえは、ネットワークの負荷が急激に上昇し、システムの応答性が悪化した場合に、 Ethernet の Broadcast storm や meltdown か起こっていないかどうかをモニタリング機器で監視することがよくおこなわれていた。現在では考えられないが、かっては Ethernet インターフェイス・カードや Ethernet トランシーバ自体の不具合でネットワークか変調をきたすことがよくあったのである。ところが、 1990 年代に入ってネットワークの大規模化が進み、 1 つの組織内でも複数の LAN セグメントか相互に接続されたネットワークが一引殳化しはしめた。これによって、ネットワーク管理者にとって頭の痛い問題か生し 1 Network GeneraI は McAfee Associates と合併し、 Network Associates と改称したが、 Sniffer 製品は引続き販売されている。言料田はいの Web ページ (http://www ・ nai.com/) を参照。 UNIX MAGAZINE 1998 ユ 0

3. UNIX MAGAZINE 1998年10月号

図 3 図 4 2 進木アルゴリズム 10.7.255.255 10.4.1 .255 10.4.1.0 10.4.0.0 10.0.0.0 10.255.255.255 2 分探索表 (L) (L) (L) (H) (H) (H) キー > 工ントリの場合 10.0.0.0 10.4.0.0 10.4.1.0 10.4.0.0 10.0.0.0 NETWORKTECHNOLOGY 1 1 ( 2 ) 10.0.0.0 10.4.0.0 10.4.1.0 10.4.1.255 10.7.255.255 10.4.5.60 ←ーーーー - 10.8.9.10 10.255.255.255 prefix length 8 12 24 24 14 flag 10.0.0.0 10.4.0.0 10.4.1.0 10.4.1.255 10.7.255.255 キー = 工ントリの場合 10.0.0.0 10.4.0.0 10.4.1.0 10.4.1.0 10.4.0.0 10.0.0.0 10.255.255.255 8 という 3 つの宛先がある場合、図 3-1 のような 2 分探索表を作成します。すなわち各宛先ネットワークは、 netl : 10.0.0.0 / 8 は 10.0.0.0 ~ 10.255.255.255 net2: 10.4.0.0 / 14 は 10.4.0.0 ~ 10.7.255.255 net3: 10.4.1.0 / 24 は 10.4.1.0 ~ 10.4.1.255 という範囲をもっとして 2 分探索表を作成します。このような経路表を用いると、たとえば 10.4.5.60 、 10.8.9.10 という IP アドレスを検索した場合、これらの IP アドレスに対して正しい経路を与えられることが分かります ( 図 3-2 ) 。図中で "L" (Low) は宛先範囲の最初を、 " Ⅱ " (High) は宛先範囲の終りをそれぞれ示します。これを実際の 2 分探索表にしたものを図 4 に示します。 2 分探索が失敗して終了する場合、検索キーはつねに最終ェントリよりも大きな値になります。したがって "L" 属性をもつ工ントリでは、検索が成功した場合にも失敗した 68 場合にもそのエントリが表すネットワークが宛先ネットワークとなります。一方・・Ⅱ " 属性をもつ工ントリでは、検索が成功した場合にはそのエントリが表すネットワークが、検索が失敗した場合にはそのエントリが表すネットワークよりももう 1 段広い範囲をもつネットワークが宛先ネットワークとなります。旧 prefix が同一で prefix length が異なる宛先ネットワーク経路表には prefix が同一で prefix length が異なる宛先ネットワーク、たとえば、 netl : 10.0.0.0 / 8 net2: 10.0.0.0 / 16 というネットワークが登録される場合があります。このような場合にもこのアルゴリズムは有効です ( 図 5 ) 。経路の更新経路表を新たに構成する場合、もっとも単純な方法は以下のとおりです。 1. 経路制御プログラムから得たすべての経路に対して宛先範囲を示す工ントリを作成し、・・ L " および・・ H " の flag を設定する。 2. 経路を IP prefix ( 宛先ネットワーク ) をキーにして並べ替える。 UNIX MAGAZINE 1998.10

4. UNIX MAGAZINE 1998年10月号

連載 /UNIX Communication Notes— さほど必要とされていなかったからである。 RMON の導入 UNIX MAGAZINE 1998.10 いる。業についてはできるかぎり自動化することカ球められて・ネットワーク管理に携わる人員に余裕がなく、単純な作入にも周囲の理解がある。・ネットワーク管理のための予算か潤沢で、 RMON の導タリングを何回もおこなう必喫がある。・ネットワーク管理作業の過程で、ネットワーク・モニいる。・管理対象のネットワークか地理的に広い範囲に分散して討してもよいだろう。のような条件を満たす管理環境では RMON の導入を検これには、一勺な解答はなさそうである。ただし、次れない。このような竟では、 RMON の導入も有効であるかもししているネットワーク・セグメントがあるのも事実である。ワークの障害を発見するために、モニタリンク機器を接続てもそれほど問題はないと考えたりもする。だが、ネットたら便利だろうと思うケースはあるが、その一方ではなく要かと間われると、判断に迷ってしまう。たしかに、あっなう体制は整っている。このような環竟で RMON が必備してあり、トラブルが発生した際にモニタリングをおこない。しかし、ネットワーク・モニタリング用の機器は準ャンノヾス・ネットワーク内で RMON をいっさい使っていえば、和誑勤務する奈良崙科判支術大凝完々学では、キ RMON 導入の - ⅱ」否を判断するのか難しい点である。たともう 1 つの間題は、監視対象のネットワークにおけるた構成でも数百万円の出費を覚語しなけれはならない。寸・万円もする。 NMS ソフトウェアも高価で、ちょっとしべれは安価になったとはいえ、それでもプロープ 1 台で数 RMON の最大の点は高価なことである。以前にくらからも、数多くの製品が出ている。 sociates の「 NETscout 」などがある。はかのメーカー j 尺であろう。定評のあるものとしては、 Network As- RMON を導入する場合は、製品を購入するのが最良のフリーな RMON プロープフリーウェアの RMON プロープとしては、オランダの DeIft University of TechnoIogy で開発された BTNG (Beholder ー The Next Generation RMON compli- ant Ethernet monitor) が知られていた。しかし、 1994 年のリリースを最後 ( ンヾージョンアップはおこなわれていない。その後、 RMON MIB の標準も改定されたため、点では利用価値はほとんどない。最近は、 SNMP 関連のフリーウェアがはとんどない。 SNMP や MIB の標準か複雑化し、単純には実装できなくなったことや、製品の機能が優れている点が大きく景化ているようだ。しかし、 SNMP に関するフリーウェアがなくなったわけではない。 RMON ー里の PDS やフリーウェアをご存じの方がいたら、編集部気付で私までお知らせいただきたい。 NMS NMS は、 SNMP を用いた管理作業工竟の基盤となるソフトウェアである。 NMS では、次のような処理をおこネットワーク状態の視覚イヒ監視対象のネットワーク機器やホストがポーリングに反応しなくなったり、あるいはトラップを送信してきた場合、これらの機器に問題が発生したことを視覚化して示す。 HP の OpenView (http://www.openview.hp. com/) では、ポーリングに反応しなくなったホスト ( または、そのホストカ材妾続されているネットワーク ) のアイコンを、緑色から赤色に変えて異常を知らせる。さらに、状態の変化についても、いろいろな方法で警告してくれる。たとえは、ポケットベルにメッセージを送信したり、あるいは事前に用意した音声ファイルを使って、「ネットワークに障害が三しています」といった音声による警告も可能である。ネットワーク機器の MIB 変数の監視ネットワーク機器か管理している MIB 変数の値の監視も NMS の重要な機能である。たとえは、 Ethernet で単位日あたりのトラフィックが 5Mbps を超えたら、 Eth- ernet が輻輳状態になったという警告を出したいとしよ 13

5. UNIX MAGAZINE 1998年10月号

0 連載 /UNIX Communication Notes— UNIX MAGAZINE 1998.10 が可能になる。は、どのネットワーク機器でも基本的なモニタリング竹喋カ鯛発された。 RMON MIB に準拠したプロープを使え企業から提案されたアイデアをとりいれて RMON MIB GeneraI などのネットワーク・モニタリング機器関連の toring (rmonmib) WG で標準イゞ進められ、 Network Base) で表現する。 IETF の Remote Network Moni- タリングした結果は MIB (Management lnformation とサーバー間の通信には SNMP を使い、プロープがモニは、 distributed sniffer と同しである。ただし、プロープのが RMON システムである。 RMON の基本的な考え方このアイデアをより一ヨ殳的なものとして構成しなおしたなものであった。ルとデータ表現を用いてはいたが、そのアイデアは画期的実行できた。 distributed Sniffer では、独自のフロトコて、 1 台の Sniffer と同様なことがネットワーク経由でれをグラフィカルに表示する。この両者の組合迂によっプはモニタリングの結果をサーバーに送り、サーバーはそフィルタリングをおこなうかといった指令を出すプローーは、プロープに対して何を監視するのか、どのようなトワーク上に設置さネットワークを監視する。サー (probe) から構成されていた。プロープは監視対象のネッこのシステムは、 1 台のサーノヾーと複数台のプロープ eral が「 distributed Sniffer 」を発売した。らなかった。このような状況にあるとき、 Network Gen- が、モニタリングにはこれといったガ去がなかなかみつか機器の設定変更は SNMP の利用によって解決できるらおこなう方法カ球められていた。りの労力を必要とする。そこで、これらの作業を遘融也か所にう攵しているキャンパス・ネットワークなどではかなットワークならたいした問題ではない。しかし、複数の場はなけれはならなくなったのである。同じビル内にあるネといったイ乍業をおこなう際に、ときとして遠くまで足を運し、ネットワーク・トラフィックを監視する・各ネットワーク・セグメントにモニタリング機器を接続定を変更する・ネットワーク機器のコンソールに端末をつなぎ、機器設散したため、た。ネットワークが大規模化し、物理的に広大な空間に分図 1 RMON の鰔要素プローブ RMON SNMP RMON MIB ~ 、運用中のネットワークロ NMS 新しいデータリンク技術の誕生とネットワーク技術の変遷を受けて、 RMON MIB の標售化竹業は現在も IETF で続けられている。これまでに 3 つの RFC がまとめらすべて標準化トラック (standard track) に入っている [ 1 ー 3 ] 。 RMON の本冓成 RMON は、プロープあるいはモニターと呼ばれる機器と、 NMS から構成される ( 図 1 ) 。プロープは監視対象のネットワーク上に設置さオ L 、そのネットワークを監視する。プロープには特別なハードウェアを使う場合もあれは、一殳的な PC に RMON プロープ・ソフトウェアを入れて利用することもある。特別なードウェアを使うプロープでは、収集したデータを蓄積するために数百 MB のメモリを載せたり、大容量のハードディスクなどを内蔵するものが多い。 NMS については、 RMON システムを販売している企業が独自に開発した製品や、一般的な NMS へのプラグイン・ソフトウェアとして開発されたものがある。どちらにせよ、 RMON での利用をⅱ財是として開発されたソフトウェアを使うべきであろう。 RMON プロープのインターフェイスと MIB 構成は、プログラム化された NMS から栄作か浦財是となっている。つまり、管理者が MIB プラウザなどのプログラムを用いてデータ 11

6. UNIX MAGAZINE 1998年10月号

連載 UNIX Communication Notes—O つ。この場合、その Ethernet をサービスしているハプの MIB 変数を監ネ寸象に、単イ寺間を 5 分間として、過去 5 分間にハプか転送したデータ量を表す MIB 変数をポーリングによって監視し、その間のデータ中幻医が 5Mbps を超えたら警告を出すといった設疋ができる。このような特定のシステムの MIB 変数を監視する機能は、大部分の NMS に用意されている。ネットワーク構成の自動探索去も丘のネットワーク管理ツールの多くはゲートウェイのネットワーク・インターフェイス橢及、経路情報などをもとにネットワーク構成を自重加勺に調べ、接続関係を視覚化する。さらに、ゲートウェイでの ARP テープルなども参考にして、接続しているホストを探しだす NMS も数多い。これらのシステムでは、ネットワークの構成変更を検知するために、ゲートウェイやホストに対して定期的なポーリングを実施している。ほかに、ネットワークの各構成機器の稼重川大態をリポート形式でまとめて出力 ( 印刷 ) できる機能、ネットワーク機器の設定情報をまとめて管理し、必要に応じて対象機器に設定をダウンロードする機能、トラップを発生させたホストと不鶤頁を言求し、事前に決めておいた管理者に対してその不鶤頁に応した障害対応処理を求める機溝などが用意されている。どの NMS を利用するか NMS については、 SNMP 自体の標準化が進められていた 1990 年当時はいくっかのフリーウェアカ甘是供されていた。しかし、各企業ごとに定義されている Enterprise MIB を統合したり、あるいは、ネットワーク機器ごとの情報を事前に設定するといった処理の煩雑さから、しだいに商用ソフトウェアが一イ勺になった。現在の NMS の大半は商用アプリケーションであり、実用に耐えうるほどのフリーウェアの NMS ははとんどないだろう。商用アプリケーションにもいろいろあるが、現在は HP の OpenView を基盤にしたシステムが多い。これ以外にも、 Sun の Sun Net Manager をもとに手冓成したシステムか数多く提供されている。国内でも、住友電工カ鯛発した NMS 「 Dr-Net 」などがある。これらには機能的な差その他の機能 14 はほとんどないが、これまでの競争のなかで OpenView カ立 -- ・歩先んしているようである。 IBM や DEC ( 現 Com- paq) などのパートナーか対種を数多く出し、 SI 企業でもひろく使われているためであろう。 NMS の導入についても、朋大では商用アプリケーションを購入したほうが、ネットワーク管理の面でもオーバーヘッドが少ない。 NMS のメーカーカ鯛催するセミナーやトレーニング・コースを、オペレータの教育に利用するのも一案であろう。 NMS か・応していないネットワーク機器でも、 ASN. 1 で言当された MIB 定義が与えられれば、 MIB コンパイラを用いてシステムに統合できる。去も匠は、 MIB コンパイラを使わすに、 ASN. 1 の定義を直接読み込んで利用するシステムも登場している。今後の展望 7 月号では、 SNMPvI と SNMPv2 について説明した。区しになるか : これまでの糸韋を簡単に振り返っておこう。 1980 年代末に開発され、 1990 年代初めに標準化作業が進められた SNMPv1 は、インターネット機器を開発、販売する多くの企業に受け入れられ、いまや SNMPv1 に対応していないネットワーク機器はないほどまでに普及した。しかし、 SNMPv1 は多くの間題を抱えていた。とくに、プロトコルが単純すぎるために NMS とエージェントとの通信か非効率になってしまう点と、コミュニティ名を基礎とするセキュリティ険か脆弱である点カ吠きな間題であった。これらの問題を解決するために生まれたのが SNMPv2 である。 SNMPv2 では、エージェントと NMS との通信にノヾルクデータ転送の概念を導入し、効率的な通信を可能にする基盤を提供した。これは、ネットワーク機器を開発する多くのべンダーに受け入れられた。しかしながら、セキュリティ対策として追加された SNMPv2 の機能は総じて不評であった。実装か難しいことに加え、 SNMPv1 との整合生が悪かったのが原因である。それゆえ、 SN- MPv2 は SNMPv1 の問題点を解決するものとして標準化されたにもかかわらす、ひろく使われるまでにはいたらなかった。 UNIX MAGAZINE 1998.10

7. UNIX MAGAZINE 1998年10月号

NETWORKTECHNOLOGY 1 1 図 2 旧テータグラムの転送 netl ホスト 1 RI の経路表 RI net4 R3 R2 の経路表宛先 netl net2 net3 net4 net5 next hop 日 2 R3 宛先 netl net2 net3 net4 net5 next hop 、 RI RI net2 net5 R3 の経路表 net5 net4 net3 net2 netl 宛先ホスト 2 net3 R2 RI 日 1 RI next hop ホスト 1 がホスト 2 宛にデータグラムを送信した場合 6. net3 は直接経路なので、日 2 はホスト 2 に直接データグラムを送信する。 5. R2 は経路表の検索により、ホスト 2 が net3 に属することを知る。 4. 日 2 はホスト 2 の旧アドレスを検索キーとして経路表を検索する。 3. RI はデータグラムを R2 に送信する。 2. RI は経路表の検索により、ホスト 2 が net3 に属することを知り、日2 を nexthop として返す。 1. RI はホスト 2 の旧アドレスを検索キーとして経路表を検索する。 IP prefix は、宛先ネットワークの IP アドレスです。従来は宛先 I P アドレスと呼ばれていましたが、 C I D R (Classless lnter-l)omain Routing) 導入後は IP prefix と呼ばれることが多いようです。 prefix length には、 IP pre ⅱ x のネットワーク部の長さを指定します。たとえば prefix length が 16 の場合、 IP pre ⅱ x の上位 16 ビットがネットワーク・アドレスとして有効であり、下位 16 ビットが各ホストの識別に使用されることになります。たとえば 10.1.1.0 / 24 という IP ( ネットワーク ) アドレスは、・下位 8 ビットがホスト部・上位 24 ビットがネットワーク部 UNIX MAGAZINE 1998.10 ネットマスク = -(2(32-prefixlength)- 1 ) length のあいだには、たネットマスクに対応しています。ネットマスクと prefix ということになります。 prefix length は従来用いられていという関係がなりたちます ( ~ は 1 の補数をとることを示します ) 。たとえば、 prefix length 24 はネットマスク 255.255.255.0 に、 prefix length 16 はネットマスク 255.255.0.0 に対応します。経路検索はネットワーク部に対してのみ適用されます。上記の例では、宛先 IP アドレスが 10.1.1.0 ~ 10.1.1.255 の 256 種類の IP アドレスはすべて同じ宛先ネットワーク 10.1.1.0 / 24 へのデータグラムとみなされます。すなわち、経路表に登録する IP アドレスの数が 256 から 1 へと、 1 / netl: 10.1.1.0 / 24 ということです。たとえば、経路表にの情報は含まれない 2. IP データグラムには、宛先ネットワークの pre ⅱ x length 1. prefix length は可変長であるこで問題になるのは、 256 に圧縮されたことになります。 65

8. UNIX MAGAZINE 1998年10月号

ト信 ASCII 基第加らフロトコルが理解る ! 事通ロ事 1 、信プロトコル第峺ポイント図解式笠野英松監修マルチメディア通信研究会編本体価格 5 , 631 円 B5 判 816 頁豊富な図面と平易な解説で好評のポイント図解式教科書シリーズのスペシャル版 ! ! 充実の 816 ページ基礎から、最新のマルチメディア , プロトコルまで、情報通信のプロトコルーー ~ 冫 ( 規約 ) のすべてをアプリケーションの視点から平易に解説情報通信関連事業に関わるすべてのビジネスマン必の書ム ~ 笠野英松 ~ 監修 , ル分アア通信研究会ポイント図解式プロトコル略語集 .ITIJ - T 勧告リスト、 RFC リスト、 NTT / KDD のサービス・リスト付きく通信プロトコル事典目次〉第 9 章電気通信網の標準 / 周辺装置接続インタフェース第 1 章ネットワークと通信プロトコル第 5 章業界標準プロトコル第 10 章マルチメディア情報通信のプロトコル第 2 章ネットワークのアプリケーション・サービス第 6 章 LAN ( ローカル・エリア・ネットワーク ) 第 3 章旧 O / OS 惨照モデル第 7 章 WAN ( ワイド・エリア・ネットワーク : 広域網 ) 第ⅱ章標準化組織第 4 章 TCP/IP プロトコル第 8 章伝送・通信制御 / ネットワーク中継く内容の一部〉一円 6 、 RSVP 、 Radius 、 SNA 、 DNA 、 NetWare 、 Windows NT 、 PDS プロトコル、 EDI, EC 、 Fast Ethernet 、ファイパ・チャネル、無線 LAN 、フレーム・リレー、 ATM 、伝送制御手順、モデム・プロトコル、ネットワーク中継、 SCSI 、 HIPPIslMT-2000 、 PHS 、 MPEG 、テレビ会議、 VOD 、 DAVIC ・・・表示価格は消費税を含みません。・本製品は書店でお買い求めください。・品切れの際は書店にてご注文いただくか、通信販売をご利用ください。・通信販売のお問い合わせ先株式会社ダイレクト電話 ( 03 ) 5351-8202 http://www.ascii.co.jp/di 「 ect/ 〒 1 51-8024 東京都渋谷区代々木 4-33-10 出版営業部電話 ( 03 ) 5351-8194 式会ネ土アスキー

9. UNIX MAGAZINE 1998年10月号

TECHNOLOGY NETWORK 播ロ陽ー最近の経路検索技術修正 2 進木 / B 木による経路検索ネットワーク機器では、近年 IP (lnternet Protocol) における高速経路検索への関心が非常に高まっています。これは物理層の帯域の増大が 1 つの要因です。経路検索に関する新しいアルゴリズムや経路検索専用の LSI なども発表されています。今回は、予定を変更して最近の高速経路検索技術について解説します。経路検索の仕組み経路検索技術の詳細に入る前に、 IP データグラム転送の仕組みについて簡単に復習しておきましよう。 IP を用いるすべての機器は ( ホストもルータも ) 経路表といわれる表をもっています ( 図 1)0 ルータ ( やホスト ) はバケットを転送あるいは送信する際、バケットごとに経路表を検索します。検索キーにはバケットに含まれる宛先 IP アドレスを用い、検索結果として、そのバケットを次に処理する機器の IP アドレスを得ます ( 図 2 ) 。そのパケットを次に処理する機器は next h 叩と呼ばれます。図 2 から分かるように、 next h 叩となる機器はバケットを送信する機器と直接接続されている必要があります。 IP データグラムは next h 叩から next h 叩へと転送され、最終的に宛先に届けられます。 IP アドレスは 32 ビットですから、 IP アドレスとしてとりうる値の数は 232 = 4G になります。したがって経路表にすべてのとりうる宛先 IP アドレス ( とそれに対する next h 叩 ) を登録するのは不可能ですし、たとえできたとしても現実的な時間で経路表を更新するのは不可能です。 IP では連続する IP アドレスを 1 つの " ネットワーク " としてまとめ、経路の検索を個別の宛先 IP アドレスではなく宛先ネットワークに対しておこなうようになっています 1 。これにより経路表のサイズを小さくすることができます。現在の IP ではネットワーク・アドレスを以下のように表しまうな経路をホスト経路 ( host route ) といいます。 1 宛先 IP アドレスごとに next h 叩を指定することもできます。このよく旧 prefix>/<prefix length> す。図 1 経路表入力テータグラム経路検索ヘッダ処理細分化工ラー処理ほか出力データグラム 64 宛先旧アドレス next hop の旧アドレス出力ポート経路制御プロトコル ( R 旧、 OSPF 、 BGP4 ほか ) 経路表 UNIX MAGAZINE 1998.10

10. UNIX MAGAZINE 1998年10月号

倉敷芸術科学大学のネットワーク構築小本林ロ真ゼロからのメールサーバー写真 1 旧メールサーバーの AlphaStation 倉敷斗学大学も今年で完成年次となり、 1 回生から 4 回生まで約 2 , 000 名の学生か本↑勺に学内ネットワークを利用するようになりました。ューサー数と利用率の増加にともない、これまで安易に運用してきた各種のサーバーの能力不足か彳余々に露呈するようになってきました。そこで、サーバー能力向 - ヒ引画の第一弾として、メールサーーを取り替えました。今回は、購入して OS をインストールしたはかりの DEC の AIphaServer 800 を学内ネットワークに接続し、メールサーバーとして機能させるまでの - ーーー連の作業を順を追って解説します。最近、歳を写真 2 新メールサーパーの AlphaServer 800 とって物慮えが一段と悪化したせいか、予想以 E に時間がかかってしまいました。 35 歳定年説がささやかれる現場にいられるのはあと数年なのでしようか・新環境の構築機種の選定これまで、倉敷芸科大では DEC の AIphaStation を (FFDT 対応で 200Mbps) があり、これまでよりも・商メールサーーとして運用してきました ( 写真 1 ) 。 CPU ノヾなレスポンスか期待できます。クロックは 166MHz 、メモリは 128MB 、ディスクはスネームサーノヾーや NIS のサーノヾーも新しいワークステフ。ール領域として約 2GB という構成で、 2 , 000 人ものユーションに取り替えました。これまでは各マシンにディスーサーを抱えるメールサーバーとしてはかなり貧弱です。プレイとマウス、キーポードを取り付けていたのですが、ネットワークも標準の 10Base T の Ethernet を利用し場戸励ゞ手狭になったため、これらのワークステーションとています。メールサーバーを 19 インチラックにマウントし、キー今回、新規に導入したメールサーバーは、 AlphaServer ポード切替え器でディスプレイとマウス、キーポードを 800 のラックマウント・タイプ ( 写真 2 ) で、 CPU は共有して利用しています。キーポード切替え器は、 CY- Alpha21164A の 50()MHz 、メモリは IGB 、スプール BEXI の SwitchView ( 写真 3 ) を使っています。ディスクが RAID 適用後で約 20GB という構成です。ネットワーク・インターフェイスには 100BaseT と FDDI 1 http://www.cybex.com/ 57 UNIX MAGAZINE 1998.10