ネットワークスペシャリスト 2018年 午後1 問02

解答の論理構成

1. RFCとプロトコルの対応付け
   • 【問題文】に「ping監視には、RFC 792で規定されているプロトコルである ア を利用する。」とあります。
   • RFC 792はInternet Control Message Protocolを定義しています。したがって [ア] は「ICMP」です。
2. pingの宛先に必要な識別子
   • 【問題文】に「echo requestパケットの宛先として、監視対象機器には イ を割り当てる必要がある。」とあります。
   • echo requestはIPレイヤで宛先を指定するため、割り当てるものは「IPアドレス」となります。
3. SYSLOGのトランスポートプロトコル
   • 【問題文】に「SYSLOGは、トランスポートプロトコルとしてRFC 768で規定されている ウ を用いている。」とあります。
   • RFC 768はUser Datagram Protocolを規定します。よって [ウ] は「UDP」です。
4. SNMPで同一グループを示す情報
   • 【問題文】に「SNMPエージェントとSNMPマネージャは、同じグループであることを示す エ を用いて、機器の管理情報（以下、MIBという）を共有する。」とあります。
   • SNMPv2cでは “community name” によってグループを識別します。したがって [エ] は「コミュニティ」です。

誤りやすいポイント

• RFC番号の取り違え
  RFC 793と勘違いしてTCPを選ぶミスが多発します。RFC 792がICMP、RFC 768がUDPです。
• ping ＝ MACアドレスではない
  echo requestはレイヤ3のプロトコルなので、宛先に必要なのはMACではなくIPアドレスです。
• SYSLOG＝TCPと決め付ける
  セキュアSYSLOGなど一部TCPを使う実装もありますが、問題文には「RFC 768」と明示されているためUDPが正答です。
• SNMPの「ユーザ名」と混同
  SNMPv3ではユーザベースのセキュリティモデルがありますが、本問題はSNMPv2cを前提としており、キーワードはコミュニティです。

FAQ

解答の論理構成

1. VRRPの目的を確認
   • 【問題文】「コアSWには、①VRRPが設定してあり、②正常時は、コアSW1がマスタルータで、コアSW2がバックアップルータとなるように設定している。」
   • VRRPは複数のルータで1つの仮想IPアドレスを共有し、ルータ障害時に経路を自動で切替えるプロトコルです。
2. PC・サーバ側で設定する情報に着目
   • PCやサーバが日常的に設定するネットワーク項目は「IPアドレス」「サブネットマスク」「デフォルトゲートウェイ」などです。
   • VRRPで冗長化されるのはルータ側の機能ですが、ホスト側から見れば「常に同じIPを指す出口」が維持される点が重要です。
3. 冗長化される対象を導く
   • ホストが通信相手にパケットを送る際、最初に問い合わせるのは「デフォルトゲートウェイ」です。
   • VRRPによりマスタルータが交代しても、ホスト設定は変えずに済みます。
   • よって、PC・サーバに設定する情報の中で冗長化される対象は「デフォルトゲートウェイ」になります。

誤りやすいポイント

• VRRPが「IPアドレス自体」を冗長化すると誤解し、答えを「仮想IPアドレス」としてしまう。実際にはホストが指定する出口＝デフォルトゲートウェイが切れ目なく維持される点が本質です。
• スイッチやポート番号など機器側パラメータを記述してしまう。設問はあくまで「PC及びサーバに設定する情報」に限定しています。
• VRRPをHSRPやGLBPなど他のFHRPと混同し、用語の整合が取れなくなる。

FAQ

解答の論理構成

1. 【問題文】では、コアスイッチについて「①VRRP」が設定されており、「②正常時は、コアSW1がマスタルータで、コアSW2がバックアップルータ」と記載されています。
2. VRRPでは、マスタルータが一定間隔でメッセージを送信し、バックアップルータはその受信が途切れた場合にマスターへ昇格する仕組みです。
3. RFC 5798などの規定によれば、この監視用メッセージは “Advertisement” と呼ばれます。日本語でも “アドバタイズメント” と表記されるのが一般的です。
4. したがって、バックアップルータが受信しなくなったときにマスタルータへ切り替わるきっかけとなるVRRPで規定されたメッセージ名は
   　　VRRPアドバタイズメント
   となります。

