ネットワークスペシャリスト 2009年 午後1 問03
eラーニングシステムの増強に関する次の記述を読んで、設問1〜3に答えよ。
H社では、社員の業務スキル向上のために、PCのブラウザから利用できるeラーニングシステム(以下、eシステムという)を導入して、一部の部署で活用してきた。その結果、eシステムの活用効果を確認できたので、研修コースを拡充して全社に展開することにした。各コースのコンテンツは、文字、図表、音声及び動画を使って作成されている。eシステムは、全社員が利用することになるので、eシステムのサーバ(以下、eSVRという)を複数台の構成にして、負荷分散装置(以下、LBという)で処理を振り分けることにした。H社のネットワーク構成を、図に示す。本社と営業所のネットワークのIPアドレスは、サブネットを設定せず、それぞれクラスAとクラスBが用いられている。


〔増強するeシステムの構成〕
eシステムの増強は、情報システム部のP君が担当することになった。P君は、eシステムの利用者数と、ベンダから入手したパフォーマンスに関する仕様を基に、eSVRとLBの機種を選定した。また、コンテンツと管理情報の一元管理のために、ファイルサーバも併せて導入することにした。
選定したLBは、(i)処理の振分け機能、(ii)ア維持機能、(iii)ヘルスチェック機能ももっている。(i)には、様々な方式がある。eシステムの応答時間は、eSVRの負荷の増加とともに長くなると考えられたので、応答時間が最短のeSVRに処理を振り分ける方式を採用することにした。(ii)には、リクエスト元のIPアドレスに基づいて行うレイヤ3方式や、Webページにアクセスしたユーザに関する情報を保持するイに埋め込まれ、セッションIDに基づいて行うレイヤ7方式などがある。eシステムを利用するPCには、IPアドレスが固定設定されているので、レイヤ3方式を利用することにした。(iii)には、レイヤ3、レイヤ4及びレイヤ7の各レイヤで稼働状況を監視する方式がある。eシステムのサービスポートの稼働状況を監視するために、レイヤ4方式を利用することにした。
LBの故障時に、ネットワーク構成を変更しなくてもシステムの運用が継続できるように、LBとeSVRは、図の構成で設置することにした。PCからのeシステム利用には、社内のPCを三つのブロックに分け、各ブロックのPCごとに、異なったeSVRのホスト名を指定させる。DNSで、三つのホスト名に一つのVIPを対応付けることによって、LB経由でeSVRに接続できる。このように、eSVRのホスト名を使い分けることで、LBの故障時にも①DNSの設定変更によって、3台のeSVRに処理を振り分けることができる。選定したLBには、PCからVIPあてに送信されたパケットの、送信元IPアドレスをLBの実アドレスに変換してeSVRに転送する、ソースNAT機能がある。ソースNAT機能を利用すると、既設eSVRのネットワーク情報の設定変更が不要になる。しかし、②管理上必要な情報が、eSVRのログから取得できなくなってしまう問題があるので、ソースNAT機能は利用しないことにした。
〔eシステムの増強〕
まず、P君は、検証環境で動作テスト実施済の2台のeSVRと1台のファイルサーバを、本社のLANに接続して、3台のeSVRに必要な情報を設定した。その後で、あらかじめ作業を依頼していた営業所のY君とともに、PC-x1とPC-y1から各eSVRにpingコマンドを発行し、正常応答を確認した。次に、PC-x1とPC-y1から各eSVRに接続して、システムが正常に利用できることを確認した。eシステムが利用できたので、P君はLBを本社のLANに接続して、DNSとLBに必要な情報を設定した。Y君にPC-y1からLB経由でeシステムを利用してもらったところ、eシステムの開始画面がPC-y1に表示されず、eシステムが利用できなかった。P君は、障害の原因究明のために、本社のLANにトラフィックモニタを接続して、通信データを収集した。収集した通信データのフレームの中から抽出した、eシステム接続に関連するフレームのアドレス情報を、表1に示す。
収集したフレームのアドレス情報から、eSVR1からPC-y1にパケットが返送されているにもかかわらず、③ PC-y1で処理が継続されないという問題が発見できた。P君は、各eSVRのネットワーク設定情報の設定間違いが原因と判断し、設定情報を変更したところ、PC-y1からeシステムが利用できるようになった。P君は、営業所からLB経由でeシステムが利用できれば、本社のPC-x1からも問題なく利用できると考えていたが、PC-x1からのeシステム利用でも、PC-y1と同様の障害が発生してしまった。再度、トラフィックモニタで通信データを収集した。eSVR1から返送されたフレームのアドレス情報は表2のとおりであり、変更が不十分であったことが判明した。P君は、各eSVRのネットワーク設定情報を追加変更して障害を解決した。
〔eシステムの運用〕
eシステムの増強が完了したので、eシステムの本格運用を開始した。eシステムの利用拡大によって、配信される音声が聞き取りにくいとか、動画が頻繁に停止するというクレームが多発するようになった。eSVRの性能やLANとWANの帯域には問題ないと判断できたので、P君はLBが原因ではないかと考え、LBベンダの技術者に対応策について相談した。LBベンダの技術者から、LBの最新ファームウェアには、eSVRから返送されたパケットを直接PCに送信できるようにする機能(以下、DSR (Direct Server Return) という) が追加されていて、eシステムではDSRを利用できる構成なので、DSRを機能させればクレームに対処できるとの助言を受けた。
DSRを有効に機能させるためには、各eSVRにループバックインタフェースを追加設定する必要がある。DSRを機能させると、LBはPCから受信したパケットに変更を加えないで、eSVRあてに転送する。eSVRが受信したパケットのあて先IPアドレスが、ループバックインタフェースに設定されたIPアドレスと同じとき、このIPアドレスがeSVR自身のものとして、eSVRから返送されるパケットに使われる。この結果、LBを経由させなくてもPCとの間で処理が継続できることになる。
P君は、LBベンダの技術者から得たこれらの情報を基に、LBのファームウェアをバージョンアップし、LBとeSVRの関連する情報を設定、変更して、問題を解決することができた。その後、eシステムの稼働は安定し、活用は更に促進された。
設問1:〔増強するeシステムの構成〕について、(1)~(4)に答えよ。
問題文を見る(1)本文中の ア、イ に入れる適切な字句を答えよ。
模範解答
ア:セッション
イ:Cookie
解説
解答の論理構成
-
問題文の該当箇所を確認
- 「選定したLBは、(i)処理の振分け機能、(ii)【引用】“ア維持機能”【引用終わり】、(iii)ヘルスチェック機能ももっている。」
- 「(ii)には、リクエスト元のIPアドレスに基づいて行うレイヤ3方式や、Webページにアクセスしたユーザに関する情報を保持する【引用】“イに埋め込まれ、セッションIDに基づいて行うレイヤ7方式”【引用終わり】などがある。」
-
文脈から欠落語を推定
- (ii)は“○○維持機能”と表現され、続く説明で「セッションIDに基づいて行う」とある。ここから「○○」に入るべき語は、通信をユーザ単位で継続させる“セッション”が適切。
- レイヤ7の方式説明では「ユーザに関する情報を保持する」要素が“イに埋め込まれ”とある。HTTPでユーザ情報とセッションIDを保持する代表的な仕組みはCookieである。
-
他の選択肢の排除
- “コネクション維持機能”“ステート維持機能”なども耳慣れ語だが、直後で「セッションID」に言及しているため、最も整合するのは“セッション維持機能”。
- “ヘッダ”“URLパラメタ”もユーザ情報を含められるが、問題文が示す「埋め込まれ」「セッションIDに基づいて行う」典型例はCookieである。
-
以上より
- ア=「セッション」
- イ=「Cookie」
誤りやすいポイント
- “コネクション”と“セッション”の混同
TCPのコネクションとアプリケーションのセッションは層が異なる。負荷分散装置で維持したいのは、HTTPアプリケーション層のセッション。 - URLリライト方式との取り違え
URLパラメタにセッションIDを付加する方法もあるが、問題文は「埋め込まれ」という表現でCookieを暗示している。 - レイヤ番号の先入観
「レイヤ3方式」と「レイヤ7方式」が対になっているため、後者を“アプリケーションヘッダ”と早合点しがち。説明文を読むと“ユーザ情報を保持するCookie”であることが明白。
FAQ
Q: セッション維持機能がないと具体的にどんな問題が起こるのですか?
A: 同一ユーザの一連のリクエストが毎回別のeSVRに振り分けられ、サーバ側で保持している学習進捗やログイン状態が失われます。
A: 同一ユーザの一連のリクエストが毎回別のeSVRに振り分けられ、サーバ側で保持している学習進捗やログイン状態が失われます。
Q: Cookie以外にセッションIDを保持する方法はありますか?
A: あります。URL書き換えや隠しフィールドなども使えますが、一般的なWebアプリではCookieが最も広く採用されています。
A: あります。URL書き換えや隠しフィールドなども使えますが、一般的なWebアプリではCookieが最も広く採用されています。
Q: レイヤ3方式とレイヤ7方式は同時に使えますか?
A: 多くの負荷分散装置は設定によって併用可能ですが、セッション維持ポリシーが競合しないよう注意が必要です。
A: 多くの負荷分散装置は設定によって併用可能ですが、セッション維持ポリシーが競合しないよう注意が必要です。
関連キーワード: 負荷分散, レイヤ3, レイヤ7, セッションID, Cookie
設問1:〔増強するeシステムの構成〕について、(1)~(4)に答えよ。
問題文を見る(2)利用予定の稼働監視では、eシステムの稼働状況を、どのような方法で監視するか。30字以内で具体的に述べよ。
模範解答
監視対象のポートに対して、コネクションの確立を試みる。
解説
解答の論理構成
- 【問題文】には、LBのヘルスチェックについて「(iii)には、レイヤ3、レイヤ4及びレイヤ7の各レイヤで稼働状況を監視する方式がある。eシステムのサービスポートの稼働状況を監視するために、レイヤ4方式を利用することにした。」と記載されています。
- 「レイヤ4方式」はTCP/UDPのポート番号を使って通信可能かを確認する仕組みであり、実際にはサービス用ポートに対して接続要求(SYNなど)を送り、応答が得られるかで稼働可否を判断します。
- したがって、稼働監視における監視方法は「監視対象ポートへのコネクション確立試行」であると導けます。
誤りやすいポイント
- ICMPのping送信(レイヤ3)と混同しやすい点。問題文は「レイヤ4方式」を明示しており、ポート疎通が求められます。
- HTTP GETなどアプリケーション要求(レイヤ7)と誤解するパターン。今回はポートレベルで十分です。
- 「ログ監視」「SNMPポーリング」など管理系プロトコルを連想してしまうミス。設問は稼働監視方法を具体的に尋ねています。
FAQ
Q: なぜICMPではなくポート監視なのですか?
A: ICMPの応答があってもアプリケーションポートが停止している可能性があります。レイヤ4方式ならサービスが待ち受けているかを直接確認できます。
A: ICMPの応答があってもアプリケーションポートが停止している可能性があります。レイヤ4方式ならサービスが待ち受けているかを直接確認できます。
Q: TCPとUDPどちらで監視するのですか?
A: eシステムはWebベースと読み取れるため、一般的にはTCPの待ち受けポート(例えば80や443)へのコネクションを試みます。
A: eシステムはWebベースと読み取れるため、一般的にはTCPの待ち受けポート(例えば80や443)へのコネクションを試みます。
Q: レイヤ7監視にしないメリットは?
A: パケット負荷と設定項目が少なく、応答時間も小さいため、簡易かつ高速に稼働有無を判定できます。
A: パケット負荷と設定項目が少なく、応答時間も小さいため、簡易かつ高速に稼働有無を判定できます。
関連キーワード: ポート監視, レイヤ4, ヘルスチェック, TCPコネクション, サービス稼働確認
設問1:〔増強するeシステムの構成〕について、(1)~(4)に答えよ。
問題文を見る(3)本文中の下線①の設定変更の内容を、35字以内で述べよ。
模範解答
三つのホスト名に、それぞれ3台のサーバのIPアドレスを設定する。
解説
解答の論理構成
-
①の位置を確認
本文には
「“このように、eSVRのホスト名を使い分けることで、LBの故障時にも ①DNSの設定変更 によって、3台のeSVRに処理を振り分けることができる。”」
とあります。LBが停止するとVIPが機能しなくなるため、DNSだけで直接各eSVRに接続させる狙いです。 -
通常時のDNS設定
直前には
「“DNSで、三つのホスト名に一つのVIPを対応付ける”」
とあり、平常時は “三つのホスト名 → VIP(10.10.0.1)” という1対多関係で登録していると分かります。 -
LB故障時の問題点と対策
VIPが応答しない以上、PCはeSVRの“実アドレス”へ名前解決できなければなりません。そこで
「“3台のeSVR”」それぞれのIP(「10.10.10.1~10.10.10.3」)を、対応する三つのホスト名に割り当て直す必要があります。 -
具体的な設定変更内容
・ホスト名A → 「10.10.10.1」
・ホスト名B → 「10.10.10.2」
・ホスト名C → 「10.10.10.3」
という形で「三つのホスト名」に「3台」のIPを一対一に登録し直せば、各PCはDNSだけでeSVRに接続できます。 -
以上より、模範解答の
「三つのホスト名に、それぞれ3台のサーバのIPアドレスを設定する。」
が導かれます。
誤りやすいポイント
- VIPを複数登録すると勘違いし、「ホスト名ごとにVIPを複数設定」と答えてしまう。故障時はVIPが使えない点を見落としています。
- 「ラウンドロビン登録」とだけ書き、具体的に“3台のeSVRのIP”を示さない。設問はあくまでDNSレコードの変更内容を問うています。
- “三つのDNSサーバを用意”など、物理機器の増設と混同する誤答。あくまでレコード変更のみです。
FAQ
Q: LBの故障回避策なら、予備LBを用意するほうが確実では?
A: 冗長化LBを導入する方法もありますが、コストや工程を抑えたい場合、DNS切替は手軽なバックアップ手段として採用されます。
A: 冗長化LBを導入する方法もありますが、コストや工程を抑えたい場合、DNS切替は手軽なバックアップ手段として採用されます。
Q: “三つのホスト名”をわざわざ分ける理由は?
A: 社内PCを三つのブロックに分けているため、障害時に一斉アクセスが集中せず、負荷を均等化できます。
A: 社内PCを三つのブロックに分けているため、障害時に一斉アクセスが集中せず、負荷を均等化できます。
Q: VIP登録時と直接IP登録時でTTLを変えるべきですか?
A: LB稼働時はキャッシュ効率を優先して長め、障害発生時は即時反映のため短めに設定する運用が一般的です。
A: LB稼働時はキャッシュ効率を優先して長め、障害発生時は即時反映のため短めに設定する運用が一般的です。
関連キーワード: DNSレコード, 負荷分散, VIP, 冗長化, フェイルオーバー
設問1:〔増強するeシステムの構成〕について、(1)~(4)に答えよ。
問題文を見る(4)本文中の下線②の取得できなくなる情報を、20字以内で述べよ。
模範解答
サーバに接続したPCのIPアドレス
解説
解答の論理構成
-
②で問題視されているのは、LBの“ソースNAT機能”を使用した場合にeSVRのログから取得できなくなる情報です。
引用:
・「選定したLBには、PCからVIPあてに送信されたパケットの、送信元IPアドレスをLBの実アドレスに変換してeSVRに転送する、ソースNAT機能がある。」
・「②管理上必要な情報が、eSVRのログから取得できなくなってしまう問題があるので、ソースNAT機能は利用しないことにした。」 -
ソースNATを適用すると、パケットの送信元IPが“PCの実IP”から“LBの実IP”へ書き換わり、eSVR側ではすべてのアクセス元がLBであるかのように見えます。
→ したがってeSVRのアクセスログに残らなくなるのは「本来のPCのIPアドレス」です。 -
PCのIPアドレスが取得できないと、利用状況の解析や不正アクセス調査といった“管理上必要な”作業が不可能になります。
-
以上より、下線②の答えは
サーバに接続したPCのIPアドレス
誤りやすいポイント
- 「ログに残らないのはMACアドレスか?」と誤解するケース
→ ソースNATで書き換えられるのはIP層。MACはセグメントごとに再付与されるため、本質的な問題はIP。 - 「LBのIPアドレスが取得できなくなる」と読み違えるケース
→ 逆で、LBのIPしか見えなくなる。失われるのは元々のPCのIP。 - 「セッションIDが失われる」と連想するケース
→ それはイのレイヤ7の話題であり、②とは無関係。
FAQ
Q: ソースNATを無効にすると設定変更が必要になるのはなぜですか?
A: eSVRからPCへの戻りトラフィックがLBを経由するよう、ルーティングやARPの調整が必要になるためです。
A: eSVRからPCへの戻りトラフィックがLBを経由するよう、ルーティングやARPの調整が必要になるためです。
Q: LBでNATせずにロードバランスする一般的な方法は?
A: IPヘッダを書き換えずL2転送だけを行い、戻りトラフィックはeSVRから直接PCへ流すDSR(Direct Server Return)方式などがあります。
A: IPヘッダを書き換えずL2転送だけを行い、戻りトラフィックはeSVRから直接PCへ流すDSR(Direct Server Return)方式などがあります。
Q: 監査ログで取得できないと困る場面は?
A: アクセス元の追跡、不正操作の証跡確保、利用状況の統計分析などが行えなくなります。
A: アクセス元の追跡、不正操作の証跡確保、利用状況の統計分析などが行えなくなります。
関連キーワード: ソースNAT, アクセスログ, 送信元IP, ロードバランサ, ルーティング
設問2:〔eシステムの増強〕について、(1)~(3)に答えよ。
問題文を見る模範解答
a:HRTMAC
b:LBMAC
c:SVR1MAC
d:172.16.0.1
解説
解答の論理構成
-
フレーム①(表1の項番1)
- 送信元はIP-VPNを抜けて本社LANに入ってきたルータ1。
- 図中の機器一覧で「ルータ1 | HRTMAC | 10.10.16.1」と明示。
- 宛先はVIP「10.10.0.1」を持つLB。
- 同じく「LB | LBMAC | 10.10.0.1 | VIP」。
- よって
- a = HRTMAC
- b = LBMAC
- 送信元はIP-VPNを抜けて本社LANに入ってきたルータ1。
-
フレーム②(表1の項番2)
- LBからeSVR1へ転送するフレーム。
- 「ソースNAT機能は利用しないことにした。」と【問題文】にあるため、送信元IPはPC-y1のまま変化しない。
- PC-y1のIPは 図の「PC-y1 | PCy1MAC | 172.16.0.1」。
- 宛先MACはeSVR1。図で「eSVR1 | SVR1MAC | 10.10.10.1」。
- よって
- c = SVR1MAC
- d = 172.16.0.1
-
フレーム③(表1の項番3)は設問対象外だが整合確認
- 送信元MAC=SVR1MAC、宛先MAC=HRTMAC
- 送信元IP=10.10.10.1、宛先IP=172.16.0.1
- ②で保持した送信元IPがPC-y1まで届くためログ取得も可能 ― 設計方針と合致。
誤りやすいポイント
- 「ソースNAT機能がある」→「利用しない」の読み落としで d を 10.10.0.1 と誤答。
- IPとMACを混同し、b をVIP「10.10.0.1」と書いてしまう。VIPはIP; フレーム宛先はMAC。
- ルータ1・LBが同一セグメントにあるイメージをもてず、a にPCy1MACを入れてしまう。IP-VPN越しのPC-y1のMACは本社LANに現れない。
FAQ
Q: ルータ1とLBはどうやってお互いのMACアドレスを知るのですか?
A: VIP「10.10.0.1」宛てARP要求をルータ1が送信し、LBが応答することで LBMAC を学習します。
A: VIP「10.10.0.1」宛てARP要求をルータ1が送信し、LBが応答することで LBMAC を学習します。
Q: なぜLB → eSVR1のフレームで送信元IPが変わらないのですか?
A: 【問題文】で「ソースNAT機能は利用しない」と明示されているため、LBはL3/IPアドレスを書き換えません。
A: 【問題文】で「ソースNAT機能は利用しない」と明示されているため、LBはL3/IPアドレスを書き換えません。
Q: フレーム③で宛先MACがHRTMACなのはなぜ?
A: eSVR1がPC-y1(172.16.0.1)宛てIPパケットを送る際、デフォルトゲートウェイ=ルータ1(10.10.16.1)へ転送するため、宛先MACは HRTMAC になります。
A: eSVR1がPC-y1(172.16.0.1)宛てIPパケットを送る際、デフォルトゲートウェイ=ルータ1(10.10.16.1)へ転送するため、宛先MACは HRTMAC になります。
関連キーワード: 負荷分散, VIP, ARP, ソースNAT, ルーティング
設問2:〔eシステムの増強〕について、(1)~(3)に答えよ。
問題文を見る(2)本文中の下線③の原因を、受信したパケットに着目して、30字以内で述べよ。
模範解答
通信相手でないサーバからのパケットを受信したこと
解説
解答の論理構成
- PC‐y1が送信したパケット
表1項番1
─ 送信元IPアドレス「172.16.0.1」
─ あて先IPアドレス「10.10.0.1」
ここでPC‐y1は “通信相手=VIPを持つLB” だと認識します。 - LBがパケットをeSVR1へ転送
表1項番2に示すように、LBはソースNATを行わず送信元IPアドレスを「172.16.0.1」のままeSVR1に届けます。 - eSVR1からの返送パケット
表1項番3
─ 送信元IPアドレス「10.10.10.1」
─ あて先IPアドレス「172.16.0.1」
返答元はLBではなくeSVR1そのものです。 - 下線③「PC-y1で処理が継続されない」理由
TCPセッションは “要求を送った相手” から戻りパケットが来ることを前提とします。ところがPC‐y1は「10.10.0.1」へ接続中なのに、実際に受信したパケットの送信元は「10.10.10.1」です。通信相手と一致しないためOSはパケットを破棄し、セッションが成立しません。 - よって原因は
「通信相手でないサーバからのパケットを受信したこと」となります。
誤りやすいポイント
- 「MACアドレスの不一致」が原因と早合点する
→ IP層での “想定相手” の違いが本質です。 - 「ルーティング設定の誤り」と考える
→ 経路自体は存在し返送パケットは届いているため、経路障害ではありません。 - 「LBがレスポンスを返さない」と決め付ける
→ LBではなくeSVR1が直接返している点を見落とさないことが重要です。
FAQ
Q: ソースNATを使えば今回の障害は起きませんか?
A: はい。LBが送信元IPアドレスを書き換えてeSVRへ渡し、戻りもLBから返せばPCは常に「10.10.0.1」と通信するだけなので問題は発生しません。ただし本文で述べられた「②管理上必要な情報」が失われます。
A: はい。LBが送信元IPアドレスを書き換えてeSVRへ渡し、戻りもLBから返せばPCは常に「10.10.0.1」と通信するだけなので問題は発生しません。ただし本文で述べられた「②管理上必要な情報」が失われます。
Q: なぜeSVR1は直接PCに返送したのですか?
A: LBがソースNATを行わず“転送のみ”だったため、eSVR1のルーティングテーブルに従って最短経路(ルータ1経由)でPC‐y1へ送った結果です。
A: LBがソースNATを行わず“転送のみ”だったため、eSVR1のルーティングテーブルに従って最短経路(ルータ1経由)でPC‐y1へ送った結果です。
Q: このような現象を防ぐ他の方法はありますか?
A: 「DSR」「対向アドレス書き換え」「ポリシーベースルーティング」など複数ありますが、いずれもログ取得や可用性とのトレードオフが生じるため要件に応じた選択が必要です。
A: 「DSR」「対向アドレス書き換え」「ポリシーベースルーティング」など複数ありますが、いずれもログ取得や可用性とのトレードオフが生じるため要件に応じた選択が必要です。
関連キーワード: VIP, NAT, TCP, ルーティング, 負荷分散
設問2:〔eシステムの増強〕について、(1)~(3)に答えよ。
問題文を見る(3)二度目の障害の対策として変更した、eSVRのネットワーク情報を、10字以内で答えよ。
模範解答
サブネットマスク
解説
解答の導き方
設問は「二度目の障害の対策として変更した、eSVRのネットワーク情報」を問うています。表に示されたフレーム情報と図のアドレス表から、どの設定を変えれば問題が解決したかを順を追って示します。
-
正常に動作させるために必要な前提
eシステムでは「ソースNAT機能は利用しないことにした」と記載されています。ソースNATを使わない場合、クライアント(PC)がVIP(10.10.0.1)へ接続し、LBがそのままクライアントの送信元IPを保持してeSVRに転送すると、eSVRの応答はLBを経由してクライアントへ戻るか(LB側での処理が必要)、あるいはDSRなどの専用構成で直接返す必要があります。初期状態ではDSRは有効化されておらず、したがって通常はeSVRの応答がLB経由で返ることが期待されます。 -
- 表1(項番3)において、eSVR1からのフレームは「送信元IPアドレス10.10.10.1あて先IPアドレス172.16.0.1」で送出されています。あて先MACがHRTMAC(図01の表でルータ1のMAC)になっていることは、eSVR1がこの宛先をルータへ送る(=ルーティング経由で送る)ように振る舞っていることを示します。これは最初の障害調査で判った挙動です。
- 表2を見ると、eSVR1からの返送フレームは「送信元IPアドレス10.10.10.1あて先IPアドレス10.128.1.1」で、かつあて先MACがPCx1MACになっています(表2)。この事実は、eSVR1が10.128.1.1(PC-x1)を同一のローカル・セグメント上にあると判断し、ARPでPCx1のMACを解決して直接送信しようとしたことを意味します。
-
なぜ「サブネットマスク」が原因か
- ホストがある宛先IPを「同一サブネットか否か」を判定する際はサブネットマスクを用います。サブネットマスクの設定次第で「10.10.10.1」と「10.128.1.1」を同一サブネットと見なすか否かが決まります。
- 図01では「本社のネットワーク10.0.0.0/8」と「eSVRのIPアドレス範囲10.10.10.1~10.10.10.3」が示されています。もしeSVRに誤ってクラスフルなマスク(例えば255.0.0.0)など広いマスクが設定されていると、eSVRは10.128.1.1を自分と同一サブネットだと判断して直接送信を試みます(表2の状況)。その結果、LBを経由せず応答が直接クライアントへ向かい、LB側の処理やセッション管理と整合せず接続継続ができなくなります。
- したがって、eSVR側で「ネットワーク長を正しく狭く指定する」、つまりeSVRが属する実際のサブネット(例えば10.10.10.0/24)に合うようにサブネットマスクを修正すれば、eSVRは10.128.1.1を異なるサブネットと判断してデフォルトゲートウェイ(図01の表にある同一サブネット内の適切なゲートウェイアドレス、例えば10.10.10.128等)へ送るようになり、応答がLB経由で正しく返るようになります。
以上の論理から、二度目の障害の対策として変更したのは「サブネットマスク」です。
誤りやすいポイント
- 表2のあて先MACがPCx1MACであることを見て「物理的にMACアドレスが重複している」と誤判断する。実際にはeSVRが宛先を同一サブネットと判断したために直接送ろうとした結果である。
- サブネットマスクではなく最初からデフォルトゲートウェイだけを疑う。今回の事象は第1の障害でゲートウェイの設定修正が有効だった可能性はあるが、第2の障害はマスク誤設定が主因である点を区別する必要がある。
- 「単にLBの設定(ソースNAT)を有効にすれば良い」と考える。確かにソースNATで回避は可能だが、要件でソースNATを使わない運用にしているため不適切である。
- 図にあるルータのIP(例えば10.10.16.1)と、eSVRの所属サブネット(10.10.10.0系)の整合を確認せずに誤ったゲートウェイ推定をすること。
FAQ
Q: なぜサブネットマスクを変えるとMAC宛先の振る舞いが変わるのですか?
A: ホストは宛先IPが同一サブネットかどうかをサブネットマスクで判定し、同一サブネットならARPで直接MACを調べて送信、異なればデフォルトゲートウェイへ送ります。したがってマスクを変えると「同一サブネット判定」が変わり、L2の宛先(MAC)決定が変わります。
A: ホストは宛先IPが同一サブネットかどうかをサブネットマスクで判定し、同一サブネットならARPで直接MACを調べて送信、異なればデフォルトゲートウェイへ送ります。したがってマスクを変えると「同一サブネット判定」が変わり、L2の宛先(MAC)決定が変わります。
Q: デフォルトゲートウェイだけ直せばよくないですか?
A: 第1の症状(PC-y1への応答が期待通り返らない)はゲートウェイ設定の問題でも起きますが、PC-x1(同一本社内)のようにeSVRが宛先を「同一サブネット」と誤判断する場合はゲートウェイを変えても直接送信しようとするため根本解決になりません。両方を整合させる必要があります。
A: 第1の症状(PC-y1への応答が期待通り返らない)はゲートウェイ設定の問題でも起きますが、PC-x1(同一本社内)のようにeSVRが宛先を「同一サブネット」と誤判断する場合はゲートウェイを変えても直接送信しようとするため根本解決になりません。両方を整合させる必要があります。
Q: 具体的にどのマスクにすればよいですか?
A: eSVRのIP範囲が10.10.10.1~10.10.10.3と明示されているので、一般には /24(255.255.255.0)など、10.10.10.0を正しいインタフェースサブネットとするマスクを設定します。
A: eSVRのIP範囲が10.10.10.1~10.10.10.3と明示されているので、一般には /24(255.255.255.0)など、10.10.10.0を正しいインタフェースサブネットとするマスクを設定します。
関連キーワード: サブネットマスク、デフォルトゲートウェイ、ARP、ロードバランサ、DSR
設問3:〔eシステムの運用〕について、(1)、(2)に答えよ。
問題文を見る(1)LBによって引き起こされたクレームの発生原因を、パケットが通信されたときの状態に着目して、35字以内で述べよ。
模範解答
・LBでの、PCあてのパケットのロスによる再送などに起因する転送遅延
・LBの負荷によるeSVRから返送されたパケットの転送遅延
解説
解答の導き方
まず事象を整理します。事例文には「配信される音声が聞き取りにくいとか、動画が頻繁に停止するというクレームが多発するようになった」とあり、これは配信に必要なパケットが時間通り届かない(損失や遅延が発生している)ことを示します。次に切り分けとして、事例文に「eSVRの性能やLANとWANの帯域には問題ないと判断できたので」とあるため、サーバ性能や回線帯域が原因ではないとされています。さらにベンダの助言で「DSRを機能させればクレームに対処できる」とあることから、LBが返送パケット(eSVR→PC)の経路または処理で影響を与えていると読み取れます。
DSRの説明から分かる点は、DSRを有効にすると返送パケットがLBを経由せずPCへ直接届くようになり、これで問題が改善するということは、現状では返送パケットがLBを経由しており、その経路やLBの処理がボトルネックになっているということです。具体的にLBが引き起こし得る現象をパケットの観点で整理すると次の2つが考えられます。
- LBで返送パケットが破棄・欠落すると、TCPであれば再送が発生して配信遅延が増大し、音声の途切れや動画の停止につながる。
- LBが返送トラフィックを処理する際にキューイングやスロットリング(負荷制限)を行うと、返送パケットの到達が遅延しストリーミング再生に影響する。
以上の流れで、LBの返送側の損失や遅延がクレームの直接原因であると導けます。したがって本問で求める記述は、返送パケットの「損失による再送等の遅延」と「LBの負荷によるeSVRから返送されたパケットの転送遅延」の2点に要約できます。
誤りやすいポイント
- HTTPがステートレスだから問題にならないと断定する(事例文にその前提は無い)。
- 問題を回線帯域不足に結びつける(事例文で帯域に問題がないとされている)。
- DSRは全ての経路問題を自動的に解決すると誤解する(DSRは返送パスの回避に効果があるが、他の要因は別途確認が必要)。
- VIPと各eSVRの「実アドレス」を混同する(返送パケットの送出元IP/MACの識別を誤ると原因切り分けを誤る)。
- 送信方向(PC→eSVR)と返送方向(eSVR→PC)を取り違えると対策を誤る。
FAQ
Q: DSRを有効にするとLBのどの負荷が下がるのですか?
A: 返送パケットをLBが中継しなくなるため、LBの出力処理と帯域・CPU負荷が低減し、返送側での遅延や損失を回避できます。
A: 返送パケットをLBが中継しなくなるため、LBの出力処理と帯域・CPU負荷が低減し、返送側での遅延や損失を回避できます。
Q: 音声や動画に対する「再送」はどう影響しますか?
A: TCPの場合はパケット損失で再送が発生して到達遅延が増え、再生バッファが枯渇して途切れます。UDPなら再送がないため損失そのものが直接音声・映像の欠落を生みます。
A: TCPの場合はパケット損失で再送が発生して到達遅延が増え、再生バッファが枯渇して途切れます。UDPなら再送がないため損失そのものが直接音声・映像の欠落を生みます。
Q: LBが原因かどうかを確認する簡単な方法は?
A: サーバ側とクライアント側でパケットキャプチャを取り、返送パケットのイーサネットヘッダにLBのMACアドレスが入っているか、返送経路がLB経由になっているかを比較します。
A: サーバ側とクライアント側でパケットキャプチャを取り、返送パケットのイーサネットヘッダにLBのMACアドレスが入っているか、返送経路がLB経由になっているかを比較します。
関連キーワード: DSR、ロードバランサ、パケットロス、再送、転送遅延
設問3:〔eシステムの運用〕について、(1)、(2)に答えよ。
問題文を見る(2)DSRを機能させた場合に、eSVRから返送されるフレームは、表2中のアドレス情報がどのように変わったものになるかを、30字以内で述べよ。ただし、PC-x1からのeシステムの利用は、eSVR1に振り分けられたものとする。
模範解答
送信元IPアドレスが、仮想IPアドレスに変わったもの
解説
解答の論理構成
- 表2の返送フレームは
送信元IPアドレス: 10.10.10.1
あて先IPアドレス: 10.128.1.1
送信元MACアドレス: SVR1MAC
あて先MACアドレス: PCx1MAC
で構成されています。 - DSR (Direct Server Return) を有効にすると、問題文にある
「eSVRが受信したパケットのあて先IPアドレスが、ループバックインタフェースに設定されたIPアドレスと同じとき、このIPアドレスがeSVR自身のものとして、eSVRから返送されるパケットに使われる。」
に従い、eSVR1はVIPを自分のアドレスとして用います。 - 図の機器情報よりVIPは10.10.0.1です。
- よってDSR適用後に変わるのは「送信元IPアドレス」だけであり、他のフィールドは変化しません。
- 以上より、解答は
「送信元IPアドレスが、仮想IPアドレスに変わったもの」
となります。
誤りやすいポイント
- 返送経路が変わるのでMACアドレスも変化すると考えてしまう
→ DSRはIP層だけに影響し、イーサネットの送受信はeSVRとPC間で完結するためMACはそのままです。 - VIPと実アドレスを混同し、10.10.10.1を残してしまう。
- ソースNATの説明とDSRを混同し、両方同時に動くと誤解する。
FAQ
Q: DSRを使うとLBは返送パケットに全く関与しないのですか?
A: 送信元→eSVRへ向かうパケットのみLBを経由し、返送パケットはLBをバイパスしてPCに直接届きます。
A: 送信元→eSVRへ向かうパケットのみLBを経由し、返送パケットはLBをバイパスしてPCに直接届きます。
Q: ループバックインタフェースを入れないとどうなるのでしょうか?
A: eSVR1がVIPを自分宛てと認識できず、返送パケットの送信元IPが実アドレスのままになり、PCがセッションを受け付けません。
A: eSVR1がVIPを自分宛てと認識できず、返送パケットの送信元IPが実アドレスのままになり、PCがセッションを受け付けません。
Q: MACアドレスが変わらない理由は?
A: 同一セグメント内の通常のフレーム転送だからです。eSVR1はARPでPCのMACを解決し、自身のMACを送信元にして返送します。
A: 同一セグメント内の通常のフレーム転送だからです。eSVR1はARPでPCのMACを解決し、自身のMACを送信元にして返送します。
関連キーワード: DSR, VIP, ループバックインタフェース, 負荷分散, ARP





