平成23年度 秋期 午後Ⅱ

本文の根拠

〔作業効率を高めるための CE 用 PC の選定〕

MPC には，駅などの公共施設にあるアクセスポイントを経由して，インターネットに接続できる ［ ア ］ 機能をもった機種が多い。

〔作業効率を高めるための CE 用 PC の選定〕

MPC の多くは，外出先での使用が前提とされているので，位置情報を取得する ［ イ ］ 機能，カメラ機能，

ア：駅などの公共施設にある“アクセスポイント”を経由してインターネットにつなぐのは，無線 LAN（IEEE 802.11 系）の公衆アクセスポイントである。携帯電話網につなぐ機能はこの後の文で別に扱われているので，ここは携帯電話網以外の接続手段になる。イ：携帯端末で位置情報を取得する機能は GPS（全地球測位システム）である。

本文は，アの直後に“携帯電話網に直接接続する機能をもたない MPC でも，…テザリング機能を使うと”と続けている。つまりアは，携帯電話網を使わずにインターネットにつなぐ機能を指す。イは“外出先での使用が前提”“位置情報を取得する”という条件から決まる。

間違えやすい点。アに“Wi-Fi”と書いても同じものを指すが，解答例の表記は“無線 LAN”である。“テザリング”は後の文で別に出てくるので，アには入らない。

採点講評（IPA）

設問１では，リモートアクセスに使われる端末の機能に関する問いであったが，身近に接しているためか，正答率は高かった。

本文の根拠

〔作業効率を高めるための CE 用 PC の選定〕

①インターネットを介してデータセンタにセキュアな VPN 接続を実現するための標準的な機能

〔地域保守会社及び MPC から A 社データセンタへの接続ネットワークの検討〕

VPN₁ のインターネット側インタフェース a のグローバルアドレス宛てに送られてきたパケットの中でポート番号 443 のパケットは，そのままモバイル端末接続装置に転送される。

CE は駅の公衆無線 LAN や顧客先，テザリングなど，様々な場所のネットワークからつなぐ。そうした場所では，ファイアウォールやプロキシ，NAT によって使えるポートが Web（HTTP/HTTPS）に絞られていることが多い。SSL（TLS）による VPN は HTTPS と同じ TCP 443 番で通信するので，こうした制限の下でも通りやすい。IPsec は ESP（IP プロトコル番号 50）や IKE（UDP 500）を使うので，途中の機器で遮断されたり NAT を越えられなかったりすることがある。

後の〔地域保守会社及び MPC から A 社データセンタへの接続ネットワークの検討〕でも，MPC からの接続はポート番号 443 のパケットとしてモバイル端末接続装置に届く設計になっている。443 は HTTPS（SSL/TLS）のポート番号であり，MPC が SSL-VPN で接続することと合う。

間違えやすい点。“IPsec”も VPN の標準的なプロトコルだが，設問は“様々な場所からネットワーク接続を行う観点”を求めている。この観点で有利なのは SSL である。現在の名称で TLS と書いても指すものは同じだが，解答例は“SSL”である。

採点講評（IPA）

設問１では，リモートアクセスに使われる端末の機能に関する問いであったが，身近に接しているためか，正答率は高かった。

本文の根拠

〔TC システムの検討〕

TC-V を利用した場合，呼制御は IP-PBX と仮想 PC 間で行うが，通話の音声を運ぶ RTP パケットは TC-V と IP-PBX 間で直接送受する。

図3

（USB リダイレクト方式）IP-PBX と仮想 PC（中にソフトフォン）の間が RTP の IP 接続，仮想 PC と TC の間が独自パケットの IP 接続，TC と USB ヘッドセットの間が音声の USB 接続。

〔TC システムの検討〕

USB リダイレクト方式は，TC に USB デバイスが接続されると，あたかも仮想 PC に USB デバイスが接続されたように動作させる機能を利用する方式である。

USB リダイレクト方式では，USB ヘッドセットの音声は USB デバイスのデータとして TC から仮想 PC へ運ばれ，仮想 PC のソフトフォンで初めて RTP に変換される。TC と仮想 PC の間を流れるのは，USB オーディオのデータ（圧縮されていない音声のサンプル）を独自パケットに載せたものなので，帯域を多く使う。TC-V 方式では TC-V 自身が RTP を送受するので，音声通話用に作られた圧縮率の高いコーデック（例えば G.729 は 8k ビット／秒で，無圧縮の G.711 の 64k ビット／秒より少ない）で符号化した音声だけが LAN を流れる。

本文は，TC-V 方式では“RTP パケットは TC-V と IP-PBX 間で直接送受する”と書いている。RTP のペイロードの形式を決めるのがコーデックであり，TC-V は音声のために作られた機器なので，通話向けのコーデックを使える。

35 字以内に収めるには，“音声通話用の圧縮率の高いコーデック”と“それが利用できる”の二つを残す。解答例は 29 字。

本文の根拠

図3

（USB リダイレクト方式）IP-PBX と仮想 PC（中にソフトフォン）の間が RTP の IP 接続，仮想 PC と TC の間が独自パケットの IP 接続，TC と USB ヘッドセットの間が音声の USB 接続。

〔TC システムの検討〕

一方，仮想 PC 方式は，PC の独立したプログラム実行環境（以下，仮想 PC という）を TC と 1 対 1 でサーバ上に用意する方式である。

USB リダイレクト方式では，音声は必ず仮想 PC を経由し，仮想 PC のソフトフォンが音声の符号化・復号や RTP との変換を行う。一つ目は，この音声処理を仮想 PC が行うための処理時間が加わることで，音声遅延が大きくなることである。二つ目は，仮想 PC は同じ物理サーバ上で他の仮想 PC と CPU などの資源を共有しているので，負荷の変動によって音声処理に掛かる時間がばらつき，音声遅延の揺らぎ（ジッタ）が生じることである。遅延は会話の間延びや話者の衝突を生み，ジッタは音の途切れや乱れを生む。

本文の図3で，TC-V 方式は IP-PBX と TC-V が RTP で直接つながり，仮想 PC を通らない。USB リダイレクト方式だけが仮想 PC の処理を挟むので，仮想 PC に起因する劣化要因は遅延と遅延のばらつき（ジッタ）になる。

間違えやすい点。“パケットロス”や“帯域不足”はネットワークの問題であり，設問の“仮想 PC の処理によって発生する”事象ではない。事象（処理時間の増加，処理時間のばらつき）と要因（遅延，ジッタ）の組にして書く。

採点講評（IPA）

