令和5年度 春期 午後Ⅰ

本文の根拠

〔現行のシステム構成〕

一方，AP サーバの動的コンテンツは，Web サーバで中継して配信される。この中継処理の仕組みを a プロキシと呼ぶ。

〔現行のシステム構成〕

DMZ の DNS サーバは，G 社のサービス公開用ドメインに対する b DNS サーバであると同時に，サーバセグメントのサーバがインターネットにアクセスするときの名前解決要求に応答する c DNS サーバである。

〔HTTP/2 の概要と特徴〕

TCP コネクション内で複数のリクエストとレスポンスのやり取りを d と呼ばれる仮想的な通信路で多重化している。

〔HTTP/2 の概要と特徴〕

ヘッダーフィールドには，e，:scheme，:path といった必須フィールドがある。

〔HTTP/2 の概要と特徴〕

通信開始処理において f プロトコルの拡張の一つである②ALPN（Application-Layer Protocol Negotiation）を利用する。

a：Web サーバは，Web ブラウザからの要求をサーバ側に置かれた AP サーバへ代わりに取り次いでいる。サーバの手前に置いてサーバの代理として要求を受ける方式はリバースプロキシである（クライアント側に置いて外への通信を代理するのがフォワードプロキシ）。b：自社のサービス公開用ドメインのゾーン情報を持ち，外部からの問合せに答えるのは権威 DNS サーバ（コンテンツサーバ）である。c：社内のサーバからの名前解決要求を受けて，他の DNS サーバへ再帰的に問い合わせ，結果を保持して答えるのはキャッシュ DNS サーバ（フルサービスリゾルバ）である。

d：HTTP/2（RFC 9113）は1本の TCP コネクションの中に複数のストリームを作り，リクエストとレスポンスの組をストリームごとにやり取りする。フロー制御もストリーム単位で行う。図3の“ID：1”“ID：3”はストリーム識別子で，クライアントが開始するストリームは奇数の番号を使う。e：HTTP/2 はリクエスト行の代わりに疑似ヘッダーフィールドを使い，:method，:scheme，:path が必須である（ほかに :authority がある）。f：ALPN（RFC 7301）は TLS の拡張で，TLS のハンドシェークの中でアプリケーション層のプロトコルを取り決める。

間違えやすい点。e は先頭のコロンまで含めて“:method”と書く。本文が“:scheme”“:path”とコロン付きで並べているのに合わせる。b と c は“権威”“キャッシュ”で，“プライマリ”“セカンダリ”（ゾーンの持ち方の区別）ではない。採点講評によると d，e，f の正答率が低かった。

採点講評（IPA）

設問1では，d，e，fの正答率が低かった。HTTP/2プロトコルは広く普及してきており，これからも多く使われる重要なプロトコルである。その基本については正しく理解してほしい。

本文の根拠

〔HTTP/2 の概要と特徴〕

HTTP/1.1 には，同一の TCP コネクション内で通信を多重化する方式として HTTP パイプラインがある

〔HTTP/2 の概要と特徴〕

①HTTP パイプラインは，複数のリクエストが送られた場合にサーバが返すべきレスポンスの順序に制約があるが，HTTP/2 ではその制約がない。

HTTP/1.1 のパイプラインでは，クライアントは前のレスポンスを待たずに複数のリクエストを続けて送れるが，レスポンスには“どのリクエストへの応答か”を示す識別子が無い。そのため HTTP/1.1（RFC 9112）は，サーバがリクエストを受け取ったのと同じ順序でレスポンスを返すことを求めている。先のリクエストの処理が重いと，後のレスポンスが用意できていても待たされる（ヘッドオブラインブロッキング）。

下線①の“レスポンスの順序に制約がある”が問われている点で，HTTP/2 ではストリームごとに識別子が付くので，準備できたものから順不同で返せる。この対比が設問1の d（ストリーム）とつながっている。

35字に収める。解答例は「リクエストを受けたのと同じ順序でレスポンスを返す必要がある。」で30字。“受けた順”“同じ順序”のように，リクエストの受信順と同じであることをはっきり書く。“順番どおりに返す”だけでは何の順か分からない。

本文の根拠

〔HTTP/2 の概要と特徴〕

一般的に HTTP/2 は，HTTP/1.1 と同じく“https://”の URI スキームが用いられる。そのため，通信開始処理において f プロトコルの拡張の一つである②ALPN（Application-Layer Protocol Negotiation）を利用する。

〔HTTP/2 における通信開始処理〕

このシーケンスによって，上位プロトコルが HTTP/2 であることが決定される。

HTTP/2 も HTTP/1.1 も同じ“https://”のスキームで，同じ TCP の 443 番ポートを使う。URI やポート番号からはどちらのプロトコルで話すかが決まらないので，通信を始めるときに TCP（その上の TLS）の上でどのアプリケーション層プロトコルを使うかを取り決める必要がある。ALPN（RFC 7301）は，TLS のハンドシェークの中でその取決めを済ませる仕組みで，余分な往復を増やさずに済む。

本文は“同じく“https://”の URI スキームが用いられる。そのため”と理由をつないでおり，図3の後に“上位プロトコルが HTTP/2 であることが決定される”とある。この2か所を合わせると“通信開始時に上位のプロトコルを決める”が目的だと分かる。

30字に収める。解答例は「通信開始時にTCPの上位のプロトコルを決定するため」で25字。採点講評によると，ALPN を暗号化処理のプロトコルと取り違えた誤答が目立った。暗号方式の取決めは TLS 本体の役目で，ALPN が決めるのはその上で動くアプリケーションのプロトコルである。

