従来は物理サーバの二つのNICをアクティブ・スタンバイで使っていた。EVPN導入後は、二台のL3SWへの回線をリンクアグリゲーションし、両方をアクティブにする。

問題

解説：従来は待機側の回線を通常の転送に使わなかった。両回線を利用可能にすることが利点であり、一つのフローが必ず二倍速になるという意味ではない。

本社の外線は80回線、営業所5拠点の外線は各10回線である。移行後の外線音声は全て本社のIPsecルータを通る。1回線当たりの必要帯域はヘッダを含め34.4 kbit/sである。

問題

解説：外線の総数は80＋5×10＝130回線である。130×34.4＝4,472となる。拠点間の内線回線数は、この外線向け区間の計算に加えない。

新ディレクトリサーバと新内部DNSは、それぞれ2本のNICをアクティブ／アクティブにする。各NICはスタックL3SWを構成する別の物理機器へ接続する。従来はアクティブ／スタンバイだった。

問題

解説：従来の待機リンクも通信に使える構成になる。同じ理由で、スタックL3SWと新内部DNSサーバ間も正答となる。

監視対象は1Gビット/秒の全二重リンクである。ネットワークタップなら送信側と受信側を別々の入力ポートへ複製する。採用案では、L2SWのミラーポート1本を1000BASE-SXでNPBへ接続し、双方向をまとめて送る。

問題

解説：監視対象は各方向に1Gビット/秒を流せるが、複製先は1本である。双方向の合計が出力容量を超えると、すべてのパケットを複製できなくなる。

キャプチャサーバへの平均入力は100kビット/秒である。1000日分を無圧縮で保存する。1kビットは10³ビット、1Gバイトは10⁹バイトとし、追加メタデータは無視する。

問題

解説：100×10³÷8＝12,500バイト/秒である。12,500×86,400秒×1,000日÷10⁹＝1,080Gバイトとなる。ビットからバイトへの変換を先に行うと計算を追いやすい。

1教室のノートPCは50台であり、各PCが1時間当たり7.2Gバイトの動画を同時に再生する。各教室にはAPを1台設置する。Gは10の9乗とし、各層のヘッダなどのオーバーヘッドは考慮しない。

問題

解説：1台分は7.2×10⁹×8÷3600＝16×10⁶ビット/秒となる。50台分では16×50＝800Mビット/秒である。これは通常の1教室分であり、他教室の端末が接続してくる場合は別に評価する。

サーバL2SW2台と基幹L3SW2台を複数の10GbEリンクで接続する。サーバ側の動画通信は、この区間に集約される。初期案ではSTPとVRRPを用いる。

変更案では、各スイッチ対をスタック化する。サーバL2SWと基幹L3SWの間も、装置をまたぐリンクアグリゲーションで接続する。

問題

解説：STPではループを防ぐため、一部の経路が転送に使われない。リンクアグリゲーションでは、複数の通信を束ねたリンクへ分散できる。単一通信の速度がリンク本数倍になるという意味ではない。

同じカメラ映像を複数のレシーバが同時に視聴する。ユニキャスト配信では、カメラがレシーバごとに映像データを送る。

問題

解説：映像内容が同じでも、宛先ごとに同じデータを送るためである。マルチキャストでは、必要な地点でネットワーク側が複製する。

カメラは20台あり、各カメラの映像レートは8Mビット/秒である。レシーバは6台あり、各レシーバは最大4映像を同時に受信できる。カメラ側の幹線では、マルチキャストによって各カメラのデータを一つずつ転送する。

問題

解説：20台×8Mビット/秒＝160Mビット/秒となる。受信可能な映像数は6台×4＝24であり、20台分を受信できる。同じ映像を複数のレシーバが受信しても、この幹線でその映像の送信量が増えるわけではない。

最大1Gビット/秒のベストエフォート型回線を利用している。実測速度は約200Mビット/秒で頭打ちとなり、ルータのCPUには余裕があった。ISPは、契約中のサービスでは構成や時間帯によりその程度になると説明した。