設問2(2)では，VoIPによる電話機能を備えたシンクライアントの実現方式について問うた。仮想PCの振る舞いと音質への影響について正答するには，出題されたシステムの具体的な動きを考える力が必要である。

本文の根拠

〔電話の着信場所の A 社データセンタへの統合化に伴う電話回線の必要数の算定〕

現在，地域保守会社は 10 社あり，地域ごとに受付回線 10 本で対応し，最繁時は 1 時間当たり 36 件の問合せ電話がかかってくる。電話応対には，通話後の後処理時間を含め，1 件当たり平均 10 分掛かる。

〔電話の着信場所の A 社データセンタへの統合化に伴う電話回線の必要数の算定〕

待ち行列理論では，待ち行列モデルを，“到着間隔の分布型／サービス時間の分布型／窓口数／待ち行列系の許容収容数”で表現するケンドール記法がよく使われる。

a：到着率 λ は単位時間当たりに到着する呼の数なので，1 時間当たり 36 件をそのまま使い，36 になる。b：サービス率 μ は 1 つの窓口が単位時間当たりに処理できる数で，1 件 10 分掛かるから 60÷10＝6（件／時）になる。c：M/M/s/s の s は窓口数で，各地域の受付回線 10 本が窓口に当たるので 10 になる。

検算。呼量（トラフィック密度）は λ÷μ＝36÷6＝6.0 アーランで，これは表1の左の表の呼量 6.0 の行と一致する。表1の注記1の“1 時間当たりの通話時間の合計”で数えても 36 件×10 分＝360 分＝6 時間で同じになる。

間違えやすい点。サービス率を平均サービス時間（10 分や 1/6 時間）と取り違えないこと。サービス率は時間の逆数である。s を地域保守会社の数 10 社と考えるのも誤りで，1 地域の窓口数（回線数）である（この問題ではどちらも 10 だが，意味が違う）。

採点講評（IPA）

設問3(1)では，待ち行列理論の用語の定義に関して誤解のある解答が散見され，正答率は低かった。

本文の根拠

〔電話の着信場所の A 社データセンタへの統合化に伴う電話回線の必要数の算定〕

②A 社で一括して受け付けるようにして，呼損率を従来と同等以下にするために，受付回線が何本必要となるかを，表1の呼損率表から求めることにした。

表1

左の表（回線数 10）：呼量 6.0 のとき 4.3，呼量 6.7 のとき 6.7，呼量 7.0 のとき 7.9。右の表（回線数 66，67，68，69，70，71，72 の順）：呼量 60.0 のとき 4.6，3.9，3.4，2.8，2.4，2.0，1.6。

従来：1 地域の呼量は設問3(1)のとおり 36 件×10 分÷60 分＝6.0 アーランで，回線数は 10 本である。表1の左の表で呼量 6.0・回線数 10 の呼損率は 4.3％になる。集約後：10 地域分の呼が A 社に集まるので，到着率は 36×10＝360 件／時，呼量は 360×10÷60＝60.0 アーランになる。表1の右の表の呼量 60.0 の行を見ると，66 回線で 4.6％（4.3％を超える），67 回線で 3.9％（4.3％以下）なので，必要最小限は 67 回線である。

従来は 10 回線×10 地域で 100 回線を使っていたが，集約すると 67 回線で同じ以上の品質を保てる。呼をまとめると回線を効率良く使える（大群化効果）ことが，数字で確かめられる。

間違えやすい点。呼量 66.7 や 70.0 の行を使わないこと。これらは別の条件の行である。また，66 回線の 4.6％は 4.3％より大きいので“同等以下”を満たさない。呼損率は％の値（4.3）を答える。

本文の根拠

〔電話の着信場所の A 社データセンタへの統合化に伴う電話回線の必要数の算定〕

現在のシステムの分析に当たり，まず，電話をかけても，回線がビジーとなってつながらない呼損状態が発生するモデル（待ち行列を作らないモデル）を想定した。

〔電話の着信場所の A 社データセンタへの統合化に伴う電話回線の必要数の算定〕

③自動音声応答用に回線を追加し，電話が着信して待ち状態になる場合は，自動音声応答機能でコールバックするための受付情報を取得して，直ちに切断する方式を導入することにした。登録された受付情報は，空きとなった受付者に順次割り当てられ，処理される。

従来のモデル M/M/s/s は，窓口数 s と許容収容数 s が等しく，窓口がふさがっていると到着した呼は捨てられる（呼損になる）即時式のモデルである。対策後は，受付者がふさがっていても，受付情報を登録して順番を待たせ，空いた受付者に順に割り当てる。これは，窓口数より多くの要求を受け入れて待ち行列に並べるモデル（ケンドール記法で M/M/s/K，K＞s，あるいは制限なしの M/M/s）であり，“通話要求の待ち行列を許すモデル”になる。

本文は，従来を“待ち行列を作らないモデル”と明示している。対策後は“登録された受付情報は，空きとなった受付者に順次割り当てられ”るので，待ちが生じても呼は失われず，順番待ちの列ができる。

20 字以内に収めるには，“待ち行列を許す（待ち合わせる）”という性質と，何が待つのか（通話要求）を残す。解答例は 15 字。

採点講評（IPA）

設問3(3)では，待ち行列のモデルについて，呼損率を計算する場合に使われる待ちを許容しない即時系と，窓口の数より許容収容数の多い待ちを許す系の存在について問うた。出題のケースでは，どのようなモデルに対応するかを問うたが，正答率は低かった。単に暗記するだけでなく，実際のシステムの動きと関連付けた理解が大切である。

本文の根拠

〔地域保守会社及び MPC から A 社データセンタへの接続ネットワークの検討〕

今回採用した VPN₁ と VPN₂ 間の VPN 接続では，VPN のトンネルが確立すると，その VPN トンネルの仮想的なインタフェースが，ルーティング上，有効な経路として扱われる。

表2

No.5：宛先 192.168.32.0/24，ゲートウェイ 0.0.0.0，インタフェース e，メトリック値 1。

図4

VPN₁ のインタフェース a，e（グローバルアドレス X₁.X₂.X₃.X₄）はインターネットに接続している（a と e は同じ位置に書かれている）。

表2の No.5 は，地域保守会社の LAN（192.168.32.0/24，図4で VPN₂ の配下）への経路で，インタフェースが e になっている。地域保守会社へのパケットは VPN トンネルを通して暗号化して送るので，この経路の出口は VPN トンネルの仮想的なインタフェースでなければならない。したがって e が VPN トンネルのインタフェースである。図4で e が物理インタフェース a と同じ位置に書かれているのは，トンネルが a の上に作られる仮想的なインタフェースだからである。