誤りやすいポイント

• メッセージ種別を “Hello” や “Keepalive” と誤記する。これらはOSPFやHSRPで用いられる語であり、VRRPでは “アドバタイズメント” が正しいです。
• “Advertisementパケット” と英語表記にした結果、15文字以内の条件を満たさなくなることがあるため注意が必要です。
• VRRPはL3の冗長化プロトコルですが、STPやVRRPの役割を混同し、ポート状態遷移メッセージと誤解するケースがあります。

FAQ

解答の論理構成

1. トランクポートの性質
   • 【問題文】には「③p4ポートをIEEE 802.1Qを用いたトランクポートに設定している。」とあります。
   • IEEE 802.1Qで設定するトランクポートは、そのスイッチで利用している全VLAN IDをタグ付きで運ぶのが原則です。
2. どのVLANを運ぶ必要があるか
   • 同じ箇所の文に続き「コアSWのp1ポート、p2ポート及びp3ポートはアクセスポート」と記載されています。
   • 図1を見ると、p1は「VLAN100」、p2は「VLAN200」、p3は「VLAN300」の各アクセスポートです。
   • したがって、コアSWが扱うVLANは「VLAN100」「VLAN200」「VLAN300」の3つです。
3. 結論
   • p4をトランクにする以上、タグ付きで流すVLAN IDは上記3つすべてになります。
   • よって解答は
     VLAN100, VLAN200, VLAN300

誤りやすいポイント

• 「管理VLANだけを流せば良い」と思い込み、VLAN100だけを答えてしまう。
• VRRPの動作VLAN（今回は特定されていません）だけを流せば良いと誤解し、VLAN200を外してしまう。
• 図1のアクセスポート設定を確認せず、VLAN300の存在を見落としてしまう。

FAQ

解答の導き方

1. 問題文の重要な記述から出発します。本文には「正常時はコアSW1がルートブリッジとなるように設定している」とあり、STPではルートブリッジがBPDUを生成してネットワークに伝播します。BPDUはルートから隣接スイッチへ届き、各スイッチは受信したBPDUの向きでルートポート／指定ポートを決めます（例：コアSW1→コアSW2→フロアSW2や コアSW1→フロアSW1の経路で到達する）。
2. 図2の接続関係を確認します。図2より、フロアSW2は
   • p1でコアSW2のp2に接続、
   • p2でフロアSW1のp2に接続 しています。つまりフロアSW2はp1経由でコア側（コアSW2経由でコアSW1へ）、p2経由でフロア側（フロアSW1経由でコアSW1へ）の二経路を持っています。
3. 本文の記述「フロアSW2のp1ポートのSTPのポート状態がブロッキングから、リスニング、ラーニングを経て、フォワーディングに遷移した」から、変化前はフロアSW2のp1がブロッキングであり、逆にp2がフォワーディング（ルートへ向かう経路＝ルートポート）であったと推定できます。
4. 本文には「ケーブル1の断線によって、フロアSW1のp1ポートとコアSW1のp2ポートを接続するケーブル1が断線した」とあります。ケーブル1断線によりフロアSW1はコアSW1からのBPDUを受信できなくなります。するとフロアSW1からフロアSW2へ送られていたBPDUも途絶え、結果としてフロアSW2のp2がBPDUを受信しなくなります。BPDU受信が途絶えたためSTPが再収束し、従来ブロッキングであったp1がリスニング→ラーニング→フォワーディングへ遷移した、という流れになります。

誤りやすいポイント

