図 15 DHCPOFFER と DHCPREQUEST バケットに言ホされたサーバー識別届 (a) インターネット家電か送信した DHCPOFFER バケット 192.168.0.201 ←サーバー識別子 ( DHCP サーバーの旧アドレス ) (b) ルータが送信した DHCPOFFER バケット Magic C00kie r SS e8. S Server ldent if ier Server ldent ifier DHCP 0pti ons DHCP 0pti ons 132.168.0.201 ← 対する応答であることを示す インターネット家電の DHCPOFFER に 3 ( DHCPREQUEST) Mag i 0 C00k i e (c) ホスト B か送信した DHCPREQUEST バケット 192.168.0.1 ・←サーバー識別子 ( DHCP サーバーの旧アドレス ) 引 c C00kie Server ldent ifier 引 ient ldent if ier DHCP Message Type DHCP 0p い ons QUEST をプロードキャストして IP アドレスの割当てを 正式に要求します。複数の DHCP サーバーから DHCP- OFFER が送られたときのため、 DHCPOFFER と DH- CPREQUEST バケットには DHCP サーバーを区別す るための識別子である Server ldentifier が含まれてい ます。 図 15 は、 DHCPOFFER と DHCPREQUEST バケ ットに記述されたサーバー識別子です。 DHCPOFFER では、各 DHCP サーバーの IP アドレスを Server lden- tifier に設疋しています。 DHCP クライアントは、 IP ア ドレスの割当てを受ける DHCP サーバーと同じ識別子を Server ldentifier にセットし、 DHCPREQUEST ノヾケ ットを送り出します。 DHCP サーバーは、受け取った DHCPREQUEST パ ケットの Server ldentifier が自分の識別子 ()P アドレス ) と一致したら、実際に IP アドレスを割り当てます。 希望する IP アドレスが返されないとき DHCP クライアントから IP アドレスカ腰求されても、 ・使用済み ・割当て可能なアドレスの範囲外 などの理由で、どの DHCP サーバーもその IP アドレス を返せないことがあります。このような場合に、希望する IP アドレスを優先する DHCP クライアントがどのように 振る舞うかを、さきほどの図 1 のネットワークとホスト B 138 を使った簡単な実験で確かめてみましよう。 手順は次のとおりです。 1. ホスト B に対してインターネット家電から IP アドレス を割り当てる。 2. インターネット家電の DHCP サーバーを停止する。 3. DHCP で取得したホスト B の IP アドレスを解放する。 4. ホスト B の IP アドレスを DHCP で再取得する。 DHCP クライアントは手順 4 で以前と同じ 192.168.0. 211 のアドレスを希望しますが、ルータの DHCP サーバ ーカ甘是供可能なアドレスの範囲ではないため、割当てを受 けられません。 図 16 は、ホスト B が手順 4 で IP アドレスの取得を 始めてから、 IP アドレスが割り当てられるまでに流れた DHCP バケットの様子です。 この図をみると、 DHCP クライアントが DHCPDIS- COVER メッセージを 3 回送信しています。いすれのメ ッセージにも、希望する IP アドレスを宣言した、 Requested IP Address: 192 .168.0.211 が含まれています。 UNIX MAGAZINE 2004. 12 ではなかったので、返事 (DHCPREQUEST) を返さ 2. しかし、 DHCP クライアントは希望する IP アドレス 回目の DHCPOFFER)0 して 192.168.0.5 のアドレスの提供を申し出ている ( 1 1. DHCP サーバーは 1 回目の DHCPDISCOVER に対

文房具としての 図 8 DHCP サーバーの言綻 (PXE 対応ブートローダからのリクエストに対する部分 ) } elsif option vendor—class—identifier "NetBSD: i386 : libsa" { 連載 ~ 08 filename "tftp:netbsd" ・ } else ←図 9 の設定が続く 図 9 DHCP サーバーの言聢 ( カーネルからのリクエストに対する部分 ) } else { option root—path "/usr/exports/root " option host—name "diskless—stationery option routers 192.168.11.1 ; option broadcast—address 192.168.11.255 ; option subnet—mask 255 . 255.255.0 ; fixed-address 192 .168.11.3 ; hardware ethernet 00 : 0c : 29 : 5b: ac :bf ; host diskless—stationery { subnet 192.168.11.0 netmask 255 .255.255.0 { ddns—updates off ; ddns—update—style none ; 図 10 DHCP サーバーの言聢 (/etc/dhcpd. conf) ← NFS で提供されるルート・ディレクトリのサーバー側のパスを指定 if substring (option vendor—class—identifier, 0 , 9 ) "PXEC1ient filename pxeb00t—ia32. bint' } elsif option vendor—class—identifier "NetBSD : i386 : libsa" { option root¯path "/usr/exports/rootll } else { filename "tftp:netbsd" ・ は TFTP サーバーは指定していません。 サーバーと TFTP サーバーが同一の場合、 TFTP サーバ ーの設定は省略することができるためです。明示的に指定 する場合は、 next-server というキーワードを使って以下 のような行を追加します。 next—server 192 .168.11.2 ; これは、 DHCP るプロトコルを教える必要があるからです。なお、 TFTP TFTP と NFS の 2 つのプロトコルカ鉢リ用でき、利用す PXE 対応プートローダでは、カーネルを読み込むために 、 tftp:" という文字列カ咐いている点に注意してください。 カーネルのファイル名です ( 図 8 ) 。こではファイル名に i386:Iibsa" という文字列が含まれています。返す情報は のリクエストには vendor-class-identifier に、、 NetBSD: 2 回目のリクエストはプートローダからのものです。 じ要領で指定します。 DHCP サーバーと TFTP サーバーが異なる場合も、同 UN 工 X MAGAZINE 2004. 12 サーバーに関してはさきほどと同じように省略しています。 最後はカーネルからのリクエストです。ここでは NFS のルートノヾスを指定します ( 図 9 ) 。図では /usr/exports /root にしていますが、ほかの場所に置きたい場合は適宜 変更してください。 dhcpd. conf の設定は以上でおしまいです。サーバーを 再起動しても dhcpd が自動的に動くように、 rc. conf に以 下の行を追加しておきましよう。 dhcpd=YES dhcpd-flags="—q fxp0" dhcpd-flags で指定している fxpO は、サーバーのネッ トワーク・インターフェイスに合わせて変更してください。 追加したら dhcpd を起動します 6 。 # /etc/rc . d/dhcpd start 6 リースファイルがないために正常に起動できない場合には、 /var/db/ dhcpd. leases という空のファイルを作成してください。 119

図 13 サーバー・バックアップ 拠点 1 個別設置 旧テレホニ サーバー 回線制御装置 ! 公衆回線網 旧 DN / アナログ 本社 回線制御装置 公衆回線網 旧 DN / アナログ 三② 拠点 n 個別設置 旧テレホニ 旧網 旧テレホニ サーバー 回線制御装置・ 2 ①通常時、本社のサーバー制御により内線・外線通話 ②本社サーバーおよびネットワーク障害時、拠点個別設置サーバー制御により 拠点内通話と公衆網通話を確保 障害時の対策 次に、ネットワーク障害などが発生したときにも電話に よる通信を可能にする方式について述べます。 代表的な障害対策としては、以下に述べるようなものが あります俵 6 も参照してください ) 。 公衆回糸罔の利用 公衆回線網への接続を保持することにより、機器障害や SIP 電言間通話と公衆回糸バックアップ 図 15 停電が発生したときにも通話ができるようにします ( 図 サーバー 旧網 12 ) 。 ・バックアップ サーバーを冗長化して信頼性を向上させたり、拠点にバ ックアップ・サーバーを設置し、ネットワークやサーバー に障害カ起きたときにも通話ができるようにします ( 図 Vo 旧 S 旧電話機 S 旧電話機 ゲートウェイ 13 ) 。 VoIP ゲートウェイによるバックアップ ている通話先 ( 100 カ所 ) ) や voIP ゲートウェイ経由 ネットワークに障害が発生した場合は、 VoIP ゲートウ での公衆回繕罔の利用力河能です ( 図 15 ) 。 ェイで公衆回線網へバックアップして通話をおこないま す ( 図 14 ) 。 こで紹介した対策は、いずれも基本的には内線網の 迂回機肯咐き SIP 電話機の利用 信頼性を向上させるためのものです。現在では携帯電話や 迂回機能付き SIP 電話機があれば、サーバーに障害カ咥 PHS がかなり普及しているため、、、どのレベルまで対応す 生しても、 SIP 電話機間の通話 (SIP 電話機に登録され べきか " を現状に即して検討しましよう。その際には、信 図 14 VoIP ゲートウェイによるバックアップ 公衆回線 電話機 Vo 旧 ゲートウェイ PBX 旧網 FAX 公衆回線網 44 UNIX MAGAZINE 2004. 12

表 2 H. 323 プロトコルの基討冓成 H. 225.0 (RAS) H. 225.0 ( Q. 931 ) H. 245 RAS 制御 ( H. 323 ゲー トキーパーと H. 323 端末 間の手川の 端末市掬 H. 225. O(RTP/RTCP) 同期制御 ( H. 323 端末間 の音声・映像伝医手順 ) 図 3 H. 323 での基勺なタ里手川頁 〇 豆 323 端末 呼の許可 端末の登録 H. 323 ゲートキーパー ① 呼の許可 端末の登録 ②確立 / 端末制御 ③通話 ④解放 H. 323 端末 ' 缶舌番号から IP アドレスに変換するアドレス解決など、 H. 323 ゲートキー パーと H. 323 端末間の交換手順を規定 H. 323 端末間の呼の確立 / 解放手順などを規定 H. 323 端末間の通話で利用する音声に関する交奐手順を規定 RTP では音声・映像を相手側に送るための手川頁などを、 RTCP は受け取 った音声・象データカ症しいかをチェックする機能などを規定 ・ロケーション・サーバー : UA の情報をイ尉寺するサーバ 2. SIP サーバーは、 UAC から受信した通話先の情報を する。 Agent Server : 電話を受ける側 ) の電話番 - 引青報を送信 SIP サーバー ( プロキシー・サーバー ) に UAS (User 1. UAC (User Agent Client : 電話をかける側 ) から、 SIP の基本的な処理手順は、以下のとおりです ( 図 4 ) 。 的な処理手順 ートキーパーに問い合わせる。 2. 事寉立 / 端末制御 H. 323 端末は、 H. 323 ゲートキーパーから送られた宛先 IP アドレスに対して接続する。 接続先の H. 323 端末と各種交換手順に関する情報を交 2 で確立したコネクションを解放する。 4. 呼解放 H. 323 端末間で通話をおこなう。 3. 通話 換し決定する。 SIP 登録サーバー : UA の IP アドレスを下記のロケーショ ていた場合、新たなアドレスを UA に通知するサーバー ・リダイレクト・サーバー : 通話先のアドレスカ畯更され 出しなどの機能をもっサーバー プロキシー・サーバー : 通話先の場所の特定、相手の呼 ・ UA (User Agent) : SIP における端末 ( 電話機に相当 ) SIP による通信は、以下の要素から構成されています。 32 ン・サーバーに登録するサーバー 知らない場合、ロケーション・サーバーに問し哈わせて UAS の情報を入手し、 UAS に接続要求をおこなう。 3. UAS は SIP サーバーから得た情報をもとに、 SIP サー ェイ丁 ヘッダ ・開女予 ットで利用されている標準的なものに似ています。 以下に示すように、 SIP のメッセージ形式はインター SIP のメッセージ形式 4.1 ~ 3 が完了した時点で通言劼ゞ開始される。 バー経由で UAC の接続を許可する。 UNIX MAGAZINE 2004. 12 言語です ) 。 は RFC2327 [ 5 ] で規定されているテキストべースの言杢 col) で記述され、 UA 間のやりとりで使われます (SDP す。通常、本文は SDP (Session Description Proto- まれるメソッドや応答コードにより、解釈方法が異なりま ジの種類 ( リクエストまたは応答 ) およびメッセージに含 種別など、呼の種類を定義します。本文は、そのメッセー 開女予とヘッダでは、サービスやアドレス、プロトコル

図 2 DHCP で IP アドレスを取得 DHCP クライアント プロードキャスト プロードキャスト DHCP DHCP サーバー 2 DHCP サーノヾー n DHCPDISCOVER 「ほい、どーぞ」 DHCPACK アドレスをください」 「 DHCP サーバー1 さん DHCPREQUEST 「このアドスではどな 0 、や ? 」 DHCPOFFER 「誰か旧アドレスをください」 各サーバーカそれぞれ DHCPOFFER メッセージを返し ます。 DHCPOFFER メッセージは、、提供の申し出 " にすぎ ないので、この時点ではまだ IP アドレスは決定しません。 DHCPOFFER メッセージを受け取った DHCP クライ アントは、申し出のあったネットワーク情報から好みのも のを選び、、、これを使わせてほしい " ということを知らせる DHCPREQUEST メッセージを返します。 DHCPREQUEST メッセージはプロードキャストで 配信しますが、バケット内にはどの DHCP サーバーへの 応答かを示す識別子 (DHCP サーバーのアドレス。彳も ) カ鯉め込まれています。これにより、複数の DHCP サー バーが DHCPOFFER メッセージを送った場合でも、ど のサーバーに対する応答なのかが区別できます。さらに、 DHCPREQUEST メッセージがプロードキャストで配 信されることで、他の DHCP サーバーもリソースを解放 するタイミングを知ることができます。 DHCPREQUEST を受け取った DHCP サーバーは、 DHCP クライアントに対して、、アドレスを使ってもよい " ということを最糸寉認する DHCPACK メッセージを送 ります ( アドレスの使用を拒否する場合は、 DHCPNAK 128 メッセージを送ります ) 。 これで、 IP アドレスの取得が完了します。 2 台の DHCP サーバー 図 3-a は、ホスト B が IP アドレスを取得する際にや りとりされた DHCP のバケットを表示したものです。パ ケットの流れを図示すると、図 3-b のようになります。分 かりやすくするため、 DHCP のバケットだけを取り出して 表示しています。 図 3 をみると、ホスト B がプロードキャストした DH ー CPDISCOVER に対して、 ・ルータ ( 192.168.0.1 ) ・インターネット家電 ( 192.168.0.201 ) の 2 つが DHCPOFFER を送って応答していることが分 かります。しかし、図 1 のネットワークでは、 DHCP サ ーバーはルータだけのはずです。それなのに、インターネ ット家電が DHCP サーバーとして返事をしているところ ・ DHCPREQUEST ・ DHCPOFFER さらに、 に問題がありそうです。 が流れたタイミングから、ホスト B はインターネット家電 UN 工 X MAGAZINE 2004. 12

ASCII 巻末付録 創刊 5 周年記念第 3 弾 用例で学ぶコマンド活用術ー必須コマンドテクニックまる覚え ! ・末付録用例で学ぶコマンド活用術必須コマンドテクニックまる寘え ! 2004 “ 1490 円 リナックスシステム活用専門誌 創刊 5 周年記意第 3 強 m Z ー住 用例で学ぶコマンド活用術 必須コマンドテクニックまる覚え ! いざという時にあわてないための リナックス KNOPPIX 3.6 日本語版 ( 20040816 セ 00409 ー 4 版 ) TurboIinux 10 Server トライアル版 最新テクノロジーか満載 ! 管理マニュアル サーバティストリビューション一 速報 ! Fedora Core 3 KNOPPIX 3.6 日本語版 Linux MLD mini 3.00 層テノストリこ」一シコン サーバ用 4 大 Linux を徹底比較 インテル CPIJ の現在と未来 NAS を使った バックアップ活用法 今すぐはじめる キーバーソンが本誌だけに語った ! N Vat で大事なテータをハックアッフ 時別企画 達載時第 ンを . 第、 リナックスマカジン 1 2 月号好評発売中 ! ! 定価 1490 円 サーバディストリビューション選択ガイド 【特集 2 】サーバ用 4 大 Linux を徹底比較 に Linux を使うために必要な日々のメンテナンス方法を徹底解説 Linux に限らず OS はインストールしたらそれで「終わり」ではない。快適に、安全に、確実 リナックス管理マニュアル 【特集 1 】いざという時にあわてないための TurboIinux 1 0 Server トライア丿レ版 KNOPPIX 3.6 日本語版 ( 2 。。 4 。 816-2 。。 4 。 914 版 ) 【 2 枚組付録 CD - ROM 】 1 月号 12 月 8 日 ( 水 ) 発売 NetVa ⅵ t で大事なデータをバックアップ冫欠号予告 インテル CPLJ の現在と未来 いま 【特別企画】キーパーソンが本誌だけに語った ! B フレツツを利用した独自ドメインのインターネットサーバを構築する 手軽に入手できるようになったプロードバンド環境だが、活用しているだろうか。 ADSL 、 今すぐはじめるインターネットサーバ 新連載【連載特集】独自ドメインの公開サーバ 勝手を評価する ターポリナックス / ノベル / ミラクル・リナックス / レッドハットのサー / ヾ向け製品の使い インターネットサーバ Li nux サーバを徹底活用しよう ASCII アスキームック 004 ネットワークサーバ構築ガイド ゆ : / / W 私 250 00 ・加川石 ux ” 9 / 工ンタープライズリナックスガドー 最新サーバ向けディストリビューション - 挙紹介 ! Webmin を使いこなせ ! GLJI システム管理ツール Samba 導入講座 Windows ユーサーのための NT 4.0 ファイルサーバを Linux にリプレース ! BIue 旧 r 忸アプライアンスサーハの構集 COba はサーバの管理システム バックアップとデイザスタリカバリ 第から素皐く復旧 NAS を使った バックアップ活用法 Fedora Core 3 詳細解説 どれを使うかーテキストエテイタ選び ※内容は変更されることがあります。 Linux サーバを徹底活用しよう Linux ネットワークサーバ構築ガイド 2004 好評発売中 ! ! 旧 BN4-7561-4532-9 定価 1995 円 ( 本体 1900 円 ) POF 、 W 0 文画も検索 全文検索エンジン M 代 akeSe 」上物えで快・をパイル通国を実環 モバイルネットク工房 Web 見られ誓い、 背 メー元か送れない、つながらないを解決 ! , 、ネットワーク 今どきのイントラネット構築に Linux は必須。中心となるファイルサーバはコ ストがかからず高機能な Samba 3.0 でキマリ ! 基本設定から大規模ドメイン 構築まで徹底解説。サポート終了が迫る NT からのリプレースもカバー。その ほか、ネットワークやサーバ構築、バックアップなどなど、盛りだくさんの内容です。 NT 4.0 ファイルサー / ヾを Linux にリプレース ! Windows ユーザーのための Samba 導入講座 GUI システム管理ツール Webmin を使いこなせ ! 2 枚組付録 C ロ - ROM Web が見られない、メールが送れない、つながらないを解決 ! ーート ? プルシューティンク ネットワークトラブルシューティング 最新サーバ向けディストリビューション一挙紹介 ! 工ンタープライズリナックスガイド 障害から素早く復旧 バックアップとデイザスタリカバリ M 旧 ACLE 凵 NLJX V3. O 評価版 Mt C し日、ド NU 3. 199 0 本製品は書店および書籍を扱っているパソコンショップでお買い求めください。〇品切れの際は書店にて注文していただくか、通信販売をご利 用ください。〇通信販売のお問い合わせ先 . アスキーストア電話 (03) 3499-9300 httP://WWW.ascii-store.com/ 株式会社アスキー -8584 東京都千代田区九段北 1 -13-5 日本地所第一ビル ( 03 ) 6888-5500 http://www.ascii ℃ o.jp/

連載 /UNIX Communication Notes ーー O ェイス・カードを挿してディスク専用のミニタワーを作り、 そこにディスクをどんどん載せていくのである。 個人レベルとはいっても、データ量は従来とくらべて驚 くほど増えている。 ITB もしくは 2TB といった単位のデ イスクを持っているユーザーも珍しくない。この春、私が 担当している大学院の授業で、出席していた 50 名ほどの 学生に訊いたところ、 ITB を超えるストレージを個人で所 有している学生が数名いた。 サーバーの増強 既存のサーバーの増強は、比較的安易な方法ではあるが、 ディスクシステム自体が安価になってきた状況を考えれば 効果的であろう。 たとえば、 AppIe の Xserve G5 は私も使っているが、 安価で処理性能力皜く、同時に UNIX システムとして使え るのでなかなか便利である。このサーバーの姉妹製品とし て、 3U サイズの Xserve RAID というシステムがある。 このシステムにはドライプペイが 14 あり、 ・ホットスワッフ。対応 サーバー接続は Fibre Channel ・ RAID 0 / 1 / 3 / 5 の構成が可能 といった機能がある。これなら、通常の RAID システム として問題はないだろう。最大ディスク容量の 5.6TB の システムで、価格は約 158 万円である。 ITB あたりにす れば約 73 万円で、サーバーとあわせて購入しても 200 万 円でおつりがくる。ちょっとしたワークグルーフ。で使用す るのであれば、それほど悪くない選択ではないかと思う。 同様の市販製品はたくさんあり、とくに、 Fibre Cha1 ト nel 経由での接続はデータ転送帯域カ昿く、大容量のディ スクシステムを利用する場合にストレスが少ない。サーバ ーのインターフェイスといえば、以前はほとんどすべてが SCSI だったが、最近は Fibre Channel に対応した製品 も増えてきている。上記のような RAID ユニットを購入 し、サーバーを増強するのも 1 つの方法だろう。 ネットワーク環境とストレーシ 企業や大学などで大規模サーバーを前提としたシステム を構成する場合は、ストレージ専用のシステムを利用する 傾向が強まってきている。これまでに、さまざまなサーバ UN 工 X MAGAZINE 2004. 12 ーの構築方法が考えられてきた。上に述べたように、最近 は巨大といってよいディスク容量の確保が必須になりつつ あるが、そういった環境でどのようにサーバーを構築する かがあらためて大きな問題となっている。 現在のサーバーには、以下に述べるように多種多様な機 能力球められる。 大容量ストレージ共有への対応 現在のネットワークエ竟は、 100Mbps Ethernet から Gigabit Ethernet への移行が進みつつあるた態といえる であろう。 Gigabit Ethernet が標準的になれば、データ 車幻去も十分な性能でおこなえるようになる。また、 CPU 性 能が格段に向上したため、クライアント側でのプロトコル 処理も十分に余裕をもっておこなうことができる。したが って、ネットワーク環境で大容量のストレージを共有して も、とくに大きな問題は生じない。 ただし、ネットワーク環境の整備が後手に回っている、すな わち、旧い機材をそのまま使ってネットワークを構築している場合 には、十分なネットワーク性能力られないこともある。導入を 本寸する前に、ネットワーク麭竟に問題がないかをかならす認す べきであろう。 環境さえ整っていれば、数 TB—数十 TB を最低容量と するストレージ・サーバーをネットワーク経由で利用する ように言妬 t しても、大きな問題はあまり発生しない。 一方、どの程度の容量が必要なのかを導入前に算定する のはひどく難しい。経験則でいえば、ストレージを際限な く消費するユーザーは本の 2 割程度であるが、この 2 割 のユーザーが全体の 8 割の資源を使うのである。ーヨ殳ユー ザーカ駛うディスク容量も、確実に増加している。とくに 大量のマルチメディア・データを扱ったり、部門単位で電子 的なドキュメントを集中的に管理するような場合には、使 用容量の予測はたいへん難しい。その意味では、導入後の 拡張性もシステム選定の重要なポイントになる。 強力な障害管理機能 ストレージを集中管理するサーバーでは、当然のことな がら、強力な障害管理機能が必要になる。サーバーが停止 すると、多くのユーザーに景彡響が出るのであればなおさら である。 従来のサーバー構築の場合と同じく、以下のような機能 49

ク・ミニ実験室① ネットワー トラブルが起きたネットワーク 図 1 インターネット ルータ兼 DHCP サーバー 192.168.0.1 LAN 192.168.0.0 / 24 インターネット家電 192.168.0.201 ( 固定旧アドレス ) ホスト B 192.168.0.211 (DHCP で割当て ) ホスト A 192.168.0.3 (DHCP で割当て ) 表 1 ホスト A とホスト B のネットワークの言綻 ワーク上に DHCPDISCOVER メッセージを、、プロー ホスト A ホスト B ドキャスト " する。 IP アドレス 192.168.0.3 192.168.0.211 2. DHCPOFFER : DHCP サーバーは、 DHCP クライ サプネットマスク 255.255.255.0 255.255.255.0 アントに DHCPOFFER メッセージを送信する。 デフォルトルート 192.168.0.1 192.168.0.201 3. DHCPREQUEST : DHCP クライアントは、 DHCP- 図 1 のネットワークのデフォルトルートは、インター不 REQUEST メッセージを、、プロードキャスト " する。 ットと接続するためのルータ ( 192.168.0.1 ) です。と一 4. DHCPACK : DHCP サーバーは、 DHCP クライアン が、ホスト B のデフォルトルートは 192.168.0.201 にな トに DHCPACK メッセージを j 言する。 っています。これが、インターネットと通信できなかった まず最初に、 DHCP クライアントがネットワーク上に 直接の原因です。 DHCPDISCOVER メッセージをプロードキャストしま ホスト A とホスト B は IP アドレスのほか、デフォル す。これは DHCP クライアントが DHCP サーバーを探 トルートや DNS サーバーのアドレスなども DHCP で取 すためのメッセージです。 得しています。そこで、ホスト B が IP アドレスを取得す DHCP サーバーは、ネットワーク上に DHCPDIS- る際の DHCP のやりとりを解析し、トラブルの本質を探 COVER メッセージが流れると、 DHCP クライアントに ってみることにします。 提供できるネットワーク情報、 DHCP の概要 . IP アドレス 実際に流れたバケットを調べる前に、 DHCP クライア . サプネットマスク ントが IP アドレスを取得するまでの手順を簡単に説明し ・デフォルトルートのアドレス ておきます。 ・ DNS サーバーのアドレス 図 2 は、 IP アドレスの取得に成功した場合の DHCP の処理の流れを示しています。 を書いた DHCPOFFER メッセージを返します。 1. DHCPDISCOVER: DHCP クライアントは、ネット ネットワーク上に複数の DHCP サーバーがある場合は、 127 UN 工 X MAGAZINE 2004. 12

図 9 イ立の決定 (a) インターネット家電の DHCP サーバーがさきに苔 インターネット家電 ロ日朝白囲 1 一〇い 14 観↓」朝副 からの応答 マ越信先 ド 255.255.255.255 255.255.255.255 255.255.255.255 1 3 2 . 1 68 . 0 . 2 255.255.255.255 キャプチャテータく dhcp enc> マロコ DHCP DHCP ! DHCP DHCP DHCP 4 ーれこ 0 リ・Ⅱ - 0 リれ 0 、ト・ CD ・ーー・Ⅱ・りと - Ⅱ・つれこ ム DHCPD I SCOVER DHCPOFFER DHCPREOUEST DHCPOFFER DHCPACK インターネット家電から 旧アドレスを取得 ルータからの応答 (b) ルータの DHCP サーバーがさきに若 ルータからの応答 ロ物目国」↓@ 在↓」↓ = 1 巫副 ID•作 " レスマ信 インターネット家電 255.255.255.255 からの応答 132. 1 68 . 0 . 1 32 . 1 圏』 . 2 と 192. 1 圏 . 0 . 20 1 255.255.2 5 5 . 2 5 5 インターネット家電から 3 0 . 0 . 0 . 0 255.255.255.255 旧アドレスを取得 4 1 3 2 . 1 68 . 0 . 20 1 255.255.255.255 回ロ キャプチャデータく dhcp2. enc> マロトコルマ DHCP DHCP DHCP DHCP DHCP を DHCPD I SCOVER DHCPOFFER DHCPOFFER DHCPREQUEST DHCPACK DHCPOFFER の配信方法 早い者勝ちではないのか 図 9 をみると、 DHCP サーバーによって DHCPOF- 前項で、、ホスト B は希望した IP アドレスを提供してく FER メッセージの配信方法が異なっています。 れる DHCP サーバーを優先する " と書きましたが、アド レス選択のルールは実際には DHCP の実装に依存するた ・インターネット家電 ( 192.168.0.201 ) : プロードキャス め、たとえは図 9 ー a のやりとりだけでは、 ト ・ルータ ( 192.168.0.1 ) : ユニキャスト ・希望した IP アドレスを返す DHCP サーバーを優先 ・最初に応答した DHCP サーバーを優先 このように、 DHCP クライアントだけでなく、 DHCP サーバーの動作にも違いがあります。 のどちらなのかは判別できません。 インターネット家電の DHCP サーバーは、 DHCPOF- アドレス選択のルールをみつけるには、何度か IP アド FER メッセージをプロードキャストで返します。 Ether- レスを取得しなおしたり、竟を変えて DHCP のやりと net ヘッダと IP ヘッダの部分をみると ( 図 10 ) 、 りの様子を調べる必要があります。 ・ Ethernet ヘッダの Destination Address は、、 FF:FF: 図 9-b は、同じ環境で IP アドレスを取得しなおしたと FF:FF:FF:FF" きに流れたバケットの様子です。インターネット家電から ・ IP ヘッダの、、 Destination IP Address" は、、 255.255. の応答がルータからの応答よりあとに届いているにもかか 255.255 " わらす、インターネット家電から IP アドレスを取得して います。 のように、 Ethernet の宛先アドレス、 IP の宛先アドレス のどちらもプロードキャストを指定しています。 図 9- a と図 9-b の 2 つの結果から、ホスト B は希望し TCP/IP の実装によっては、 IP アドレスカリり当てら た IP アドレスを割り当ててくれる DHCP サーバーを優 れるまでプロードキャスト以外のバケットを受け取れない 先していることカ認できます。 134 UNIX MAGAZINE 2004. 12

ワークステーションのおとーー 193 写真 4 ローゼット・ポックスに組み込む 写真 1 Ethernet 用の 2 ロローゼット 写真 5 泉の様子 0 Sun Blade IOOO を使う このところ、勤務先で使っているサーバーの変更を検討 していました。いま利用している Sun UItra 5 (CPU は 270MHz 、メモリ 256AIB 、ディスク 160GB (80GB >< 2 の RAID 1 が 2 セット ) で、 OS は Solaris9) では、 さすがにつらくなってきたからです。 初めのうちは、数名でログインしてメールを読み書きし たり、ファイルサーバーとして使うぶんにはとくに問題は ありませんでした。ところが、 Linux を OS とする PC サーバーでのソフトウェア開発が増えるにつれて問題が出 てきたのです。たとえば、いま使っているターゲット機の PC サーバーの CPU は Xeon 3GHz X 2 で、ディスク は 15 , 000 回転の SCSI ディスクです。つまり、 Ultra 5 とは 10 倍くらいの性能差があるので、 PC サーバー側が 待たされることがあります。また、 Windows から SMB 経由で大きなファイルを書き込もうとすると、なんとなく もたついた感じもします。 サーバー OS は ? 簡単です。 まず、ローゼット・ボックスからモジュラー・ジャック を外します ( 写真 2 ) 。カラーコードに沿って、橙 / 白交じ りの橙、緑 / 白交じりの緑、茶 / 白交じりの茶のより線に 1 ・ジャックを、青 / 白交じりの青に別のモ つのモジュラー ・ジャックを取り付けます ( 写真 3 ) 。カラーコー シュフー ドに沿って取り付ければ、青 / 白交じりの青はモジュラー ジャックの 4 番と 5 番のピンに酉泉されます。これはモジ ・ジャックの中央の 2 本で、 ーーに電話線のプラグ ュフー を入れると、ちょうと真ん中の 2 本、電話線が入っている ところに対応します。 Ethernet ケープルのテスターで配線カ噫図どおりに分 配されているかを確認したら、あとはローゼット・ボック スに組み込むだけです ( 写真 4 ) 。これと同じものをもう 1 っ作り、図 1 のように配線します ( 写真 5 ) 。 このようにしたあとでテストをしてみたところ、みごと に電話からノイズが消えていました。 サーバーとしては、次のような候補カ考えられます。 142 UN 工 X MAGAZ 工 NE 2004. 12