主页 / server / 问题 / 37297
Accepted
Christopher Cashell
Asked: 2009-07-08 11:49:19 +0800 CST

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

  • 772

我正在为一个非常大的网络（大约 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 等）负载平衡解决方案？或者任何人都可以想到任何其他替代方案来解决这个问题？

load-balancing snmp network-monitoring udp netflow

6 个回答

  1. Best Answer

    一位同事刚刚给我看了采样器。这个工具看起来是我一直在寻找的完美解决方案。从该工具的网站：

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

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

    • 4

  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

    要构建守护进程，您可以使用daemon-kit ruby​​ gem。

    如果您保持简单并定义好的对象，您可以毫不费力地维护软件。

    • 3

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

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

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

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

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

    • 1

  4. 另一个基于 netfilter 的 hack：

    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 台机器。[虽然我没有测试过]。

    • 0

  5. 我认为 chmeee 的答案是正确的方法。尽早摆脱 UDP 和 SNMP，它们很难管理。

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

    • 0

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

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

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

    • 0

相关问题