他のインタフェースを確かめると，a はインターネット側の物理インタフェース（No.1 のデフォルトルートと No.2），b はモバイル端末接続装置，c は L2SW，d は認証サーバ，m は Null ポートにつながっている。どれも VPN トンネルではない。

間違えやすい点。a と答えないこと。a はトンネルが確立していなくても使えるインターネット側の実インタフェースで，ここから出るパケットは暗号化されない（設問4(2)の問題の原因になる）。

採点講評（IPA）

設問4(1)と4(2)では，IPsec-VPNとSSL-VPNの両方に対応したリモートアクセスシステムに関する具体的な設計と設定について問うた。VPNトンネルが，どことどこの間に存在するのか，理解ができていない解答が多かった。

本文の根拠

〔地域保守会社及び MPC から A 社データセンタへの接続ネットワークの検討〕

VPN₁ と VPN₂ 間のインターネット VPN 接続のためのアソシエーションが確立できなかった場合，暗号化されないパケットがインターネット側に送出されてしまうことを発見した。

〔地域保守会社及び MPC から A 社データセンタへの接続ネットワークの検討〕

ゲートウェイに“0.0.0.0”を指定したときは，ゲートウェイを経由せず直接宛先ネットワークに到達可能であることを示している。また，メトリック値は数値が小さいほど優先度が高い。

図4

注1）m は Null ポートであり，Null ポートに送出されたパケットは転送されない。

トンネルが確立していないと，No.5（インタフェース e）の経路は無効になる。すると 192.168.32.0/24 宛てのパケットは No.1 のデフォルトルート（0.0.0.0/0，インタフェース a）に一致し，暗号化されずにインターネットへ出てしまう。これを防ぐには，同じ宛先 192.168.32.0/24（ウ）について，Null ポート m へ捨てる経路を用意する。ゲートウェイは経由しないので 0.0.0.0（エ）とする。この経路は，トンネルが確立しているときは No.5 に負け，トンネルが無いときだけ使われなければならない。No.5 のメトリック値が 1 なので，それより大きい 2 以上（オ）にする。

ルーティングでは，まず宛先が最も長く一致する経路（ロンゲストマッチ）が選ばれるので，/24 の No.6 は /0 のデフォルトルートより必ず優先される。同じ宛先の No.5 と No.6 の間では，本文の“メトリック値は数値が小さいほど優先度が高い”によって，有効なら No.5 が選ばれる。このように，本命の経路より優先度の低い予備の経路を置く方法をフローティングスタティックルートと呼ぶ。

間違えやすい点。オを 0 や 1 にすると，トンネルが確立していても No.6 が選ばれたり，No.5 と並んだりして，地域保守会社宛ての通信が捨てられてしまう。ウを 0.0.0.0/0 にしても，192.168.32.0/24 宛てのパケットはメトリック値 1 の No.1 に一致してインターネットへ出てしまい，対策にならない。

採点講評（IPA）

設問4(1)と4(2)では，IPsec-VPNとSSL-VPNの両方に対応したリモートアクセスシステムに関する具体的な設計と設定について問うた。VPNトンネルが，どことどこの間に存在するのか，理解ができていない解答が多かった。

本文の根拠

〔地域保守会社及び MPC から A 社データセンタへの接続ネットワークの検討〕

VPN₁ のインターネット側インタフェース a のグローバルアドレス宛てに送られてきたパケットの中でポート番号 443 のパケットは，そのままモバイル端末接続装置に転送される。

図4

モバイル端末接続装置のインタフェース f（10.0.0.1/24）は VPN₁ のインタフェース b に接続している。

MPC は，インターネット上で到達できる VPN₁ のグローバルアドレス X₁.X₂.X₃.X₄ のポート 443 へ接続してくる。一方，モバイル端末接続装置のアドレスはプライベートアドレスの 10.0.0.1 なので，インターネットから直接は届かない。そこで VPN₁ に，グローバルアドレス宛てでポート番号が 443 のパケットだけを，宛先を 10.0.0.1 に変換してモバイル端末接続装置へ転送する設定（ポートマッピング，静的 NAPT，ポートフォワーディングとも呼ぶ）をする。

本文は“ポート番号 443 のパケットは，そのままモバイル端末接続装置に転送される”と動作を書き，図4はモバイル端末接続装置のアドレス 10.0.0.1/24 を示している。VPN₁ はファイアウォールを兼ねているので，443 以外は転送しない（“だけ”）ことも設定の要点になる。

60 字以内に収めるには，“ポート番号 443 だけ”“10.0.0.1 宛てにアドレス変換”“転送”の三つを残す。解答例は 56 字。

本文の根拠

〔地域保守会社及び MPC から A 社データセンタへの接続ネットワークの検討〕

認証が完了すると，モバイル端末接続装置では，MPC があたかもインタフェース g にいて，L2SW のインタフェース h に接続しているように動作する。

〔作業効率を高めるための CE 用 PC の選定〕

①インターネットを介してデータセンタにセキュアな VPN 接続を実現するための標準的な機能

MPC とモバイル端末接続装置の間は SSL-VPN のトンネルで，MPC のアプリケーションが使う通信（宛先ポート番号を含む）は暗号化されて SSL のデータの中にカプセル化されている。VPN₁ から見えるのは，外側のポート番号 443 だけで，中のアプリケーションのポート番号は分からない。トンネルを終端して復号するのはモバイル端末接続装置なので，アプリケーションのポートによる制限はモバイル端末接続装置で行う必要がある。

本文は，認証が完了すると MPC が“インタフェース g にいて，L2SW のインタフェース h に接続しているように動作する”と書いている。復号後の通信はモバイル端末接続装置から g を通って社内の L2SW へ出ていくので，その手前のモバイル端末接続装置で中身を見て制限できる。

50 字以内に収めるには，“暗号化・カプセル化されている”と“中継する装置では内容を認識できない”の二つを残す。解答例は 44 字。

本文の根拠

〔拡張性を考慮した A 社データセンタ内ネットワーク構成の検討〕

データセンタでは，サーバの設置台数が増加し，中でも，ブレード型サーバの使用が増えている。

〔拡張性を考慮した A 社データセンタ内ネットワーク構成の検討〕

この製品は，10 G ビット／秒のイーサネットと FCoE に対応しており，1 個のアダプタで HBA（Host Bus Adapter）と NIC を兼ねることができる。