• BPDUの発生源を誤認する：本文の「コアSW1がルートブリッジ」という記述を見落とし、別経路（例：サーバ側経路）を想定してしまう。
• 物理リンクの断（ケーブル断）したポートと、BPDU受信停止となったポートを混同する：断線したのはケーブル1（フロアSW1のp1–コアSW1のp2）だが、BPDU受信停止はその影響を受けた隣接ポート（フロアSW2のp2）で起きる。
• 「どのポートがもともとブロッキングか」を問題文の記述から逆算するのを怠ると誤答する。本文の状態遷移記述から初期状態を推定することが重要。
• STPの振る舞い（BPDUの到達方向に基づくルートポート選定）を理解していないと、誤った経路推定を行う。

FAQ

解答の論理構成

1. まず障害の発端は、フロアSW1とコアSW1を結ぶ「ケーブル1」が切断されたことです。問題文には、
   「ケーブル1の断線によって、④フロアSW2のp1ポートのSTPのポート状態がブロッキングから、リスニング、ラーニングを経て、フォワーディングに遷移した」
   とあり、STPがトポロジの変化を検知して再計算（再構築）を開始したことが分かります。
2. STP再構築中は、ポート状態がブロッキング／リスニング／ラーニングのいずれかにあり、フォワーディングになるまでユーザーフレームは転送されません。
3. 同じタイミングで「ケーブル2」も切断され、フロアSW1はそのリンクダウンを検知してSYSLOGメッセージを即時送信しました。しかし、問題文には、
   「⑤フロアSW1が送信した、リンク状態遷移を示すSYSLOGメッセージが監視サーバに到達できなかった」
   と記載されています。
4. 到達しなかった直接の理由は、STPが収束する前だったために、フロアSW1から監視サーバへ至る経路上のポートがフォワーディング状態になっておらず、SYSLOGフレームが破棄されたからです。
5. よって要求どおり「スパニングツリー」の語を含めると、解答は「スパニングツリーが再構築中だったから」となります。

誤りやすいポイント

• 「ケーブル2」の断線そのものが原因と答えてしまう
  ─ 到達できなかったのはリンク切断ではなく経路再計算が未完了だったためです。
• SYSLOGが「UDP」だから届かなかったと誤解する
  ─ トランスポートは問題ではなく、フレーム転送経路が開通していなかった点が本質です。
• STPの各状態（ブロッキング→リスニング→ラーニング→フォワーディング）の役割を混同する
  ─ リスニング／ラーニング中はデータフレームが転送されないことを押さえましょう。

FAQ

解答の論理構成

1. 監視対象機器の確認
   【問題文】には「監視対象機器は、コアSW、サーバSW及びフロアSWである。」とあります。図1を見ると該当機器は
   ・「コアSW1」,「コアSW2」
   ・「サーバSW」
   ・「フロアSW1」～「フロアSW4」
   です。
2. SNMPの役割分担
   【問題文】の下線⑥には「SNMPエージェントとSNMPマネージャで構成される」と記載されています。一般に
   ・SNMPエージェント：監視される側（機器内でMIBを保持）
   ・SNMPマネージャ：監視する側（ネットワーク管理ソフトを搭載）
   で動作します。
3. A社でマネージャを担う機器
   同じ段落の直前に「Cさんは、ネットワーク監視の改善策として、新たにSNMP … を使って監視することを検討した。」とあり、従来監視を担当していたのは「監視サーバ」です。したがってSNMPを導入しても、管理を行うのは「監視サーバ」になります。
4. A社でエージェントを担う機器
   ポーリングやトラップ／インフォームの送信元は各スイッチ・サーバです。よって1. で列挙した機器がすべてSNMPエージェントに該当します。
5. 結論
   SNMPエージェント：
   「コアSW1」又は「コアSW2」又は「フロアSW1」又は「フロアSW2」又は「フロアSW3」又は「フロアSW4」又は「サーバSW」
   SNMPマネージャ：
   「監視サーバ」

誤りやすいポイント

