Solution pour acheminer / proxy Traps SNMP (ou Netflow, UDP générique, etc.) pour la surveillance du réseau?


15

J'implémente une solution de surveillance réseau pour un très grand réseau (environ 5000 périphériques réseau). Nous aimerions que tous les appareils de notre réseau envoient des interruptions SNMP à une seule boîte (techniquement, ce sera probablement une paire de boîtes HA), puis que cette boîte transmette les interruptions SNMP aux vraies boîtes de traitement. Cela nous permettra d'avoir plusieurs boîtiers dorsaux manipulant des pièges et de répartir la charge entre ces boîtiers dorsaux.

Une fonctionnalité clé dont nous avons besoin est la possibilité de transmettre les pièges à une boîte spécifique en fonction de l'adresse source du piège. Des suggestions sur la meilleure façon de gérer cela?

Nous avons notamment envisagé:

  • Utilisation de snmptrapd pour accepter les interruptions et les faire passer à un script de gestionnaire perl écrit personnalisé pour réécrire l'interruption et l'envoyer dans la boîte de traitement appropriée
  • Utiliser une sorte de logiciel d'équilibrage de charge fonctionnant sur une boîte Linux pour gérer cela (avoir du mal à trouver de nombreux programmes d'équilibrage de charge qui géreront UDP)
  • Utilisation d'un dispositif d'équilibrage de charge (F5, etc.)
  • Utilisation d'IPTables sur une boîte Linux pour router les pièges SNMP avec NATing

Nous avons actuellement implémenté et testons la dernière solution, avec une boîte Linux avec IPTables configurée pour recevoir les interruptions, puis en fonction de l'adresse source de l'interruption, réécrivez-la avec une destination nat (DNAT) pour que le paquet soit envoyé à le bon serveur. Par exemple:

# 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

Cela devrait fonctionner avec une excellente efficacité pour le routage de piège de base, mais cela nous laisse complètement limités à ce que nous pouvons mach et filtrer avec IPTables, nous sommes donc préoccupés par la flexibilité pour l'avenir.

Une autre fonctionnalité que nous aimerions vraiment , mais qui n'est pas tout à fait un "must have" est la possibilité de dupliquer ou de refléter les paquets UDP. Être capable de prendre un piège entrant et de l'acheminer vers plusieurs destinations serait très utile.

Quelqu'un a-t-il essayé l'une des solutions possibles ci-dessus pour les interruptions SNMP (ou Netflow, UDP général, etc.)? Ou peut-on penser à d'autres alternatives pour résoudre ce problème?

Réponses:


4

Un collègue vient de me montrer un échantillonneur . Cet outil semble être à peu près une solution parfaite ce que je cherchais. Depuis le site Web de l'outil:

Ce programme simple écoute les datagrammes UDP sur un port réseau et envoie des copies de ces datagrammes à un ensemble de destinations. En option, il peut effectuer un échantillonnage, c'est-à-dire que plutôt que de transmettre chaque paquet, ne transmettre que 1 en N. Une autre option est qu'il peut "usurper" l'adresse source IP, de sorte que les copies semblent provenir de la source d'origine, plutôt que du relais . Actuellement, prend uniquement en charge IPv4.

Il peut être utilisé pour distribuer, par exemple, des paquets Netflow, des interruptions SNMP (mais pas des informations) ou des messages Syslog à plusieurs récepteurs.


3

J'irais implémenter la solution moi-même, car je ne sais pas si vous trouverez quelque chose d'aussi spécifique que vous le souhaitez.

J'utiliserais un langage de haut niveau comme ruby ​​pour implémenter les règles d'équilibre et même l'écouteur de trap. Par exemple, l'utilisation de ces bibliothèques semble facile .

Écoutez les pièges:

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

Vous devez ajouter la logique d'équilibre dans le on_trap_defaultbloc.

Envoyer des pièges:

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

Pour construire le démon, vous pouvez utiliser la gemme ruby ​​du kit démon .

Si vous restez simple et définissez de bons objets, vous pouvez maintenir le logiciel sans trop d'efforts.


J'apprécie la réponse, mais honnêtement, si je construis quelque chose moi-même, il sera basé sur snmptrapd de Net-SNMP et implémenté en Perl, car snmptrapd a un support intégré pour accepter les pièges et appeler les modules Perl pour les gérer. Cela le rend plus simple et beaucoup mieux pris en charge (nous avons une douzaine de gars qui peuvent gérer Perl de base et un gars qui joue (à peine) avec Ruby).
Christopher Cashell

1

Votre problème principal va être, comment savez-vous l'IP réelle de l'appareil dont vous recevez les pièges?