SAN と LAN を分けると，サーバごとに SAN 用の HBA と LAN 用の NIC を，冗長化のためにそれぞれ 2 個ずつ用意し，別々のケーブルとスイッチにつなぐ必要がある（図6の既設サーバは HBA 2 個と NIC 2 個をもつ）。ブレードサーバは筐体が小さく，外部インタフェースを載せる場所が限られている。FCoE で統合すると，CNA 1 個で HBA と NIC を兼ねられるので，インタフェースの数，そのための実装スペース，ケーブルの本数を減らせる。

本文は，ブレード型サーバの使用が増えていること，CNA が“1 個のアダプタで HBA と NIC を兼ねる”ことを書いている。図6でも，新規導入のサーバは CNA 2 個だけで SAN と LAN の両方につながる。

40 字以内に収めるには，“ブレードサーバの外部インタフェースの接続スペースの節約”と“配線数の削減”を残す。解答例は 34 字。

採点講評（IPA）

設問5では，製品への実装が進むFCoE対応スイッチの動作について問うた。問題文をよく読み，FCoEで実現する機能の利点を把握することが必要である。

本文の根拠

〔拡張性を考慮した A 社データセンタ内ネットワーク構成の検討〕

④FC では，フロー制御の方法として，送信側と受信側の双方で，受信側の空きバッファ数を管理して送信を制御している。この方式を使うことによって，TCP で使われているような，ウィンドウサイズを用いたエンドシステム間の応答確認によるフロー制御では実現できないパケットロスの防止効果が得られる。

〔拡張性を考慮した A 社データセンタ内ネットワーク構成の検討〕

パケットロスの要因としては，伝送路上でのビット誤りよりも，バッファの枯渇の方が大きいと考えられた。

TCP のウィンドウによるフロー制御は，送信元と宛先（エンドシステム）の間で行う。途中のスイッチのバッファがあふれても，送信元はそれを直接知ることができず，パケットが失われた後に再送で回復するしかない。FC のフロー制御（バッファ・トゥ・バッファ・クレジット）は，リンクでつながった隣り合うノード同士が，受信側の空きバッファ数（クレジット）を双方で管理し，空きが無ければ送らない。これにより，経路の途中の隣接ノード間で起きる局所的なバッファ枯渇でも，あふれる前に送信を止められる。

本文は，パケットロスの主な要因を“バッファの枯渇”とし，TCP のような“エンドシステム間の応答確認によるフロー制御では実現できない”効果を問うている。エンドシステム間と対比されるのは，隣接ノード間（ホップごと）の制御である。

35 字以内に収めるには，“隣接ノード間”“局所的なバッファ枯渇”“対処できる”を残す。解答例は 28 字。

採点講評（IPA）

設問5では，製品への実装が進むFCoE対応スイッチの動作について問うた。問題文をよく読み，FCoEで実現する機能の利点を把握することが必要である。

本文の根拠

〔拡張性を考慮した A 社データセンタ内ネットワーク構成の検討〕

LAN の MAC 層でも，フロー制御の方法として，送信側に対して PAUSE フレームを送って送信を抑止する機能が，オプションとして規定されている。しかし，FCoE の実現には，この機能では不十分と考えられており，

〔拡張性を考慮した A 社データセンタ内ネットワーク構成の検討〕

図5に示す方式では，⑤優先度別にバッファを用意し，受信バッファが枯渇したときには優先度別に送信を抑止するための PAUSE フレームを送出している。

図5

優先度 7 と優先度 0 のバッファからは，送信側から受信側へフレーム転送（実線の矢印）が行われている。優先度 3 のバッファについては，受信側から送信側へ PAUSE（破線の矢印，注1）が送られている。

イーサネットの従来の PAUSE フレーム（IEEE 802.3x）は，リンク上のすべての送信を止める。バッファが一つでもあふれそうになると，優先度に関係なくそのリンクの通信全体が止まるので，優先度の低い大量の通信がバッファを使い切ったせいで，優先度の高い通信（FCoE のストレージ通信など）まで送れなくなる。優先度別の PAUSE（IEEE 802.1Qbb の Priority-based Flow Control）なら，枯渇した優先度の送信だけを止め，他の優先度は流し続けられる。

図5では，優先度 3 のバッファにだけ PAUSE が送られ，優先度 7 と 0 のフレーム転送は続いている。本文も，PAUSE フレームだけでは“FCoE の実現には，この機能では不十分”としている。

50 字以内に収めるには，“優先度の低い通信によるバッファ枯渇”と“優先度の高い通信のパケットが送信されない”の因果を残す。解答例は 43 字。

採点講評（IPA）

設問5では，製品への実装が進むFCoE対応スイッチの動作について問うた。問題文をよく読み，FCoEで実現する機能の利点を把握することが必要である。

本文の根拠

〔拡張性を考慮した A 社データセンタ内ネットワーク構成の検討〕

フレームの転送経路については，コストを評価して最短経路を決める SPF（Shortest Path First）というアルゴリズムを使用している。このアルゴリズムでは，経路を冗長化する場合，⑥経路のコストを適切に設計することによって，トラフィックを分散できる。その結果，冗長化のためにスパニングツリープロトコルを使った場合には得られない効果が期待できた。

コスト設計：SPF では最もコストの小さい経路が選ばれる。複数の経路のコストを同じにすると，どれも最短経路として並行して使え（等コストマルチパス，ECMP），トラフィックをそれらに分散できる。TRILL（RFC 6325）はリンクステート型のルーティングで経路を決め，等コストの複数経路を使える。効果：スパニングツリープロトコルは，ループを防ぐために冗長な経路をブロックし，使う経路を 1 本に絞る。冗長経路は障害時の予備で，平常時は使われない。等コストの経路をすべて使えば，冗長経路の分だけ帯域を増やせる。

本文の“トラフィックを分散できる”“スパニングツリープロトコルを使った場合には得られない効果”が手掛かりである。スパニングツリーでも冗長化はできるので，冗長化そのものは答えにならない。得られないのは，複数経路を同時に使うことによる帯域の増加である。

コスト設計は 25 字以内，効果は 20 字以内。“同一コスト”“帯域の増加”を核にする。解答例はそれぞれ 19 字，15 字。

採点講評（IPA）

設問5では，製品への実装が進むFCoE対応スイッチの動作について問うた。問題文をよく読み，FCoEで実現する機能の利点を把握することが必要である。

本文の根拠

〔拡張性を考慮した A 社データセンタ内ネットワーク構成の検討〕