採点講評（IPA）

設問2では，(2)の正答率が低く，ALPNを暗号化処理プロトコルと誤った解釈をしているような誤答が目立った。ALPNはHTTP/2プロトコルでは必須の技術であり，HTTP/2に限らず，TCP/443番ポートを複数のサービスで共用する場合によく使われる技術なので理解を深めてほしい。

本文の根拠

〔HTTP/2 における通信開始処理〕

HTTP/2 の通信を開始するときに，ALPN を用いて③クライアントとサーバとの間でネゴシエーションを行う。

図3

続いて (d)ClientHello（クライアント→サーバ），(e)ServerHello（サーバ→クライアント），…（省略）を“TLSセッション開始”とまとめている。

ALPN は TLS の拡張なので，ネゴシエーションは TLS のハンドシェークの中で行われる。クライアントは ClientHello の ALPN 拡張に使えるプロトコルの一覧を入れ，サーバはその中から1つを選んで返す（RFC 7301）。TLS 1.2 ではサーバの選択結果は ServerHello の拡張で返る。したがって (d)ClientHello と (e)ServerHello が該当する。

(a)〜(c) は TCP の3ウェイハンドシェイクで，TLS より下の段階なので ALPN の情報は載らない。(f)〜(i) は HTTP/2 と決まった後のストリーム上のやり取りで，ネゴシエーションはもう終わっている。

間違えやすい点。“全て答えよ”なので (d) だけでは足りない。なお TLS 1.3（RFC 8446）ではサーバが選んだプロトコルは ServerHello の後に送る EncryptedExtensions に入る。図3は ServerHello の後を“…”で省いており，解答例は ClientHello と ServerHello の組を答えとしている。採点講評によると，設問3は (1)，(2) とも正答率が低かった。

採点講評（IPA）

設問3では，(1)，(2)の正答率が低く，暗号アルゴリズムの交換といった誤答が散見された。HTTP/2プロトコルの通信開始シーケンスについても，その意味や内容について十分に理解しておいてほしい。

本文の根拠

〔HTTP/2 における通信開始処理〕

HTTP/2 の通信を開始するときに，ALPN を用いて③クライアントとサーバとの間でネゴシエーションを行う。

〔HTTP/2 の概要と特徴〕

HTTP/2 は，HTTP/1.1 と互換性が保たれるように設計されている。

ALPN（RFC 7301）では，クライアントが ClientHello の拡張に自分が使えるアプリケーション層プロトコルの名前を優先順に並べて送る（HTTP/2 なら“h2”，HTTP/1.1 なら“http/1.1”）。サーバはその一覧から自分も使えるものを1つ選んで返す。選べるものが無ければハンドシェークを失敗させる。

本文の“HTTP/1.1 と互換性が保たれる”は，HTTP/2 に対応していないサーバとも通信できるということで，それができるのはクライアントが複数の候補を示し，サーバに選ばせる仕組みだからである。

35字に収める。解答例は「クライアントが利用可能なアプリケーション層のプロトコル」で27字。“利用可能な（対応している）”と“アプリケーション層のプロトコル”の2つが要素。採点講評によると“暗号アルゴリズムの交換”という誤答が散見された。暗号スイートの一覧も ClientHello に入るが，それは TLS 本体の取決めで，ALPN のネゴシエーションではない。

採点講評（IPA）

設問3では，(1)，(2)の正答率が低く，暗号アルゴリズムの交換といった誤答が散見された。HTTP/2プロトコルの通信開始シーケンスについても，その意味や内容について十分に理解しておいてほしい。

本文の根拠

〔新 Web システム構成〕

G 社用 VPC セグメントでは IP アドレスとして，172.21.10.0/24 を用いる。

〔新 Web システム構成〕

専用線接続の IP アドレスとして，172.21.11.0/24 を用い，L3SW の IP アドレスを 172.21.11.1 とし，仮想ルータの IP アドレスを 172.21.11.2 とする。

表1

L3SW：宛先ネットワークは空欄［ ア ］，ネクストホップは空欄［ イ ］。仮想ルータ：宛先ネットワークは 0.0.0.0/0，ネクストホップは空欄［ ウ ］。

ア・イ：L3SW から見て，J 社クラウドにある G 社用 VPC セグメント 172.21.10.0/24 は直結していないので，静的経路が要る。その先への入口は専用線の向こう側にある仮想ルータなので，ネクストホップは仮想ルータの 172.21.11.2 である。

ウ：仮想ルータは 0.0.0.0/0（デフォルトルート）で，VPC セグメント以外の宛先を全て専用線の向こうの L3SW 172.21.11.1 へ送る。Web サーバが DMZ の DNS サーバで名前解決し，AP サーバへの通信も G 社データセンターへ向かうので，G 社側のネットワークへの経路がまとめて必要になる。

間違えやすい点。ネクストホップは“自分と同じセグメント上にある，相手側のルータのアドレス”である。イに L3SW 自身の 172.21.11.1 を，ウに仮想ルータ自身の 172.21.11.2 を書くと逆になる。アはホストアドレスではなくネットワークアドレス（/24 付き）で書く。

本文の根拠

〔G 社 Web システム構成見直しの方針と実施内容〕

Web ブラウザからのリクエストを受信した仮想 LB は，リクエストの URL に応じて AP サーバ又は Web サーバに振り分ける。

