ネットワークスペシャリスト 2018年 秋期 午後II 問題

共通の文章

ネットワークシステムの設計に関する次の記述を読んで,設問1ー4に答えよ。 機械メーカのX社は,顧客に販売した機械の運用・保守と,機械が稼働している 顧客の工場の自動化支援に関する新事業を拡大しようとしている。 機械は工作装置及び通信装置の2種類である。工作装置には,センサ,アクチュ エータなどを制御する機構(以下、デバイスという),及びレイヤ2スイツチが内蔵 されている。通信装置は。デバイスをインターネットに接続するための機器で,エ ッジサーバ,ファイアウォール及びレイヤ3スイッチが内蔵されている。 X社の情報システム部は,新事業用のサービス基盤システム(以下,Xシステムと いう)を計画中である。情報システム部に所属するネットワーク担当のWさんが, Xシステムの構想について,検討を行っている。 [Xシステムの構想〕 Xシステムは,X社が運用・保守を行う顧客の工場内の機器,X社内のサーバ,及 びそれらを接続するためのネットワーク機器から構成されている。 Xシステムの導入構成例を図1に示す。 顧客の工場 Tei = “rel BeAv KZ! |pc||rsw||me FW:ファイアウォール FTし9 L2SW:レイヤ2スイッチ |az L3SW:レイヤ3スイッチ |pc|[la]:X社が運用・保守を行う トーーーーーー--ニーニーニニーーニーニーーーー!顧客の工場内の機器 図1 Xシステムの導入構成例(抜粋) Xシステムの業務アプリケーションプログラムは,エッジサーバと業務サーバ上で =2 anit 動作する。これらのサーバとデバイスは,デバイスの運用・保守に関する情報を, 自動的に交換する。この情報交換に関する説明を次に示す。 ・工作装置と通信装置を接続し,顧客の工場内にXシステム専用のネットワークを 構成する。顧客ネットワークは利用しない。 ・publish/subscribe型のメッセージ通信プロトコルMQTT(Message Queuing Telemetry Transport)を使って,交換サーバを介して,デバイス,エッジサーバ及 び業務サーバの間でメッセージを交換する。 ・デバイス,エッジサーバ及び業務サーバにMQTTクライアント機能を,交換サー バにMQTTサーバ機能をそれぞれ実装する。 業務サーバは,顧客向けにAPI(Application Programming Interface)を提供する。 顧客は,インターネット経由でAPIにアクセスし,デバイスの運用・保守に関する 情報を参照する。このAPIに関する説明を次に示す。 0・X社の業務サーバと認可サーバにHTTPサーバ機能をそれぞれ実装する。 ・顧客は,顧客サーバに,AP]アクセス用のWebアプリケーション(以下,WebAP という)とHTTPサーバ機能を実装する。 ・顧客は,PCのWebブラウザを使い,顧客サーバを経由して,APIにアクセスする。 ・X社の認可サーバは,顧客サーバからAPIへのアクセスを認可する。 Wさんは,上司から,Xシステムの構想に関する四つの技術検討を指示されてい る。四つの技術検討項目を次に示す。 ・ネットワークセキュリティ対策 ・MQTTを使ったメッセージ交換方式 ・APIにアクセスする顧客サーバの管理 ・エッジサーバを活用する将来構想 [ネットワークセキュリティ対策] X VATA,インターネット及び顧客の工場内のXシステム専用のネットワー クを利用するので,これらのX社外の通信区間に関するネットワークセキュリティ 対策が必要となる。Wさんが検討したネットワークセキュリティ対策を次に示す。 ーョー ・情報の漏えい及び改ざん対策のためにTLを利用する。TLSには,情報を する機能,情報の改ざんをする機能,及び通信相手を |ウ|する機能がある。 ・工場内の機器とX社内の機器との通信は,いずれもクライアントサーバ型の通信 であり,機器問の|エ|コネクションの確立要求は,工場からX社の方向に 行われる。それを踏まえて,次の侵入及びなりすまし対策を採用する。 -X社に設置されたFWを使った対策 -①通信装置内のFWを使った対策 -②TLSの機能を使った,デバイス及びエッジサーバに関する対策 (MQTTを使ったメッセージ交換方式 Wさんは,MQTTを使ったメッセージ交換方式を調査した。 このメッセージ交換方式では,固定ヘッダ,可変ヘッダ及びペイロードから構成 されたMQTTコントロールパケットを使う。MQTTコントロールパケットの種別を 表1に示す。 表1 MQTTコントロールパケットの種別(抜粋) クライアントからサーバへの接続要求|(省略) CONNECTに対する確認応和(省略) ume[avevRaowm Rm ume.[ayesvyy—aomm«RD 注りQoSレベルは,送信者と受信者間のメッセージの送達確認手順を指定する識別子である。 2トピック名は,メッセージの種類を表す識別子である。 3パケットIDは,PUBLISH又はSUBSCRIBEに付与する識別子である。 MQTTを使ったメッセージ交換方式の通信シーケンス例を図2に示す。 ーー4ピー (配信元)(配信先)(配信先) CONNECT PONNIEZT _|CONNECT lcowwack| ||SUBSCRIBE lsogAack。|| メッセージ送信 (人 メッセージ送信 (31829)LISI|(ez tee) (人BE(受信者) 注記Pk,図3中のメッセージ送信の通信シーケンスを示す。 図2 MQTTを使ったメッセージ交換方式の通信シーケンス例 2中の通信シーケンスでは,配信元から複数の配信先へメッセージが配信され ている。通信シーケンスの説明を次に示す。 ・クライアントは,サーバのTCPポート8883番にアクセスし,TCPコネクション を確立する。このTCPコネクションは,メッセージ交換の間は常に維持される。 ・クライアントはCONNECTを送信し,サーバはCONNACKを返信する。 ・配信先となるクライアントは,サーバにSUBSCRIBEを送信し,購読対象のメッ セージを,トピック名を使って通知する。サーバはクライアントにSUBACKを返 信し,購読要求を受け付けたことを通知する。 ・配信元クライアントは,PUBLISHを使ってサーバにメッセージを送信する。 ・メッセージを受信したサーバは,PUBLISHに含まれるトピック名について購読要 求を受け付けている全てのクライアントに,そのメッセージを送信する。 PUBLISHを使ったメッセージ送信では,QoSレベルを使って送達確認手順を指定 する。QoSレベルとメッセージ送信の通信シーケンスを図3に示す。 Semis 5 1 QoSレベルが0の場合のメッセージ送信 (次のメッセージの送信)ve(メッセージの処理) . QoSレベルが2の場合のメッセージ送信 PUBLISHの保存 ーーesの保存 PUBRELの保存(メッセージの処理) . (メッセージ送信の完了) 注記1 QoSレベルが2の場合,送達確認を行うPUBLISHを識別するために,パケットIDが付与される。 注記2 QoSレベルが2の場合,受信者は,メッセージの処理を開始した以降に受信したPUBLISHは,パケ ットIDの重複にかかわらず新しいパケットとみなす。 図3 QoSレベルとメッセージ送信の通信シーケンス 図3中の通信シーケンスの説明を次に示す。 ・QoSレベルが0の場合,MQTT層におけるPUBLISHの送達確認は行わかい。TCP 層による送達確認だけが行われる。 ・QoSレベルが2の場合,MQTT層においてもPUBLISHの送達確認が行われる。 MQTT層の送達確認の説明を次に示す。 -TCPコネクションが切断された場合のために,PUBLISH及びPUBRELは送信 者によって保存され,送信者から受信者への再送に利用される。 -@PUBLISHを受信した受信者は,.メッセージの処理を始める前に送信者に PUBRECを送信し,その応答であるPUBRELを受信してからメッセージの処理 を開始する。 -PUBRELを送信した送信者は,その応答であるPUBCOMPを受信してから,メ ッセージ送信を完了する。 次にWさんは,Xシステムの2種類のメッセージ交換について,トピック名, QoSレベル,及び配信元と配信先を整理した。 Xシステムのメッセージ交換を図4に示す。 ーー6— axe sy区QoS heyy yess 業務サーバから,特定のデバイスDiに対して,設定情報を送信す る。 。|デバイスDi 1-ーー2 config/Diの設定情報 全てのデバイスDi(i=1,2,…,m)から,業務サーバ及び同じ 工場のエッジサーバに対して,稼働情報を定期的に送信する。 FanデバイスDi Onの移働情報 注記Diは,デバイスの識別子を表す。 図4 Xシステムのメッセージ交換 図4の説明を次に示す。 ・項番1では,デバイスDiは,あらかじめ|オォ|を交換サーバに送信し,ト :ピック名が|カ|]のPUBLISHが送信されるようにする。 ・項番1では,QoSレベルとして2が使用されている。交換サーバからデバイスDi へのPUBLISH送信中に|キ|が電源断などで非稼働になった場合,その PUBLISHは,|ク|の中に保存され,稼働再開後に再送される。 ・項番2では,QoSレベルとして0が使用されている。これは,|ヶケ|及びェ ッジサーバは安定した稼働が見込めるからである。 Wさんは,1台の業務サーバが6,000台のデバイスの設定を変更する場合の送信時 間(T)を概算した。 WさんがTの概算に用いた通信シーケンスを図5に示す。 ーー7ーー ee|ianーー1 NN t2 mXt1 t2 |t2 注記太線の矢印は,QoSレベルが2の場合のメッセージ送信を表す。 図5 WさんがTの概算に用いた通信シーケンス 図5中の装置の処理時間を無視し,図5中のtl及びt2は,それぞれの装置間の RTT(Round Trip Time)の2倍に等しいとし,LANのRITを20ミリ秒,WANの RTTを200ミリ秒とすると,Tは次のように概算できる。 T=mXtl+t2=6,000 X 2 X 20+2 X 200(ミリ秒)=4(分) この概算を基に,Wさんは,次のように報告することにした。 ・TCPコネクションが正常であれば,全デバイスへの設定情報の送信は4分間程度 で完了する。 ・ただし,図1に示すように,は同一拠点に設置されている必 要がある。 [APIにアクセスする顧客サーバの管理〕 Wさんは,顧客サーバからのAPIアクセスに関する検討を行った。 Xシステムでは,認可サーバを使って,顧客サーバからのAPIアクセスを認可す る。契約及びサービス仕様の変更が顧客ごとに発生するので,それらを前捉とした 認可の仕組みが必要になる。Wさんは,認可コード,アクセストークン,及びリフ レッシュトークンを使った,認可の仕組みを採用することにした。 XシステムのAPIアクセスの通信シーケンスを図6に示す。 ーag一 (Webブラウザ)(WebAP)サーバ(API) (1)有効なトークンがな|情報要求 いり場合リダイレクト応答 (a)認可要求 ーーーアクセスの確認(省略)・-ーーー (b)認可応答 (c)トークン要求 (d)トークン応答 アクセストークンを使った情報要求 (HI)アクセストークンが|情報要求 有効な場合アクセストークンを使った情報要求 (Ml)リフレッシュトーク|svsuaese|| eeアクセストークンを使った情報要求 ed リフレッシュトークンを使ったトークン要求 新アクセストークンを使った情報要求 (a)認可要求:|IGET/authorizezredirect un=【WebAPのURI】(省略) HOST:【認可サーバ】 (b)認可応答:|HTTP/1.1 302 Found Location:【WebAPのURI】?code=【認可コード】 (c)トークン要求:IPOST/token HTTP1.1 (省略) (省略)code=【認可コード】&redirect un=【WebAPのURI】(省略) (d)トークン応答:|HTTP/1.1 200 OK (省略) 【アクセストークン】,【リフレッシュトークン】(省略) 図6 XシステムのAPIアクセスの通信シーケンス 6中の(1)に示すように,有効なトークンがない場合,Webブラウザから mm 9—_ WebAPへの情報要求は,|サ|サーバにリダイレクトされる。設可応答では, 認可要求で通知されたURIを用いたリダイレクトによって,|シ|に認可コー ドが通知される。続いて,認可コードを用いたトークン要求とトークン応答が行わ れ,WebAPはアクセストークンとリフレッシュトークンを獲得する。 図6中の(1)~(MM)に示すように,業務サーバへの情報要求には,アクセス トークンが用いられる。アクセストークンには,アクセス可能なAPIと有効期間に 関する情報が含まれており,業務サーバはそれらの情報からアクセスの可否を決め る。アクセストークンの有効期間を過ぎた場合でも,|ス ]の有効期間内であ れば,利用者の確認を行わずに,新しいアクセストークンが発行される。 Xシステムでは,顧客ごとに異なるアクセストークンを定義し,認可サーバに格納 しておく。ある顧客に提供するAP]の範囲が変わる場合,X社は認可サーバのアク セストークンを変更する。Wさんは,アクセストークンの有効期間を10分間,リ フレッシュトークンの有効期間を60分間と想定し,トークンの運用を確認した。 6の通信シーケンスでは,6 HO“(a)認可要求"のredirect uriパラメタが 書き換えられ,図6中の|セ|に含まれる認可コードが意図しない宛先に送信 される可能性がある。Wさんは,その対策として“redirect uriパラメタの確認"を 行うことにした。これは,図6中の[|ソ|サーバに,HTTPリクエストに含ま れるURIとあらかじめ登録されている絶対URIが一致することを確認させる,とい う対策である。⑤顧客向けのAPI利用ガイドラインには,COMRICMECMEN の依頼内容を明記することにした。 [エッジサーバを活用する将来構想] 4中のメッセージ交換では,X社内の交換サーバを利用するので,顧客の企業秘 密を含むような設定情報及び稼働情報OE,これらを内部情報という)は,対象 外としている。しかし,内部情報についても図4と同様にメッセージ交換を行いた い顧客も多い。X社では,エッジサーバを活用して,内部情報もXシステムに取り 込む将来構想をもっている。 顧客サーバが一つの場合について,将来構想で追加されるXシステムのメッセー ジ交換例を図7に,Wさんが考えた将来構想におけるネットワーク構成案を図8に, それぞれ示す。 =te= 顧客サーバと同じ工場のデバイスDi(i=1,2,…,m')AIC,エッジ サーバを使って,顧客の工場に閉じた情報交換を行う。 =>デバイスni|ConfidentialDi|に関する内 デバイスDi ーエッジサーバ部情報 -Fa 図7将来構想で追加されるXシステムのメッセージ交換例 顧客の工場 工作装置 中 LSW NATルータ-P !顧和客ホットワーク。See NATルータ-P" Le上sw| ee L2SW FW ES WISP 1サーバ! ddd-P:Xシステムにおける,機器dddのプライベートIPアドレス ddd-P’:顧客ネットワークにおける,機器dddのプライベートIPアドレス 図8 Wさんが考えた将来構起におけるネットワーク構成案(抜粋) 8に示すように,Wさんは,NATルータを使って,顧客ネットワークとXXシス テムを接続する案を考えた。NATルータは,1:1静的双方向NATとして動作させ, 8中のNATルータ-PとNATルータ-P”を利用して,宛先IPアドレスと送信元TP アドレスの両方を変換させる。 Wさんが考えた将来構想におけるメッセージの流れを図9に示す。 顧客の工場(将来構想を実現する拠点) 『人|デバイス(MQTTクライアント) 「顧客ホネットワーク| ipoeeeles Te |ーーゴーMG機能|ee ーー=将来構想における図4中のメッセージの流れ るーーご>:図7中のメッセージの流れ 9 Wさんが考えた将来構想におけるメッセージの流れ 図9の説明を次に示す。 ・顧客サーバにMQTTクライアント機能を,エッジサーバにMQTTサーバボ機能をそ れぞれ実装し,顧客サーバとエッジサーバ間でメッセージ交換を行う。 ・エッジサーバのMQTTサーバ機能は,通常のMQTTサーバ機能に加えて,メッセ ージをほかのMQTTサーバと送受信する機能(以下,MQTTブリッジという)を もつ。Xシステムのデバイスは複数の機器とTCPコネクションを確立できないの で,このMQTTブリッジを利用する。 ・⑥MQTTブリッジには,トピック名をあらかじめ定義しておき,そのトピック名 |のメッセージを交換サーバと送受信させる。 Wさんは,図7て9を使って,ネットワークの動作について検討し,将来構想への 対応が可能であると判断した。 Wさんは,以上の検討結果を上司に報告した。X社の情報システム部は,Xシステ ム構想を実現するためのプロジェクトを発足させた。

共通の文章

サービス基盤の構築に関する次の記述を読んで,設問1こ5に答えよ。 Y社は,データセンタ(以下,DCという)を運営ししホスティングサービスを提 供している。ホスティングサービスのシステムは,顧客ごとに独立したネットワー クとサーバから構成されている。Y社が運営しているホスティングサービスのシステ ム構成を図1に示す。 P社のWebサーバ利用者 Y社のDC cee サーバpl||サーバp4サーバq1l||サーバq2|サーバz1||サーバ22サーバタz P社向けサーバQ社向けサーバZ社向けサーバ 広域イーサ綱:広域イーサネットサービス網FW:ファイアウォール L2SW:レイヤ2スイッチL3SW:レイヤ3スイッチLB:サーバ負荷分散装置 注記P社,Qt,Z社は,Y社の顧客である。 図1 Y社が運営しているホスティングサービスのシステム構成(抜粋) このたび,Y社では,新規顧客へのサービスの提供やサーバの増設を迅速に行える ようにするとともに,導入コストや運用コストを削減してサービスの収益性を高め る目的で,サービス基盤の構築を決定した。このサービス基盤では,ネットワーク と物理サーバを顧客間で共用し,論理的に独立した複数の顧客システムを稼働させ る,マルチテナント方式のIaaS(Infrastructure as a Service)を提供する。 サービス基盤構築プロジェクトリーダに指名された,基盤開発部のM課長は,部 下でネットワーク構築担当のN主任に,次の3点の要件を提示し,サービス基盤の 構成を検討するよう指示した。 (1)サーバの仮想化によって,サーバ増設要求に迅速に対応可能とすること (2)サービス基盤で稼働する顧客システムは,顧客ごとに論理的に独立させること (3)サービス基盤は冗長構成とし,サービス停止を極力抑えられるようにすること N主任は,SDN(Software-Defined Networking)技術を用いず,従来の技術を用い た方式(以下,従来方式という)とSDN技術を用いた方式(以下,SDN方式という) の二つの方式に関して,サービス基盤を構築する場合や顧客が増減した場合の作業 内容などを比較して,構築方式を決めることにした。この方針を基に,N主任は,部 下の」さんに,サービス基盤の構成について検討するよう指示した。 [従来方式でのサービス基盤の構成案〕 Jさんは,まず,従来方式で構築する場合のサービス基盤の構成を検討した。]さ んが設計した,従来方式によるサービス基盤の構成案を図2に示す。 P社のWebサーバ利用者Qt・・・Z社 Y社のDC 「サービス基盤ee| || ||i| |Sees| |aan| tk||[i:既設機器 =a@:NIC(Network Interface Card) 物理サーバュニーュー1!物理サーバnl!|し:リンクアグリゲーション又は 1チーミング !sti!|注記1物理サーバに接続する共有 1<“=ディスク装置の記述は省略さ Hサーバサーバサーバサーバ||注記2顧客向けのサーバは,それ 1 1ぞれ別の仮想サーバ上で稼働 間昌EEIIEIIIIIさせる。 図2従来方式によるサービス基盤の構成案 サービス基盤は,VLANによって顧客問のネットワークを論理的に独立させる。、 図2中の既設のL2SW及びL3SWのサービス基盤への接続ポートには,それぞれ リンクアグリゲーションを設定する。既設のL2SW又はL3SWに接続するL2SWaと L2SWbのポートには,接続先の顧客ごとにリンクアグリゲーションとVLANを設定 する。L2SWaとL2SWbの間及びL2SWcとLaswaの間は,|ア|接続して, それぞれ,一つのL2SWとして動作できるようにする。 FWは,①装置の中に複数の仮想FWを稼働させることができ,②装置の冗長化が. できる製品を選定する。冗長構成では,アクティブの仮想FWが保持しているセッ ション情報が,装置間を直結するケーブルを使って,スタンバイの仮想FWに転送 される。セッション情報を継承することで,仮想FWの[イ|フェールオーバ を実現している。 LBは,負荷分散対象のサーバ群を一つのグループ(以下,クラスタグループとい う)としてまとめ,クラスタグループを複数設定できる製品を選定する。クラスタ グループごとに仮想Pアドレスとアルゴリズムが設定できるので,B 数の顧客の処理を1台で行える。LBも冗長化が可能であり,FWと同様の方法で冗 長構成を実現している。 2の構成案では,FWとLBは,FWaとLBaをアクティブに設定する。スタンバ イの装置がアクティブに切り替わる条件は,両装置とも同様であり,両装置は連動 して切り替わる。 物理サーバには2枚のNICを実装し,|エ機能を利用してアクティブンノア クティブの状態にする。L2SWcとL2SWdには,リンクアグリゲーションのほかに, ⑨③仮想サーバの物理サーバ間移動に必要となるVLANを設定する。 (SDN方式でのサービス基盤の構成案」 Ric,Jさんは,SON製品のベンダの協力を得て,SDN方式で構築する場合のサ ービス基盤の構成を検討した。 SDNを実現する技術の中に,OpenFlow(AF,OFという)がある。今回の検討 では,標準化が進んでいるOFを利用することにした。 OFは,データ転送を行うスイッチ(以下,OFSという)と,OFSの動作を制御す るコントローラ(以下,OFCという)から構成される。OFSによるデータ転送は, ー16一 OFCによって設定されたフローテーブル(以下,FEテーブルという)に基づいて行 われる。 ]さんが設計した,OFによるサービス基盤の構成案を図3に示す。 P社のWebサーバ利用者Q社vee Z社 Y社のDC eee"[oss FT one| |—oe 3 物理サーバ1!!!!物理サーバn! |回|(BH| 1サーバサーバ|サーバサーバ ーーー。計 注記1物理サーバに接続する共有ディスク装置の記述は省略されている。 注記2 OFCはL2SW1を介して,OFS1とOFS2の管理用ポートに接続される。 注記3顧客向けのサーバ,FW及びLBは,それぞれ別の仮想サーバ上で稼働させる。 図3 OFによるサービス基盤の構成案 OFSは2台構成とし,相互に接続する。図3中の既設のL2SW及びL3SWのサー ビス基盤への接続ポートには,リンクアグリゲーションを設定し,OFS1とOFS2に 接続する。物理サーバには,図2と同様に2枚のNICを実装して各NICをアクティ ブンノアクティブの状態にする。FWとLBには,仮想サーバ上で稼働する仮想アプラ イアンス製品を利用する。OFCは,OFS1とOFS2の管理用ポートに接続する。 これらのOFSは,起動するとOFCとの間でTCPコネクションを確立する。その elk,OFCとの間の通信路となるOFチャネルが開設され,それを経由してOFCか らFテーブルの作成や更新が行われる。したがって,OFSの導入時には,④OFCと のTCPコネクションの確立に必要な最小限の情報を設定すればよく,導入作業は容 易である。 Jさんは,二つの方式で設計したサービス基盤の構成をN主任に説明したところ, ニニつの方式を比較し,Y社に適した方式を提案するよう指示を受けた。 (二つの方式の比較)〕 了さんは,図2と図3のサービス基盤を構築する場合について,二つの方式で実施 することになる作業内容などを基に,比較表を作成した。]さんが作成した二つの方 式の比較を表1に示す。 表1 Jさんが作成した二つの方式の比較 以上の比較検討を基に,Jさんは,OFを用いると技術習得などに時間を要するこ とになるが,今後のサービス拡大に柔軟に対応できるようになると判断し,OFによ るサービス基盤の構築を,N主任に提案した。N主任は,Jさんの提案がY社にとっ て有益であると考え,Jさんの提案を基にサービス基盤の構築案をまとめ,M課長に 報告したところ,テストシステムを構築して,OFの導入効果を確認するようにとの 指示を受けた。 [技術習得を目的とした制御方式の設計 テストシステムの構築に当たって,N主任と」さんの2人は最初に,OFの技術習 得を目的として,MACアドレスの学習によるパケットの転送制御方式を考えること (luge, テストシステムは,M1中のP社,Q社及びZ HO 3顧客向けのシステムを収容 した構成である。テストシステムの構成を図4に,テストシステム中の機器と仮想 サーバのMACアドレスを表2に示す。 a HG es P社のWebサーバ利用者Q社Z社 Bs OFS1 pl p2 p3 p20 p20 pl p2 p3 OFS2 ae od EE Ls pll p12 p13 a p23 pll p12 p13 レニーーーmm In ee er @ぃ=gi「いヽab biic dite fs Web||Web Web業務 サーバpl||サーバp4サーバ21サーバタ 物理サーバ1物理サーバ2物理サーバ3 CL):P社向け仮想サーバ還調:Q社向け仮想サーバBBB:Z社向け仮想サーバ a:VLANID=100 b:VLANID=110 c:VLANID=120 d:VLANID=テ200 e:VLANID=210 f:VLANID=300 g:VLANID=310 注記1 pl~p3,pll~pl3,p20てp23は,ポート番号を示す。 注記2 OFCと共有ディスク装置の記述は省略されている。 図4テストシステムの構成 表2テストシステム中の機器と仮想サーバのMACアドレス 想サー: 、機器名又は内部側りのWAN側2の >[piel|[seca[mirser|ca Ci) [ 2社の系務サーバッ 注記MACアドレスの重複はないものとする。 注')内部側は,図1中の各機器の下側のポートを指す。 2 WAN側は,図1中の各機器又はサーバの上側のポートを指す。 図4に示したように,P社にはVLAN IDに100,110,120,Q社にはVLAN IDに 200,210,Z社にはVLAN IDに300,310を,それぞれ割り当てる。各顧客のWeb サーバと業務サーバ間の通信は発生しない。 2人は,Fテーブルの構成について検討した。Fテーブルは,OFSのデータ転送動 作を確認しやすくするために,最初に処理されるFテーブル0と,パケットの入力 ポートに対応して処理されるFテーブル1~4の五つの構成とした。2人がまとめた, 五つのFテーブルの役割を表3に示す。 表3五つのFテーブルの役割 a Fテーブルは,複数のフローエントリGER,FEY RV EWS)からなる。 Fエントリは,OFSに入力されたパケットがどのFエントリに一致するかを判定 するためのマッチング条件,条件に一致したパケットに対する操作を定義するアク Yay,パケットが複数のFエントリに一致した場合の優先度などで構成される。 入力されたパケットが,Fテーブル内の複数のFエントリのマッチング条件に一致し た場合は,優先度が最も高いFエントリのアクションが実行される。また,COV ッチング条件にも一致しないパケットは廃棄される。一つのFエントリには,複数 のアクションを定義できる。 OFCとOFSの間では,メッセージの交換が行われる。このメッセージの中には, OFSに対してFエントリを設定するFlow-Modメッセージ,OFSが受信したパケッ トをOFCに送信するPacket-Imメッセージ,OFCがOFSに対して指定したパケット の転送を指示するPacket-Outメッセージなどがある。 次に,2人は,3顧客で全てのサーバとの通信が正常に行われたとき(以下,正常 通信完了時という)に,OFCによってOFSに生成されるFエントリを,机上で作成 した。正常通信完了時のFテーブル0て4を,それぞれ表4一8に示す。 ー20一 表4正常通信完了時の0FS1とOFS2のFテーブル6 ||ポート=mg|テーブル4できれな年ち3| 表5正常通信完了時の0FS1と0FS2のFテーブル1 |+logsycmrw ats|wl 注!eTYPE lk,イーサタイプを示す。 2_mDESは,宛先MACアドレスを示す。 表6正常通信完了時の0FS1とOFS2のFテーブル2 [+[aowscmeneremamar’”[sme| |4|mbES=mLBp,msRc”=mWspt—[pismoiiyしmu Ps[erwerrarr«(OPER ave ewe 注記項番5は,仮想サーバが物理サーバ1に移動してきたことをOFCに知らせるためのFエントリで ある。 注"mSRCは,送信元MACアドレスを示す。 ー21一 表7正常通信完了時の0FS1とOFS2のFテーブル3 eTYPE=ARP,VLAN ID=310,sc Ps ferecmane irc akon ave vem| 以下,省略 注記項番5は,仮想サーバが物理サーバ2に移動してきたことをOFCに知らせるためのFエントリで ある。 表8正常通信完了時の0FS1と0FS2のFテーブル4 eTYPE=ARP,VLAN ID=100,x I a bY に9 eTYPE=ARP,VLAN ID=120,、と eTYPE=ARP,VLAN ID=300,し~ |“Nyに[| a ee coc eTYPE=ARP,VLAN ID=310,~ |s[apes ment,msnomuby|mなsm| |』lmpescmWegi nsRccmue。|mgがsm| 以下,省略 注記項番12は,仮想サーバが物理サーバ3に移動してきたことをOFCに知らせるためのFエントリで ある。 表8中の項番2は,。イーサタイプがARP,VLAN IDが100及び宛先MACアドレ スがFEF-FF-FF-FF-FF-FFのパケットを,VLANタグを削除してplから出力すること を示している。 OFSにパケットが入力されると,OFSは表4のFテーブル0の処理を最初に実行 する。例えば,図4中のQ社のIPsecルータからOFS1のp2にARPリクエストパケ ットが入力された場合,そのパケットは,表4中の項番2に一致するので,パケッ トにVLAN IDが200のVLANタグをセットし,次に表5のFテーブル1で定義され た処理を行う。表5のFテーブル1では,項番1に一致するので,当該パケットは Packet-Imメッセージに収納されて,OFCに送信される。OFCは受信したパケットの 内容を基に,Flow-ModメッセージでFエントリを生成したり,Packet-Outメッセー ジなどをOFSに送信したりする。 N主任とSAIS,作成したFテーブルの論理チェックを行い,五つのFテーブ ルによってテストシステムを稼働させることができると判断した。 パケット転送制御方式の机上作成を通してOFの動作イメージが学習できたので, 次に,2人は,実際にテストシステムを構築して,動作検証と性能評価を行うことに した。