アプリケーション ロ lllllll サーバー 3 図 2 プロープとトラフィック里アプリケーションを組み合わせた配置 プローフ プロープ トラフィック管理アプリケーション 基幹スイッチ Traffic Management• トラフィック管理アプリケーション 基幹スイッチ プロープ スイッチ 。プロープ スイッチ スイッチ プローフ スイッチ 反応速度テータの利用 ネットワークカ寸包える問題を特定するには、トラフィッ ク情報として利用可能なネットワーク資源、データ資源に ついて、トラフィック管理アプリケーションが自重加勺に学 習する必要がある。ここでいうデータ資源とは、 SNMP や RMON 工ージェントを実装した高匪能プロープやそ の他のネットワーク機器のことである。大規模なう靖攵型ネ ットワークでは、管理アプリケーションを分昔己置して、 離れた装置のあいだの通信やデータ収集の各を適切にお こなう必要がある。図 2 は、アプリケーション性能の情 報を収集するときのトラフィック管理アプリケーションと プロープの組合せ方を示している。 トラフィック管理アプリケーションは、高性能プロー プが収集した反応速度のデータをもとに、ネットワーク上 のアプリケーションのそれぞれの入出力について、芯速 度のデータを作成し、管理の基とする。反芯速度の偏差 が、ユーザーカ症義する一定の値を超えると、ネットワー ク管理者に警告が送信される。アプリケーション房芯速度 だけをモニターするので、モニターしなければならない要 素は減っているが、ネットワーク性能は十分に観察でき る。芯速度を変化させる原因は、ルータの嵂章や大量の プロードキャストなどである。反芯速度をモニターするこ とにより、ネットワーク管理者は警告を受け、これらの事 態の発生を知ることカそきる。 また、管理アプリケーションは、アプリケーション反 応速度を測定し、複数のプロープのデータを 1 つにまとめ て、ネットワークのどの箇所で反芯速度カ畯化したかを特 UNIX MAGAZINE 1998.5 定できる。図 3 は、反芯速度によって間題箇所を特定す るガ去を示す 1 つのシナリオである。クライアントーサー ・アプリケーションは、、クライアント " と、、サーバー と名付けられたワークステーションのあいだのネットワー ク上でイ乍している。この経路十には、 SNMP を実装し た 2 つのルータ (SNMP ルータ 3 、 4 ) と、 RMON を実 装した 3 つのスイッチ (RMON スイッチ 1 、 2 、 5 ) が 存在する。プロープ 1 は自らとサーバーのあいだを行って 返ってくるアプリケーション反芯速度をモニターする。プ ロープ 2 と 3 も同様である。芯速度か変化し、プロー プ 1 の値自体には変化がなかった場合、クライアント側 のワークステーションかテンヾイスに間題がある可能性か高 い。プロープ 3 か変化を検出した場合、問題はサーバー側 にある。プロープ 2 と 1 か変化を検出した場合、管理アプ リケーションはプロープ 1 か験出した変化からプロープ 2 カ鹸出した変化を差し引いて考える。プロープ 2 カ出し た変化を差し引くことでプロープ 1 の反応速度の変イゞな くなるなら、反芯速度刎氏下はデバイス ( ルータまたはス イッチ ) 3 、 4 、 5 のいすれかで発生している。 間題が発生したネットワークの領域を特定できれは、 の領域にあるネットワーク・デバイスからデータを収集す ることで、反応速度の低下を惹き起こしている原因を究明 できる。 ロ 問題防止のための時系列分析 性能低下の長期的な傾向を発見して、アプリケーション 反芯速度を問題防止のために利用することも可能だ。管理 61

