応用情報技術者 2017年 秋期 午後 問05

解答の論理構成

1. 問題文の確認
   「顧客YのPCから顧客YのAPサーバにアクセスする場合、FWとAPサーバの間を流れるAPサーバ向けイーサネットフレームの送信元MACアドレスはa、宛先MACアドレスはbとなる。」とあります。
   つまり、通信方向は「FW ➜ APサーバ」です。
2. 機器ごとのMACアドレスを把握
   表1より
   ・「APサーバ」→「aaa」
   ・「FW」→「ccc（LAN側）、mmm（WAN側）」
   LAN内でAPサーバへフレームを送るのは「FWのLAN側インタフェース」です。
3. 送信元MACの決定
   フレームを発信するのは「FWのLAN側」。よって送信元は「ccc」。
4. 宛先MACの決定
   フレームの届け先は「APサーバ」。よって宛先は「aaa」。
5. 結論
   a＝「ccc」、b＝「aaa」となります。

誤りやすいポイント

• 「FWのWAN側mmm」を送信元だと思い込む。今回はLAN内通信なので「ccc」が正解です。
• 物理L2SWの転送先ポート番号（表2の8や9）とMACアドレスを混同する。設問はあくまでMACアドレスを問うています。
• 顧客ZのMACアドレス「ddd」「eee」と誤って対応させる。顧客Yの通信である点を見落とさないよう注意が必要です。

FAQ

解答の論理構成

1. 送信元・宛先MACの確認
   • 顧客YのDBサーバは表1「項番2」でMACアドレスが「bbb」、APサーバは表1「項番1」でMACアドレスが「aaa」と示されています。
   • よってDBサーバ → APサーバ のフレームは「送信元MAC：bbb」「宛先MAC：aaa」です。
2. 物理L2SW#1に入るポート (c の決定)
   • DBサーバ（仮想サーバ#9）は物理サーバ#2に載り、最終的に物理L2SW#1へは相互接続用ポート経由で到達します。
   • 表2を見ると、DBサーバあて（宛先MACが「bbb」）のフレームはすべて「Forward 13」となっており、逆向きに考えると「bbb」を送信元とするフレームは13番ポートから物理L2SW#1に入ってくることが分かります。
   • したがって c＝「13」となります。
3. マッチするテーブル項番 (d の決定)
   • 表2で「送信元MAC：bbb」「宛先MAC：aaa」に完全一致する行は「項番3」です。
   • 従って d＝「3」となります。
4. 結果
   • 問題文の空欄に当てはめると
     「物理L2SW#1の13番ポートに入力されると、通信制御テーブルの項番3のルールにマッチし、イーサネットフレームが物理L2SW#1の9番ポートに転送される。」
     となり、ネットワークの動作と整合します。

誤りやすいポイント

• 図だけを頼りに「クロスケーブル＝8番ポート」と早合点し、c を「8」としてしまうケース。MACアドレスごとの転送先ポートを示す表2を必ず参照する必要があります。
• 送信元・宛先を取り違えて「項番1（aaa→bbb）」を選択し、d を誤答してしまうミス。フレーム方向を確認しましょう。
• 表2の判定順序（上から順に評価）を見落とし、あいまい条件「送信元MAC：bbb、宛先：any」（項番10）を先に適用してしまう誤解。完全一致の項番3が上位に配置されています。

FAQ

解答の論理構成

1. 初めに、【問題文】の「表2物理L2SW#1の通信制御テーブル」を確認します。
   • 項番7 送信元MACアドレス「ddd」 宛先MACアドレス「eee」 アクション「Forward e」
   • 項番8 送信元MACアドレス「eee」 宛先MACアドレス「ddd」 アクション「Forward f」
2. 次に、通信相手（宛先）のポート番号を推定します。
   • 同表には、各MACアドレスごとに「宛先がanyの場合」の転送先ポートが定義されています。
   • 項番12 送信元「ddd」 宛先「any」 アクション「Forward 8」
   • 項番13 送信元「eee」 宛先「any」 アクション「Forward 13」
     これより、 • 「ddd」から出ていくフレームはポート「8」に送れば相手に届く
     • 「eee」から出ていくフレームはポート「13」に送れば相手に届く
     というトポロジが読み取れます。
3. したがって、
   • 「ddd」→「eee」（項番7）は宛先「eee」を収容するポート「8」へ転送するので e = 8
   • 「eee」→「ddd」（項番8）は宛先「ddd」を収容するポート「13」へ転送するので f = 13
4. 以上より解答は
   e：8
   f：13