Si vous utilisez SNMP v1, vous pouvez retirer l'ip de l'en-tête du piège. Si vous utilisez des interruptions v2 ou v3, vous devrez corréler l'ID snmpengine à l'IP que vous avez précédemment récupérée à partir de l'appareil. Engineid n'est généralement pas un élément de configuration obligatoire pour la plupart des implémentations SNMP, et vous ne pouvez donc pas compter entièrement sur cela seul.

Le repli est que vous pouvez utiliser l'ip source à partir de l'en-tête du paquet udp. Bien sûr, cela échouera si votre interruption est acheminée via un autre EMS / NMS ou si vous avez un NAT entre le périphérique et votre application mgmt.

  1. Si vous n'avez pas besoin de prendre en charge les traps NAT / transférés à partir d'autres NMS, faites simplement une copie du paquet udp et route en fonction de l'ip

  2. Si vous devez prendre en charge cela, vous devez analyser le piège SNMP et vérifier la correspondance de l'ID du moteur pour v2 / v3, pour v1, vous pouvez le lire dans le champ d'adresse de l'agent dans l'en-tête SNMP.


0

un hack de plus basé sur 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

[hypothèse - tous les pièges sont envoyés vers 10.0.0.1, qui les redirige ensuite vers 10.0.0.2, 10.0.0.3, 10.0.0.4]

tant que vous avez des interruptions snmp d'un paquet - cela devrait bien répartir la charge - dans ce cas sur 3 machines. [même si je ne l'ai pas testé].


En fait, nous ne voulons vraiment pas que la charge soit répartie de manière aléatoire. Nous voulons que tous les pièges d'un sous-réseau donné atteignent la même machine afin que nous puissions corréler les événements à des sites spécifiques. À l'heure actuelle, mes règles IPTables définissent la destination DNAT en fonction de la source du piège.
Christopher Cashell

@Christopher Cashell - puis alternativement à votre solution, vous pouvez utiliser le module u32 netfilter pour «hacher» le serveur de destination en fonction de l'adresse IP src. par exemple, prendre les 2 derniers bits de l'adresse IP src et répartir la charge sur 4 «consommateurs» snmp. netfilter.org/documentation/HOWTO/…
pQd

@Christopher Cashell stearns.org/doc/iptables-u32.v0.1.html est un joli tutoriel pour le match u32. alternativement - regardez le projet "linux virtual server" - ils peuvent aussi faire un équilibrage de charge pour les paquets udp basés sur src / dst ip.
pQd

0

Je pense que la réponse de chmeee est la bonne voie à suivre. Débarrassez-vous d'UDP et de SNMP dès que possible dans le processus, ils sont horribles à gérer.

Je construis maintenant un système qui placera tous les événements (y compris les interruptions) dans une file d'attente JMS, puis utilisera toutes les merveilles de la messagerie d'entreprise pour effectuer l'équilibrage de charge et le basculement.


Je pense que vous vous méprenez. . . Je n'essaie pas de construire un système de surveillance complet, juste un routeur de déroutement SNMP. Nous avons 5000 périphériques réseau et des centaines de milliers de ports que nous surveillons ici. Il n'y a aucun moyen que je réinvente cette roue. . . juste essayer d'améliorer les outils dont nous disposons.
Christopher Cashell

Je vous ai bien compris, vous ne m'avez probablement pas compris;) JMS est utilisé comme transport parce que les courtiers modernes ont toutes ces fonctionnalités de basculement, de persistance et d'équilibrage. Vous pouvez poster sur une URL, envoyer un e-mail, SOAP, tout ce qui fonctionne. UDP n'a jamais été conçu pour être fiable ou équilibrable car il n'a aucun concept de flux de données ou de contrôle de flux. Vous serez juste foutu sur le long terme en essayant de faire UDP ce qu'il n'a pas été conçu pour faire.
Aleksandar Ivanisevic

J'apprécie la suggestion, mais je n'ai vraiment aucune intention ni intérêt de construire mon propre système de surveillance de réseau au niveau de l'entreprise. Il y en a déjà beaucoup disponibles, et l'implémentation d'un avec l'ensemble de fonctionnalités et l'évolutivité dont nous avons besoin nécessiterait une équipe d'une douzaine de programmeurs pendant 2 à 4 ans. Ce n'est ni faisable ni souhaitable. Cela me laisse interagir avec les systèmes existants, et cela me laisse faire face à beaucoup de SNMP sur UDP.
Christopher Cashell

0

Votre problème principal va être, comment savez-vous l'IP réelle de l'appareil dont vous recevez les pièges?

Pour obtenir l'IP de l'expéditeur d'origine, vous pouvez essayer de patcher le snmptrapd avec ce patch - https://sourceforge.net/p/net-snmp/patches/1320/#6afe .

Cela modifie la charge utile, de sorte que les en-têtes IP seront conservés intacts, afin qu'ils n'entrent pas dans votre routage et / ou NATting.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.