連載 /FreeBSD ノートーの により存在しないことカ蔀寉認され、電磁波は真空中を伝播する ことが分かった。このあたりが基礎となって、 Einstein の特 殊相対性理言舳、成立した。 その 1 世紀後、 Xerox の研究者たちは新しいネットワークの メディアとして現代にエーテルを復活させた。そのセンスのよ さには脱帽する。 ネットワークに興味をもち始めたころの私は物理を学ふ学生で、 インターネットから入手した資科を読んでいて、「はて、エーテ ルネットってなんだろう ? 」と頭をひねったが、それも懐かし い思い出である。 broadcast 方式の起源はハワイ大学の ALOHA ネッ トで、ハワイ諸島間を無泉で結んでデータを交換するため の方式として研究されていた。複数のインターフェイスが どのようにバケットを送れは効率がよいかという観点に れを Media Access Control 、略して MAC と呼ぶ ) か らは、メディアが大気からケープルに変わっただけで、考 え方の基本は同しである。 もっとも素朴な方式である pure ALOHA では、装置 から各インターフェイスにデータが送られてきたら、ただ ち 0 ンヾケットを送出する。すこしネットワークカ鯤んでい るとバケットどうしか衝突する可能性は相当大きいので、 ネットワークの利用効率はかなり低いといえる。衝突を回 避するにはさまざまな工夫が必要になる。このあたりの基 礎理論を調べるのはなかなか楽しいので、読者の譏題とい うことにしよう。 Ethernet の特徴 Ethernet は、 l-persistent CSMA/CD という方式 をとっている。ごく大雑把にみてみよう。装置から送出す べきデータがくると、インターフェイスはメディアカ啌い ているかを調べる。空いていれば送出し、そうでなければ 空くまで待つ。送出中にバケットどうしがぶつかっている ことを検出したら、送出をやめて任意の時間だけ待ってか ら最初に戻って送出を始めるという方式である。 そのため、 Ethernet では相手に届くまでの時間が保証 されていないので、リアルタイム性カ腰求される用途に は限界がある。通信内容に優先度をもたせることもできな い。さらに、ネットワークか冲議してくると効率が念敷に 低下することはよく知られている。 すいぶんいいカ靦咸な方式のようだが、そのぶんプロトコ ルの仕組みか簡単で故 ; 章に強いのか特徴である。 去も匠では、 Ethernet 上でできるだけリアルタイム性を 114 糸財寺したり通信に優先度をつけるためのさまざまな方式が 研究されている。その 1 つである ALTQ (AIternate Queueing) という方式を FreeBSD に実装したものがソ CSL から公開されている (http://www.csl.sony ・ co ・ jp/person/kjc/programs. html)o Ethernet と対照的な LAN 方式が IBM の Token- Ring である。大雑把にいうと、 TokenRing ではネット ワーク上を token と呼ばれる特殊な識別子がめぐってい る。インターフェイスは送出すべきバケットを受け取る と、ますこの token を獲得してからバケットを送出する。 TokenRing ではバケットの到達時間に上限を設けた り、通信に優先度をもたせたりすることかできる。輻中鄭寺 : にも効率か落ちにくい。たいへんけっこうなのだが、 いうかっちりした方式はちょっとした古郊章でも石定しがち である。たとえは、 token を握ったままインターフェイ スカ答しなくなると、 LAN 本か饑能しなくなってし まう。この種の嵂章をなるべく回避するように言されて はいるが、実際には珍しくないらしい。 Ethernet と TokenRing のどちらが優れているかと いう論争がニュースやメーリングリスト上でしはしは起 こる。方式自体にはどちらにもそれなりの利点があるよう だ。ただし、コストの面からは Ethernet が間違いなく有 利である。 Ethernet の規格 Xerox の開発した Ethernet は、 IEEE802.3 で規格 化された。わすかな違いがあるので厳密には区別される場 合もあるが、両方を合わせて Ethernet と呼ぶことが多い ようだ。ちなみに、 TokenRing は IEEE802.5 として規 格化されている。 Ethernet には物理的なインターフェイスがイ研重類か 定義されている ( デバイスドライバではこのインターフェ イスのことをメディアと呼んでいる ) 。太くて黄色い同軸 ケープルでおなしみの 10Base5 や細い同軸ケープルの 10Base2 、そして最近主流の撚り対線によるケープルの 10B e T のほか、光ファイバーによる 10Base F な どもある。 たんに Ethernet というと IOMbps のものを指す力ゞ、 「匠は IEEE802.3u で規格イヒされた 100Mbps の Fast Ethernet もかなり普及してきた。カテゴリー 5 刎然り対 UNIX MAGAZINE 1998.5

UNIX Communication Notes ネントワーク管理 ( 3 ) 山口英 管理の専門化と管理システム UNIX MAGAZINE 1998.5 ネットワーク管理には、さまざまな専門匁昴勧ゞ必要であ ならない。 たちがシステムの運用に責任をもつ体制を確立しなけれは ネットワーク管理者あるいは管理グループを決め、その人 業務の片手間にすませられるような竹喋ではない。専任の このような状況では、ネットワーク管理はもはやほかの ステムを扱わなけれはならなくなってきた。 がって、ネットワーク管理者は以前にも増して数多くのシ のシステムの多くがネットワークに接続されている。した システムを使い分けるような場合もある。そして、これら 利用する竟も珍しくなく、仕事の不鶤頁に合わせて複数の うになった。現在は、 1 人が 1 台のコンピュータを占有 差ない価格の UNIX ワークステーションも販売されるよ は・いわゆる PC だったが、去も丘はデスクトップ PC と大 はさらに加速された。以前は、安価なコンピュータといえ は急に増え、コンピュータの低価↑箚ヒによってその勢い ネットワークの普及とともに、接続されるシステムの数 求められる。 ワーク管理者は運用の安圜生と障害からの速やかな復旧を 務と妾にかかわるネットワークを運用する場合、ネット 事にならないところもあるようだ。このように、主要な業 接に関係しているために、ネットワークか動かなけれは仕 り驚かなくなった。なかには、ネットワークか業務と密 るので、仕事にネットワークを使っていると聞いてもあま 送ったり、 Web でグループ内の情報を共有していたりす か利用されている。どこの糸でも電子メールて報告書を 去も丘は、オフィスでごく当り前のようにネットワーク る。現在のところ、すべての管理竹喋をマニュアル化して オペレータに迂たり、屯な管理竹業を外部に委託でき るような体制は整っていない。さらに、管理作業の手間を 軽減する環竟を整備するのも難しい。 そこで、ネットワーク以外の分野の専門家が、たまた まネットワークやシステムに詳しいがために、システム管 理に携わっている状況がよくみられる。とくに大学では、 このような傾向がいちしるしい。一方で、ネットワーク やシステムの規模は拡大の全をたどり、十分な数の専門 家を確保するのはますます困難になってきている。このよ うな状況を改善するには、管理イ乍業のマニュアル化や、部 分的にではあっても竹喋を自動化する欟冓の開発が急務で ある。 1990 年代の初めに、ネットワーク管理システムの開 発力ワ。ームになったことがあった。ちょうど SNMP や CMIP か登場したころで、ネットワーク管理やシステム 管理にコンピュータ・システムを利用し、管理作業のか なりの部分が自重加ヒできるのではないかとの期待か高まっ た。たしかに、プームに乗って多くのネットワーク管理シ ステムか誕生した。しかし、それらのシステムか対象とし ていたのはネットワークだけで、サーバーやユーサーに割 り当てられたシステム、ネットワーク本てイ吏われている アプリケーションなどをネ日こ入れた総合的なネットワー ク管理システムは登場しなかった。もちろん、プームが過 ぎ去った現在もそのようなシステムは出現していない。 ネットワークに依存する業務か増大しているいまこそ、 そのようなシステムの登場が強く求められているはすであ る。しかし、描匠はネットワーク管理闊連の製品開発や研 究活重丿のプームが過ぎたからか、この分野での新たな成果 や新製の発表はそれほどない。たいへん残念である。 13

0 反応速度にもとづくトラフィック管理 by John Feldmeier Af 「 om LJNIX REVIEW 今日では多くの企業で複雑なネットワークが使用され ており、日常のサポートや業務管理のための情報処理のは か、業務変革を目的とした単各的アプリケーション実装の 基盤となっている。実装と管理の方法が適切なら、こう したネットワークは即座に企業全体の生産性止に貢献す る。反対に、ネットワークのパフォーマンスカ觝いと、企 業の生産陸は低下する。 従来の管理ツールでは、ネットワーク管理者はネット ワークの最下位層を扱うことになり、ネットワーク・デ バイス自体かイ : 苻するデータの収集分析をおこなう必要が あった。こうしたデータは、問題箇戸励寺定されたのちに 詳細なトラブル・シューティングが必要になる場合は貴 重である。しかし、ネットワークに問題がないかどうかを 判断したいときにルータの CPU 使用率やスイッチ・イ ンターフェイスのエラー率を調べるのは、病気かどうかを チェックするのにいきなり全身の精密検査をおこなうよう なものだ。体がだるいのか、それともどこか痛むのかカ吩 かれは、より迅速な仂ゞ可能になる。 このようなトップダウン・アプローチによるネットワー ク管去として、ネットワークの生産性に景を与・える 2 つの孑票に注目する手法がある。その指標とは、アプリケ ーションの可用性 (application availability) とアプリ ケーション . 反 ) 芯ー隻 (application responsiveness) で ある。最上位の論理層 ( ネットワークて新川第しているアプ リケーション ) から中間層 ( ネットワークの基盤と接彬 態 ) へそして最下位の物理層 ( ネットワーク上のデバイ ス ) へと順にネットワークを管理するはうが、ネットワー ク上のデバイスを 1 っすっ調べていくよりもアプローチと UNIX MAGAZINE 1998.5 しては合理的だ。 ロ トップダウン・アプローチ データ・ネットワークにおけるトラフィック管理は、 1991 年の RMON (Remote MONitoring) 標準の尊入 によって始まった。 RMON はトラフィックの面からネッ トワークを捉えてはいるが、個々のアプリケーションのト ラフィックについての清報は・学えてくれない。これに対し て、 RMON2 標準 ( 1997 年 1 月公開 ) は、ユーサーの アプリケーション利用によって発生する個々のトラフィッ クをモニターするガ去を提供している。これによってネッ トワーク管理者は、ネットワーク上のユーザー、ユーサー による入出力、アプリケーションなどの景些を知ることが できる。 RMON2 は、 RMON に欠けていた多くの機能 を追加して、大規模ネットワークのトラフィック管理に必 要な情報の大半を提供している。 RMON2 により、ネットワーク上のアプリケーション やユーザーを視 : 勺に把握することかできる。しかし、ネ ットワークの性能がユーサーに与える景グを知るために必 要なアプリケーション反芯速度を測定する去は含まれて いない。ネットワーク上のアプリケーション反芯速度は、 工ンドユーサーの期待と要望に応えるネットワークを提供 できているかどうかを詔面する指標として最良のものだ。 アプリケーション反芯速度は、、、バケットがネットワー クの 2 点間を移重丿けるのに要する時間 " といった単純なも のではない。ューサーとサーバーのあいだで測定される値 をいくつか組み合わせたものであり、アプリケーションの 性能に対するユーサーの調面を擒則する数値として高い信 頼性をもつ。最初の測定値はアプリケーションの可性で ある。ューサーがなんらかの理由でアプリケーションにア 59

