ネットワークスペシャリスト 2010年 午後1 問02
ネットワークの評価に関する次の記述を読んで、設問1~3に答えよ。
Z社では、家電製品・OA機器の故障品の受付、修理及び修理完了品の返送の業務をメーカーから受託している。Z社の本社は東京にあり、修理業務は、仙台拠点と横浜拠点で行っている。両拠点への業務委託元及び取扱製品は異なるが、業務内容や作業量に大差がなく、ネットワークの使用状況もほぼ同じである。また、各拠点ではZ社の社員のほかに、派遣社員やパートタイマが作業員として勤務している。
本社に設置されているSV業務管理サーバ(以下、業務管理SVという)及びファイルサーバ(以下、ファイルSVという)には、全社のPCがアクセスしている。拠点では、業務の都合上、修理記録や各種伝票類を帳票で管理しており、常時、PCからプリンタへ印刷データを送信している。また、Z社には、IP電話による社内電話システムが構築されている。本社と各拠点間は、IP-VPNで接続されている。現在のところ、IP-VPNのピーク時の回線使用率は約8割であり、通信帯域域は不足していない。Z社の現在のネットワーク構成を、図1に示す。

Z社では、運用管理の省力化とセキュリティの強化を目的に、全社のPCをデータの記録蓄積機能のないシンクライアントと呼ばれる端末(以下、TCという)へ移行する計画がある。TCへの移行は、PCの更新時期が控えている仙台拠点を先行して、問題がないか試験的に拡大する方針である。移行計画では、TCへの移行のために、現在のネットワークを変更する必要があるかどうかを評価することが、検討課題の一つとして挙げられている。そこで、移行計画を担当することになった情報システム部のO主任と後輩のU君は、ネットワークの評価について打合せを行った。
次は、そのときのO主任とU君の会話である。
〔TCの実装方式と通信〕
O主任:会社の業務は変わらないとして、全社のPCをTCへ移行すると、現在のネットワーク構成で問題になるところは何かしら。
U君:調査しないと分かりません。ところで、TCの実装方式は決まったのですか。
O主任:ええ。画面転送型といって、仮想化機構を組み込んだサーバ(以下、仮想化SVという)に、PC単位の独立したプログラム実行環境(以下、仮想PCという)をソフトウェアで構築し、仮想PCの画面情報をTCに表示する方式に決まったのよ。仮想化SVは、本社に設置する計画よ。
U君:その構成だと、拠点間の通信形態が変わるので、LANやWANでのトラフィックの流れと量が変わります。まずは、TCへ移行した後のIP-VPNの使用帯域の試算と、RTの優先制御設定の再検討が必要になります。
O主任:そうね。仮想PCとTC間の通信には、①画面転送時の伝送情報量の削減技術や、通信のバースト性の低減技術が採用されているので、TC1台当たりの平均使用帯域が20 kビット/秒となると聞いているわ。
U君:それならば、仙台拠点に設置する40台のTCの通信には、IP-VPNの伝送効率を0.8としてa kビット/秒の通信帯域をIP-VPNで確保すればよいことになります。また、独立した複数のトラフィックを一つの伝送路に多重化することで、帯域を効率よく共用できるア多重効果を期待すれば、確保する通信帯域をもう少し減らせるかもしれません。
O主任:でも、実際には画面の表示内容によって、使用帯域が一時的に増加することがあるのよ。仮想PCとTC間の通信帯域が不足するとTCの操作に影響するので、通信帯域の余裕を十分に見ておいてね。後で資料を一式渡すわ。
U君:はい。それと、拠点からは、新規配属の作業員向けの訓練で動画を活用したいという要望があります。イと呼ばれる映像の符号化及び復号装置やソフトウェアについても調べ、TCの機能で対応できるかどうかを確認しておきます。
U君は、仙台拠点でTCへ移行した後の、本社と仙台拠点間のIP-VPNのトラフィックについて検討することにした。U君が、O主任から渡された資料を基に対象装置を選定して、図1に反映させたネットワーク構成を、図2に示す。

