betroffene 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 

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 

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|http://download.ffgraz.net/collectd|Download-Server] zu finden.

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.

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.

#!sh (-)
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 [[[http://firmware.leipzig.freifunk.net/kamikaze/|ff-luci|http://firmware.leipzig.freifunk.net/kamikaze/|ff-luci]]] der Freifunk Firmware auf Basis von Kamikaze 
        selber bauen 

      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? 

    ✓ collectd-Patch (=collectd als Routing-Daemon verwenden) 
    * Patch notwendig und jede collectd-Instanz muß alle Nachrichten der anderen auf Duplikate überprüfen. 

    ganglia (gmond) 
    * kann out-of-the-box auf verschiedenen Interfaces Multicast-Traffic senden/empfangen, aber offenbar nur innnerhalb eines Clusters. 

    IPv6 = neue Firmware oder zusätzliches Kernel-Modul 
    - IPv6 Kernel-Unterstützung (auch ohne Multicast-Routing) 
    - Multicast Routing-Daemon (mrd6) 

    :!: olsr-bmf (OLSR Multicast forwarding plugin) 
    * Damit aber sicher Abhängigkeit von OLSRd und es hat einen eher experimentellen Status 

Legende:

<gloss><label>Alphanumerische oder punktuelle Gliederung</label><item>entweder/oder (XOR)

</item><label>Numerische Gliederung</label><item>und (AND)

</item><label>bereits verfügbar</label><item>

</item><label>bereits implementiert</label><item>✓

</item></gloss>