〔G 社 Web システム構成見直しの方針と実施内容〕

Web ブラウザと仮想 LB との間の通信を HTTP/2 とし，仮想 LB と AP サーバ及び Web サーバとの間の通信を HTTP/1.1 とする。

表2

アプリケーションモード：レイヤー7で動作して負荷分散処理を行う。ネットワークモード：レイヤー4で動作して負荷分散処理を行う。

仮想 LB は，Web ブラウザとは HTTP/2 で，サーバとは HTTP/1.1 で通信する。HTTP/2 のリクエストをいったん受け取って（TLS も終端して）中身を解釈し，HTTP/1.1 のリクエストに組み直して送らなければならない。これは HTTP を理解するレイヤー7 の処理なので，アプリケーションモードが必要である。レイヤー4（ネットワークモード）では TCP のコネクションをそのまま振り分けるだけで，プロトコルの変換はできない。

本文には“リクエストの URL に応じて”振り分けるともあり，URL を見るのもレイヤー7 の処理である。設問は理由を“HTTP/2”という字句を用いて書かせているので，プロトコルの変換の方を理由に書く。

35字に収める。解答例は「HTTP/2リクエストをHTTP/1.1に変換して負荷分散するから」で33字。“HTTP/2 を HTTP/1.1 に変換する”が核で，URL による振分けだけを書くと“HTTP/2”を使うという条件を満たせない。

本文の根拠

〔IP マルチキャストに関する調査及び設計〕

L2SW では，マルチキャストフレームを受信した際，同一セグメント上の受信インタフェース以外の全てのインタフェースへ ［ ア ］ するので，通信帯域を無駄に使用し，接続先のインタフェースへ不必要な負荷を掛けてしまう。この対策機能として，［ イ ］ スヌーピングがある。

図2の説明 (c)

レシーバ 11 は，IGMPv3 メンバーシップレポートの (S,G) Join を作成し，IGMP 用に割り当てられた IP ［ ウ ］ アドレス宛てに送信する。

図2の説明 (d)

ソースの方向である FW01 へ PIM の (S,G) Join を送信する。これによってディストリビューション ［ エ ］ が作成される。

〔IP マルチキャストに関する調査及び設計〕

FW01，L3SW11 及び L3SW21 では，マルチキャストルーティングを有効化し，全てのインタフェースにおいて ［ オ ］ を有効化する。

〔IP マルチキャストに関する調査及び設計〕

L3SW11 及び L3SW21 では，マルチキャストルーティング用のプロトコルとして ［ カ ］ を有効化し

〔追加指示への対応〕

PC には，IGMPv3 に対応し，映像データから映像へ ［ キ ］ する機能をもつソフトウェア製品を新たに導入する。

ア：L2SW は宛先がマルチキャストの MAC アドレスのフレームを，どのポートの先に受信者がいるか分からないので，受信ポート以外の全ポートへ送り出す。これをフラッディングという。イ：その対策が IGMP スヌーピングで，L2SW がホストとルータの間の IGMP のやり取りをのぞき見て，受信者がいるポートにだけ転送する。ウ：IGMPv3 のメンバーシップレポートは，IGMPv3 対応ルータ向けに割り当てられたマルチキャストアドレス 224.0.0.22 宛てに送る（RFC 3376）。

エ：PIM の Join をソース側へ送ると，ソースから受信者までの配信経路が木の形で作られる。これをディストリビューションツリーという（(S,G) で作るものは最短経路ツリー）。オ：図2の (b) で，PIM-SM が有効なインタフェースでは PIM hello が送られ，FW01 と L3SW11 が互いに PIM ネイバーを見つけている。3台の全インタフェースで有効化するのは PIM-SM である。カ：L3SW11・L3SW21 はレシーバから (S,G) Join を受けるので，ソースを指定する SSM を有効化する。キ：本文冒頭の“映像データを映像へ復号し”と同じく，PC のソフトウェアも映像データを復号する。

間違えやすい点。オとカは“PIM-SM 及び PIM-SM の派生型である SSM”の2つを，全インタフェースの基本（PIM-SM）と，ソース指定の受付け（SSM）に振り分ける。キは“符号化”ではなく受信側の“復号”（デコード）。採点講評によると，エの正答率が低かった。

採点講評（IPA）

設問1では，エの正答率が低かった。ディストリビューションツリーは，IPマルチキャストの中で重要な用語である。IPマルチキャストは，映像配信に限らず株価情報の配信など，最新データを多数の宛先へ配信する用途において有用なプロトコルなので，ネットワークの基礎知識の一つとして学習しておいてほしい。

本文の根拠

〔ネットワーク構成〕

①IP カメラの導入によって増加する通信量に着目し，通信帯域を効率良く使用するため，IP マルチキャストを用いて配信を行う

〔ネットワーク構成〕

ネットワーク機器は，マルチキャストパケットを複製して配信する。

ユニキャストでは，宛先ごとに別々のパケットが要る。1台の IP カメラの映像を複数のレシーバが見るなら，ソースの IP カメラが同じ映像データをレシーバの数だけ送らなければならない。ソースから出る通信量と，ソースに近い区間の通信量がレシーバの数に比例して増える。

IP マルチキャストでは，ソースは1本の流れだけを送り，本文のとおり“ネットワーク機器は，マルチキャストパケットを複製して配信する”。分岐点でだけ複製されるので，ソースの送信量はレシーバの数によらない。下線①の“通信帯域を効率良く使用する”はこの点を指している。