今回導入することにした FCoE-SW には，FC と FCoE の相互変換機能が用意されているということなので，既設のシステムに追加接続する形で，図6のような拡張性を考慮したネットワーク構成を考えた。ここで，二つの CNA は同時に使用する。

〔拡張性を考慮した A 社データセンタ内ネットワーク構成の検討〕

これによって，相互接続された複数の FCoE-SW が，一つの大きな FCoE-SW のように動作する。

図6

凡例：○はインタフェース，●は FC と FCoE 相互変換機能のインタフェース，L3SW はレイヤ3スイッチ，FC-SW は FC 対応スイッチ。

新規導入のサーバは CNA だけで SAN と LAN の両方を使うので，FCoE-SW はストレージ側（既設の FC-SAN）と LAN 側（既設の L3SW）の両方につながっていなければならない。必要な線は次のとおり。①上下の FC-SW の空いているインタフェースを，それぞれ上下の FCoE-SW の黒丸（FC と FCoE の相互変換機能のインタフェース）へつなぐ。FC-SW は FC しか話せないので，変換機能のある黒丸につなぐ。②上下の L3SW の空いている右側のインタフェースを，それぞれ上下の FCoE-SW の左側の白丸へつなぎ，LAN 側の通信をデータセンタ内の他の LAN と行き来させる。③二つの FCoE-SW を，上の FCoE-SW の下側と下の FCoE-SW の上側のインタフェースでつなぐ。④各 CNA を，それぞれ別の FCoE-SW の右側のインタフェースへつなぐ。

本文は“既設のシステムに追加接続する形”としているので，既設の FC-SW と L3SW につなぐ。“二つの CNA は同時に使用する”ので，CNA は 2 台の FCoE-SW に 1 本ずつつなぎ，どちらの経路も使う。FCoE-SW どうしは TRILL で“一つの大きな FCoE-SW のように動作する”ので，相互に接続しておく。上下の系統を正（FC-SW・L3SW・FCoE-SW の上）と副（下）にそろえておくと，1 台が止まっても他方でストレージにも LAN にも届く。

間違えやすい点。FC-SW を FCoE-SW の白丸（イーサネットのインタフェース）につないだり，L3SW を黒丸につないだりしないこと。L2SW に空きインタフェースは無く，LAN 側は L3SW の右側の空きインタフェースを使う。FCoE-SW どうしの接続を忘れると，片方の FCoE-SW に入った通信がもう一方の CNA へ届かない。

採点講評（IPA）

設問5では，製品への実装が進むFCoE対応スイッチの動作について問うた。問題文をよく読み，FCoEで実現する機能の利点を把握することが必要である。

本文の根拠

〔TC システムの設計〕

サーバと NAS の NIC には，チーミング機能を設定して 2 本の回線に負荷を分散させ，［ ア ］ と冗長化を図ります。

〔TC システムの設計〕

VRRP では，VRRP メッセージ（VRRP advertisement）がマスタルータから ［ イ ］ ルータへ送信され，マスタルータの稼働状態が報告される。VRRP メッセージは，宛先 IP アドレスが 224.0.0.18 の ［ ウ ］ キャスト通信である。Priority 値は，大小関係で優先順位が決まり，Preempt モードでは L3SW の起動タイミングに関係なく，最も ［ エ ］ 値をもつルータが，マスタルータになる。

ア：チーミングは複数の NIC を束ねて一つの論理的なインタフェースとして扱う機能で，“2 本の回線に負荷を分散させ”れば，使える帯域は 1 本のときより広がる。片方が故障しても残りで通信を続けられるのが冗長化で，アはもう一つの効果である帯域拡大になる。イ：VRRP（RFC 5798）では，マスタルータが定期的に advertisement を送り，バックアップルータはそれが途絶えるとマスタに切り替わる。ウ：224.0.0.0/4 はクラスD のマルチキャストアドレスで，224.0.0.18 は VRRP 用に IANA が割り当てたアドレスである。エ：Priority 値は大きいほど優先され，最も大きい値をもつルータがマスタになる。

表1でも，通常時にマスタにしたい L3SW_A の Priority 値を 100，L3SW_B を 80 としている。障害検出時は 50 に下げて，80 の L3SW_B にマスタを譲る設計なので，大きい方が優先されることと合う。

間違えやすい点。アを“負荷分散”と書くと，本文の“負荷を分散させ”をなぞるだけで，その結果として得られる効果になっていない。エは，OSPF のコストなど“小さいほど優先”の値と混同しないこと。講評によるとアの正答率が低かった。

採点講評（IPA）

設問1では，アの正答率が低かった。チーミングで2本の回線を一つの回線として束ねたときの効果に着目すれば，“帯域拡大”が導き出せたはずである。

本文の根拠

〔TC システムの設計〕

一つは，利用者ごとの TC 利用環境を作るための情報を記録したファイル（以下，プロファイルという）を保管します。プロファイルの働きによって，①TC 共用サーバにログインすると，ログインした利用者の TC 利用環境が作られます。

〔TC システムの設計〕

このとき，TC は最も低負荷の TC 共用サーバに接続され，TC 共用サーバの負荷が平準化される。

プロファイルは利用者ごとに作られ，NAS に保管されている。TC はログインのたびに，その時点で最も低負荷の TC 共用サーバに接続されるので，どのサーバにログインしても，ログインした利用者のプロファイルを NAS から探して読み込めなければならない。そのためには，利用者名（ログインする利用者）とプロファイル名（その利用者の環境を記録したファイル）が対応付けられている必要がある。

本文は，プロファイルが“利用者ごとの TC 利用環境を作るための情報を記録したファイル”であること，SBC なので TC 共用サーバは複数の利用者で共用され，接続先のサーバが毎回変わりうることを示している。

15 字以内なので，対応付ける二つのものの名前だけを書く。解答例は 12 字。

本文の根拠

〔TC システムの設計〕

二つ目は，TC 利用者が作成したファイル類を保管します。第1段階で，本社の FS を NAS に統合します。

〔TC システムの設計〕

第1段階は，PC の持出し時の事故による，情報漏えいとデータ消失のリスクが大きい営業員のうち，本社所属の 80 人に導入する。

図1

この L2SW は広域イーサ網に接続し，広域イーサ網には札幌営業所の L2SW と福岡営業所の L2SW が接続している。

