Рішення для маршрутних / проксі SNMP пасток (або 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 на Н. Інший варіант полягає в тому, що він може "підробляти" IP-адресу джерела, так що, здається, копії надходять з вихідного джерела, а не ретранслятора . На даний момент підтримується лише IPv4.

Він може використовуватися для розповсюдження, наприклад, пакетів Netflow, SNMP-пасток (але не інформує) або Syslog-повідомлення на декілька приймачів.

Я б пішов на реалізацію рішення сам, тому що не знаю, чи знайдете ви щось таке специфічне, як ви хочете.

Я б використовував мову високого рівня, як рубін, для виконання правил балансу і навіть слухача пасток. Наприклад, використовувати цю бібліотеку здається просто .

Слухайте пастки:

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

Щоб створити демон, ви можете використовувати рубінову дорогоцінну дорогу з набору демона .

Якщо ви будете просто і визначати хороші об'єкти, ви можете підтримувати програмне забезпечення не дуже багато зусиль.

Ваша основна проблема полягає в тому, як дізнатися фактичний 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.

ще один хакер на основі 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, що мають один пакет, - це повинно добре розповсюджуватися - у цьому випадку на трьох машинах. [хоча я цього не перевіряв].

Я думаю, що відповідь від chmeee - це правильний шлях. Позбудьтеся UDP та SNMP якнайшвидше, ними можна керувати.

Зараз я будую систему, яка розміщуватиме всі події (включаючи пастки) на черзі JMS, а потім використовую всі чудеса обміну повідомленнями підприємств, щоб зробити балансування навантаження та відмову.

Ваша основна проблема полягає в тому, як дізнатися фактичний ip пристрою, з якого ви отримуєте пастки?

Щоб отримати вихідний IP-адресу відправника, ви можете спробувати промацувати snmptrapd цим патчем - https://sourceforge.net/p/net-snmp/patches/1320/#6afe .

Це змінює корисну навантаження, тому IP-заголовки залишатимуться недоторканими, тому вони не потраплять у вашу маршрутизацію та / або NATting.