35字に収める。解答例は「配信先のレシーバの数に応じてソースの通信量が増加する。」で27字。指定の字句“ソース”と“レシーバ”を使い，“レシーバの数に応じて”“ソースの通信量が増える”の因果を1文で書く。

本文の根拠

冒頭

河川・沿岸の主要 5 地点周辺に合計 20 台新設し

(2) 新設機器

IP カメラは，1 台当たり 8 M ビット／秒で映像データを含むパケットを送信する。

(2) 新設機器

②レシーバ及び大型モニターは，各 6 台新設する。レシーバは，最大四つの映像データを同時に受信し，大型モニターへ 4 分割で表示する。

図2の説明 (a)

IP カメラ 11 は，映像データを自身のグループアドレス宛てに常時送信する。

河川・沿岸の20台の IP カメラは，L2SW91〜L2SW95 を経て，全て L2SW91 から FW01 へ入る（図1）。マルチキャストでは1台のカメラの映像は，見ているレシーバが何台あっても FW01 までは1本の流れで，複製は FW01 から先で行われる。したがって L2SW91→FW01 の最大は，全カメラが同時に送る場合の 20台 × 8 M ビット／秒 = 160 M ビット／秒 である。

下線②から，レシーバ6台が最大4つずつ受信すると 6 × 4 = 24 の映像を同時に要求でき，20台のカメラ全部が見られている状態がありうる。さらに (a) のとおり IP カメラは常時送信するので，どちらから考えても20台分が流れ込む。

間違えやすい点。24（レシーバの受信数）を掛けて 192 とするのは，ユニキャストの考え方である。マルチキャストでは同じカメラの映像を何台が受信しても，ソース側の区間を流れるのは1本分なので，上限はカメラの台数で決まる。

本文の根拠

(4) IP カメラのアドレス設計

③全ての IP カメラに個別の IP アドレス及び同一のグループアドレスを使用する。

〔IP マルチキャストに関する調査及び設計〕

IGMPv2（Internet Group Management Protocol, Version 2）を使用する場合，レシーバはグループアドレスを指定して IP マルチキャストの配信要求を行う。

〔IP マルチキャストに関する調査及び設計〕

IGMPv3 を使用する場合，レシーバは④ソースの IP アドレス及びグループアドレスを指定して IP マルチキャストの配信要求を行う。

IGMPv2 では，レシーバはグループアドレスだけを指定して配信を要求する。下線③のように全カメラが同じグループアドレスで送っていると，どのカメラの映像が欲しいかを表せず，そのグループを要求すると20台全部の映像が届いてしまう。カメラを選んで受信するには，カメラごとに異なるグループアドレスを割り当て，グループアドレスでカメラを区別する必要がある。

IGMPv3 ならソースの IP アドレスとグループアドレスの組 (S,G) で要求できるので，グループアドレスが同じでも送信元の IP アドレスでカメラを選べる。本文の IGMPv2 と IGMPv3 の説明を並べて読むと，この違いが分かる。

45字に収める。解答例は「全てのIPカメラに個別のIPアドレス及び個別のグループアドレスを使用する。」で37字。下線③の“同一のグループアドレス”を“個別のグループアドレス”に変えた形で書くと過不足がない。採点講評は，下線部だけでなく IGMPv2 と IGMPv3 の違いを本文全体から読み取るよう求めている。

採点講評（IPA）

設問2では，(3)の正答率が低かった。IPカメラのアドレス設計を本文中のものからどのように変えるべきか，下線部だけを読んで解答するのではなく，IGMPv2とIGMPv3との違いを本文全体からしっかり読み取り，正答を導き出してほしい。

本文の根拠

〔IP マルチキャストに関する調査及び設計〕

IGMPv3 を使用する場合，レシーバは④ソースの IP アドレス及びグループアドレスを指定して IP マルチキャストの配信要求を行う。

(3) IP マルチキャスト

グループアドレスは，IP カメラが送信するマルチキャストパケットの宛先 IP アドレスなどに使用され，使用可能なアドレス範囲は決められている。

(2) 新設機器

IP カメラ，レシーバ及び大型モニターの設置に当たっては，将来的な追加や更新を考慮する。

IGMPv3 では映像を (S,G) の組で指定するので，カメラの区別はソースの IP アドレスで付けられる。グループアドレスはカメラごとに分けなくてよく，全カメラで同じものを使える（下線③）。グループアドレスは使える範囲が決められているので，カメラごとに重ならないよう割り当てて管理する手間が無くなり，カメラを増やすときもグループアドレスを新しく考えなくて済む。SSM 用には 232.0.0.0/8 の範囲が割り当てられている（RFC 4607）。

本文の“使用可能なアドレス範囲は決められている”と“将来的な追加や更新を考慮する”が，グループアドレスの設計を簡単にしておく意味を支えている。設問2(3)の IGMPv2 の場合と裏返しの関係になっている。

25字に収める。解答例は「グループアドレスの設計が容易になる。」で18字。指定の字句“グループアドレス”を主語に置き，“設計（割当て）が容易”と書く。

本文の根拠

〔IP マルチキャストに関する調査及び設計〕

L2SW のこの機能は，⑤レシーバから送信される Join や Leave のパケットを監視し，マルチキャストフレームの配信先の決定に必要な情報を収集する。

〔IP マルチキャストに関する調査及び設計〕

