Решение для маршрутизации / прокси SNMP Traps (или Netflow, универсальный UDP и т. Д.) Для мониторинга сети?

Я внедряю решение для мониторинга сети для очень большой сети (около 5000 сетевых устройств). Мы хотели бы, чтобы все устройства в нашей сети отправляли ловушки SNMP в один ящик (технически это, вероятно, будет пара блоков HA), а затем передавали этот ловушку SNMP ловушкам в реальные блоки обработки. Это позволит нам иметь несколько внутренних блоков, обрабатывающих ловушки, и распределять нагрузку между этими внутренними блоками.

Одна ключевая особенность, которая нам нужна, - это возможность пересылать ловушки в конкретный ящик в зависимости от исходного адреса ловушки. Любые предложения для лучшего способа справиться с этим?

Среди вещей, которые мы рассмотрели:

• Использование snmptrapd для принятия ловушек и передачи их в специальный сценарий обработчика perl, чтобы переписать ловушку и отправить ее в соответствующий блок обработки
• Для этого используется какое-то программное обеспечение для балансировки нагрузки, работающее на Linux, (возникают трудности с поиском многих программ балансировки нагрузки, которые будут обрабатывать UDP)
• Использование устройства балансировки нагрузки (F5 и т. Д.)
• Использование IPTables на Linux-боксе для маршрутизации SNMP-ловушек с NATing

В настоящее время мы внедрили и тестируем последнее решение. Ящик Linux с IPTables настроен на прием прерываний, а затем, в зависимости от исходного адреса прерывания, переписывает его с помощью 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-дейтаграммы на сетевом порту и отправляет копии этих дейтаграмм на множество адресатов. Опционально, он может выполнять выборку, то есть, вместо того, чтобы пересылать каждый пакет, пересылать только 1 в N. Другой вариант заключается в том, что он может «подделывать» IP-адрес источника, так что копии выглядят поступающими из исходного источника, а не из ретранслятора. , В настоящее время поддерживается только IPv4.

Его можно использовать, например, для распространения пакетов Netflow, прерываний SNMP (но не для информирования) или сообщений системного журнала среди нескольких получателей.

Я бы сам решил внедрить решение, так как не знаю, найдете ли вы что-то конкретное, как вы хотите.

Я бы использовал язык высокого уровня, такой как 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 .

Если вы сохраняете это простым и определяете хорошие объекты, вы можете поддерживать программное обеспечение без особых усилий.

Ваша главная проблема будет, как вы узнаете фактический IP-адрес устройства, с которого вы получаете ловушки?

Если вы используете SNMP v1, вы можете отключить ip от заголовка ловушки. Если вы используете ловушки v2 или v3, вам нужно будет сопоставить идентификатор snmpengine с ip, который вы ранее извлекли с устройства. Engineid, как правило, не является обязательным элементом конфигурации для большинства реализаций SNMP, и, следовательно, вы не можете полностью полагаться на него в одиночку.

Резервным вариантом является то, что вы можете использовать исходный ip из заголовка пакета udp. Конечно, это не удастся, если ваша ловушка направлена ​​через другую EMS / NMS или если у вас есть NAT между устройством и вашим приложением mgmt.

1. Если вам не нужно поддерживать переадресацию NAT / переадресованных сообщений от других NMS, просто скопируйте пакет udp и выполните маршрутизацию на основе ip

2. Если вам нужно это поддержать, вам нужно проанализировать ловушку SNMP и проверить соответствие идентификатора механизма для v2 / v3, для v1 вы можете прочитать его в поле адреса агента в заголовке SNMP.

еще один взлом на основе сетевого фильтра:

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.