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

解答の論理構成

• 【問題文】には「②DNSサーバの故障又はDNSサーバへの経路の障害ではないかと考え」とあり、DNSサーバの IP は【問題文】の図1で「172.16.1.4」と示されています。したがって a は「172.16.1.4」→解答群「イ」。
• 「OSPFによるb経路制御」は、OSPF が RIP などと同じくルーティング情報を交換して経路を自動で決定するプロトコルであることから「動的」→解答群「コ」。
• 【問題文】には「PCのデフォルトゲートウェイには、L3SW1の内部ルータのVLANインタフェースアドレスcが設定されており」とあり、図1 の VLAN20 側インタフェースは「172.16.2.250」です。よって c は「172.16.2.250」→解答群「オ」。
• 「③図2中のL3SW1のルーティングテーブルが更新され、ネクストホップIPアドレスdがセットされる」との記述から、障害時に迂回先となる L3SW2 の VLAN20 側アドレスを指定する必要があります。図2 における L3SW2 の VLAN20 側インタフェースは「172.16.2.251」です。従って d は「172.16.2.251」→解答群「カ」。
• 【問題文】では「L3SW1は当該PC宛てで、経路の変更を指示するeパケットを送信する」とあり、ルータがより適切なゲートウェイを通知する際に利用する制御メッセージは ICMP Redirect です。よって e は「ICMPリダイレクト」→解答群「ク」。

誤りやすいポイント

• DNS の IP を誤って「172.16.1.1」などサーバ群の別アドレスにしてしまうミス。
• OSPF を「静的」と勘違いし、経路制御を「ケ」と回答してしまうパターン。
• デフォルトゲートウェイが VLAN10（172.16.1.250）ではなく VLAN20（172.16.2.250）であることを図1から読み取れず間違えるケース。
• 「ICMPリダイレクト」と「GARP」「プロキシARP」を混同しやすい。

FAQ

解答の論理構成

• 【問題文】では、K君は「業務サーバ」を利用できないが、他のサーバは利用できると報告しています。
• J君は自席の PC からは「業務サーバ」を利用できたため、サーバ自体の故障ではなく、K君の PC からサーバまでのネットワーク経路に問題があると推測しました。
• そこで下線①「K君の席に行き、K君のPCでpingコマンドを172.16.1.1宛てに実行」しました。
• ping は ICMP Echo を用いて到達可否を確認する基本的な疎通テストであり、アプリケーション層ではなくネットワーク層（レイヤ3）の経路を検証します。
• 宛先 IP「172.16.1.1」は図1で「業務サーバ」に割り当てられているアドレスです。
• 以上より、操作の目的は「K君の PC から業務サーバまでの経路に障害があるかどうか」を判定することになります。

誤りやすいポイント

• 「サーバが生きているか確認」だけと答えると、既に J 君は自席から接続できておりサーバ稼働を把握しているため主旨がずれます。
• ping＝通信可能性の判定と理解せず、アプリケーション層の問題切り分け手順だと誤解するケース。
• 目的を「ネットワーク全体の障害確認」と広げ過ぎると、設問が求める主体（業務サーバへの経路）から逸脱します。

FAQ

解答の論理構成

1. 事象の整理
   • 本文では、J君が「②DNSサーバの故障又はDNSサーバへの経路の障害ではないかと考え」とあります。
   • しかし一部の社員は、DNSサーバが不達でも業務サーバ・ファイルサーバ・営業支援サーバに正常にアクセスできていました。
2. 名前解決の要否
   • サーバ利用時には、ホスト名を IP アドレスへ変換する DNS が通常必要です。
   • ところが「DNSサーバの故障」でも通信できた PC があったということは、名前解決を DNS で行わずとも IP アドレスが判明していたと推測できます。
3. キャッシュの存在
   • OS やブラウザは、過去の DNS 応答をローカルに保持します。これを DNS キャッシュと呼びます。
   • 以前に同じサーバへアクセスしていれば、IP アドレスはローカルに保存されているため、新たに DNS クエリを送信する必要がありません。
4. したがって
   • DNS サーバが不通でも「PCにDNSのキャッシュが残っている」PC では名前解決が内部で完結し、サーバを問題なく利用できたと結論づけられます。