同一セグメント上の受信インタフェース以外の全てのインタフェースへ ［ ア ］ するので

(3) IP マルチキャスト

映像データを識別する情報の一つとして，グループアドレスを用いる。

IGMP スヌーピングは，レシーバの Join（メンバーシップレポート）や Leave を見て，“どのグループのフレームを，どのインタフェース（ポート）へ送ればよいか”の対応表を作る。マルチキャストフレームを受けると，その宛先のグループアドレスを表で引き，参加者のいるインタフェースにだけ転送する。したがって必要な情報は，グループアドレスとインタフェースの2つである。

本文の対策前の説明が“全てのインタフェースへ”フラッディングするとあるので，対策後は“インタフェース”を絞り込む。絞り込むときの鍵が映像データを識別する“グループアドレス”である。

間違えやすい点。“本文中の字句で”とあるので，“ポート番号”“MAC アドレス”ではなく，本文の“グループアドレス”“インタフェース”を使う。二つの順序は問わない。

本文の根拠

(2) 新設機器

カメラ管理サーバは，IP カメラの死活監視，遠隔制御を行い，Web サーバ機能をもつ。PC とは HTTPS で，IP カメラとは独自プロトコルでそれぞれ通信を行う。

表1

項番1：通信経路 サーバ室→河川・沿岸，送信元 空欄［ Ⅰ ］，宛先 IP カメラ，プロトコル/宛先ポート番号（省略）。項番2：通信経路 執務エリア1，2→サーバ室，送信元 PC，宛先 空欄［ Ⅰ ］，プロトコル/宛先ポート番号 TCP / 空欄［ Ⅱ ］。

Ⅰ：サーバ室にあってユニキャストで通信する機器は，図1ではカメラ管理サーバだけである。カメラ管理サーバは IP カメラの死活監視と遠隔制御のために IP カメラへ通信し（項番1），PC はカメラ管理サーバの Web サーバ機能に HTTPS でアクセスする（項番2）。Ⅱ：HTTPS のウェルノウンポート番号は TCP の 443 である。

表の注記に“FW01 は，ステートフルパケットインスペクション機能をもつ”とある。行きの通信を許可すれば戻りのパケットは自動で通るので，許可ルールは通信を始める側から書けばよく，逆向きのルールは要らない。

間違えやすい点。Ⅰは“図1中の機器名で”とあるので“カメラ管理サーバ”と書く（“サーバ”だけにしない）。Ⅱは HTTP の 80 ではなく，本文の“PC とは HTTPS で”に合わせて 443 である。

本文の根拠

〔追加指示への対応〕

⑥既設機器には，IP マルチキャストの設定を追加する。

〔IP マルチキャストに関する調査及び設計〕

L3SW11 及び L3SW21 では，マルチキャストルーティング用のプロトコルとして ［ カ ］ を有効化し，レシーバが接続された L2SW と接続するインタフェースにおいて，IGMPv3 を有効化する。

〔IP マルチキャストに関する調査及び設計〕

K 市庁舎の全ての L2SW では，［ イ ］ スヌーピングが有効になっていることを確認する。

PC で映像を受けるには，PC が送る IGMPv3 の (S,G) Join を，PC のセグメントのルータ（ラストホップのルータ）が受け付けなければならない。図1で PC のセグメントを収容するルータは執務エリア1の L3SW11 と執務エリア2の L3SW21 である。これまでの設計では，この2台で IGMPv3 を有効にしたのは“レシーバが接続された L2SW と接続するインタフェース”だけなので，PC 側のインタフェースにも設定を追加する必要がある。

FW01 は全インタフェースで PIM-SM がすでに有効で，L2SW は全て IGMP スヌーピングを有効にしてある。したがって設定を追加する既設機器は L3SW11 と L3SW21 になる。

間違えやすい点。“複数該当する場合は全て答えよ”なので2台とも書く。FW01 や L2SW を挙げるのは，すでに設定済みの項目と重なる。採点講評によると設問4(1)の正答率が低かった。

採点講評（IPA）

設問4では，(1)の正答率が低かった。ネットワーク構成と通信プロトコルとの関係を正しく理解し，必要となる変更作業を導き出してほしい。

本文の根拠

〔IP マルチキャストに関する調査及び設計〕

レシーバが接続された L2SW と接続するインタフェースにおいて，IGMPv3 を有効化する。

図1

執務エリア1では，L3SW11 の下に L2SW11 と L2SW12 があり，L2SW11 と L2SW12 にはそれぞれ PC（複数台）が接続する。L2SW12 にはレシーバ11〜レシーバ13（新設）が接続し

図1

執務エリア2も同じ形で，L3SW21 の下に L2SW21 と L2SW22 があり，それぞれ PC（複数台）が接続する。L2SW22 にはレシーバ21〜レシーバ23（新設）が接続し

PC は L2SW11・L2SW12（執務エリア1）と L2SW21・L2SW22（執務エリア2）に接続している。このうち L2SW12 と L2SW22 にはレシーバも接続されており，L3SW11・L3SW21 のこれらと接続するインタフェースでは既に IGMPv3 を有効化している。まだ IGMPv3 が有効でないのは，PC だけが接続された L2SW11 と L2SW21 に向いたインタフェースである。

図1で L2SW と L3SW のつながり方を追い，本文の“レシーバが接続された L2SW と接続するインタフェース”という限定と照らし合わせると，残る接続先が決まる。