本社と仙台拠点間の通信には、仮想 PC と TC 間の通信のほかにも②新たに発生する通信があり、また、現在ある通信のうち発生しなくなる通信もある。これらの通信によるトラフィックの増減を見積もり、TC へ移行した後の IP-VPN の使用帯域を試算する。仮想 PC と TC 間の通信については、TC メーカの測定結果を使用し、そのほかの通信については、実際にネットワークを調査することにした。
〔ネットワークの調査〕
U君は、本社と仙台拠点間の IP-VPN のトラフィックを調査した。調査方法は、次のとおりである。本社内の PC で動作している SNMP マネージャから、RT2 の WAN 側ポートのIPアドレスをあて先にして RT2 の SNMP ウ と通信を行う。RT2 の エ と呼ばれる管理情報のオブジェクトのうち、ポートで受信又は送信した総バイト数を表す ifInOctets と ifOutOctets のカウンタ値を 1 分間隔で取得し、それぞれの増分を求める。カウンタ値は、LAN 側ポートのものも取得する。RT2 及び SNMP マネージャの動作が正常であっても③増分が負になることがあるので、その場合には定数を加えて補正する。増分を b で割り、トラフィックの 1 分間ごとの平均値を求める(単位:k ビット/秒)。さらに、L2SW2 にトラフィックモニタを接続して、拠点内の機器で発生するトラフィックを詳しく調査する。以上の結果から、TC へ移行した後の仙台拠点での IP-VPN のトラフィックは、現在の約 6 割に削減されることが分かった。また、横浜拠点についても同じ調査を行い、仙台拠点と同様の結果を得た。
続いて、U君は RT の優先制御設定の再検討を行った。現在は、IP 電話に関連する通信を優先するよう設定している。RT の優先制御の動作は、次のとおりである。
・入力パケットの最大出力パケットの最以下であれば、パケットを入力した順に出力する、オと呼ばれる仕組みに基づいて転送する。
・入力パケットの量が出力パケットの量を超えると、パケットを優先と非優先に分けてメモリ上の待ち行列として一時的に保存し、優先パケットから先に転送する。非優先パケットは、優先パケットの待ち行列が空になったときに転送する。待ち行列の長さが上限に達すると、次の入力パケットを待ち行列に追加せずに破棄する。
RT の優先制御の動作では、トラフィックの状態によっては、④非優先の通信におけるTCPの転送速度が端末に低下する場合がある。しかし、今回は、そのような場合はないと判断し、仮想 PC と TC 間の通信を優先する通信として追加することにした。
最後に、U君は拠点での動画表示について検討した。動画ファイルは、ファイル SV に保存する。一般に、画面転送型 TC での動画表示には制約を伴うが、導入予定の TC には、画面転送とは別セッションで仮想 PC から動画情報を送り、TC で復号を行う機能がある。U君は、この機能を使用することと、⑤動画表示に必要な通信帯域を IP-VPN の見込余剰帯域以下にするための運用条件を検討することを提案することにした。
U君は、以上の検討・調査の結果をまとめ、O 主任に、現在のネットワークを変更せずに TC を運用できることを報告し、O 主任の了解を得た。
設問1:
本文中のア~オに入れる適切な字句を答えよ。
模範解答
ア:統計
イ:コーデック
ウ:エージェント
エ:MIB
オ:FIFO 又は First In First Out
解説
解答の論理構成
-
ア の判断
- 会話文には「独立した複数のトラフィックを一つの伝送路に多重化することで、帯域を効率よく共用できるア多重効果」とあります。
- 伝送路を利用者全体で動的に分け合い、空き帯域を有効活用する考え方は “統計的多重化(Statistical Multiplexing)” です。よって「統計」が入ります。
-
イ の判断
- 会話文には「映像の符号化及び復号装置やソフトウェア」と明記されています。
- 映像や音声を符号化 (encode)・復号 (decode) する仕組みは “Codec(コーデック)” と呼ばれます。
-
ウ の判断
- 調査方法として「RT2 の WAN 側ポートの IP アドレスをあて先にして RT2 の SNMP ウ と通信を行う」と書かれています。
- SNMP で管理対象機器側に常駐し、マネージャと通信するプログラムは “Agent(エージェント)” です。
-
エ の判断
- 同段落で「RT2 の エ と呼ばれる管理情報のオブジェクトのうち、ポートで受信又は送信した総バイト数を表す ifInOctets と ifOutOctets…」とあります。
- SNMP で管理情報を階層構造で定義したデータベースは “MIB (Management Information Base)” です。
-
オ の判断
- RT の優先制御について「入力パケットの最大出力パケットの最以下であれば、パケットを入力した順に出力する、オと呼ばれる仕組みに基づいて転送する」と記述されています。
- 入力順=先に来たものから順に送る方式は “FIFO (First In First Out)” です。
以上より、解答は
ア:「統計」
イ:「コーデック」
ウ:「エージェント」
エ:「MIB」
オ:「FIFO 又は First In First Out」
ア:「統計」
イ:「コーデック」
ウ:「エージェント」
エ:「MIB」
オ:「FIFO 又は First In First Out」
誤りやすいポイント
- ア を「時分割」や「周波数分割」と誤記
「統計多重」は時間や周波数を固定で割り当てる方式ではなく、利用実績に応じて帯域を共有する点が特徴です。 - ウ と エ を逆に覚える
“エージェント” はプログラム、“MIB” は情報のデータベース。語句の役割をセットで整理しましょう。 - オ を「キューイング」だけで答える
FIFO はキューイングの一種ですが、問題は “入力順そのまま” という仕組み名を問うています。
FAQ
Q: SNMP の “Manager—Agent” モデルは必ず UDP を使うのですか?
A: 標準プロトコルとしては UDP/161,162 が一般的ですが、冗長性やセキュリティを考慮し TCP を使う実装もあります。
A: 標準プロトコルとしては UDP/161,162 が一般的ですが、冗長性やセキュリティを考慮し TCP を使う実装もあります。
Q: 「統計多重効果」が期待できるのはどのようなトラフィック特性ですか?
A: 端末ごとにピークトラフィックが同時に発生しにくい、バースト的な通信が混在している場合に効果が高まります。
A: 端末ごとにピークトラフィックが同時に発生しにくい、バースト的な通信が混在している場合に効果が高まります。
Q: FIFO で優先制御はできないのですか?
A: FIFO 自体は優先度を区別しません。優先制御が必要な場合は、FIFO の前段でパケットを優先/非優先の複数キューに振り分ける仕組みを併用します。
A: FIFO 自体は優先度を区別しません。優先制御が必要な場合は、FIFO の前段でパケットを優先/非優先の複数キューに振り分ける仕組みを併用します。
関連キーワード: 統計多重化, SNMP, MIB, FIFO, コーデック
設問2:〔TCの実装方式と通信〕について、(1)~(3)に答えよ。
(1)本文中のaに入れる適切な数値を答えよ。
模範解答
a:1,000
解説
解答の論理構成
-
端末 1 台当たりの平均帯域
【問題文】には「TC1台当たりの平均使用帯域が20 kビット/秒」とあるので、1 TC の実効トラフィックは 20 kbit/s です。 -
端末台数の考慮
仙台拠点に導入する台数は「40台のTC」と明記されています。
よって、理論上の合計トラフィックは
となります。 -
伝送効率による補正
回線にはプロトコルヘッダなどのオーバヘッドが存在し、実効スループットは物理帯域より小さくなります。本文では「IP-VPNの伝送効率を0.8として」と指示されています。
実効スループット = 物理帯域 × 0.8
を逆算すると、必要な物理帯域は -
結論
以上より、[ a ] に入る値は 1,000 kビット/秒 となります。
誤りやすいポイント
- 伝送効率 0.8 を「掛ける」か「割る」かを取り違える
実効値から物理帯域を求めるときは除算です。 - 単位換算のミス
kbit/s と Mbit/s を混同すると 1 桁以上ずれます。 - 端末台数の読み落とし
仙台拠点だけで 40台 であり、全社分(PC+TC)ではありません。
FAQ
Q: 伝送効率 0.8 とは具体的に何を指しますか?
A: IP-VPN 区間で発生する各種ヘッダ・再送制御などのオーバヘッドを含めたとき、実効スループットが物理帯域の 80 % になるという前提値です。
A: IP-VPN 区間で発生する各種ヘッダ・再送制御などのオーバヘッドを含めたとき、実効スループットが物理帯域の 80 % になるという前提値です。
Q: 「帯域をもう少し減らせる」とあるが、なぜ今回は 1,000 kbit/s で確保するのですか?
A: [ア] 多重効果(統計多重)の期待はありますが、O主任が「通信帯域の余裕を十分に見ておいて」と指示しており、設問では理論値をそのまま算出させる意図だからです。
A: [ア] 多重効果(統計多重)の期待はありますが、O主任が「通信帯域の余裕を十分に見ておいて」と指示しており、設問では理論値をそのまま算出させる意図だからです。
Q: 20 kbit/s はピーク帯域ですか?
A: いいえ。「平均使用帯域」と明記されています。ピークを評価するときは別途余裕幅や QoS を検討します。
A: いいえ。「平均使用帯域」と明記されています。ピークを評価するときは別途余裕幅や QoS を検討します。
関連キーワード: 伝送効率, 統計多重, スループット, シンクライアント, 画面転送
設問2:〔TCの実装方式と通信〕について、(1)~(3)に答えよ。
(2)本文中の下線①に示す技術を二つ挙げ、それぞれ10字以内で具体的に答えよ。
模範解答
①:データ圧縮
②:差分伝送
または
プログレッシブ符号化
または
帯域制御
解説
解答の論理構成
- 問題文は、シンクライアント方式で「①画面転送時の伝送情報量の削減技術や、通信のバースト性の低減技術」が採用されていると述べています。
引用:【問題文】「仮想PCとTC間の通信には、①画面転送時の伝送情報量の削減技術や、通信のバースト性の低減技術が採用されている…」 - 画面転送における“伝送情報量の削減”は、
・画像や動画のデータ自体を小さくする「データ圧縮」
・前回から変化した部分だけを送る「差分伝送」
という代表的な二方式で実現されます。 - “通信のバースト性の低減”も、圧縮によるデータ量削減と差分伝送によりトラフィックの瞬間的な集中(バースト)を抑えることで達成できます。
- したがって、①の具体例としては
「データ圧縮」・「差分伝送」
を挙げれば要件を満たします。
誤りやすいポイント
- 画面転送と動画ストリーミングを混同し、「コーデック名」を答えてしまう。
- “バースト性の低減”をQoS機能のような“優先制御”と勘違いし「帯域制御」を主答案にしてしまう。
- シンクライアントの種類(ブレードPC方式/画面転送方式)に着目し過ぎて「USBリダイレクト」など関連薄い技術を挙げる。
FAQ
Q: 「プログレッシブ符号化」でも正解になりますか?
A: はい。模範解答に示されているとおり「プログレッシブ符号化」も伝送情報量を段階的に減らす技術として認められます。
A: はい。模範解答に示されているとおり「プログレッシブ符号化」も伝送情報量を段階的に減らす技術として認められます。
Q: 「帯域制御」は“削減技術”ではないのでは?
A: 帯域制御は厳密には“利用量の平準化”によりバーストを抑える手法です。問題文が“通信のバースト性の低減技術”も例示しているため容認されています。
A: 帯域制御は厳密には“利用量の平準化”によりバーストを抑える手法です。問題文が“通信のバースト性の低減技術”も例示しているため容認されています。
Q: 画像圧縮形式(JPEG、PNGなど)を答えるべきでしょうか?
A: 形式名よりも、「データ圧縮」など一般的な技術名称を求めています。
A: 形式名よりも、「データ圧縮」など一般的な技術名称を求めています。
関連キーワード: データ圧縮, 差分伝送, プログレッシブ符号化, 帯域制御
設問2:〔TCの実装方式と通信〕について、(1)~(3)に答えよ。
(3)本文中の下線②に示す新たに発生する通信を一つ、発生しなくなる通信を一つ、図1、2中の機器名を用いてそれぞれ答えよ。
模範解答
新たに発生する通信:
・仮想PC と 仙台拠点のプリンタ間の通信
または
・仮想化SV と 仙台拠点のプリンタ間の通信
発生しなくなる通信:
①:仙台拠点のPC と 業務管理SV間の通信
②:仙台拠点のPC と ファイルSV間の通信
解説
解答の論理構成
-
前提の整理
- TC 方式採用後の構成について本文には、仮想化サーバ(本社)上の「仮想PC」の画面が「TC」に転送されると記載されています。
- さらに下線②で「新たに発生する通信があり、また、現在ある通信のうち発生しなくなる通信もある」とあります。
-
“新たに発生する通信” の特定
- 仙台拠点の「TC」上で印刷操作を行うと、そのジョブは本社の「仮想PC」から仙台拠点の「プリンタ」に送られます。
- つまり、従来は拠点内で完結していた印刷データが IP-VPN を横断するため、
「仮想PC と 仙台拠点のプリンタ間の通信」
あるいは同義の
「仮想化SV と 仙台拠点のプリンタ間の通信」
が“新たに” WAN 上に現れます。
-
“発生しなくなる通信” の特定
- TC への移行によって仙台拠点の「PC」は撤去されます。
- したがって、これまで仙台拠点の「PC」から本社の「業務管理SV」や「ファイルSV」へ直接流れていた業務系/ファイル参照系トラフィックは消滅します。
- 設問では“一つ”答えれば良いので、代表例として
「仙台拠点のPC と 業務管理SV間の通信」
または
「仙台拠点のPC と ファイルSV間の通信」
のいずれかを挙げれば成立します。
-
結論
- 新たに発生する通信:仮想PC(または仮想化SV)と 仙台拠点のプリンタ間の通信
- 発生しなくなる通信:仙台拠点のPC と 業務管理SV間の通信(同等にファイルSV間でも可)
誤りやすいポイント
- 「プリンタ通信は以前からあったので“新た”ではない」と誤解しがち
→ 以前は拠点内完結、今後は IP-VPN 経由になる点が変化しています。 - 「TC と 仮想PC 間の画面転送」を“新たな通信”と勘違い
→ これはもちろん新規ですが、設問は“下線②の例”を求めており、印刷通信の方が典型例として想定されています。 - “発生しなくなる通信”で「PCとプリンタ間」を選ぶ誤答
→ 仙台拠点に TC が来てもローカル印刷は残るため、この通信は消えません。
FAQ
Q: 「仮想化SV と 仙台拠点のプリンタ間の通信」と「仮想PC と 仙台拠点のプリンタ間の通信」はどちらを書けば良いですか?
A: どちらでも採点対象になります。仮想PC は仮想化SV 上に論理的に存在するため、実体としては同じ経路を意味します。
A: どちらでも採点対象になります。仮想PC は仮想化SV 上に論理的に存在するため、実体としては同じ経路を意味します。
Q: 「仙台拠点のPC と IP電話機間の通信」は発生しなくなりますか?
A: そもそも PC と IP電話機の直接通信は業務フローに含まれていません。撤去によって“消える”通信は、本社サーバへ向かう業務系トラフィックです。
A: そもそも PC と IP電話機の直接通信は業務フローに含まれていません。撤去によって“消える”通信は、本社サーバへ向かう業務系トラフィックです。
Q: 印刷トラフィック以外に新たに増えるものはありますか?
A: 動画訓練用に「仮想PC → TC」へ別セッションで流す動画データも増えますが、本設問は下線②時点での変化を問うているため、印刷経路が最も直接的な答えになります。
A: 動画訓練用に「仮想PC → TC」へ別セッションで流す動画データも増えますが、本設問は下線②時点での変化を問うているため、印刷経路が最も直接的な答えになります。
関連キーワード: IP-VPN, シンクライアント, 画面転送, SNMP, ルーティング
設問3:〔ネットワークの調査〕について、(1)~(5)に答えよ。
(1)本文中のbに入れる適切な数値を答えよ。
模範解答
b:7,500
解説
解答の論理構成
-
前提整理
【問題文】には「カウンタ値を 1 分間隔で取得し...増分を b で割り、トラフィックの 1 分間ごとの平均値を求める(単位:k ビット/秒)」とあります。したがって、b は“1 分間に増えたバイト数”を“1 秒当たりのキロビット数”に換算するための係数です。 -
バイト → ビットへの換算
1 バイトは 8 ビットなので、増分(バイト)に 8 を掛ければビット数になります。 -
1 分 → 1 秒への換算
取得間隔は「1 分間隔」であるため、ビット/分を 60 で割ってビット/秒にします。 -
ビット/秒 → キロビット/秒への換算
本問は「単位:k ビット/秒」です。ここで “k” は 10³(1,000)と解釈するのが一般的です。したがって、ビット/秒を 1,000 で割りキロビット/秒を得ます。 -
係数の導出
以上をまとめると、換算係数は
よって、増分(バイト)÷7,500 = k ビット/秒 となり、b = 7,500
誤りやすいポイント
- 1,024 で割って “kibi” 表記にしてしまう
本問は「k ビット/秒」と明示されており、2 進接頭辞ではなく 10 進系(1,000)で計算します。 - “8” と “60” を掛け算する代わりに割り算をしてしまう
ビット換算(×8)と時間換算(÷60)を逆に覚えてミスするケースが多いです。 - 1 分間隔の取得を忘れ、秒単位と勘違いする
取得間隔が「1 分間隔」であるため、時間換算を入れ忘れると 60 倍の誤差が生じます。
FAQ
Q: 取得間隔が 30 秒なら係数はどう変わりますか?
A: 時間換算が 30 秒になるだけなので、 ではなく という計算結果になります(7,500 の半分)。
A: 時間換算が 30 秒になるだけなので、 ではなく という計算結果になります(7,500 の半分)。
Q: “k ビット/秒”でなく “M ビット/秒” を直接出したいときは?
A: キロ→メガでさらに 1,000 で割るだけです。つまり 7,500 × 1,000 = 7,500,000 を係数に用います。
A: キロ→メガでさらに 1,000 で割るだけです。つまり 7,500 × 1,000 = 7,500,000 を係数に用います。
Q: ifInOctets と ifOutOctets のどちらを見ればよいですか?
A: 双方向のトラフィックを知りたい場合は両方のカウンタ値の増分を別々に求め、合計しても構いません。片方向だけで良い場合は目的に応じて片方のみを使用します。
A: 双方向のトラフィックを知りたい場合は両方のカウンタ値の増分を別々に求め、合計しても構いません。片方向だけで良い場合は目的に応じて片方のみを使用します。
関連キーワード: SNMP, ifInOctets, 帯域計算, 単位換算, ルータ待ち行列
設問3:〔ネットワークの調査〕について、(1)~(5)に答えよ。
(2)LAN側ポートのカウンタ値を取得する目的は何か。調査方法に着目して、30字以内で述べよ。
模範解答
SNMP の通信によるカウンタ値の増加を排除するため
解説
解答の論理構成
- 調査方法では、RT2 の WAN 側ポートから ifInOctets と ifOutOctets を取得し、増分を IP-VPN のトラフィックとみなしています。
引用︓「RT2 の WAN 側ポートの IP アドレスをあて先にして RT2 の SNMP ウ と通信を行う。」 - しかし、その取得操作自体(SNMP 要求/応答)も WAN 側ポートを経由するため、カウンタ値に“測定トラフィック”が混入します。
測定対象=通常業務のパケット
混入要因=SNMP マネージャ↔RT2 のやり取り - この混入を検出・除外する手段として、SNMP パケットが通らない LAN 側ポートの ifInOctets / ifOutOctets も同時に取得します。
引用︓「カウンタ値は、LAN 側ポートのものも取得する。」 - WAN 側と LAN 側の差分を比較し、SNMP 分を補正することで“純粋な IP-VPN 利用量”を算出できるため、目的は
「SNMP の通信によって増えたバイト数を排除すること」となります。
誤りやすいポイント
- WAN 側だけを測定すると、SNMP パケットが通信量として計上される事実を見落としがちです。
- 「LAN 側カウンタを取得=拠点内トラフィック測定」と短絡し、排除目的まで言及しない答案が散見されます。
- SNMP トラフィックは小さいから無視してよいと判断し、目的自体を誤解するケースがあります。
FAQ
Q: SNMP パケットは本当に測定に大きな影響を与えますか?
A: 通常は微量ですが、1分間隔で定常的にポーリングすると数値精度に影響します。正確な帯域試算では排除が推奨されます。
A: 通常は微量ですが、1分間隔で定常的にポーリングすると数値精度に影響します。正確な帯域試算では排除が推奨されます。
Q: LAN 側ポートの値を使って直接トラフィックを計算してはいけませんか?
A: LAN 側にはプリンタや IP 電話など内部通信も含まれるため、WAN 利用量を求めるには WAN 側を基本にし、SNMP 分だけを補正する必要があります。
A: LAN 側にはプリンタや IP 電話など内部通信も含まれるため、WAN 利用量を求めるには WAN 側を基本にし、SNMP 分だけを補正する必要があります。
Q: SNMP 以外の管理通信(例: Telnet, SSH)でも同じ考え方を適用できますか?
A: はい。測定処理そのものが測定対象に影響を与える場合、別経路で比較・補正するのが一般的です。
A: はい。測定処理そのものが測定対象に影響を与える場合、別経路で比較・補正するのが一般的です。
関連キーワード: SNMP, MIB, オクテットカウンタ, 帯域計測, トラフィック補正
設問3:〔ネットワークの調査〕について、(1)~(5)に答えよ。
(3)本文中の下線③の現象は、何によるものか。15字以内で述べよ。
模範解答
カウンタのけたあふれ
解説
解答の論理構成
-
【問題文】には、トラフィックを求める手順として
「RT2 の … ifInOctets と ifOutOctets のカウンタ値を 1 分間隔で取得し、それぞれの増分を求める」とあります。
これは SNMP の “オクテットカウンタ”をポーリングし、差分で 1 分間の転送バイト数を算出する標準的な方法です。 -
ところが同じ段落に
「③増分が負になることがあるので、その場合には定数を加えて補正する」と記載されています。
正常な通信であれば増分は非負になるはずですが、実際には負値が発生することを示唆しています。 -
ifInOctets/ifOutOctets は RFC1213‐MIB の 32 ビット符号なし整数で実装されることが多く、値の上限は “4 294 967 295” です。
監視間隔より速いペースでデータが転送されこの上限を超えると、カウンタは “0” に戻り再び加算されます。これをカウンタのラップアラウンド(けたあふれ)と呼びます。 -
ラップアラウンドが起こると「前回値 > 今回値」となるため「今回値−前回値」が負数になり、【問題文】の「増分が負になる」現象を説明できます。
-
したがって原因は「カウンタのけたあふれ」であり、模範解答と一致します。
誤りやすいポイント
- 監視間隔の SNMP パケットロスや時計ずれを原因と誤解しやすい。問題文には装置の動作が正常であると明示されています。
- 64 ビットカウンタならラップアラウンドはほぼ無視できますが、多くの装置が 32 ビット実装のままという事実を見落としやすい。
- “符号ビットの解釈間違い”と混同するケース。ifInOctets/ifOutOctets は符号なし整数なので符号の問題ではなく上限超えが本質です。
FAQ
Q: 監視間隔を短くすればラップアラウンドは防げますか?
A: 転送量が少なければ有効ですが、帯域が極端に高い場合は 1 秒間隔でも回避できないことがあります。64 ビットカウンタの利用が確実です。
A: 転送量が少なければ有効ですが、帯域が極端に高い場合は 1 秒間隔でも回避できないことがあります。64 ビットカウンタの利用が確実です。
Q: 定数を加えて補正する方法とは具体的に何ですか?
A: 一般には “2³²” を加算して負の差分を正の値に直します。これが 32 ビット符号なしカウンタの最大値+1です。
A: 一般には “2³²” を加算して負の差分を正の値に直します。これが 32 ビット符号なしカウンタの最大値+1です。
Q: SNMPv2c/SNMPv3 でも同じ問題が起こりますか?
A: MIB オブジェクトが 32 ビット型で実装されている限り発生します。プロトコルバージョンとは無関係です。
A: MIB オブジェクトが 32 ビット型で実装されている限り発生します。プロトコルバージョンとは無関係です。
関連キーワード: SNMP, MIB, 32ビットカウンタ, ラップアラウンド
設問3:〔ネットワークの調査〕について、(1)~(5)に答えよ。
(4)本文中の下線④の原因は何か。TCPの動作に着目して、35字以内で述べよ。
模範解答
パケットの破棄による再送とウインドウサイズの縮小が起こるから
解説
解答の論理構成
- 【問題文】は優先制御の動作として
「入力パケットの量が出力パケットの量を超えると…待ち行列の長さが上限に達すると、次の入力パケットを待ち行列に追加せずに破棄する。」
と述べています。 - 非優先トラフィック(本設問では TCP)では、上記のキューオーバーフロー時にパケットが破棄されます。
- TCP は信頼性を確保するため、破棄(≒損失)を検出すると再送制御を行い、輻輳回避アルゴリズムにより輻輳ウインドウ(cwnd)を縮小します。
- cwnd が小さくなると同一 RTT 内に送れるデータ量が減り、結果としてスループットが低下します。
- したがって、下線④「非優先の通信における TCP の転送速度が端末に低下する」原因は
「パケットの破棄による再送とウインドウサイズの縮小が起こるから」
となります。
誤りやすいポイント
- 「遅延が増すだけで速度が落ちる」と考え、損失と再送を見落とす。
- 優先制御=QoS と結び付け、TCP でなく UDP の例(音声など)を答案に書いてしまう。
- 再送要求 (ACK) が増えることだけを強調し、ウインドウ縮小を忘れる。
FAQ
Q: UDP も同じ優先制御で破棄されますか?
A: 破棄はされますが、UDP は再送・ウインドウ制御を行わないため、単に品質(音切れ等)が悪化するだけでスループット調整は起こりません。
A: 破棄はされますが、UDP は再送・ウインドウ制御を行わないため、単に品質(音切れ等)が悪化するだけでスループット調整は起こりません。
Q: TCP のウインドウ縮小は常に発生しますか?
A: 損失を示す重複 ACK またはタイムアウトが検出された場合に輻輳制御が働き、cwnd が減少します。損失がなければ縮小しません。
A: 損失を示す重複 ACK またはタイムアウトが検出された場合に輻輳制御が働き、cwnd が減少します。損失がなければ縮小しません。
Q: 優先制御を非優先にも適用して救済する手法は?
A: WRED などの早期検出型キュー制御を用い、完全なオーバーフロー前に確率的に破棄して TCP の自己調整を促す方法があります。
A: WRED などの早期検出型キュー制御を用い、完全なオーバーフロー前に確率的に破棄して TCP の自己調整を促す方法があります。
関連キーワード: キューオーバーフロー, TCP輻輳制御, 再送制御, ウインドウ縮小, QoS
設問3:〔ネットワークの調査〕について、(1)~(5)に答えよ。
(5)本文中の下線⑤で想定すべき項目を二つ挙げ、それぞれ20字以内で答えよ。
模範解答
①:動画一つの再生に必要な通信帯域
②:拠点における動画の同時再生数
解説
解答の論理構成
-
前提把握
引用: 「⑤動画表示に必要な通信帯域を IP-VPN の見込余剰帯域以下にするための運用条件を検討すること」
目的は「余剰帯域内に収める」ことであり、余剰帯域≒上限値に対して動画通信量をコントロールする条件を洗い出す必要があります。 -
動画通信量の内訳を因数分解
動画トラフィックは
通信量 = 1本の動画再生に必要な帯域 × 同時再生本数
で表せます。したがって、上限値(余剰帯域)を超えないよう管理するには、
(a) 1本当たりの帯域を把握する
(b) 同時に流れる本数を管理する
という2要素が不可欠です。 -
両要素が“運用条件”に合致する理由
・(a) はコーデック設定や解像度を変更すれば調整できます。
・(b) は教育担当者の時間割やストリーミングサーバ側の接続制御で制限できます。
どちらも「運用」レベルで実施可能で、回線増強などハード変更を伴わずに済むため、O主任の方針「現在のネットワークを変更せずに TC を運用」に合致します。 -
よって想定すべき2項目は
①「動画一つの再生に必要な通信帯域」
②「拠点における動画の同時再生数」
となります。
誤りやすいポイント
- 動画ファイル容量と帯域を混同し、ファイルサイズを答えてしまう。帯域は単位時間当たりのデータ量です。
- 「動画コーデックの種類」を項目に入れるミス。コーデックは帯域を左右する要因ですが、直接的な運用条件は帯域量そのものです。
- 「仮想 PC と TC 間の平均使用帯域 20 kビット/秒」を流用してしまう。動画用セッションは別セッションであり、画面転送帯域とは別管理です。
FAQ
Q: 解像度やフレームレートは考慮不要ですか?
A: それらは最終的に「動画一つの再生に必要な通信帯域」に吸収される要素なので、個別に挙げる必要はありません。
A: それらは最終的に「動画一つの再生に必要な通信帯域」に吸収される要素なので、個別に挙げる必要はありません。
Q: 同時再生数はユーザ数と同義ですか?
A: 教育動画の利用場面を想定すると「同一時刻に再生している端末数」を指し、必ずしも拠点の総ユーザ数とは一致しません。
A: 教育動画の利用場面を想定すると「同一時刻に再生している端末数」を指し、必ずしも拠点の総ユーザ数とは一致しません。
Q: 余剰帯域を超えた場合はどうなりますか?
A: RT の優先制御で非優先トラフィックとなり、動画がコマ落ち・停止する恐れがあるため、事前に同時再生数を制限する運用が必要です。
A: RT の優先制御で非優先トラフィックとなり、動画がコマ落ち・停止する恐れがあるため、事前に同時再生数を制限する運用が必要です。
関連キーワード: 帯域計算, 同時接続数, トラフィック制御, コーデック, ストリーミング