問題

解説：装置のCPU不足ではなく、利用中の回線サービスが実効速度の制約になっている。最大速度の表記だけで性能を判断せず、必要な帯域を確保する契約形態を検討する。

PCは600台ある。PC1台当たり最大200セッションを見積もる。現在のNAPT変換テーブル上限は65,536エントリーである。PC以外の通信は考慮しない。

問題

解説：65,536÷200＝327.68なので、上限を超えない整数台数は327台となる。600台に必要な数は600×200＝120,000である。端数の切り上げ・切り捨ては、資源上限と必要容量のどちらを求めているかで判断する。

対象L3SWはパケット単位のランダムな分散と、送信元・宛先IPアドレスのハッシュ値によるフロー単位の分散を備える。

問題

解説：同じ通信を異なる遅延の経路に交互に流すと、後のパケットが先に届き得る。フロー内で経路を固定すれば、その要因を減らせる。

多数の社内PCと業務サーバが通信する。L3SWは送信元IPアドレスと宛先IPアドレスからハッシュ値を求め、等コスト経路を選ぶ。

問題

解説：分散の単位はパケット数そのものではなく、IPアドレスの組から計算する値である。原問の判断は、この値の偏りが小さいという前提に基づく。

IP-in-IPとIPsecのヘッダーが加わると、転送パケットのサイズが増える。UTMにはTCPパケットのIPフラグメントを防止する設定がある。この設定を行わず、UTMでフラグメント処理が発生する場合を考える。

問題

解説：分割による追加処理が必要になる。ここでは通信が必ず失敗するという判断ではなく、UTMの処理負荷への影響が問われている。

L2SWは音声を最優先キュー1、データをキュー2へ入れる。機器の内部処理時間は無視する。音声が到着した時点でキュー1は空だった。

問題

解説：優先順位は次に送るフレームの選択に適用される。既に送信し始めたデータフレームの途中へ、音声フレームを割り込ませる処理ではない。

本社L3SW0は、IPsecルータ、FW、ファイルサーバ、業務サーバ、eLNサーバ、端末収容L2SW01・L2SW02、広域網へ接続する。営業所L3SW1は広域網と端末収容L2SW1へ接続する。

端末側IP電話はCoSを付ける。サーバ側などはCoSを付けない。広域網を渡るパケットには既にDSCPを付けている。

問題

解説：既に端末側で付いたCoSは活用する。未マーキングのサーバ側などでは通信種別を判定する。拠点間リンクはDSCPが付いた状態であり、この二つの分類対象に含めない。

音声は最優先キュー1で処理する。残りの通信は、eラーニング動画用キュー2に75%、一般データ用キュー3に25%の重みを付けてWRRで転送する。

問題

解説：同じ待ち行列へ混在させず、動画に対して重み付きの転送機会を確保する。音声最優先の設定とは別に、残りの通信同士の干渉を抑えている。

IPゲートウェイは音声パケットの到着間隔の揺らぎを吸収するバッファを持つ。バッファ容量を増やすことを検討している。

問題

解説：揺らぎを吸収するために待つ時間が増える。欠落の抑制と、会話の往復遅延の増加を分けて考える。

音声はG.729のCS-ACELPで符号化する。IP・トランスポート層・RTPのヘッダを付けて運ぶ。大量の動画通信と同じLANを使い、Diffservで優先制御する。

問題

解説：符号化した音声のビットレートだけで回線帯域は決まらない。ヘッダの追加分も必要になる。輻輳による遅延と廃棄は、通話品質を損なう別の現象である。

本社のL2SW10はR11とR13の両方に接続する。R11は専用線でR12へ、R13は別の専用線でR14へ接続する。R11とR13はVRRPを構成する。R12とR14自体の障害試験は事業者が実施済みである。

問題

解説：装置故障だけでなく、WAN側とLAN側のリンク断を分けて試験する。どの故障でも、利用可能なもう一方へ切り替わるかを確認する。