誤りやすいポイント

• 「項番12」「項番13」の “any” ルールを見落とし、図の物理配線からポートを類推してしまう。テーブルが優先です。
• 「送信元ポート」ではなく「宛先を収容するポート」を転送先にする点を混同しやすい。
• 顧客Ｙと顧客Ｚで物理ポートを共有している（MACアドレスで分離）ことに気付かず、「ポートは顧客ごとに専有」と思い込む。

FAQ

解答の論理構成

1. 表2の項番9〜13を確認すると、いずれも判定条件の宛先MACアドレスがanyになっており、送信元だけがそれぞれ
   aaa、bbb、ccc、ddd、eee
   と顧客ごとの機器を示しています。アクションには複数ポートへのForwardが指定されています。
   これは「未知の宛先に対してフレームを複数ポートへ転送し、宛先機器からの応答を待ってMACアドレスを学習する」標準的なL2SWの“フラッディング”動作と同じです。
2. 問題文には
   「各L2SWにおいてイーサネットフレーム内のMACアドレスを用いた通信制御を行うことによって、顧客Yと顧客ZのサーバのIPアドレスが同一であっても、それぞれの顧客の通信を区別することができる。」
   とあります。つまりL2SWは“MACアドレス”単位で顧客ごとの通信を識別・分離します。よって収集対象もMACアドレスです。
3. また小問は「同一顧客内のサーバやFWがイーサネットフレームを用いて通信を行うために必要な情報を収集可能とするためのルール」と述べており、通信相手を決定するために必要なのは宛先機器のMACアドレスです。
4. 以上より、顧客Y・Zの各サーバおよびFWが収集する情報は「サーバやFWのMACアドレス」となります。

誤りやすいポイント

• 「IPアドレスが同じでも区別できる」との記述からIPアドレスと答えてしまう。実際はL2レベルの制御なのでMACアドレスが鍵です。
• 項番9〜13のアクションに複数ポートが書かれているのを「ロードバランシング」と誤解する。本質はフラッディングによるMAC学習です。
• 「収集する情報＝ポート番号」と誤答するケース。ポート番号はスイッチが内部で保持するだけで、サーバやFWが収集する対象ではありません。

FAQ

解答の導き方

1. 表1と図2から関係を整理する

• 表1を見ると、顧客YのAPサーバは「仮想サーバ#1（割当て仮想MACアドレスaaa）」、DBサーバは「仮想サーバ#9（割当て仮想MACアドレスbbb）」である。
• 図2の構成では「仮想L2SW#1」は物理サーバ#1上にあり「仮想サーバ#1」は物理サーバ#1上に接続されている。一方「仮想サーバ#9」は物理サーバ#2上に接続されている（図2中の仮想スイッチと仮想サーバの配置を参照）。したがって初期状態ではAP(aaa) は物理サーバ#1側、DB(bbb) は物理サーバ#2側に存在する。

1. 表2のルールと例の読み取り

• 本文の例にある「例えば、顧客YのDBサーバからAPサーバ向けのイーサネットフレームが、物理L2SW#1のc番ポートに入力されると、通信制御テーブルの項番dのルールにマッチし、イーサネットフレームが物理L2SW#1の9番ポートに転送される。」は、図2のリンク構成（物理L2SW#2と物理L2SW#1は8番ポート同士で接続）と表2を照合すると、c = 8, d = 3と特定できます。つまりDB→APのフレームは物理L2SW#1の8番ポートで受け、表2の項番3（送信元bbb、宛先aaa）にマッチして物理L2SW#1の9番ポートへ転送されていたことが分かります。
• 以上から、表2の項番1（aaa → bbb）と項番3（bbb → aaa）は、APとDB間の一対一のやり取り（APが物理サーバ#1側、DBが物理サーバ#2側にいたときのL2SW#1を経由する振る舞い）を直接扱うルールであることが明確です。

1. 物理サーバ#1故障・APを物理サーバ#2に移動した場合の影響

• 問題文にある通り、物理サーバ#1が故障したため「物理サーバ#2に移動させたAPサーバは仮想L2SW#2の2番ポートに接続する」となります。つまりAP(aaa) とDB(bbb) はともに物理サーバ#2上の同じ仮想L2SW（仮想L2SW#2）内に存在することになります。
• 「仮想サーバや仮想FWは仮想L2SWに接続し、仮想L2SWの1番ポートは物理L2SWに接続する」という記述から、同一の仮想L2SW内にある仮想サーバ間の通信はその仮想L2SW内で処理され、物理L2SW#1を経由しない（＝物理L2SW#1に該当フレームが入ってこない）ことが分かります。
• よって、APとDBの相互通信（表2の項番1：aaa → bbb、項番3：bbb → aaa）に対応するフレームは移動後は物理L2SW#1に到達しなくなり、物理L2SW#1上のこれらのルールは適用されなくなります。