間違えやすい点。PC がつながる L2SW を4台とも書くと，L2SW12・L2SW22 は既に設定済みなので過剰になる。“設定を追加する”のは今の設定で足りない所だけである。

採点講評（IPA）

設問4では，(1)の正答率が低かった。ネットワーク構成と通信プロトコルとの関係を正しく理解し，必要となる変更作業を導き出してほしい。

本文の根拠

(3) IP マルチキャスト

IP マルチキャストの配信要求プロトコルとして，IGMPv3（Internet Group Management Protocol, Version 3）を用いる。

〔追加指示への対応〕

PC には，IGMPv3 に対応し，映像データから映像へ ［ キ ］ する機能をもつソフトウェア製品を新たに導入する。

PC は IGMPv3 に対応したソフトウェアで，IGMPv3 の (S,G) Join を送って配信を要求する。これを受けるために，L3SW11・L3SW21 の L2SW11・L2SW21 と接続するインタフェースで有効にするプロトコルは IGMPv3 である。

L3SW どうしや FW01 との間のマルチキャストルーティング（PIM-SM，SSM）は既に設定済みで，PC の追加で変わるのは受信者とルータの間の配信要求の部分だけである。

間違えやすい点。“本文中の字句で”とあるので“IGMP”ではなく版まで含めて“IGMPv3”と書く。IGMPv2 では (S,G) を指定できず，同一のグループアドレスを使う本問の設計（下線③）では PC がカメラを選べない。

採点講評（IPA）

設問4では，(1)の正答率が低かった。ネットワーク構成と通信プロトコルとの関係を正しく理解し，必要となる変更作業を導き出してほしい。

本文の根拠

〔追加指示への対応〕

デスクトップアプリケーション方式では，PC 上でソフトウェア製品を起動し，ソフトウェア製品に IP カメラを登録すること及び登録済みの IP カメラを選択して映像を表示することができる。

〔追加指示への対応〕

Web ブラウザ方式では，PC の Web ブラウザからカメラ管理サーバの Web ページを開き，カメラ管理サーバに登録された IP カメラを選択することによってソフトウェア製品が起動され，映像を表示することができる。

〔追加指示への対応〕

⑦デスクトップアプリケーション方式と Web ブラウザ方式とを比較して，IP カメラの追加や更新における利点から Web ブラウザ方式を採用

デスクトップアプリケーション方式では，IP カメラの情報を各 PC のソフトウェア製品に登録する。カメラを追加・更新するたびに，全ての PC で登録をし直さなければならない。Web ブラウザ方式では，カメラの情報はカメラ管理サーバに登録され，PC はその Web ページから選ぶだけなので，カメラの追加・更新はカメラ管理サーバの Web ページを直せば全 PC に反映される。

本文の2つの方式の説明で，IP カメラを“ソフトウェア製品に登録する”か“カメラ管理サーバに登録された”ものを選ぶかの違いが根拠になる。下線⑦が“IP カメラの追加や更新における利点”と観点を絞っている。

25字に収める。解答例は「Webページを改修するだけで対応完了できる。」で22字。“カメラ管理サーバの Web ページだけの変更で済む”（PC ごとの作業が要らない）という点を書く。

本文の根拠

(1) 通信の高速化

①5 GHz 帯を二つに区別し，2.4 GHz 帯と合わせて計三つの周波数帯を同時に利用できる a に対応した AP が多く登場している。

(2) 多数の WLAN 端末接続時の通信速度低下を軽減

Wi-Fi 6 では，送受信側それぞれ複数の b を用いて複数のストリームを生成し，複数の WLAN 端末で同時に通信する MU-MIMO が拡張されている。

(3) セキュリティの強化

更に利用者が指定した c の解読を試みる辞書攻撃に対する耐性を強化している。

〔LAN システムの構成〕

B 主任：はい，20 MHz 帯域幅チャネルを d によって二つ束ねた 40 MHz 帯域幅チャネルによって，要件を満たす目途がついています。

〔LAN システムの構成〕

PoE の方式は PoE+ と呼ばれる IEEE802.3at の最大 30 W では電力不足のリスクがありますので，e と呼ばれる IEEE802.3bt を採用します。

〔LAN システムの構成〕

それではフロア L2SW と AP との間には f と呼ばれる 2.5 GBASE-T か 5 GBASE-T を検討してみます。

〔LAN システムの構成〕

基幹 L3SW とサーバ L2SW はそれぞれ 2 台を g 接続して論理的に 1 台とし

〔LAN システムの構成〕

WLAN 端末への IP アドレス配布は DHCP サーバを使用しますので，基幹 L3SW には h を設定します。

a：2.4 GHz 帯と 5 GHz 帯の2つを同時に使うのがデュアルバンド，5 GHz 帯を2つに分けて計3つを同時に使うのがトライバンドである。b：MIMO は送信側・受信側それぞれが複数のアンテナを使い，空間的に別々のストリームを作る技術である。c：WPA3-Personal の SAE は，事前共有のパスワード（パスフレーズ）を直接推測しにくくし，やり取りを盗聴してから手元で総当たりするオフライン辞書攻撃に強くしている。d：隣り合う 20 MHz 幅のチャネルを束ねて広い帯域幅にする技術はチャネルボンディングである。

