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

15

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?

Christopher Cashell
źródło

Odpowiedzi:

4

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.

Christopher Cashell
źródło
3

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.

chmeee
źródło
Doceniam odpowiedź, ale szczerze mówiąc, jeśli zbuduję coś samodzielnie, będzie on oparty na snmptrapd Net-SNMP i zaimplementowany w Perlu, ponieważ snmptrapd ma wbudowaną obsługę akceptowania pułapek i wywoływania modułów Perla, aby je obsłużyć. To sprawia, że ​​jest to prostsze i znacznie lepiej obsługiwane (mamy kilkunastu facetów, którzy potrafią poradzić sobie z podstawowym Perlem i jednego, który (ledwo) bawił się Ruby).
Christopher Cashell
1

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.


źródło
0

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].

pQd
źródło
W rzeczywistości nie chcemy, aby obciążenie rozkładało się losowo. Chcemy, aby wszystkie pułapki z danej podsieci trafiły na tę samą maszynę, abyśmy mogli powiązać zdarzenia z określonymi stronami. Obecnie moje reguły IPTables ustawiają miejsce docelowe DNAT na podstawie źródła pułapki.
Christopher Cashell
@Christopher Cashell - wtedy alternatywnie do swojego rozwiązania możesz użyć modułu netfilter u32 do 'hashowania' serwera docelowego na podstawie adresu IP src. np. weź 2 ostatnie bity adresu IP src i rozłóż obciążenie na 4 „konsumentów” snmp. netfilter.org/documentation/HOWTO/…
pQd
@Christopher Cashell stearns.org/doc/iptables-u32.v0.1.html to fajny samouczek dotyczący dopasowania u32. naprzemiennie - spójrz na projekt „wirtualny serwer linux” - mogą one również wykonywać równoważenie obciążenia dla pakietów udp opartych na src / dst ip.
pQd
0

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.

Aleksandar Ivanisevic
źródło
Myślę, że nie rozumiesz. . . Nie próbuję budować pełnego systemu monitorowania, tylko router pułapki SNMP. Mamy tutaj 5000 urządzeń sieciowych i setki tysięcy portów, które tutaj monitorujemy. Nie ma mowy, żebym wymyślił to koło na nowo. . . po prostu próbujemy ulepszyć narzędzia, które mamy, działają lepiej.
Christopher Cashell
Zrozumiałem dobrze, prawdopodobnie mnie nie zrozumiałeś;) JMS jest używany jako transport, ponieważ nowi brokerzy mają te wszystkie fajne funkcje przełączania awaryjnego, odporności i równoważenia. Możesz POST na adres URL, wysłać e-mail, SOAP, cokolwiek działa. UDP nigdy nie został zbudowany w taki sposób, aby był niezawodny lub zrównoważony, ponieważ nie ma koncepcji strumienia danych ani kontroli przepływu. Na dłuższą metę będziesz po prostu przykręcony, próbując zmusić UDP do zrobienia tego, do czego nie został zaprojektowany.
Aleksandar Ivanisevic
Doceniam tę sugestię, ale tak naprawdę nie mam absolutnie żadnego zamiaru ani zainteresowania budowaniem własnego systemu monitorowania sieci na poziomie przedsiębiorstwa. Istnieje już wiele z nich, a wdrożenie jednego z wymaganym zestawem funkcji i skalowalnością wymagałoby zespołu kilkunastu programistów przez 2-4 lata. To nie jest wykonalne ani pożądane. To pozostawia mi interakcję z istniejącymi systemami i pozwala mi radzić sobie z dużą ilością SNMP przez UDP.
Christopher Cashell
0

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.

Pik Master
źródło