ECサーバのCPU使用率が設計値を超えた。処理能力の増強方法として、1台の性能を高める方法と、サーバを追加して処理を分担する方法を比較している。

問題

解説：原問ではサービスを止めずに増強するため、追加サーバへ処理を振り分けるスケールアウトを採用する。

ECサイトの必要処理能力はサーバ2台で満たせる。設計では3台を設置し、LBで負荷を分散する。将来のアクセス増加は考慮しない。

問題

解説：1台を失っても必要な2台分の処理能力が残る。正常時の性能だけでなく、単一障害時の性能を満たす構成である。

社内DNSの既定TTLは172800秒である。二台への振分けに使うmail.y-sha.lanのAレコードだけはTTLを60秒にしている。

問題

解説：長い間同じDNS応答を使い続けると、同じ転送先が選ばれやすくなる。キャッシュ時間を短くして、名前解決し直す機会を増やす。

同じAPを動かす仮想サーバ2台でVRRPを構成する。配置先を同一物理ホストとするか、異なる物理ホストとするかを検討している。

問題

解説：仮想サーバを2台用意しても、共通の物理ホストが単一障害点のままでは冗長化の目的を満たさない。

各配信サーバの性能は同じである。配信ファイルの大きさにはばらつきがあり、接続時間が変動する。方式の候補は順番に接続を割り当てるラウンドロビンと、現在の接続数が最も少ないサーバへ割り当てる方式である。ゲームα・β・γのサーバは、それぞれ172.21.1.0/24、172.22.1.0/24、172.23.1.0/24に置く。

問題

解説：接続を同じ回数ずつ割り当てても、長時間残る接続が多いサーバは混雑する。現在の接続数を見て振り分ける方式が条件に合う。増設先は対象ゲームに対応するサーバ群のセグメントで判断する。

数万台のGメーターが毎時測定する。各端末は0時の測定後、過去24回分を送る前に0〜1時間の範囲でランダムに待つ。

問題

解説：全端末の送信を0時に揃えると、短時間に要求が集中する。待ち時間を分散させれば、総データ量を変えずに同時送信数を抑えられる。

Gメーターは電池で長期間動作する。測定や送信を終えた後は、次の処理時刻までスリープ状態にする。

問題

解説：常時動作させるのではなく、測定と送信に必要な時間だけ動作させる。設問が求めるのはサーバ負荷ではなく端末側の電力への効果である。

各支社は本社のプロキシを利用する。PACで宛先がプライベートIPアドレスの場合にDIRECTを返し、その通信をプロキシへ送らないようにする。

問題

解説：社内宛ての通信を中継対象から外すため、プロキシの処理が減る。宛先が社内であることと、直接通信できる構成であることが判断の前提となる。

従来は本社FWからインターネットへ出てSaaSへ接続していた。導入後はIPsecでSGWのPOPへ接続し、SGWのFW機能を経由してSaaSへアクセスする。

問題

解説：通信経路と通過する処理が増える。接続の成否だけでなく、実際の業務利用で許容できる応答時間かも測定する。

社内PCから社内業務用サーバへの通信も、当初はSWGへ送り、インターネットから社内へ戻す案だった。業務用サーバのプライベートIPを直接接続リストへ追加し、社内では直接接続させる。

問題

解説：社内で完結する通信を外へ迂回させなければ、通過するFWや回線の負荷を減らせる。公式解答は、RTT短縮や可用性向上など、直接通信・経路短縮の利点も認めている。検査機能が自動的に強くなるという理由ではない。

同一帯域の専用線を二回線利用し、トラフィックを均等に分散できると仮定する。一回線が故障すると、全通信が残る一回線へ集約される。通信量は障害前後で変わらない。

問題

解説：各回線の容量をC、平常時の通信量をxとすれば、障害時は残る回線に2xが流れる。2x≦Cから、x/C≦1/2となる。これは均等分散と通信量不変を仮定した上限である。