Traffic ManagementA 図 3 . つ比較による高度な言去 反応領域 1 反応領域 2 反応領域 3 SNMP ルータ 3 SNMP ルータ 4 プローブ 2 プロープ 3 トラフィック管理 アプ丿ケーション 日 MON スイッチ 2 日 MON スイッチ 5 ⅧⅢ サーバー プローブ 1 RMON スイッチ 1 RMON RMON RMON クライアント アプリケーション反応速度は、ネットワークの性能を評 アプリケーションを使って反応速度の傾向を把握し、それ 価するための要素として唯一もっとも重要なものだ。トラ をもとに推定することで、ネットワーク性能の変化がいつ フィック管理によってアプリケーション反芯速度を測定す ューサーに悪景グを与・えそうかを予測できる。 れば、その可用性や反応速度低下の直接の原因になってい 大量の情報によりネットワーク管理者か苦しまないよう に、管理アプリケーションはデータを収集、角斤してから る問題を発見できる。 トラフィック管理製品は数社から販売されているが、ネ レポートを作成する。自重加勺に作成されたアプリケーショ ットワークへの組込み機能を活かしていない汎用性に欠け ン反応速度の基礎データから、すぐに間題に発展しそうな るものや、従来の SNMP 管理プラットホームとなんら変 深刻な事態や、いすれはネットワーク性能に景グを与えう わらないシステムを提供しているものも多い。効果的な管 る微小で継読的な変化などを発見できる。 理システムを築くには、今日存在する標準コンポーネント 効果的な管理システム を活用しつつ、エンドユーサーの期待に応える新たな機能 も提供できなくてはならない。この牛を満たす製品を使 分昔アプリケーションを強力な糸囚み工ージェント技 えば、顧客はネットワーク管理のために投資した金額を損 術と組み合わせることにより、ネットワーク・トラフィッ なわすにすむし、ネットワーク管理者は、より信頼生の高 ク管理システムの基礎を築き、ネットワークの成長に合わ い予測可能なネットワークを提供することで、重要なアプ せた引の作成、問題の防止、障害発鰤の迅速な原因箇 リケーションを実装できるようになるだろう。 戸斤ク芋定が可能になる。 John Feldmeier 速ネットワーク用機器の使用や、ハードウェアの冗長 トラフィック管理システムを提信い - る Technically EIite の製品マーケ ティン旦当副社長を務める。 3 年前からネットワーク管理の工地昜におり、 構成によって回避できる性能上の問題も多いだろう。しか コンピュータ業界で 11 年にわたる告と販う ) キャリアをもつ。 し、こうした出費は不要かもしれないし、サーバー刎星延 「 Network Traffic Management 」 の原因になっている場合など、根本的な解決に至らないこ UNIX REVIEW 1997 年 11 月号より ともある。実際のネットワーク竟に学える景グを十分に ◎ 1997 , UNIX REVIEW (). S. A. ) 検言寸せずに、数千ドルから数百万ドル単位のネットワーク 用ハードウェアとアプリケーションを配置するのは投資の 無駄である。 高 62 UNIX MAGAZINE 1998.5

