☰

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

tag-icon • tag-icon load-balancing snmp network-monitoring udp netflow
用于网络监控的路由/代理 SNMP 陷阱（或 Netflow、通用 UDP 等）的解决方案？

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

我们需要的一个关键功能是能够根据陷阱的源地址将陷阱转发到特定的框。有什么建议可以最好地处理这个问题吗？

我们考虑的事情包括：

  • 使用 snmptrapd 接受陷阱，并让其将其传递给自定义编写的 perl 处理程序脚本，以重写陷阱并将其发送到适当的处理框
  • 使用在 Linux 机器上运行的某种负载平衡软件来处理这个问题（找到许多可以处理 UDP 的负载平衡程序有些困难）
  • 使用负载平衡设备（F5 等）
  • 在 Linux 机器上使用 IPTables 通过 NATing 路由 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 等）负载平衡的可能解决方案？或者有人能想到其他解决这个问题的办法吗？

答案1

一位同事刚刚给我看了取样器。这个工具看起来就是我所寻找的完美解决方案。摘自该工具的网站：

这个简单的程序监听网络端口上的 UDP 数据报，并将这些数据报的副本发送到一组目的地。它还可以执行采样，即不转发每个数据包，而是只转发 N 中的 1 个。另一个选项是它可以“欺骗” IP 源地址，这样副本看起来就像来自原始源，而不是中继。目前仅支持 IPv4。

它可用于将 Netflow 数据包、SNMP 陷阱（但不通知）或 Syslog 消息分发给多个接收器。

答案2

我会自己去实施解决方案，因为我不知道你是否能找到你想要的具体的东西。

我会使用像 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

要构建守护进程，您可以使用守护进程套件红宝石。

如果您保持简单并定义好的对象，您可以轻松维护软件。

答案3

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

如果您使用的是 SNMP v1，则可以从陷阱的标头中获取 IP。如果您使用的是 v2 或 v3 陷阱，则需要将 snmpengine id 与您之前从设备获取的 IP 关联起来。对于大多数 SNMP 实现，Engineid 通常不是必需的配置项，因此您不能完全依赖它。

后备方案是，您可以使用 udp 数据包头中的源 ip。当然，如果您的陷阱通过另一个 EMS/NMS 路由，或者设备和管理应用程序之间有 NAT，则此方法会失败。

  1. 如果你不需要支持来自其他 NMS 的 NAT/转发陷阱，那么只需复制 udp 数据包，并根据 ip 进行路由

  2. 如果您需要支持这一点，您必须解析 SNMP 陷阱并检查 v2/v3 的引擎 ID 是否匹配，对于 v1，您可以从 SNMP 标头中的代理地址字段读取它。

答案4

我认为 chmeee 的答案是正确的。在流程的早期阶段，尽可能摆脱 UDP 和 SNMP，因为它们很难管理。

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

相关内容