用于网络监视的路由/代理SNMP陷阱（或Netflow，通用UDP等）的解决方案？

我正在为一个非常大的网络（大约5000个网络设备）实施网络监视解决方案。我们希望网络上的所有设备都将SNMP陷阱发送到一个盒子（从技术上讲，这可能是一对HA盒子），然后让该盒子将SNMP陷阱传递到真实的处理盒子上。这将使我们拥有多个处理陷阱的后端盒，并在这些后端盒之间分配负载。

我们需要的一项关键功能是能够根据陷阱的源地址将陷阱转发到特定的盒子。对解决此问题的最佳方法有何建议？

我们考虑过的事情包括：

• 使用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数据包。能够捕获一个进入的陷阱并将其路由到多个目的地将非常有用。

是否有人尝试过上述任何可行的SNMP陷阱（或Netflow，通用UDP等）负载平衡解决方案？还是有人可以想到其他解决方案吗？

一位同事刚给我看了抽样者。该工具似乎是我一直在寻找的完美解决方案。从该工具的网站：

这个简单的程序侦听网络端口上的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相关联。对于大多数SNMP实现，Engineid通常不是必需的配置项，因此您不能完全依靠它。

缺点是您可以使用udp数据包头中的源ip。当然，如果陷阱是通过另一个EMS / NMS路由的，或者设备与mgmt应用程序之间有NAT，这将失败。

1. 如果您不需要支持其他NMS的NAT /转发陷阱，则只需复制udp数据包，然后根据ip进行路由

2. 如果需要支持，则必须解析SNMP陷阱并检查v2 / v3的引擎ID匹配，对于v1，您可以从SNMP标头中的agent-address字段读取它。

另一种基于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]

只要您有一个一包长的snmp陷阱-这样就可以很好地分散负载-在这种情况下，可以跨越3台计算机。[尽管我还没有测试]。

我认为chmeee的答案是正确的方法。尽早删除UDP和SNMP，它们很容易管理。

我现在正在构建一个系统，该系统会将所有事件（包括陷阱）放入JMS队列，然后利用企业消息传递的所有奇迹来进行负载平衡和故障转移。

您的主要问题将是，您如何知道接收陷阱的设备的实际IP？

要获取原始发件人的IP，你可以尝试使用这个补丁以修补snmptrapd - https://sourceforge.net/p/net-snmp/patches/1320/#6afe。

这会修改有效负载，因此IP标头将保持不变，因此它们不会进入您的路由和/或NATting。