インターネットとあなたが日本の通信を変える ☆日本で初めて 日本における戦略拠点が AT & TJens 。 ☆世界で初めて 電話を開発し、トランジスタ、レーザー、デジタル光プロセッサを送り出してきた AT&T の 取り組んでいます。社会のベストプレーンとして高品質な通信サービスを提供しています。 もっと多くの人々と、もっと多くの国々と、国境を越えたグローバルなネットワークの構築に AT & T Jens が日本の通信ビジネスをドラスティックに変えています。 今、インターネット電話サービス「 AT & T @ phone 」を提供。 商用インターネットサービスを発表し、国内に大きな衝撃を与え、注目を集めました。そして、 募集職種 コンピューターネットワークエンシニノ ①当社基幹ネットワーク ()P ) の設計・構築 ・ IP ネットワーク ( インターネット・ LAN ) 構築経験 ・広域ネットワーク /LAN ネットワーク知識 ( 専用線、 ISDN 、 ATM など ) ②インターネット付加価値サービスの設計・構築 ( インターネット電話サービスの設計・構築など ) ・ UNIX/Windows 上でのシステム開発経験 (), C + + , perl など ) ・ TCP/IP ネットワーク構築経験者 ③当社ネットワークサーヒスの運用・管理 ( 主に、 IP ネットワークの運用 ) ・ UNIX/Windows 上でのシステム運用経験 ・広域ネットワーク・ LAN ネットワーク運用経験 ④当社顧客支援システムの設計・構築・運用・管理 ・業務アプリケーションの開発・運用経験 募集要項 ・採用条件 : 学歴不問、 32 歳位まで ー勤務時間 : 9 : 0 0 ~ 1 7 : 3 0 * 職種によりフレックスタイム制及びシフト勤務あり ※応募書類は返却致しません。 ( 応募秘密厳守 ) 書類選考の上、選考日を別途通知します。 ・応募方法 : 履歴書 ( 写真貼付 ) 、職務経歴書をご郵送下さい。 ・勤務地 : 本社 ( 六本木 ) ・オペレーションセンター ( 新宿 ) ■休日 . 完全週休 2 日制、祝日、夏季、年末年始 社員持株制度、適格退職金制度 ・待遇 : 昇給年 1 回、賞与年 2 回、社会保険完備、 ■給与 : 当社規程による ワークによる高度情報通信サービス 社員数 / 140 名・事業内容 / マルチメディアネット 設立 / 1 9 8 4 年 1 1 月・資本金 / 192 億 9000 万円 会社概要 AT & T Jens 株式会社 〒 106 - 0032 東京都港区六本木 1 -4 - 30 第 25 森ビル 9F 人事総務部 ( 担当 / 小島、高野 ) TeI 03-5561-5702 電子メール : hr@tokyo.attjens.co.jp ホームペーシ : http//www.attjens.co.jp 資料請求 No. 050

