今朝、SNMPはUDP上で実行されるため、SNMPトラップが「通過」しなかったため、職場で大きな問題が発生しました。大学のネットワーキングクラスから、UDPはTCP/IPのような配信が保証されていないことを覚えています。また、ウィキペディアによると、SNMPはTCP/IP上で実行できますが、UDPの方が一般的です。
UDPがTCP/IPより優れている点のいくつかは、速度、ブロードキャスト、およびマルチキャストであることがわかります。しかし、配信の保証は、ブロードキャスト機能よりもネットワーク監視にとって重要であるように思えます。特に、深刻な高度なセキュリティニーズがある場合。同僚の一人は、トラフィックが多くなるとUDPパケットが最初にドロップされると言った。これは、ネットワーク監視(IMO)でUDPよりもTCP/IPを好むもう1つの理由です。
では、なぜSNMPはUDPを使用するのですか?私はそれを理解できず、Googleでも正当な理由を見つけることができません。
UDPは、実際にはTCP損失の多いネットワーク(または混雑したネットワーク)よりもうまく機能することが期待されています。TCPは、大量のデータを転送する場合は、ネットワークに障害が発生すると、UDPが通過する可能性が高くなります(実際、最近、これをテストする調査を行った結果、SNMP over UDPは、SNMP over TCP UDPタイムアウトは適切に設定されていました。一般的に、TCPは約5%のパケット損失で動作が悪くなり、33%(ish)で完全に無用になり、UDPは(最終的に)成功します。
したがって、正しいことは、いつものように、適切な仕事に適切なツールを選択することです。大量のデータを定期的に監視している場合は、TCPを検討できます。ただし、問題を修正するためにUDPにフォールバックする準備をしてください。最近のほとんどのスタックは、実際にTCPとUDPの両方を使用できます。
TRAPの送信に関して、yes TRAPは承認されていないため、信頼できません。ただし、SNMP INFORMは、SNMP TRAPの承認済みバージョンです。したがって、通知の受信者がメッセージを受け取ったことを知りたい場合は、INFORMを使用してください。 TCPは じゃない この問題は、メッセージが受信されたというレイヤー3レベルの通知のみを提供するため、解決します。通知の受信者が実際に受け取ったという保証はありません。 SNMP INFORMはアプリケーションレベルの確認を行い、TCP ackが受け取ったことを示すと仮定するよりもはるかに信頼できます。
システムがTCPを介してSNMPトラップを送信した場合、受信者へのトラフィックの取得に問題がある場合、パケットがACKされるのを待つことをブロックできます。多くのトラップが生成された場合、 UDPは、ステートレスであるため問題ではありません。同様の問題が1月にBitBucketを取り出しましたが、これはSNMPではなくsyslogプロトコルでしたが、基本的に、syslogを誤って使用していました。 over TCP設定エラーが原因で、syslogサーバーが停止し、syslogサーバーがパケットをACKするのを待っているすべてのサーバーがロックされました。SNMPトラップがTCP経由で送信された場合、問題が発生する可能性があります。
http://blog.bitbucket.org/2012/01/12/follow-up-on-our-downtime-last-week/
SNMPでのトラップの使用は信頼できないと見なされます。あなたは本当にトラップに頼るべきではありません。
SNMPは、要求/応答プロトコルとして使用されるように設計されました。プロトコルの詳細はシンプルです(そのため、「シンプルネットワーク管理プロトコル」という名前です)。 UDPは非常に単純なトランスポートです。基本エージェントにTCPを実装してください-UDPを使用してコーディングされた単純なエージェントよりもかなり複雑です。
SNMP get/getnext操作には再試行メカニズムがあります-タイムアウト内に応答が受信されない場合、同じ要求が最大試行回数まで送信されます。
SNMPに関するO'Reillyの著作を確認してください。 https://library.oreilly.com/book/9780596008406/essential-snmp/18.xhtml
SNMPトラップにUDPを使用する利点の1つは、UDPをブロードキャストアドレスに送信し、そのサブネット上の複数の管理ステーションにUDPをフィールドできることです。
通常、SNMPを実行している場合、会社のネットワーク上にいるため、長期にわたってこれを実行しているわけではありません。 UDPはより効率的です。 TCPを介して、次にUDPを介した会話(の大幅な単純化)を見てみましょう...
TCPバージョン:
client sends SYN to server
server sends SYN/ACK to client
client sends ACK to server - socket is now established
client sends DATA to server
server sends ACK to client
server sends RESPONSE to client
client sends ACK to server
client sends FIN to server
server sends FIN/ACK to client
client sends ACK to server - socket is torn down
UDPバージョン:
client sends request to server
server sends response to client
一般に、UDPバージョンは同じサブネット上にあるか、遠く離れていない(つまり、会社のネットワーク上にある)ため成功します。ただし、最初の要求または応答のいずれかに問題がある場合、決定するのはアプリ次第です。 A.紛失したパケットで対処できますか?もしそうなら、気にする人は先に進みましょう。 B.メッセージが送信されたことを確認する必要がありますか?単純で、すべてをやり直します...クライアントはサーバーにリクエストを送信し、サーバーはクライアントにレスポンスを送信します。メッセージの受信者が両方のメッセージを受信した場合に備えて、アプリケーションは番号を提供できます。彼は、それが本当に同じメッセージであることを知っています。
これと同じ手法が、DNSがUDP上で行われる理由です。 DNSリゾルバーの近くにいることになっているので、はるかに軽量で、一般的に初めて動作します。