e：IEEE 802.3bt は PoE++ と呼ばれ，PSE（給電側）の出力は Type 3 で最大 60 W，Type 4 で最大 90 W である。f：2.5GBASE-T・5GBASE-T（IEEE 802.3bz）は，既設の UTP ケーブルで 1 Gbps を超える速度を出す規格群で，マルチギガビットイーサネットと呼ばれる。g：複数のスイッチを専用の接続で束ね，論理的に1台として管理・動作させるのがスタック接続である。h：DHCP の要求（DHCPDISCOVER）はブロードキャストなので，ルータを越えられない。WLAN 端末のセグメントとマシン室の DHCP サーバは基幹 L3SW で隔てられるので，基幹 L3SW に DHCP リレーエージェントを設定し，要求をユニキャストで DHCP サーバへ中継させる。

間違えやすい点。a は“デュアルバンド”と対比されているので“トライバンド”。e は“PoE+”と区別して“PoE++”とプラスを2つ書く。g は“リンクアグリゲーション”（リンクを束ねる技術）ではなく，スイッチ本体を束ねる“スタック”である。採点講評によると設問1は全体的にやや低く，特に a と f の正答率が低かった。

採点講評（IPA）

設問1では，正答率は全体的にやや低く，特にaとfが低かった。本設問の内容のほとんどは無線LAN製品に実装されている技術仕様であり，公開されている情報である。提案時における方式選択の際に必要となるので，是非知っておいてもらいたい。

本文の根拠

表1

周波数帯：Wi-Fi 4 は 2.4 GHz と 5 GHz（W52/W53/W56），Wi-Fi 5 は 5 GHz（W52/W53/W56），Wi-Fi 6 は 2.4 GHz と 5 GHz（W52/W53/W56）。

(1) 通信の高速化

①5 GHz 帯を二つに区別し，2.4 GHz 帯と合わせて計三つの周波数帯を同時に利用できる

〔LAN システムの構成〕

B 主任：二つの 5 GHz 帯にはそれぞれ異なる ESSID を付与し，生徒及び教職員のノート PC を半数ずつ接続します。

周波数帯：表1の 5 GHz 帯は W52・W53・W56 に分かれている。W52（5.2 GHz 帯）と W53（5.3 GHz 帯）は周波数が連続しており，W56（5.6 GHz 帯）は離れている。5 GHz 帯を二つに区別するときは，W52/W53 と W56 に分ける。トライバンドの AP は，この2つの 5 GHz 帯にそれぞれ別の無線部を割り当てて同時に電波を出す。

利点：デュアルバンドでは 5 GHz 帯の無線部は1つで，5 GHz 帯の端末は全てそこに集まる。トライバンドなら 5 GHz 帯の無線部が2つになり，端末を2つに分けて収容できる。本文でも B 主任は二つの 5 GHz 帯に別々の ESSID を付けてノート PC を半数ずつ接続する。1つの無線部当たりの端末数が減るので，より多くの端末がつながっても安定して通信できる。

30字に収める。解答例は「より多くのWLAN端末が安定して通信できる。」で22字。“接続できる端末数が増える”と“安定して通信できる”の両方が入るとよい。採点講評によると，トライバンドの利点の理解が不十分な解答が散見された。周波数帯の①②の順序は問わない。

採点講評（IPA）

設問2は，全体的に正答率は高かったものの，(1)ではトライバンドの利点に関する理解が不十分な解答が散見された。無線LANの設計において，端末の接続性及び通信の安定性を確保するためには，電波周波数帯の種類と特性を理解して適切に利用することが重要なので，是非とも理解を深めてほしい。

本文の根拠

(1) 通信の高速化

②5 GHz 帯の一部は気象観測レーダーや船舶用レーダーと干渉する可能性があるので，AP はこの干渉を回避するための DFS（Dynamic Frequency Selection）機能を実装している。

表1

Wi-Fi 6 は 2.4 GHz と 5 GHz（W52/W53/W56）。

周波数帯：国内の 5 GHz 帯無線 LAN のうち，W53 と W56 は気象レーダーなどのレーダーと周波数を共用しているため，DFS の実装が電波法令で義務付けられている。W52 はレーダーと共用しておらず，DFS は不要である。

動作：DFS は，運用中にレーダー波を検知すると，そのチャネルでの電波の送信を止め，別のチャネルへ移って通信を再開する。移った先が DFS の対象チャネルなら，使い始める前にレーダー波が無いことを一定時間確かめる。影響：チャネルが切り替わる間，AP につながっていた WLAN 端末は接続が切れたり通信が止まったりする。レーダー波はいつ来るか分からないので，この切断は不定期に起きる。

40字・25字に収める。解答例の動作は「検知したチャネルの電波を停止し，他のチャネルに遷移して再開する。」で32字，影響は「APとの接続断や通信断が不定期に発生する。」で21字。動作は“停止”“他チャネルへ移る”“再開”の3段を書く。影響は“不定期に”を入れると，DFS の起き方の特徴まで表せる。周波数帯の①②の順序は問わない。

本文の根拠

RFP の要件

1 教室当たり 50 人分のノート PC を無線 LAN に接続し，4K UHDTV 画質（1 時間当たり 7.2 G バイト）の動画を同時に再生できること。

RFP の要件

AP は各教室に 1 台設置し，同じ階のフロア L2SW から PoE で電力供給すること

〔LAN システムの構成〕

③ノート PC の台数と動画コンテンツの要件に従ってフロア L2SW と AP との間のトラフィック量を試算