第1段階では，TC になるのは本社の営業員 80 人だけで，営業所の社員は引き続き PC を使う。この段階で営業所の FS を本社の NAS に統合すると，営業所の PC は，これまで営業所の LAN 内にあった FS のファイルを，広域イーサ網を経由して本社の NAS まで読み書きしに行くことになる。ファイル操作のデータが WAN を往復するので，応答が遅くなる。第2段階で営業所の社員も TC になれば，ファイルを扱うのは本社の TC 共用サーバで，NAS とは同じ LAN 上にあり，WAN には画面の情報だけが流れる。

本文は，画面転送型の TC システムについて“ネットワークへの負荷が少ない”と書いている。TC 化の前に FS だけを移すと，この利点を得られないまま WAN の遅延を受ける。

25 字以内に収めるには，“営業所から FS を利用するとき”と“レスポンス（応答速度）の低下”を残す。解答例は 22 字。

本文の根拠

表1

VLAN ID：VLAN1，VLAN2，VLAN3。仮想 IP アドレス：IPVIP10，IPVIP20，IPVIP30。所属ポート：P0，P1，P10。

図2

L3SW_A と L3SW_B は，どちらも P0 で L2SW₁ に，P1 で L2SW₂ に接続している。

図2の配線だけを見ると，L2SW₁ − L3SW_A − L2SW₂ − L3SW_B − L2SW₁ と輪になっている。しかし表1で，L3SW の P0 は VLAN1，P1 は VLAN2 に所属している。VLAN が違うポートの間でフレームはスイッチング（ブリッジ）されず，L3SW がルーティングで中継する。ルーティングでは IP ヘッダの TTL が減るので，レイヤ2 のようにフレームが無限に回り続けることはない。L2SW₁ 側（VLAN1）と L2SW₂ 側（VLAN2）はそれぞれ別のブロードキャストドメインで，どちらの中にも輪はできない。

表1の“所属ポート”の行が根拠である。P0 と P1 が同じ VLAN なら，L3SW の中でブリッジされてループになる。

講評によると，“バックアップルータの L3SW は動作しないのでループが発生しない”という誤答が多かった。VRRP のバックアップでも，スイッチとしての転送は普通に行う。25 字以内に収めるには，“P0 と P1 の VLAN が異なる”を核にする。解答例は 16 字。

採点講評（IPA）

設問2(3)では，バックアップルータのL3SWが動作しないのでループが発生しないという誤った解答が散見された。このL3SWも，スイッチとしての動作は通常通りに行われていることを理解して欲しい。

本文の根拠

〔TC システムの設計〕

また，②ポートやケーブルの障害時には，全ての VRRP が同期して，同じ L3SW がマスタルータになります。

表1

監視対象インタフェース：設定1 は P1，P10，P11，P12，設定2 は P0，P10，P11，P12，設定3 は P0，P1，P11，P12。障害検出時の Priority 値：50，50，50。

表1

Priority 値：設定1〜3 のいずれも L3SW_A が 100，L3SW_B が 80。

項目は“監視対象インタフェース”。各 VRRP グループは，自分の所属ポート以外のポートを監視し，そのどれかがリンクダウンすると自分の Priority 値を 50 に下げる。例えば L3SW_A の P0 が故障すると，VRRP グループ 1 は advertisement が L3SW_B に届かなくなって L3SW_B がマスタになる。同時に，P0 を監視しているグループ 2 と 3 では L3SW_A の Priority 値が 100 から 50 に下がり，L3SW_B の 80 より小さくなるので，L3SW_B がマスタになる（Preempt モード）。こうして全グループのマスタが同じ L3SW_B にそろう。

表1の監視対象インタフェースは，設定1〜3 それぞれで，所属ポート（P0，P1，P10）以外の全ポートになっている。障害検出時の Priority 値 50 は，バックアップ側の 80 より小さい値に選ばれている。グループごとにマスタがばらばらになると，行きと帰りで違う L3SW を通ったり，L3SW 間に経路の無い通信が生じたりするので，同期させる。

50 字以内に収めるには，“監視対象のポートがリンクダウンしたとき”と“Priority 値を 50 に再設定する”を残す。解答例は 40 字。

本文の根拠

表1

項目ごとに，設定1，設定2，設定3 の値を示す。VRRP グループ ID：1，2，3。VLAN ID：VLAN1，VLAN2，VLAN3。仮想 IP アドレス：IPVIP10，IPVIP20，IPVIP30。所属ポート：P0，P1，P10。仮想 MAC アドレス：00-00-5e-00-01-01，00-00-5e-00-01-02，00-00-5e-00-01-03。

〔TC システムの設計〕

VRRP では，VRRP メッセージ（VRRP advertisement）がマスタルータから ［ イ ］ ルータへ送信され，マスタルータの稼働状態が報告される。

VRRP の advertisement（RFC 5798）には，どの仮想ルータの広告かを示す VRRP グループ ID（Virtual Router ID），送信元ルータの Priority 値，その仮想ルータが引き受ける仮想 IP アドレス（IPvX Address）などが入っている。バックアップルータは，グループ ID でどの仮想ルータの話かを知り，Priority 値を自分の値と比べてマスタになるべきかを判断する。

表1の他の項目は，メッセージには入らない。仮想 MAC アドレスは 00-00-5e-00-01-{グループ ID} の形で VRRP グループ ID から決まる（表1でも末尾が 01，02，03）。VLAN ID や所属ポートは L3SW のポートの設定であり，監視対象インタフェースと障害検出時の Priority 値は各ルータ内部の設定である。

間違えやすい点。“仮想 MAC アドレス”は，advertisement を運ぶイーサネットフレームの送信元 MAC アドレスには使われるが，VRRP メッセージ自体の中身ではない。三つは順不同で，表1の項目名のとおりに書く。

本文の根拠

〔社外での TC 使用時のセキュリティ対策〕

トークンが生成する数字は 1 分経過ごとに変化し，一度しか使用できない。

トークンの数字は“一度しか使用できない”。数字が変わる間隔を長くすると，同じ数字が表示されている時間が長くなる。その間に利用者がもう一度ログインしようとすると（接続が切れて入り直すなど），表示されている数字を正しく入力しても，それは既に使った数字なので，再使用として不正パスワードになる。

本文は，時刻同期方式の OTP が“1 分経過ごとに変化し，一度しか使用できない”と書いている。間隔を長くすると，“一度しか使えない”という規則と，“表示されている数字が正しい”という利用者の認識が食い違う時間が長くなる。

20 字以内に収めるには，“パスワードの再使用となる”を核にする。解答例は 14 字。講評のとおり，時刻同期方式の OTP が一般に 1 分間隔で生成されるのはこのためである。

採点講評（IPA）