NET WORTH 丘 om UNIX REVIEW 6 M. Steven Baker ネットワークの名前付け事情 アダムの日罸にから、人間は周りのものに名前を付けてき すむ点である。 た。私たちは数字よりも名前を好むようだ。憶えておける インターネットの名前付けの歴史 数字列はわすか ( 自分の社尉章番号、誕生日や番地をい くつか、電話番号なら数十程度 ) にすぎないのに、人名な インターネットは、 1969 年に 4 つのノードからなる ら数百、単語なら数千は簡単に記匱する。企業のマーケテ 実験ネットワークとして始まった。資金を提供したのは イング部門は、そういう記億の特質を利用して電話番号を DoD (Department of Defense) とのちの DARPA 短い名前 (I-800-USA-4-SUN や 1-800-COLLECT な (Defense Advanced Research Projects Agency) で ど ) に置き換え、憶えやすくしている。 ある。そのころのネットワーク・プロトコルは、 1 バイト インターネットでは、その始まりからネットワーク名が 数字を使ったアドレッシングを採用していた。そのため、 欠かせなかった。 IP (lnternet Protocol) や IP 対応の 相互接続できるマシン数は最大 256 台までに制限されて アプリケーションは、ルーティングやアドレッシングに いた。これは時を経るにつれて、現在のより柔軟な IP ア IP アドレス ( 現在の IPv4 では 32 ビット ) を用いてい ドレッシング方式 (IPv4) に進化した。 る。もっとも、そうしたアプリケーションではユーサーの 最初の 10 年間、インターネット ( 当時は ARPANET 使産を図るために、ネットワーク資源の場所をホスト名で と呼はれていた ) の管理は簡単だった。 1970 年代の後半 指定することもできる。これらのホスト名は、 OS によっ に、インターネットは約 25 のネットワークと数百台の て実際に使われる IP アドレスへ〕あ的に対応づけられる。 ホストマシンを含むまでに成長していた。当時、ホストマ IP アドレスとネットワーク名の割当て方式は、インタ シンに付けられた論理名はマスター HOSTS. TXT ファ ーネットの大きな特徴の 1 つである。これは、中央の認 イルに書かれていた。このファイルは、 DARPA が資金 可組織とローカル・ネットワークでの分散管理とを組み合 援助した NIC (Network lnformation Center) によ わせたものだ。中央の認可系目織は、ネットワーク番号 ( 複 って管理されていた。 NIC は、各新規ホストに対して一 数の IP アドレス群 ) のう己と、最 - ヒ位ドメイン名の階層 意な名前を発行し、それをこのような本表 (global ta- 下にあるドメイン名の管理・登録をおこない、一意性を保 ble) に追加した。リモートホストは、定期的にマスターの 証する。ローカルの管理者は、ネットワーク・アドレス群 HOSTS. TXT ファイルをローカルマシンにコピーして現 のなかから自由にノード番号を割り当て、サブドメインに 状を央していた。 対する認可や、自分のドメインにおける IP アドレスと名 前の里づけをおこなう。 しかし、 1981 年までに、全体表の大きさと新しいホス WWW とそのプロトコルの魅力の 1 つは、ハイバーテ トやネットワークの追加による更新頻度がシステムの限界 キスト・リンクの性質上、ユーサーのホームページやブッ を超えた。インターネット上のメールシステム開発者はす クマークから簡単にリンクをみつけられるので、ユーサー っと以前から、メールポックス名を 1 つにまとめることの はもはや資源が置かれているネットワーク名を知らなくて 無益さを認識していた。同程度の機能をもちながら、ネッ 63 UNIX MAGAZINE 1998.5

