ネットワークスペシャリスト 2010年 午後1 問02
ネットワークの評価に関する次の記述を読んで、設問1~3に答えよ。
Z社では、家電製品・OA機器の故障品の受付、修理及び修理完了品の返送の業務をメーカから受託している。Z社の本社は東京にあり、修理業務は、仙台拠点と横浜拠点で行っている。両拠点への業務委託元及び取扱製品は異なるが、業務内容や作業量に大差がなく、ネットワークの使用状況もほぼ同じである。また、各拠点ではZ社の社員のほかに、派遣社員やパートタイマが作業員として勤務している。
本社に設置されている業務管理サーバ(以下、業務管理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)に答えよ。
問題文を見る模範解答
新たに発生する通信:
・仮想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
解説
解答の導き方
設問文には「ポートで受信又は送信した総バイト数を表すifInOctetsとifOutOctetsのカウンタ値を1分間隔で取得し、それぞれの増分を求める」とあり、ここで得られる増分は「1分間に送受信したバイト数(Δ バイト)」であることが分かります。増分 Δ(単位:バイト)を「1分間ごとの平均値(単位:kビット/秒)」に変換するための係数が b です。変換の手順を段階的に示します。
- バイトをビットに変換する:1バイト = 8ビットなので、ビット数は 。
- 1分間(60秒)のビット数を秒当たりに直す:(ビット/秒)。
- kビットにする(問題で求める単位はkビット/秒):1 kbit = 1,000 bitなので、さらに 。
以上をまとめると単位変換の式は
となります。これを「増分 Δ を何で割ればよいか」の形にすると、割るべき値 は
です。数値計算すると
。
したがって、b は7,500です。
(実務上の注意:本文にもあるとおり「増分が負になることがあるので、その場合には定数を加えて補正する」処理が必要です。これはカウンタのラップアラウンド対策です。)
誤りやすいポイント
- バイト/ビットの換算を忘れる(8を掛ける/割るを間違える)。増分がバイト単位である点を必ず確認すること。
- 時間の単位変換を忘れる(1分間の値を秒当たりに直すために60で割る必要がある)。
- 「k」を1,024と誤用する(ここではkbit = 1,000 bitを用いる)。
- 演算の順序や「係数」を誤って記述する(正しくは を割る)。
- 取得間隔(ポーリング間隔)を問題文の1分(60秒)ではなく別の値で扱ってしまうと除数が変わる点。
- カウンタのラップアラウンドにより増分が負になるケースの補正を忘れると誤った値になる。
FAQ
Q: 取得間隔が30秒なら b はどうなりますか?
A: 手順は同じで、時間を30秒に置き換えます。
。
よって30秒間隔なら除数は3,750になります。
A: 手順は同じで、時間を30秒に置き換えます。
。
よって30秒間隔なら除数は3,750になります。
Q: なぜ1,000で割るのですか?1024ではないのですか?
A: 帯域(kビット/秒)の表記では慣例的に1 kbit = 1,000 bitを使います。問題文の単位表記「kビット/秒」に従い1,000を用いるのが正解です。
A: 帯域(kビット/秒)の表記では慣例的に1 kbit = 1,000 bitを使います。問題文の単位表記「kビット/秒」に従い1,000を用いるのが正解です。
Q: 増分が負になったときに「定数を加えて補正」するとは具体的にどうするのですか?
A: これはカウンタのラップアラウンド(オーバーフロー)への対応です。カウンタのビット幅に応じて定数を加えます(例:32ビットカウンタなら を加える等)。問題文では補正が必要であることだけ示しているので、「増分が負なら所定の定数を加えて正の増分に戻す」処理を行えばよいです。
A: これはカウンタのラップアラウンド(オーバーフロー)への対応です。カウンタのビット幅に応じて定数を加えます(例:32ビットカウンタなら を加える等)。問題文では補正が必要であることだけ示しているので、「増分が負なら所定の定数を加えて正の増分に戻す」処理を行えばよいです。
関連キーワード: SNMP、ポーリング間隔、バイト→ビット変換、カウンタラップアラウンド、帯域単位換算
設問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の優先制御で非優先トラフィックとなり、動画がコマ落ち・停止する恐れがあるため、事前に同時再生数を制限する運用が必要です。
関連キーワード: 帯域計算, 同時接続数, トラフィック制御, コーデック, ストリーミング