1. 他の「aaa」を含むルールについての扱い（なぜ除外されるものとならないか）

• 表2のうち「送信元または宛先にaaaを含む」項番は1, 2, 3, 5, 9です。ここで項番1・3は前述の通りAP⇔DBの直接往復を扱うため確実に適用されなくなります。
• 残る項番2（aaa → ccc）、項番5（ccc → aaa）、項番9（aaa any）は、APとFW（ccc）やその他宛先とのやり取りを扱うルールです。APを物理サーバ#2に移動しても、APとFWのように異なる物理サーバ間の通信や、外部／他顧客方向への通信は物理系の経路やSDNの転送設定によっては依然として物理L2SW#1にフレームが到達する可能性があります（物理L2SW#1と #2間のリンクや、SDNコントローラによる経路設定の影響を受けるため）。したがって「確実に適用されなくなる」と断定できるのは項番1と3に限られます。

誤りやすいポイント

• 「aaaを含むすべてのルールが適用されなくなる」と早合点すること。重要なのはそのルールが物理L2SW#1に到達するフレームを前提としているかどうかで、APとDBが同一仮想L2SWに移動して初めて「物理L2SW#1に到達しない」と断言できる。
• 物理ポートの死＝そのMACがネットワーク全体から消える、とは限らない点を見落とすこと。仮想サーバ移動後も別経路で同じMACに関連するフレームが別のポート経由で来る可能性がある。
• 表2は上から順に評価される（最初にマッチしたルールが適用される）ことを忘れると、具体的にどのルールが実際に使われるかの判断を誤る。

FAQ

解答の論理構成

1. 初期構成を確認
   • APサーバは「表1」で“仮想サーバ#1”に割り当てられており、この仮想サーバは「図2」で“物理サーバ#1 → 物理L2SW#1の 9番ポート”にぶら下がっています。
   • したがって、APサーバあてフレームを物理L2SW#1から取り出すための既定経路は「表2」項番 5
     （送信元 ccc、宛先 aaa、Action Forward 9）です。
2. 故障時の変化を整理
   • 【問題文】には
     「物理サーバ#1が故障して、APサーバの移動を完了した場合…物理サーバ#2に移動させたAPサーバは仮想L2SW#2の2番ポートに接続する。」
     とあります。
   • 仮想L2SWは「仮想L2SWの1番ポートは物理L2SWに接続する」とあるため、 仮想L2SW#2 ―(1番ポート)→ 物理L2SW#2 ―(9番ポート)→ 物理L2SW#1 ―(13番ポート)
     という経路でAPサーバ（aaa）が物理L2SW#1に “現れる” ことになります。
     すでに「表2」では、DBサーバ（bbb）関連トラフィック用に
     「項番 6 送信元 ccc 宛先 bbb Action Forward 13」
     が設定されており、13番ポートが物理L2SW#2側へのリンクであることが読み取れます。
3. どのルールを直す必要があるか
   • APサーバ宛のフレームで物理L2SW#1を経由するのは「送信元 ccc（FW）→ 宛先 aaa（AP）」だけです。
   • これは「表2」項番 5 に該当し、現在のActionは Forward 9 のまま。
   • APサーバが13番ポート側に移動したので、Actionを Forward 13 へ変更する必要があります。
4. まとめ
   • 変更対象のルール：項番 5
   • 変更後のアクション：Forward 13

誤りやすいポイント

• 「項番9,10,11は除外」と指示されているのに加えて、宛先 aaa が含まれる項番 3 に目を取られがちです。
  DBサーバ（bbb）→ APサーバ（aaa）の通信はAPが物理サーバ#2へ移動すると 物理L2SW#1を経由しなくなるので、そもそも不要になります。
• 物理L2SW#1と物理L2SW#2の接続ポートを 8番と早合点し、APサーバ宛をForward 8としてしまうミス。
  表2でDBサーバ宛がForward 13になっていることから、13番ポートが実際のリンクであると読み取る必要があります。
• MACアドレスの送受信方向を取り違え、送信元 aaa（AP）側のルールに手を入れようとするケース。設問は「FW → AP」の方向であることを忘れないようにしましょう。

FAQ