ートーの 連載 /FreeBSD ノ 図 3 NIC 成 bus maln memory CPU bus i nterface Network lnterface Card F 旧 0 control ROM MAC controller 厄介なのが、、 jabber ( わめき屋 ) " である。切れ目なく 連続して続くデータで、バケットの体をなしていない。機 器の障により起こることがあるが、 jabber がいるとネッ トワークの機能が停止してしまう。さいわい、去も丘のハー ドウェアではめったに起こらないようだ。 ネットワーク・カードとドライバ ネットワーク・カード ( ネットワークインターフェイ ス・カード、ネットワーク・アダフ。タなどいろいろな呼び 方がある。以ード、 NIC と略 ) の構造をみたあと、デバイス ドライバからどのように扱えばよいかを考えてみよう。 ネットワーク・カードの構造 NIC の構成を簡略化したものを図 3 に示す。 bus interface は ISA ノヾスや PCI ノヾスなどのマシンの 拡リルヾスへのインターフェイスである。 CPU からのアク セスは I/O ポートやメモリアクセスで、 NIC からは割込 みラインやメモリアクセスを通してマシンとデータを交換 する。 FIFO (first ⅲ , first out) は、送受信されるデータ をイ褓内しておくバッフアである。 MAC controller は、 Ethernet の状態を監視して、実際に送受信したデータを FIFO とやりとりする。 PHY は、 Ethernet の信号と MAC controller の信号を相互に変換する物理的なデバ イスである。 ROM には MAC アドレスや設定情報などのデータが 116 Ethernet PHY 収められており、ドライバはこれを読み出して NIC の各 種設疋をおこなう。また、 BIOS ROM を載せているカー ドもある。 BIOS ROM はマシンの起重加に実行される ので、マシンをネットワーク・プートするのに利用できる (FreeBSD でのネットワーク・プートについては netboot のマニュアルページが参考になる ) 。 各要素か物理的にうしておらす、 ASIC などに統合さ れている場合もある。たとえば、 ISA の古典的な NIC で あるオリジナルの NE2000 は、大きめのカード上に各種 のチッフ。がぎっしりと載っていた。描匠の互換カードは チッフ。か数えられるはど少ない。なかには内部処理も非常 に進化していて、 NE2000 よりもはるかに優れた中幻速度 をもっカードもある。 デパイスドライバと NIC Ethernet を利用するには、マシンが、 1. ネットワークを常時監視して自分宛のバケットカ毓れて いないかを調べる 2. 送出すべきバケットがある場合はネットワークか空くの といった複雑な欟冓を備えていなけれはならない。これら は NIC に内蔵されており、ソフトウェアからは自重加勺に 処理されているようにみえる。 したがって、デバイスドライバのもっとも基本的な部分 は、 NIC からバケットを受信したという通知がきたらこ UNIX MAGAZINE 1998.5

