Lösung zum Weiterleiten / Proxy-SNMP-Traps (oder Netflow, generisches UDP usw.) für die Netzwerküberwachung?

Ich implementiere eine Netzwerküberwachungslösung für ein sehr großes Netzwerk (ca. 5000 Netzwerkgeräte). Wir möchten, dass alle Geräte in unserem Netzwerk SNMP-Traps an eine einzelne Box senden (technisch handelt es sich wahrscheinlich um ein HA-Paar von Boxen) und diese Box die SNMP-Traps dann an die realen Verarbeitungsboxen weiterleiten lässt. Auf diese Weise können mehrere Back-End-Boxen Fallen verwalten und die Last auf diese Back-End-Boxen verteilen.

Eine wichtige Funktion, die wir benötigen, ist die Möglichkeit, die Traps abhängig von der Quelladresse der Trap an eine bestimmte Box weiterzuleiten. Irgendwelche Vorschläge, wie Sie am besten damit umgehen können?

Unter den Dingen, die wir betrachtet haben, sind:

• Verwenden Sie snmptrapd, um die Traps zu akzeptieren, und geben Sie sie an ein benutzerdefiniertes Perl-Handler-Skript weiter, um die Trap neu zu schreiben und an die richtige Verarbeitungsbox zu senden
• Verwenden einer Art von Lastausgleichs-Software, die auf einer Linux-Box ausgeführt wird, um dies zu handhaben (es gibt einige Schwierigkeiten, viele Lastausgleichsprogramme zu finden, die mit UDP umgehen können)
• Verwenden einer Load Balancing-Appliance (F5 usw.)
• Verwenden von IPTables auf einer Linux-Box zum Weiterleiten der SNMP-Traps mit NAT

Wir haben die letzte Lösung derzeit implementiert und testen sie mit einer Linux-Box mit IPTables, die für den Empfang der Traps konfiguriert ist, und schreiben sie dann abhängig von der Quelladresse der Traps mit einem Ziel-Nat (DNAT) neu, damit das Paket gesendet wird der richtige Server. Beispielsweise:

# 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

Dies sollte für das grundlegende Trap-Routing mit hervorragender Effizienz funktionieren, lässt uns jedoch völlig auf das beschränkt, was wir mit IPTables bearbeiten und filtern können, sodass wir uns Sorgen um die Flexibilität für die Zukunft machen.

Ein weiteres Merkmal , dass wir würden wirklich wie, ist aber nicht ganz ein „must have“ ist die Fähigkeit , die UDP - Pakete zu duplizieren oder zu spiegeln. In der Lage zu sein, eine eingehende Falle zu nehmen und sie an mehrere Ziele weiterzuleiten, wäre sehr nützlich.

Hat jemand eine der oben genannten möglichen Lösungen für SNMP-Traps (oder Netflow, allgemeines UDP usw.) für den Lastenausgleich ausprobiert? Oder kann sich jemand andere Alternativen vorstellen, um dies zu lösen?

Ein Mitarbeiter hat mir gerade einen Samplicator gezeigt . Dieses Tool scheint eine perfekte Lösung zu sein, wonach ich gesucht habe. Von der Website des Tools:

Dieses einfache Programm wartet auf UDP-Datagramme an einem Netzwerkport und sendet Kopien dieser Datagramme an eine Reihe von Zielen. Optional kann es Sampling durchführen, dh, anstatt jedes Paket weiterzuleiten, nur 1 in N weiterleiten. Eine andere Option besteht darin, dass die IP-Quelladresse "gefälscht" werden kann, sodass die Kopien anscheinend von der Originalquelle und nicht vom Relay stammen . Unterstützt derzeit nur IPv4.

Es kann verwendet werden, um z. B. Netflow-Pakete, SNMP-Traps (aber keine Informationen) oder Syslog-Nachrichten an mehrere Empfänger zu verteilen.

Ich würde die Lösung selbst implementieren, da ich nicht weiß, ob Sie etwas finden, das so spezifisch ist, wie Sie möchten.

Ich würde eine Hochsprache wie Ruby verwenden, um die Balance-Regeln und sogar den Trap-Listener zu implementieren. Zum Beispiel scheint die Verwendung dieser Bibliotheken einfach .

Hören Sie auf Fallen:

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

Sie sollten die Balance-Logik im on_trap_defaultBlock hinzufügen .

Traps senden:

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

Um den Daemon zu erstellen, können Sie das Daemon-Kit Ruby Gem verwenden.

Wenn Sie es einfach halten und gute Objekte definieren, können Sie die Software ohne großen Aufwand warten.

Ihr Hauptproblem wird sein, woher wissen Sie, von welcher IP-Adresse des Geräts Sie die Traps empfangen?

Wenn Sie SNMP v1 verwenden, können Sie die IP-Adresse aus dem Header des Traps entfernen. Wenn Sie v2- oder v3-Traps verwenden, müssen Sie die snmpengine-ID mit der IP-Adresse korrelieren, die Sie zuvor vom Gerät abgerufen haben. Engineid ist normalerweise kein obligatorisches Konfigurationselement für die meisten SNMP-Implementierungen, und daher können Sie sich nicht allein darauf verlassen.

Der Fallback besteht darin, dass Sie die Quell-IP aus dem UDP-Paket-Header verwenden können. Natürlich schlägt dies fehl, wenn Ihr Trap über ein anderes EMS / NMS geleitet wird oder wenn Sie eine NAT zwischen dem Gerät und Ihrer mgmt-Anwendung haben.

1. Wenn Sie keine Unterstützung für NAT / weitergeleitete Traps von anderen NMS benötigen, erstellen Sie einfach eine Kopie des udp-Pakets und leiten Sie es basierend auf der IP weiter

2. Wenn Sie dies unterstützen möchten, müssen Sie den SNMP-Trap analysieren und auf Übereinstimmung mit der Engine-ID für v2 / v3 prüfen. Für v1 können Sie ihn aus dem Feld für die Agentenadresse im SNMP-Header ablesen.

Noch ein Netfilter-basierter 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

[Annahme - Alle Traps werden an 10.0.0.1 gesendet, der sie dann an 10.0.0.2, 10.0.0.3, 10.0.0.4 weiterleitet.]

Solange Sie ein Paket lange snmp-Traps haben - dies sollte die Last gut verteilen -, in diesem Fall auf 3 Maschinen. [obwohl ich es nicht getestet habe].

Ich denke, die Antwort von chmeee ist der richtige Weg. Befreien Sie sich von UDP und SNMP so früh wie möglich, da deren Verwaltung schrecklich ist.

Ich baue jetzt ein System auf, das alle Ereignisse (einschließlich Traps) in eine JMS-Warteschlange stellt und dann alle Vorteile von Enterprise Messaging für den Lastenausgleich und das Failover nutzt.

Ihr Hauptproblem wird sein, woher wissen Sie, von welcher IP-Adresse des Geräts Sie die Traps empfangen?

Um die IP des ursprünglichen Absenders zu erhalten, können Sie versuchen, den snmptrapd mit diesem Patch zu patchen - https://sourceforge.net/p/net-snmp/patches/1320/#6afe .

Dadurch wird die Nutzlast geändert, sodass die IP-Header intakt bleiben und nicht in Ihr Routing und / oder NATting gelangen.