Monitoring

Ausgangspunkt

betroffene Geräte:

gesamt: ca. 20 Geräte

Das Ziel ist ein dezentrales Monitoring, welches folgende Punkte möglichst gut erfüllt

• dezentral
  • es gibt optimalerweise mehr als eine "zentrale" Instanz
• erweiterbar
  • zusätzliche Knoten und Server sind einfach einfügbar
• effizient
  • auch auf schwacher Hardware (WRT) sinnvoll lauffähig
• vielleicht unabhängig von OLSRd

Software

Distributed Monitoring im Sinne von ganglia/collectd kann in zwei Modi verwendet werden

• unicast
  • alle potentiellen Server-Adressen müssen auf jedem Gerät eingetragen werden (damit auch Abhängigkeit von OLSRd)
• multicast

Collectd

Vorteile:

• sehr geringer CPU- und Speicheroverhead
• Event-basierte Benachrichtigung

Nachteile:

• kein dediziertes Frontend

Pakete der Version 4.8.3 für OpenWRT Kamikaze 7.09 (x86) und Whiterussian RC6 (mipsel) bzw. die darauf basierende Freifunk-Firmware, sowie dazu passende Patches sind auf dem Download-Server zu finden.

Ganglia

Vorteile:

• unterstützt logische Gruppierungen
• Verwendung häufiger Übertragungsstandards
• fertiges Frontend

Nachteile:

• eigentlich für Cluster entwickelt und unterstützt daher auch Funktionen, die in diesem Fall nicht benötigt/erwünscht sind.

Multicast

Eine wichtige Vorabbedingung für die Verwendung von Multicast ist die Eignung des verwendeten Switch. Zum Glück unterstützt der Nortel Baystack 5510-48T (Standort/Spektral) IGMP-snooping für IGMPv1 und IGMPv2. Alle anderen Geräte sind entweder direkt verbunden oder haben eine (L2) transparente Verbindung zueinander.

Um mit dem Switch zusammenarbeiten zu können, muß daher auf den angeschlossenen Geräten folgendes eingerichtet werden, da der Linux Kernel je nach Version auch IGMPv3 unterstützt.

sysctl net/ipv4/conf/<interface>/force_igmp_version=2

• Unter Linux können im MFC (multicast forwarding cache) zwar statische Einträge angelegt werden (z.B. mit smcroute), aber es sind nur (S,G)-Einträge und keine (*,G)-Einträge möglich.

1. funktioniert in einer Broadcast-Domain. Dies würde bedeuten, daß der Multicast-Verkehr über eine (Linux-)Bridge weitergeleitet werden muß. (z.B. mit ebtables ausschließlich auf Multicast-Verkehr reagieren)
2. funktioniert mit mehreren Broadcast-Domains, wenn ein Multicast-fähiger Router dazwischen ist. Dies kann auf mehreren Wegen erreicht werden.
   1. neue Firmware mit
      1. Kernel-Unterstützung für Multicast-Routing (MROUTE)

         • OpenWRT default

           • ab Kamikaze 8.09.2 bzw. rev. (generic-2.4) "18312" oder rev. (generic-2.6) 2.6.21, 2.6.25, 2.6.30 "16044" bzw. für 2.6.31, 2.6.32 "16713"

         • auch mit ff-luci der Freifunk Firmware auf Basis von Kamikaze

         • selber bauen
      2. Routing-Daemon (auch für forwarding!!)

         • smcroute

           • statische Multicast forwarding Einträge müssen für jeden upstream Host eingetragen werden
         • igmpproxy
           • leitet die IGMP-Nachrichten der "interessierten" Geräte weiter und legt entsprechende MROUTE_Cache-Einträge an. Wie verhält er sich mit upstream und downstream?

   2. collectd-Patch (=collectd als Routing-Daemon verwenden)

      • Patch notwendig und jede collectd-Instanz muß alle Nachrichten der anderen auf Duplikate überprüfen.
   3. ganglia (gmond)
      • kann out-of-the-box auf verschiedenen Interfaces Multicast-Traffic senden/empfangen, aber offenbar nur innnerhalb eines Clusters.
   4. IPv6 = neue Firmware oder zusätzliches Kernel-Modul
      1. IPv6 Kernel-Unterstützung (auch ohne Multicast-Routing)
      2. Multicast Routing-Daemon (mrd6)

   5. olsr-bmf (OLSR Multicast forwarding plugin)

      • Damit aber sicher Abhängigkeit von OLSRd und es hat einen eher experimentellen Status

Legende:

Alphanumerische oder punktuelle Gliederung

entweder/oder (XOR)

Numerische Gliederung

und (AND)

bereits verfügbar

bereits implementiert