Traffic Management ■ 図 1 →殳的なプロープ己置 クセスできないなら、反芯速度に直接の景カ咄る。 2 つ 目の測定値は、ユーサーとサーバー間の ) 芯答時間である。 これは、ユーサーがサ→ヾーの情報をリクエストしてから 最初のバケットが到着するまでのを指す。 3 つ目の測 定値は、要求したデータがユーザーのワークステーション に到達する速さである ( バーストフレーム速度 ) 。アプリ ケーション反応速度は、可用性、応答時間、バーストフ レーム速度から構成される。 ューザーが Web ページにアクセスしようとして最初の 2 回のリクエストで応答が受信できない場合、反応速度に 悪景グ響を与えているのは可用性である。実際に接続された ときのユーザー・リクエストから、 Web ページか更新され 始めるまでの時間か ) 芯答琲間である。 1 つのリクエストで 複数の応答バケットが Web サーバーから送られる場合、 を使用して、この機能がネットワーク機器に耐妾組み込ま バーストフレーム速度が速いほど、 Web ページの更新も れるようになる可能生もある。 速くなる。アプリケーション反芯速度は、これらの測定値 アプリケーション反芯変のデータを収集するためのプ に重みづけして組み合わせた直である。 ロープは、高性能のハードウェアと高度なトラフィック収 ネットワークが、安定したアプリケーション接続をユー 集工ージェントを組み合わせたものである。通常、ハ ザーに提供しているかどうかを判断するうえで、アプリケ ウェアは専用 RISC プロセッサで、最低でも 16MB の ーショシ反芯速度は唯一もっとも重要な要素である。アプ RAM が必要だ。 100Mbps 以 - E の高速ネットワークでは、 リケーション反芯速度を測定することで、ネットワーク障 高速のバケットに対応するために、複数のプロセッサや特 害の防止や、問題発生時の迅速な解決が可能になる。 別なハードウェアを使ったプロープが必要になる。スイツ チを介したネットワークでは、プロープがスイッチリンク ロアプリケーション反応速度の測定 を直接調べるか、スイッチメーカーカ甘是供するさまざまな モニタリング・ポートを利用する必要がある。複雑なネッ スイッチ、ルータ、コンセントレータなど、ネットワー トワークであっても、プロープをうまく配置することで、 ク上には多くの情報原がある。これらのデバイスは、標準 効率的にアプリケーション反芯速度をモニターできる。 SNMP 工ージェントの一部である MIB Ⅱ (Manage- トラフィック管理工ージェントには、専用のものも、標 ment lnformation Base Ⅱ ) を通して、自らのステー 準をベースにした製品もある。 RMON か RMON2 標準 タスやネットワーク接続の状態を送信する。 RMON 工ー をベースとしたエージェントをイ吏用するのが、もっとも一 ジェントを実装することにより、物理層とデータリンク層 勺な実装形態である。 RMON2 では新しい管理対象や のネットワーク糸帰 1 イ直を測定できるデバイスもある。 則題直の追加か容易でないため、アプリケーション反芯 速度の測定を標準のなかでサポートするのには適さない。 現在のところ、これらのネットワーク機器はアプリケー この種のデータには、 RTFM WG (Real-Time Flow ション反芯速度について刎青報は与えてくれない。これを Measurements Working Group) カ甘是唱している Me- 得るには、アプリケーションに関す則定値や反応速度の ter MIB 構造のはうが適している。 Meter MIB 構造で データを収集する専用のモニター装置 ( 高速プローフ ) を は、新しい測定の追加、言が可能だ。これにより、トラ ネットワークの要所要所に配置しなければならない。高速 フィックに関する測定値収集 . 用のエージェントに刻生を ネットワークでアプリケーションのトラフィック情報を もたせることができる。図 1 は、一ヨ勺なネットワーク 収集する竹喫には多くの資源が必喫なので、専用のハード でのプロープの配置例を示している。 ウェア機器の機能力材く可欠である。将来は、ハードウェア アプリケーション サーバー プロープ 基幹スイッチ lllllll プロープ - に スイッチ スイッチ プロープ プロープ 一三ロ 60 UNIX MAGAZINE 1998.5

