ネットワーク監視のためにSNMPトラップ（またはNetflow、汎用UDPなど）をルーティング/プロキシするソリューションですか？

非常に大規模なネットワーク（約5000台のネットワークデバイス）にネットワーク監視ソリューションを実装しています。ネットワーク上のすべてのデバイスが単一のボックスにSNMPトラップを送信し（技術的にはこれはおそらくHAペアのボックスになります）、そのボックスにSNMPトラップを実際の処理ボックスに渡すようにします。これにより、トラップを処理する複数のバックエンドボックスを使用し、それらのバックエンドボックス間で負荷を分散できます。

必要な重要な機能の1つは、トラップのソースアドレスに応じて特定のボックスにトラップを転送する機能です。これを処理する最良の方法に関する提案はありますか？

私たちが検討したものの中には：

• snmptrapdを使用してトラップを受け入れ、カスタム記述されたperlハンドラスクリプトに渡して、トラップを書き換えて適切な処理ボックスに送信します。
• Linuxボックスで実行されている何らかの負荷分散ソフトウェアを使用してこれを処理します（UDPを処理する多くの負荷分散プログラムを見つけるのは多少困難です）
• 負荷分散アプライアンスの使用（F5など）
• LinuxボックスでIPTablesを使用して、NATでSNMPトラップをルーティングする

現在、トラップを受信するようにIPTablesが設定されたLinuxボックスを使用して最後のソリューションを実装し、テストしています。次に、トラップの送信元アドレスに応じて、パケットが送信されるように宛先nat（DNAT）で書き換えます適切なサーバー。例えば：

# Range: 10.0.0.0/19       Site: abc01    Destination: foo01
iptables -t nat -A PREROUTING -p udp --dport 162 -s 10.0.0.0/19 -j DNAT --to-destination 10.1.2.3
# Range: 10.0.33.0/21       Site: abc01    Destination: foo01
iptables -t nat -A PREROUTING -p udp --dport 162 -s 10.0.33.0/21 -j DNAT --to-destination 10.1.2.3
# Range: 10.1.0.0/16       Site: xyz01    Destination: bar01
iptables -t nat -A PREROUTING -p udp --dport 162 -s 10.1.0.0/16 -j DNAT --to-destination 10.3.2.1

これは基本的なトラップルーティングに対して優れた効率で機能するはずですが、IPTablesを使用してフィルター処理できるものに完全に制限されているため、将来の柔軟性が懸念されます。

私たちが本当に望んでいるが、「必須」ではない別の機能は、UDPパケットを複製またはミラーリングする機能です。1つの着信トラップを取得し、それを複数の宛先にルーティングできると非常に便利です。

SNMPトラップ（またはNetflow、一般的なUDPなど）の負荷分散のために、上記の解決策を試した人はいますか？それとも、誰かがこれを解決する他の選択肢を考えることができますか？

同僚がサンプリケーターを見せてくれました。このツールは、まさに私が探していた完璧なソリューションのようです。ツールのWebサイトから：

この単純なプログラムは、ネットワークポートでUDPデータグラムをリッスンし、これらのデータグラムのコピーを一連の宛先に送信します。オプションとして、サンプリングを実行できます。つまり、すべてのパケットを転送するのではなく、Nの1つだけを転送します。別のオプションは、IPソースアドレスを「スプーフィング」できるため、コピーがリレーではなく元のソースから来ているように見えることです。現在、IPv4のみをサポートしています。

Netflowパケット、SNMPトラップ（インフォームではない）、Syslogメッセージなどを複数の受信者に配信するために使用できます。

あなたが望むほど具体的なものを見つけるかどうかはわかりませんので、私は自分でソリューションを実装します。

私は、Rubyのような高レベル言語を使用して、バランスルール、さらにはトラップリスナーを実装します。たとえば、このライブラリの 使用は 簡単に思えます。

トラップを聞く：

m = SNMP::TrapListener.new(:Port => 1062, :Community => 'public') do |manager|
  manager.on_trap_default { |trap| p trap }
end
m.join

on_trap_defaultブロックにバランスロジックを追加する必要があります。

トラップを送信：

Manager.open(:Version => :SNMPv1) do |snmp|
  snmp.trap_v1(
    "enterprises.9",
    "10.1.2.3",
    :enterpriseSpecific,
    42,
    12345,
    [VarBind.new("1.3.6.1.2.3.4", Integer.new(1))])
end

デーモンを構築するには、daemon-kit ruby gemを使用できます。

シンプルに保ち、適切なオブジェクトを定義すれば、それほど労力をかけずにソフトウェアを保守できます。

あなたの主な問題は、トラップを受信して​​いるデバイスの実際のIPをどのように知るのでしょうか？

SNMP v1を使用している場合、トラップのヘッダーからIPを取得できます。v2またはv3トラップを使用している場合、snmpengine idを以前にデバイスから取得したIPに関連付ける必要があります。Engineidは通常、ほとんどのSNMP実装の必須の構成アイテムではないため、それだけでは完全に信頼できません。

フォールバックは、udpパケットヘッダーからソースIPを使用できることです。もちろん、トラップが別のEMS / NMSを経由する場合、またはデバイスとmgmtアプリケーションの間にNATがある場合、これは失敗します。

1. 他のNMSからのNAT /転送トラップをサポートする必要がない場合は、udpパケットのコピーを作成し、ipに基づいてルーティングします

2. それをサポートする必要がある場合、SNMPトラップを解析し、v2 / v3のエンジンIDの一致を確認する必要があります。v1の場合、SNMPヘッダーのagent-addressフィールドから読み取ることができます。

もう1つのnetfilterベースのハック：

iptables -t nat -A PREROUTING -d 10.0.0.1 -p udp --dport 162 -m random --average 33 -j DNAT --to-destination 10.0.0.2:162
iptables -t nat -A PREROUTING -d 10.0.0.1 -p udp --dport 162 -m random --average 33 -j DNAT --to-destination 10.0.0.3:162
# everything else goes to other consumer
iptables -t nat -A PREROUTING -d 10.0.0.1 -p udp --dport 162 -j DNAT --to-destination 10.0.0.4:162

[前提-すべてのトラップは10.0.0.1に送信され、10.0.0.2、10.0.0.3、10.0.0.4にリダイレクトされます]

1パケット長のSNMPトラップがある限り-これは負荷をうまく分散させるはずです-この場合は3台のマシンにまたがっています。[私はそれをテストしていませんが]。

chmeeeからの答えは正しい道だと思います。プロセスのできるだけ早い段階でUDPとSNMPを削除します。これらは管理が大変です。

現在、すべてのイベント（トラップを含む）をJMSキューに配置し、エンタープライズメッセージングの不思議をすべて使用して負荷分散とフェイルオーバーを実行するシステムを構築しています。

あなたの主な問題は、トラップを受信して​​いるデバイスの実際のIPをどのように知るのでしょうか？

元の送信者のIPを取得するには、このパッチ（https://sourceforge.net/p/net-snmp/patches/1320/#6afe）で snmptrapdにパッチを当てることができます。

これによりペイロードが変更されるため、IPヘッダーはそのまま保持されるため、ルーティングやNAT処理に入らないようになります。