誤りやすいポイント

• 「hosts ファイルに手動登録されていた」と思い込む
  → 問題文にその示唆はなく、全社員で発生しない点と整合しません。
• サーバの FQDN ではなく IP 直打ちで接続したと考える
  → 社員が普段通り利用している描写からは IP 直打ちの可能性は低いです。
• 「キャッシュ＝プロキシサーバのキャッシュ」と混同する
  → 本設問は DNS キャッシュ（ローカル or OS 内部）を指しています。

FAQ

解答の論理構成

1. きっかけとなる障害
   • 問題文に「③図2中のL3SW1のルーティングテーブルが更新され」とあるのは、L3SW1 の p1（VLAN10 側）障害時を想定した記述です。
   • この結果、L3SW1 から VLAN10（サーバ側）への直接経路が失われるため、OSPF により別経路（L3SW2 経由）が計算されます。
2. 更新対象の経路はどれか
   • 図2の「L3SW1のルーティングテーブル（抜粋）」には
     項番1　宛先ネットワーク 172.16.1.0/24　VLANインタフェース 172.16.1.250　VLAN名 VLAN10 項番2　宛先ネットワーク 172.16.2.0/24　VLANインタフェース 172.16.2.250　VLAN名 VLAN20
   • サーバが属するネットワークは「172.16.1.0/24」であり、この行が 項番1 です。したがって更新対象は項番1になります。
3. 更新後の VLAN インタフェースと VLAN 名
   • L3SW1 はサーバネットワークへ直接つながっていないため、自身の VLAN10 インタフェース（「172.16.1.250」）は使えません。
   • 代わりに、PC 側のネットワーク経由で L3SW2 にバイパスさせるため、VLAN20 側のインタフェース「172.16.2.250」を経路の出力点に変更します。
   • それに伴い VLAN 名も VLAN20 に書き換わります。
   • 問題文はこの動きを「ネクストホップIPアドレスdがセットされる」と説明しており、ICMP リダイレクトによって PC にも経路が通知される仕組みです。
4. まとめ
   • よって、更新が発生する行は項番1。
   • 更新後の VLAN インタフェースは「172.16.2.250」、VLAN 名は「VLAN20」となります。

誤りやすいポイント

• 「p1 の障害＝VLAN10 側が不通」なのに、VLAN インタフェースを「172.16.1.250」のままにしてしまう。OSPF はあくまで到達可能なインタフェースを選定します。
• 項番2（PC 側ネットワーク）を更新すると勘違いする。宛先ネットワークがどちらかに注目すること。
• VLAN インタフェースの IP を「172.16.2.251」と誤記。これはネクストホップ（L3SW2 側）であって、L3SW1 自身のインタフェースではありません。

FAQ

解答の論理構成

1. 【問題文】では、下線④について「PCとサーバに設定されているネットワーク情報の一つを、図1 の状態から変更することになる」とあります。
2. 図1 ではサーバのデフォルトゲートウェイに「172.16.1.250」が設定されています。これは “L3SW1 の内部ルータの VLAN インタフェース” です。
3. ところが VRRP を導入すると【問題文】に「L3SW の内部ルータの VLAN インタフェースに仮想 IP アドレスが設定される」と明記され、図3 には “VRRPグループ1（VLAN10） 仮想IPアドレス：172.16.1.200” が示されています。
4. VRRP 運用時、端末は仮想 IP アドレスをデフォルトゲートウェイに設定しないと、マスター装置切替時に通信が継続できません。したがって変更対象のネットワーク情報は “デフォルトゲートウェイアドレス” になります。
5. サーバは VLAN10（172.16.1.0/24）に属しているため、新しいデフォルトゲートウェイ値は VRRP グループ1 の仮想 IP アドレス「172.16.1.200」となります。

誤りやすいポイント

• IP アドレスを「172.16.1.250」→「172.16.1.251」と勘違いする
  L3SW2 の物理 IP を指定しても VRRP による自動切替は起こりません。
• 変更対象を DNS サーバ設定だと思い込む
  VRRP はルータ冗長技術であり名前解決とは無関係です。
• PC 側だけを書き、サーバ側を失念する
  問題は「PCとサーバ」と明記され、サーバの新値を具体的に要求しています。

FAQ