設問3(1)は，期待した正答率に届かなかった。ワンタイムパスワードの基になる，トークンに表示される数字が長時間変わらなければ，利用者によってその数字が2度使われる可能性が生まれる。このような事態を避けるために，時刻同期型ワンタイムパスワードは，一般的に1分間隔で生成されている。

本文の根拠

〔社外での TC 使用時のセキュリティ対策〕

本方式では，時刻のずれが発生するので，ずれの許容範囲を設定する。認証サーバは，許容範囲内で認証を試みて，認証できたらトークンとの時刻のずれを推定して記憶し，次回の認証時に，記憶したずれを基に時刻の補正を行う。

認証サーバは，受信した時刻の前後の許容範囲にある各時刻について，その時刻にトークンが生成したはずのパスワードを計算し，受信したパスワードと照合する。一致したパスワードがどの時刻に生成されたものかが分かれば，その生成時刻とパスワードを受信した時刻（認証サーバの時刻）の差が，トークンの時計のずれの推定値になる。

本文の“許容範囲内で認証を試みて，認証できたら…ずれを推定して記憶し”という手順から，ずれは“認証できた”パスワードを手掛かりに求めることが分かる。

50 字以内に収めるには，“認証できたパスワードの生成時刻”と“受信した時刻”，その“差”の三つを残す。解答例は 41 字。

本文の根拠

〔現在のメールシステムの構成と利用状況〕

POP3 の利用者は，PC に作成したフォルダにメールを保存し，メールボックスのメールは，メーラでダウンロード後に消去されるように設定している。Y 社では，PC のフォルダに保存したメールの障害時に備えた対応作業は，社員に任せている。

POP3 の利用者は，メールをダウンロードした後にサーバのメールボックスから消去しているので，メールは PC のフォルダにしか残らない。PC が壊れればメールは失われる。障害時に備えて社員がしなければならないのは，PC に作成したフォルダのメールのバックアップである。

本文は，“PC のフォルダに保存したメールの障害時に備えた対応作業は，社員に任せている”と書いている。IMAP4 の利用者のメールはサーバ側のフォルダにあり，サーバの運用で守られる。

30 字以内に収めるには，“PC のフォルダのメール”と“バックアップ”を残す。解答例は 23 字。

本文の根拠

〔現在のメールシステムの構成と利用状況〕

POP3 の利用者は，PC に作成したフォルダにメールを保存し，メールボックスのメールは，メーラでダウンロード後に消去されるように設定している。

〔現在のメールシステムの構成と利用状況〕

しかし，③複数の PC で同じメールアカウントを使用するときには，違いが分かる。

POP3（RFC 1939）はメールをサーバから PC へダウンロードする方式で，Y 社ではダウンロード後にサーバから消去している。ある PC がメールを受信するとサーバから消えるので，同じアカウントを使う別の PC からは，そのメールを読めない。IMAP4（RFC 3501）はメールをサーバ上に置いたまま操作するので，どの PC からでも同じメールを見られる。

本文の“ダウンロード後に消去されるように設定している”が直接の根拠である。消去しない設定でも，既読や削除などの状態は PC ごとに別々になるが，この設定ではメールそのものが残らない。

30 字以内に収めるには，“複数の PC から”と“同じメールを読めない”を残す。解答例は 24 字。

本文の根拠

図4

“43200 ; refresh 時間（12時間）”，“1800 ; retry 時間（30分）”，“604800 ; expire 時間（7日）”，“10800 ) ; negative cache 時間（3時間）”。

SOA レコードの refresh は，セカンダリ DNS サーバがプライマリの SOA のシリアル番号を問い合わせ，更新されていればゾーン転送でコピーする間隔である（RFC 1035）。図4では 43200 秒（12 時間）になっている。

他の値の意味。retry（1800 秒）は refresh の確認に失敗したときに再試行するまでの間隔，expire（604800 秒）はプライマリと連絡が取れないままセカンダリがゾーンデータを使い続けられる期限，negative cache（10800 秒）は“存在しない”という応答をキャッシュする時間である。$TTL 86400 は，各レコードをキャッシュしてよい時間の既定値である。

間違えやすい点。retry と取り違えないこと。retry は失敗したときだけ使う間隔である。解答例は“43,200 秒（12 時間）”で，秒と時間を両方書いている。

本文の根拠

〔メールサービスへの移行方法の設計〕

2. メールサービスのツールで，パスワードを設定する。また，使用中のメーラでメールサービスへの接続設定を行う。

〔メールサービスへの移行方法の設計〕

この段階では，メールの送受信を社内メールサーバで行うように設定する。

図6

項番2：パスワードの設定，接続設定，利用者，3週の初めから4週の途中まで（矢印）。

項番2 は利用者が各自で行う作業で，図6では 3 週から 4 週にかけて 1 週間以上を掛ける。その間，設定を終えた利用者とまだの利用者が混在する。この期間にメールをメールサービスへ届け始めると，まだ項番2 の設定をしていない利用者は，メーラからメールサービスに接続できないので，メールサービスのメールボックスに届いたメールを受信できない。そこで全員の設定が終わるまでは，送受信を従来どおり社内メールサーバで行わせ，項番4 で一斉に切り替える。

本文は，項番2 で“この段階では，メールの送受信を社内メールサーバで行うように設定する”とし，切替えは項番4 で“業務開始前に実施”としている。講評も，項番2 の作業が 1 週間以上掛かることに着目するよう述べている。

50 字以内に収めるには，“項番2 の設定を行っていない利用者”と“メールサービスのメールボックスから受信できない”を残す。解答例は 43 字。

採点講評（IPA）

設問5(1)では，送受信に利用するメールサーバを，メールサービスに切替えるタイミングに関して問うたが，正答率は低かった。図6項番2の作業が，1週間以上を費やして行われることに着目して考えると正答が導き出せる。一方，設問5(2)の，ループが発生する問題に関する正答率は高かった。

本文の根拠

〔メールサービスへの移行方法の設計〕

また，メールサービスが y-sya.example.co.jp 宛てのメールを受信したとき，そのユーザのアカウントが登録されていれば，メールサービスのメールボックスに配信され，登録されていないアカウントや ML のときは y-sya.example.co.jp に中継されるように，あらかじめ設定しておく。

図4

“IN MX 10 mail.y-sya.example.co.jp.”

〔現在のメールシステムの構成と利用状況〕

DMZ に，Y 社ドメイン（以下，y-sya.example.co.jp という）宛てのメールを受信するメール中継サーバがあり，社外へのメールも，このサーバが中継している。