• 「SNMPマネージャ」をコアスイッチだと思い込む
  VRRPやルーティングを行う機器＝管理装置と誤解しがちですが、管理トラフィックを集約する役割は「監視サーバ」です。
• 「サーバSW」を忘れる
  監視対象は“SW”という名前に惑わされやすく、レイヤ2スイッチである「サーバSW」をエージェント一覧から漏らしがちです。
• 「SW1〜SW32」まで含めてしまう
  監視対象に列挙されていない機器を勝手に追加すると減点対象になります。問題文に明示された範囲に限定することが必要です。

FAQ

解答の論理構成

• 【問題文】では、ポーリングについて「SNMPマネージャが、SNMPエージェントに対して、例如5分ごとといった定期的に MIBの問合せを行う」と記述されています。
  したがって取得間隔よりも短い時間で障害が収束・再収束すると、監視サーバは変化を捕捉できません。「多くの場合異常検知が遅れる」という結論になります。
• トラップについては「SNMPエージェントが直ちにメッセージを送信し、SNMPマネージャがメッセージを受信」するのみで、確認応答はありません。この点は後段のインフォームの説明―「SNMPマネージャがメッセージの確認応答を持つ」―と対比されます。
  よって「到達確認がないのでメッセージが失われる可能性がある」という弱点が導けます。
• 以上より、模範解答
  ・ポーリング：5分ごとに状態を取得するので多くの場合異常検知が遅れる。
  ・トラップ：到達確認がないのでメッセージが失われる可能性がある。
  が妥当となります。

誤りやすいポイント

• ポーリング＝“定期的な取得”という語感だけで「通信量増大」を最優先に挙げてしまう。今回の設問は通信量ではなく障害検知の遅延に着目しています。
• トラップの欠点を「エージェントから送られない場合がある」と漠然と書く。実際の論点は「確認応答が無い＝未達時に再送されず、途中でロスしてもマネージャは気づけない」点です。
• インフォームの説明を混在させてしまい、トラップ単体の欠点を書くのを忘れる。

FAQ

解答の論理構成

1. 監視できなかった原因の整理
   • ケーブル断線時に「⑤フロアSW1が送信した、リンク状態遷移を示すSYSLOGメッセージが監視サーバに到達できなかった」と記載されています。つまり、障害発生直後は通信経路自体が寸断されていました。
2. 経路復旧までの時間的ギャップ
   • 断線後、「④フロアSW2のp1ポートのSTPのポート状態がブロッキングから、リスニング、ラーニングを経て、フォワーディングに遷移した」とあるように、STP再収束には一定時間を要します。この間に送られた通知は届かない可能性があります。
3. SNMPインフォームの特性
   • 本文には「SNMPのインフォームでは、MIBに変化が起きた際に、SNMPエージェントが直ちにメッセージを送信し、SNMPマネージャからの確認応答を待つ。確認応答を受信できない場合、SNMPエージェントは、SNMPマネージャがメッセージを受信しなかったと判断し、メッセージの再送信を行う。」とあります。
   • つまり、届かなければ再送し続けるという自己回復機構を備えています。
4. ⑧の要求事項
   • 問題は「⑧今回と同様なネットワークの異常が発生した場合に備えて、SNMPマネージャがインフォームの受信を行えるよう、SNMPエージェントの設定パラメタを考えた」と述べています。
   • 指定すべき動作は「障害で最初のインフォームが届かなくても、STPが経路を張り直すまで再送を継続する」ことです。
5. したがって模範解答
   • 「スパニングツリーが再構築するまでインフォームの再送信を繰り返す。」

誤りやすいポイント

• インフォームとトラップを混同し、確認応答（ACK）の有無を取り違える。
• STP収束後に経路が確立する事実を見落とし、「一度送れば十分」と考えてしまう。
• 再送回数や間隔など細部のパラメータに目が行き、求められる動作の主旨（到達するまで送り続ける）を外してしまう。

FAQ