Daemons & Dragons— 0 をもっていれば ( しかも、 routed の実行ファイルが存 在しなければ ) 、スクリプトは in. rdisc を router モー ドて起動する。 したがって、 host として IRDP を利用するには、 /etc/defaultrouter があればこれを削除するだけでい い。 router として利用する場合は、 IRDP の advertise- ment メッセージを送り始められるように設定を変更す る必要がある。具体的な手順は router によって異なる。 router を導入したあとに起動した host は、 in. rdisc を 使って自重加勺にデフォルト経路を管理するようになるだ ろう。 設定とネットワークへの負荷 58 in-the-middle) 方式の攻撃をする機会を与・えることに る。これはクラッカーに、データの盜聴や中継 ( man ー ネットワーク上の全トラフィックを盜聴することができ ルータとして通知するようにマシンをセットアップし、 接アクセスできれば、自分自身をもっとも優先度の高い したがって、悪意をもった第三者がネットワークに直 頼 (authenticity) をチェックする機能は備わってい のプロトコル自体には、 advertisement メッセージの信 IRDP のセキュリティについて触れておこう。 IRDP セキュリティ ある。 されるもっとも短い間隔は 4 秒、生存時間は 12 秒で り、ネットワークへの負荷は増大する ) 。一般的に許容 ジの送出間隔をもっと短くすることができる ( その代わ 早く対応することが必要な場合、 IRDP ではメッセー まく動く。しかし、ネットワーク構成の変化にさらに素 ドレスはめったに変わらないため、はとんどの環境でう 7 ~ 10 分の間隔で送り出される。デフォルトルータのア 全体で 56 バイトになる。メッセージは各 router から ダと 32 バイトの ICMP メッセージなどから構成さオ L 、 れる advertisement メッセージは 20 ノヾイトの IP ヘッ とんど負荷をかけない。ある 1 つの router から送出さ デフォルトの値を使えば、 IRDP はネットワークには なるかもしれない。 まとめ IRDP を正しく使えば、ローカルなネットワーク全 体のデフォルト経路の設定を集中的に管理することがで きる。これは、ユーザーがワークステーションでおこ なう設定作業を 1 つ減らせることを意味する。さらに、 ネットワーク構成をより簡単に変更することもできる。 IRDP の host は変更を重加勺にチェックするので、マシ ンのリプートは必要ない。マシンを別のサプネットに移 動した場合も、変更する設定ファイルを 1 っ減らすこと ができる。 IRDP に対応していないホストは従来のやり 方で、対応するシステムでは IRDP を利用して設定す ればいいだろう。 UNIX システムやインターネット技術の研究に 15 年弸秀わってきた技 術者。 Group Sys ConsuIting を経営する。 [ 参考文献 ] [ 1 ] S. Deering, Host Ea;tensions for IP 1'1 石 cast 9 , RFCI 112 , August 1989 [ 2 ] S. Deering, ICMP 0 社 te D co ? 肥型 Messages, RFC1256 , September 1991 [ 3 ] J. ReynoIds and J. PosteI, Assigned Numbers, RFC1700 , October 1994 [ 4 ] Ⅵを Richard Stevens, TCP/IP lllustrated レ 0 ん me 7 : The Protocols, Addison-WesIey, 1994 ・ William LeFebvre 「 ICMP Router Discovery ProtocolJ UNIX REVIEW 1997 年 7 月号より ◎ 1997 , UNIX REVIEW (). S. A. ) UNIX MAGAZINE 1998.5