アカウントが無いアドレス宛てのメールを追うと，①社内メールサーバがそのメールを宛先を変えずにメールサービスへ転送する。②メールサービスにはそのアカウントが無いので，項番1 の設定で y-sya.example.co.jp に中継する。③y-sya.example.co.jp の MX は，項番8 までは Y 社のメール中継サーバを指しているので，メールはメール中継サーバに届き，社内メールサーバへ渡る。④社内メールサーバは再びメールサービスへ転送する。こうしてメールサービス，メール中継サーバ，社内メールサーバの間をメールが回り続ける。

項番3 の本来の設計では，社内メールサーバが宛先ドメインを y-sya.example.com に書き換えるので，アカウントの無いアドレス宛てならメールサービスで宛先不明として扱われ，y-sya.example.co.jp に戻ってこない。宛先を“そのまま”転送すると，メールサービス側が y-sya.example.co.jp 宛てとして中継し返してしまう。

40 字以内に収めるには，ループに関わる三つ（メールサービス，メール中継サーバ，社内メールサーバ）と“ループする”を残す。解答例は 34 字。

採点講評（IPA）

設問5(1)では，送受信に利用するメールサーバを，メールサービスに切替えるタイミングに関して問うたが，正答率は低かった。図6項番2の作業が，1週間以上を費やして行われることに着目して考えると正答が導き出せる。一方，設問5(2)の，ループが発生する問題に関する正答率は高かった。

本文の根拠

〔メールサービスへの移行方法の設計〕

3. 社内メールサーバが受信したメールを，メールサービスに配送させるために，社内メールサーバに，メールアドレスの変換設定を行う。この変換は，メールアドレスの y-sya.example.co.jp を y-sya.example.com に書き換えるもので，ML に関しては，個人アドレスに展開された後に，この変換が行われる。

〔メールサービスへの移行方法の設計〕

登録されていないアカウントや ML のときは y-sya.example.co.jp に中継されるように，あらかじめ設定しておく。

〔現在のメールシステムの構成と利用状況〕

DMZ に，Y 社ドメイン（以下，y-sya.example.co.jp という）宛てのメールを受信するメール中継サーバがあり，社外へのメールも，このサーバが中継している。

項番4 の後，社員はメールサービスからメールを送る。ML はまだメールサービスに登録されていないので，①メールサービスは ML 宛てのメールを y-sya.example.co.jp に中継する。②y-sya.example.co.jp の MX はまだメール中継サーバなので，メール中継サーバが受け取り，③社内メールサーバへ渡す。④社内メールサーバは ML を個人アドレスに展開し，項番3 の変換で宛先を y-sya.example.com に書き換える。y-sya.example.com はメールサービスのドメインなので社外宛てになり，社外へのメールを中継する⑤メール中継サーバを通って，メールサービスに届き，各自のメールボックスに配信される。

したがって経路は，メールサービス → メール中継サーバ → 社内メールサーバ → メール中継サーバ → メールサービス → メールボックス で，空欄には最初の四つを書く。メール中継サーバを 2 回通ることがポイントで，1 回目は Y 社ドメイン宛ての受信として，2 回目は社外宛ての送信としてである。

間違えやすい点。社内メールサーバから直接メールサービスへ送ると考えて，2 回目のメール中継サーバを落とさないこと。本文は，社外へのメールもメール中継サーバが中継すると書いている。項番7（中継の解除）と項番8（MX の変更）はこの期間より後なので，まだ効いていない。

本文の根拠

〔TC システムの設計〕

二つ目は，TC 利用者が作成したファイル類を保管します。第1段階で，本社の FS を NAS に統合します。

〔TC システムの設計〕

TC システムを導入するときは，データの移動が必要になる。

図2

注記3：TC は，既設の PC を流用する。

一つ目は，TC として使う PC に保存されているファイルである。第1段階では本社の営業員の既設 PC を TC として流用するが，TC はデータを保存しない端末になるので，PC に入っているファイルを NAS へ移す。二つ目は，本社の FS に保管されているファイルで，第1段階で本社の FS を NAS に統合するので NAS へ移す。どちらも移動先は NAS である。

本文は，NAS の用途の二つ目を“TC 利用者が作成したファイル類を保管”とし，“第1段階で，本社の FS を NAS に統合します”と書いている。図2の注記3 は，TC が既設の PC の流用であることを示す。

間違えやすい点。メールはメールサービスへの移行（TC 導入より前に済む）で移すので，ここでは対象外である。営業所の FS の統合は第2段階なので，第1段階の答えにならない。①と②は順不同。

本文の根拠

〔TC システムの設計〕

第1段階の導入では，既設のサーバ，L3SW₁ 及び FW の IP アドレスの変更は伴いませんが，本社の PC の IP アドレスの変更と L3SW₁ への IP アドレスの追加設定が必要になります。

〔TC システムの設計〕

L3SW_A，L3SW_B 及び L3SW₁ では，静的経路制御を行わせます。

表1

VLAN ID：VLAN1，VLAN2，VLAN3。仮想 IP アドレス：IPVIP10，IPVIP20，IPVIP30。所属ポート：P0，P1，P10。

図2で，既設の L2SW₁，L2SW₂（本社の PC，これから TC になる端末）は，L3SW₁ の直下から L3SW_A，L3SW_B の配下へ移る。PC のデフォルトゲートウェイは，これまでの L3SW₁ のアドレスから，L3SW_A，L3SW_B の VRRP の仮想 IP アドレス（VLAN1 なら IPVIP10，VLAN2 なら IPVIP20）に変える必要がある。L3SW₁ は，PC のセグメントが直接つながらなくなるので，そのセグメント宛ての経路を，L3SW_A，L3SW_B 側（VLAN3 の仮想 IP アドレス IPVIP30）を次の宛先として，ルーティングテーブルに静的に設定し直す必要がある。

本文は，PC の IP アドレスの変更と L3SW₁ への IP アドレスの追加が必要と書き，設問はそれ以外の情報を問うている。静的経路制御なので，経路は手で設定しなければ変わらない。

20 字以内で，“L3SW₁ のルーティングテーブル”と“PC のデフォルトゲートウェイアドレス”のように，どの機器のどの情報かを書く。解答例はそれぞれ 16 字，18 字。①と②は順不同。

採点講評（IPA）

設問6(2)は，正答率が高かった。PCのデフォルトゲートウェイやL3SW1の経路表は，日々の業務で扱われるネットワーク関連情報であり，よく理解されていることが確認できた。