SNMP(ポーリング・トラップ・インフォーム)【ネットワークスペシャリスト試験 平成30年度 秋期 午後1 問2 No.4】
ネットワークスペシャリスト試験 平成30年度 秋期 午後1 問2 No.4
【出典:ネットワークスペシャリスト試験 平成30年度 秋期 午後1 問2(一部、加工あり)】
【ネットワーク監視の改善策の立案】
Cさんは、ネットワーク監視の改善策として、新たにSNMP(Simple Network Management Protocol)を使って監視することを検討した。Cさんは、監視対象機器で利用可能なSNMPv2について調査を行った。
SNMPは機器を管理するためのプロトコルで、⑥SNMPエージェントとSNMPマネージャで構成される。SNMPエージェントとSNMPマネージャは、同じグループであることを示す(エ:コミュニティ)を用いて、機器の管理情報(以下、MIBという)を共有する。
SNMPの基本動作として、ポーリングとトラップがある。ポーリングは、SNMPマネージャが、SNMPエージェントに対して、例えば5分ごとといった定期的にMIBの問合せを行うことによって、機器の状態を取得できる。一方、トラップは、MIBに変化が起きた際に、SNMPエージェントが直ちにメッセージを送信し、SNMPマネージャがメッセージを受信することによって、機器の状態を取得できる。
Cさんは、⑦5分間隔のポーリング、又はトラップを使用して監視しても、今回発生したネットワークの異常においてはそれぞれ問題があることが分かった。しかし、SNMPのインフォームと呼ばれるイベント通知機能を利用すれば、これらの問題に対応できると考えた。
SNMPのインフォームでは、MIBに変化が起きた際に、SNMPエージェントが直ちにメッセージを送信し、SNMPマネージャからの確認応答を待つ。確認応答を受信できない場合、SNMPエージェントは、SNMPマネージャがメッセージを受信しなかったと判断し、メッセージの再送信を行う。Cさんは、⑧今回と同様なネットワークの異常が発生した場合に備えて、SNMPマネージャがインフォームの受信を行えるよう、SNMPエージェントの設定パラメタを考えた。
その後、CさんはSNMPのインフォームを用いたネットワーク監視の改善策をB課長に報告し、その内容が承認された。
⑥について、SNMPエージェントとSNMPマネージャに該当する機器名を、図1中の機器名を用いてそれぞれ一つ答えよ。:(SNMPエージェント)コアSW1、コアSW2、サーバSW、フロアSW1、フロアSW2、フロアSW3、フロアSW4のうちのいずれか一つ、(SNMPマネージャ)監視サーバ
SNMPエージェントは監視される側の機器です。
本文に「監視対象機器は、コアSW、サーバSW及びフロアSWである」とあるので、図1と照らし合わせて選びます。
SNMPマネージャは監視する機器ですので、監視サーバとなります。
エ:コミュニティ
SNMPに関する基本的なキーワードですので覚えておきましょう。
SNMPではコミュニティというグループを組んで情報をやりとりします。
デフォルトのコミュニティ名は「public」であることが多いですが、実際の運用に向けては適切な名前に変更するようにします。
⑦について、ポーリングとトラップの問題を、それぞれ35字以内で述べよ。:(ポーリング)5分ごとに状態を取得するので多くの場合異常検知が遅れる。、(トラップ)到達確認がないのでメッセージが失われる可能性がある。
ポーリングやトラップの動作を踏まえて正解を導き出しますが、なんとなくぼんやりとしていて文章が書きにくい気がします。
そんな時はもう少し前後の本文を読んで、ヒントになるところがないか探しましょう。
すると、直後の文章に「しかし、SNMPのインフォームと呼ばれるイベント通知機能を利用すれば、これらの問題に対応できる」とあります。
SNMPのインフォームで「これらの問題」にどのように対応できているのか記載されている部分を参考に、逆にポーリング、トラップでの問題を導き出せそうです。
その後の本文で「SNMPのインフォームでは、MIBに変化が起きた際に、SNMPエージェントが直ちにメッセージを送信し、SNMPマネージャからの確認応答を待つ。確認応答を受信できない場合、SNMPエージェントは、SNMPマネージャがメッセージを受信しなかったと判断し、メッセージの再送信を行う。」とあります。
したがって、「5分間隔のポーリング」に対し、異常発生後、直ちにメッセージを送信することで、異常検知の遅れを防ぐことができます。
また、「トラップ」で用いるUDPにはない確認応答・再送信によりメッセージが失われることを防ぎます。
⑧について、SNMPエージェントが満たすべき動作の内容を、40字以内で述べよ。:スパニングツリーが再構築するまでインフォームの再送信を繰り返す。
SNMPのインフォームでは確認応答がない場合、再送信を行うことが分かっています。
本文にある「今回と同様なネットワークの異常が発生した場合に備えて、・・・」を改めて考えると、スパニングツリーの再構築で50秒程度メッセージが届かない状況でした。
この状況に備えてSNMPエージェントの設定パラメタを考える場合、再送信は一度ではなく、スパニングツリーが再構築するまで繰り返すということが必要になってきます。