Rozwiązanie trasy / pułapek SNMP Traps (lub Netflow, ogólny UDP itp.) Do monitorowania sieci?

Wdrażam rozwiązanie do monitorowania sieci dla bardzo dużej sieci (około 5000 urządzeń sieciowych). Chcielibyśmy, aby wszystkie urządzenia w naszej sieci wysyłały pułapki SNMP do pojedynczego urządzenia (technicznie prawdopodobnie będzie to para urządzeń HA), a następnie aby urządzenie to przesyłało pułapki SNMP do rzeczywistych urządzeń przetwarzających. Pozwoli nam to na posiadanie wielu skrzynek zaplecza obsługujących pułapki i rozdzielenie obciążenia między te skrzynki.

Jedną z kluczowych funkcji, których potrzebujemy, jest możliwość przekazywania pułapek do określonego pudełka w zależności od adresu źródłowego pułapki. Wszelkie sugestie dotyczące najlepszego sposobu rozwiązania tego problemu?

Rozważaliśmy między innymi:

• Używanie snmptrapd do akceptowania pułapek i przekazywania ich do niestandardowego napisanego skryptu obsługi perla w celu przepisania pułapki i wysłania jej do odpowiedniego pola przetwarzania
• Korzystanie z jakiegoś oprogramowania do równoważenia obciążenia działającego na Linux-ie, aby to obsłużyć (trudności z odnalezieniem wielu programów do równoważenia obciążenia, które będą obsługiwały UDP)
• Korzystanie z urządzenia do równoważenia obciążenia (F5 itp.)
• Używanie IPTables na Linux-ie do trasowania pułapek SNMP z NATingiem

Obecnie wdrożyliśmy i testujemy ostatnie rozwiązanie, używając Linux-a z IPTables skonfigurowanymi do odbierania pułapek, a następnie, w zależności od adresu źródłowego pułapki, przepisz go docelowym nat (DNAT), aby pakiet został wysłany do właściwy serwer. Na przykład:

# 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

Powinno to działać z doskonałą wydajnością dla podstawowego routingu pułapek, ale pozostawia nas całkowicie ograniczone do tego, co możemy obrabiać i filtrować za pomocą IPTables, dlatego martwimy się o elastyczność na przyszłość.

Inną funkcją, która naprawdę nam się podoba, ale nie jest „koniecznością”, jest możliwość duplikowania lub dublowania pakietów UDP. Bardzo przydatna byłaby możliwość wzięcia jednej przychodzącej pułapki i skierowania jej do wielu miejsc docelowych.

Czy ktoś wypróbował dowolne z powyższych rozwiązań równoważenia obciążeń SNMP (lub Netflow, ogólne UDP itp.)? Czy ktoś może wymyślić inne alternatywy, aby rozwiązać ten problem?

Współpracownik właśnie pokazał mi samplicator . To narzędzie wydaje się być idealnym rozwiązaniem, którego szukałem. Ze strony internetowej narzędzia:

Ten prosty program nasłuchuje datagramów UDP na porcie sieciowym i wysyła kopie tych datagramów do zestawu miejsc docelowych. Opcjonalnie może wykonać próbkowanie, tzn. Zamiast przekazywać każdy pakiet, przekierować tylko 1 w N. Inną opcją jest to, że może „sfałszować” adres źródłowy IP, dzięki czemu kopie wydają się pochodzić z oryginalnego źródła, a nie z przekaźnika . Obecnie obsługuje tylko IPv4.

Można go wykorzystać do dystrybucji np. Pakietów Netflow, pułapek SNMP (ale nie informuje) lub wiadomości Syslog do wielu odbiorców.

Sam bym wdrożył rozwiązanie, ponieważ nie wiem, czy znajdziesz coś tak konkretnego, jak chcesz.

Używałbym języka wysokiego poziomu, takiego jak ruby, aby zaimplementować reguły równowagi, a nawet detektora pułapek. Na przykład korzystanie z tych bibliotek wydaje się łatwe .

Słuchaj pułapek:

m = SNMP::TrapListener.new(:Port => 1062, :Community => 'public') do |manager|
  manager.on_trap_default { |trap| p trap }
end
m.join

Powinieneś dodać logikę równowagi w on_trap_defaultbloku.

Wysyłaj pułapki:

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

Aby zbudować demona, możesz użyć rubinowego klejnotu daemon-kit .

Jeśli upraszczasz to i definiujesz dobre obiekty, możesz utrzymywać oprogramowanie bez większego wysiłku.

Twoim głównym problemem będzie, skąd znasz rzeczywiste IP urządzenia, z którego otrzymujesz pułapki?

Jeśli używasz SNMP v1, możesz pobrać ip z nagłówka pułapki. Jeśli używasz pułapek v2 lub v3, musisz skorelować identyfikator snmpengine z adresem IP, który wcześniej pobrałeś z urządzenia. Engineid zazwyczaj nie jest obowiązkowym elementem konfiguracji dla większości implementacji SNMP, a zatem nie można w pełni polegać na tym samym.

Awarią jest to, że możesz użyć źródłowego adresu IP z nagłówka pakietu udp. Oczywiście, to się nie powiedzie, jeśli twoja pułapka jest poprowadzona przez inny EMS / NMS lub jeśli masz NAT pomiędzy urządzeniem a aplikacją mgmt.

1. Jeśli nie potrzebujesz obsługi pułapek NAT / przekazanych z innych NMS, po prostu zrób kopię pakietu udp i trasuj na podstawie adresu IP

2. Jeśli chcesz to obsługiwać, musisz przeanalizować pułapkę SNMP i sprawdzić, czy identyfikator silnika odpowiada v2 / v3, w przypadku v1 możesz odczytać ją z pola adresu agenta w nagłówku SNMP.

jeszcze jeden hack oparty na filtrach sieciowych:

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

[założenie - wszystkie pułapki są wysyłane do 10.0.0.1, który następnie przekierowuje je do 10.0.0.2, 10.0.0.3, 10.0.0.4]

pod warunkiem, że masz pułapki snmp o długości jednego pakietu - powinno to ładnie rozkładać obciążenie - w tym przypadku na 3 komputerach. [chociaż go nie testowałem].

Myślę, że odpowiedź od chmeee jest właściwą drogą. Pozbądź się UDP i SNMP tak wcześnie, jak to możliwe, są okropne w zarządzaniu.

Buduję teraz system, który umieści wszystkie zdarzenia (w tym pułapki) w kolejce JMS, a następnie wykorzystam wszystkie cuda związane z komunikacją korporacyjną do równoważenia obciążenia i przełączania awaryjnego.

Twoim głównym problemem będzie, skąd znasz rzeczywiste IP urządzenia, z którego otrzymujesz pułapki?

Aby uzyskać adres IP pierwotnego nadawcy, możesz spróbować załatać snmptrapd za pomocą tej poprawki - https://sourceforge.net/p/net-snmp/patches/1320/#6afe .

To modyfikuje ładunek, więc nagłówki IP pozostaną nienaruszone, aby nie dostały się do twojego routingu i / lub NATtingu.