動画1本当たりのビットレートは，1時間当たり 7.2 G バイトなので，7.2 G バイト × 8 = 57.6 G ビットを 3,600 秒で送る。57.6 G ビット ÷ 3,600 秒 = 0.016 G ビット／秒 = 16 Mbps である。AP は1教室に1台で，1教室の 50 台のノート PC が同時に再生するので，フロア L2SW と AP の間は 16 Mbps × 50 = 800 Mbps になる。

これは本文の B 主任の“1 Gbps 以下に収まる”と合う。C 課長の指摘のとおり，隣の教室の AP が故障してその教室の PC が流れ込むと 1,600 Mbps となり，1 Gbps を超える。これが f（マルチギガビットイーサネット）の検討につながる。

間違えやすい点。バイトからビットへの ×8 と，時間から秒への ÷3,600 を忘れない。G（10の9乗）と M（10の6乗）の換算で桁を誤りやすく，採点講評でも桁の誤りが散見されたとされている。

採点講評（IPA）

設問3では，(1)の正答率がやや低く，桁の誤りも散見された。端末当たりのスループットや，認証やDHCPも含めたトラフィックの流れと流量を把握することは，LANの全体設計に必要である。計算式自体は単純なので，落ち着いて計算してもらいたい。

本文の根拠

〔LAN システムの構成〕

まず，基幹部分及び高負荷が見込まれる部分は 10 GbE リンクを複数本接続します。そして，レイヤー2 ではスパニングツリーを設定してループを回避し，レイヤー3 では基幹 L3SW を VRRP（Virtual Router Redundancy Protocol）で冗長化する構成にしました。

〔LAN システムの構成〕

④スパニングツリーと VRRP では，高負荷時に 10 GbE リンクがボトルネックになる可能性があります

〔LAN システムの構成〕

⑤サーバ，FW，WLC 及びフロア L2SW を含む全てのリンクを，スイッチをまたいだリンクアグリゲーションで接続

図1

基幹 L3SW1・基幹 L3SW2 のそれぞれが，サーバ L2SW1 とサーバ L2SW2 の両方に 10GbE で接続し，この区間を (ⅱ) としている。

区間：動画は動画コンテンツサーバから，サーバ L2SW → 基幹 L3SW → フロア L2SW → AP と流れる。全 15 教室が同時に再生すると，合計は 800 Mbps × 15 = 12 Gbps である。スパニングツリーはループになる冗長リンクをブロックし，VRRP ではマスタの基幹 L3SW だけがゲートウェイとして転送する。そのため (ⅱ) の4本のうち実際に使われるのは1本に近くなり，12 Gbps が 10 GbE の1本に集まってボトルネックになる。ほかの区間は，(ⅲ) が1フロア 3 教室で 2.4 Gbps，(ⅳ) が4台のサーバに分かれて1台 3 Gbps 程度で，10 GbE に収まる。(ⅰ) はインターネット向け，(ⅴ) は WLC で，本文のとおり認証後の通信は WLC を経由しない。

理由：スタックで論理的に1台にしたスイッチどうしをスイッチをまたいだリンクアグリゲーションで結ぶと，ループにならないので全リンクを同時に使える。平常時から本数分の帯域（(ⅱ) なら 10 GbE × 本数）を使えるので，ボトルネックが解消する。

30字に収める。解答例は「平常時にリンク本数分の帯域を同時に利用できるから」で24字。スパニングツリーでは予備のリンクが“待機”になるのに対し，“平常時にも”全リンクを使う点を書く。区間は図1の記号で (ⅱ) と答える（解答例PDFは半角の“(ii)”と表記）。

本文の根拠

RFP の要件

フロア L2SW と AP はシングル構成とし，A 専門学校の職員が保守を行う前提で，予備機を配備し保守手順書を準備すること

RFP の要件

動画コンテンツは A 専門学校が保有する計 4 台のサーバ（学年ごとに 2 台ずつ）で提供し，A 専門学校がサーバの保守を行っている。

RFP の要件

(ケ) 基幹 L3SW，サーバ L2SW，認証システム，DHCP サーバ及び FW に対する，故障交換作業及び設定復旧作業（以下，保守という）

〔LAN システムの構成〕

⑥この LAN システム提案構成では，職員が保守を行った際にブロードキャストストームが発生するリスクがあります

機器：保守（故障交換作業及び設定復旧作業）のうち，(ケ) で提案に含めるのは基幹 L3SW，サーバ L2SW，認証システム，DHCP サーバ，FW である。RFP はそれ以外について，フロア L2SW と AP を職員が保守する前提とし，動画コンテンツサーバも A 専門学校が保守している。したがって職員の作業対象は AP，フロア L2SW，動画コンテンツサーバの3種類である。

作業ミス：採用した案ではスイッチをまたいだリンクアグリゲーションで全リンクを束ねるので，ループはリンクアグリゲーションの設定で防いでいる。故障交換のときにケーブルをつなぐポートを誤ったり，交換機の設定（リンクアグリゲーションなど）を正しく戻さなかったりすると，ループができる。例えばフロア L2SW は2台の基幹 L3SW に1本ずつつながっているので，交換したフロア L2SW でその2本が束ねられていなければ，基幹 L3SW との間でループになる。ループではブロードキャストが回り続け，ブロードキャストストームになる。

25字に収める。解答例は「ループ状態になるような誤接続や設定ミス」で19字。“ループ”を必ず入れ，接続の誤りと設定の誤りの両方を挙げる。機器は“図1中の機器名を用いて”とあるので，“フロア L2SW”“動画コンテンツサーバ”と図の表記どおりに書く。