Wer viele Netzwerksysteme betreibt, kann auch viele Probleme bekommen. Fehlen die Mitarbeiter für eine Echtzeitüberwachung, genügen SNMP und ein paar kleine Skripte, um den Gerätezoo im Blick zu behalten.

Router, Switches, Server, Drucker – Datennetze enthalten viele komplexe Komponenten. Will man sie trotzdem mit möglichst geringem organisatorischen und finanziellen Aufwand überwachen, helfen schon ein Raspberry Pi und das Simple Network Management Protocol SNMP. Letzteres lässt sich nutzen, um Werte wie Datendurchsatz, CPU-Auslastung oder Temperatur eines Geräts abzufragen oder das entsprechende System sogar neu zu konfigurieren.

SNMP ist der Nachfolger des Simple Gateway Management Protocol (SGMP). Seine Spezifikation wurde 1990 von der Internet Engineering Task Force (IETF) verabschiedet und seitdem mehrmals überarbeitet. Mittlerweile liegt sie in der dritten Version vor. Dabei bietet SNMPv3 im Gegensatz zu den Vorgängern verschlüsselte Kommunikation und eine sichere Authentifizierung. Allerdings unterstützen viele heute zu erwerbende Geräte nach wie vor nur SNMPv1 oder SNMPv2.

Das Protokoll in Kürze

SNMP nutzt standardmäßig den UDP-Port 161. Die Kommunikation erfolgt mittels Agenten und Managern, wobei die Agenten auf den einzelnen Geräten laufen und auf Abfragen oder Anweisungen durch den oder die Manager warten. Es gibt zudem noch die SNMP-Traps, bei denen ein Gerät bei bestimmten Ereignissen aktiv eine Meldung an einen Manager verschickt. Diese läuft in der Regel auf dem Port 162 des Managers ein.

SNMP liest Werte verschiedener Netzwerkkomponenten aus, die Managed Objects. Bei einem solchen Managed Object kann es sich um den Status einer Netzwerkschnittstelle, CPU oder den Speicher eines Geräts handeln. Um hier einen Standard zu etablieren, wurde die SNMP-Management Information Base (MIB) entwickelt. In der baumartig organisierten MIB sind die Eigenschaften zahlreicher Managed Objects beschrieben. Die Beschreibungen enthalten den genauen Namen oder die OID (Object Identifier) sowie die erlaubten Datentypen eines Objekts. Die OID können numerisch oder menschenlesbar vorliegen – so meinen .iso.org.dod.internet.mgmt und .1.3.6.1.2 das gleiche Objekt und lassen sich dementsprechend später bei Abfragen gleichberechtigt verwenden.

SNMPv1 und SNMPv2 bauen über die sogenannten Communities Verbindungen auf, denen Manager und Agenten vertrauen. Dazu existieren die Community-Namen für Nur Lesen, Lesen und Schreiben sowie Trap. Die Community-Namen ersetzen das Passwort. Da sie jedoch als Klartext übertragen werden, kann ein Angreifer sie relativ leicht abfangen. Mit den Community-Namen lassen sich verschiedene Aktivitäten abwickeln.

Mit dem Nur-Lesen-Community-String, den die meisten Hersteller mit public voreinstellen, dürfen Sie lediglich Daten am Gerät abfragen. Der Lesen-Schreiben-Community-String, der bei Geräten im Auslieferungszustand meist private lautet, erlaubt auch Änderungen am Gerät vorzunehmen. So dürfen Sie Zähler zurücksetzen oder auch die Router-Konfiguration ändern.

Der Trap-Community-String ist letztendlich nötig, damit Manager die Trap-Meldungen der Agenten entgegennehmen. Die beiden letzten Community-Strings trifft man auf Geräten für Endbenutzer jedoch nicht so häufig an. Noch seltener ist SNMPv3 zu finden, bei dem die gesamte Kommunikation verschlüsselt abläuft und sich die Teilnehmer regulär authentifizieren müssen.

Das Szenario

Wir zeigen am Beispiel eines Komplexes aus Seminar- und Gästehäusern, dessen Nutzer sich in der Vergangenheit sporadisch über eine langsame Internetverbindung beklagten, wie sich mit den Net-SNMP-Werkzeugen [1] einige Gerätewerte abfragen und gegebenenfalls protokollieren lassen. Darauf basierend können Sie weitere Informationen zum Geschehen im Netzwerk einsammeln und Entscheidungen über Infrastrukturverbesserungen treffen.

Die Bildungsstätte Hochlland in Potsdam [2] besteht aus drei mehrstöckigen Seminar- und Gästehäusern, die rege von Schulklassen sowie Gruppen der Jugend- und Erwachsenenbildung genutzt werden. Die drei Häuser teilen sich einen Internetanschluss und sind via Funk und Kabel mehr oder weniger gut miteinander verbunden. Die WLAN-Versorgung für die Gäste erfolgt durch derzeit acht Access Points (APs), in der nächsten Ausbaustufe soll ihre Anzahl auf vierzehn ansteigen.

Die Bildungsstätte verfolgt das Konzept der Selbstorganisation, was bedeutet, dass die Gruppen die Häuser völlig selbstständig nutzen. Personal ist nicht immer vor Ort, sodass sich Probleme mit der meist stabilen Internetanbindung im Nachhinein nur schwer nachvollziehen lassen. Viele Gruppen reisen allein an und ab – wobei es gelegentlich passiert, dass auch einmal ein AP ungefragt mitreist. Darüber hinaus gibt es Nachbarn, die an die Zugangsdaten des halböffentlichen Hauses gelangt sind und das Netz gern und ausgiebig nutzen. Diesen soll der Zugang möglichst erschwert werden.

Vorbereitungen

Um die auftretenden Probleme zeitnah zu erkennen, haben wir in dem Haus einen Raspberry Pi als Monitor installiert. Er soll die Geräte überwachen, bei ausgewählten Ereignissen zusätzliche Werte abfragen, protokollieren und gegebenenfalls Mitarbeiter benachrichtigen. Auf dem RasPi läuft das Raspbian-Minimal-Image Darkbasic [3]. Es wurde um die Raspberry-Pi-Paketquellen erweitert (Listing 1, Zeile 1 bis 3), aktualisiert (Zeile 4 und 5), mit den nötigen Anwendungen bestückt (Zeile 6) – insbesondere aus den Paketen snmp und snmp-mibs-downloader – sowie einem Firmware-Update unterzogen (ab Zeile 7).

$ sudo echo "deb http://archive.raspberrypi.org/debian wheezy main" >> /etc/apt/sources.list
$ sudo wget http://archive.raspberrypi.org/debian/raspberrypi.gpg.key -O raspberrypi.gpg.key
$ sudo apt-key add raspberrypi.gpg.key
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get install vim vim-runtime aria2 ntpdate anacron msmtp-mta bsd-mailx raspi-config less screen snmp snmp-mibs-downloader
$ sudo curl -L --output /usr/bin/rpi-update https://raw.githubusercontent.com/Hexxeh/rpi-update/master/rpi-update && chmod +x /usr/bin/rpi-update
$ sudo rpi-update
$ sudo reboot

Auf allen eingesetzten APs mit DD-WRT [4] (Abbildung 1) oder Ubiquiti AirOS [5] haben wir die SNMP-Agents aktiviert (Abbildung 2). Die quasi historisch gewachsene WLAN-Versorgung bietet noch keine Lösung aus einem Guss, sodass wir auf einigen Routern und dem RasPi noch statische Routen setzen mussten, damit der Mini-Rechner sämtliche Geräte erreicht. Listing 2 zeigt, wie Sie die Routen mit route statisch setzen. Funktioniert alles, wandern entsprechende Einträge unter dem passenden Netzwerkinterface in die Konfigurationsdatei /etc/network/interfaces, sodass sie bei einem Reboot nicht verloren gehen (Listing 3).

Abbildung 1: Der SNMP-Agent der freien Router-Firmware DD-WRT ist schnell aktiviert und akzeptiert lesende und schreibende Zugriffe.

Abbildung 2: Viele im Handel erhältliche Netzwerkgeräte bringen bereits einen SNMP-Agenten mit.

$ sudo route add -net 192.168.100.0/24 gw 192.168.2.2
$ sudo route add -net 192.168.13.0/24 gw 192.168.2.2

# /etc/network/interfaces
up route add -net 192.168.100.0/24 gw 192.168.2.2 dev eth0
up route add -net 192.168.13.0/24 gw 192.168.2.2 dev eth0

SNMP im Einsatz

Nach dem Abschluss der Vorbereitungen können Sie in einem ersten Test alle via SNMP verfügbaren Informationen eines Geräts abfragen. Dabei hilft folgendes Kommando:

$ sudo snmpwalk -v1 -c RO-Community-String Host OID

Der Parameter -v1 erzwingt den Einsatz von SNMPv1, den Community-String setzen Sie mit -c. Hinzu kommen der Hostname oder die IP-Adresse des abzufragenden Rechners sowie die OID. Geben Sie für Letztere lediglich einen Punkt an, fragt Snmpwalk alle verfügbaren OIDs ab (Abbildung 3). Je genauer die OID, desto geringer fällt letztendlich die Informationsflut aus.

.) beginnender Snmpwalk liefert viele Ergebnisse.” width=”300″ height=”182″ /> Abbildung 3: Ein an der Wurzel des MIB-Baums (OID: .) beginnender Snmpwalk liefert viele Ergebnisse.

Informationen über die Bedeutung einzelner OIDs finden Sie oft auf den Seiten der Gerätehersteller oder in einschlägigen Internetforen. Zudem existiert eine ganze Reihe standardisierter OIDs, etwa für Namen und Uptime eines Geräts sowie die Anzahl der versendeten und empfangenen Pakete. Je nach Produkt lassen sich auch Informationen über die Anzahl der mit einem AP verbundenen Clients oder die Menge der verfügbaren und vergebenen DHCP-Leases abfragen.

Neben Snmpwalk gibt es eine Reihe weiterer SNMP-Kommandos. Während Snmpwalk den kompletten angeforderten OID-Zweig zurückliefert, beschränkt sich Snmpget allein auf die angeforderte OID. Standardmäßig liefern die Kommandos OIDs unter Debian/Raspbian im numerischen Format zurück. Möchten Sie stattdessen lieber die zugehörigen Namen sehen, um die Bedeutung des Eintrags besser einschätzen zu können, kommentieren Sie in der Datei /etc/snmp/snmp.conf die Zeile mibs : aus.

Im Hochlland interessieren uns letztendlich nur wenige Dinge: Kann man alle unsere Geräte noch erreichen? Wie viele WLAN-Clients sind mit den einzelnen APs verbunden? Wie steht es mit CPU- und Speicherauslastung, und wie viele Pakete durchlaufen die jeweiligen Geräte? Hier kann man beliebige weitere Punkte hinzunehmen.

Die Erreichbarkeit der Geräte prüfen Sie statt via SNMP besser schlicht mit einem Ping. Lässt sich ein System nicht ansprechen, bemängelt SNMP zwar ebenfalls den entsprechenden Timeout, was sich für weitere Auswertungen nutzen lässt. Das Stellen vieler SNMP-Abfragen dauert jedoch länger als einige wenige Pings abzusetzen.

In der Kürze …

Ein MIB-Baum enthält in aller Regel wesentlich mehr Informationen, als Sie für Ihre Auswertung benötigen. Sie tun sich daher durchaus einen Gefallen, wenn Sie sich auf wenige Informationen beschränken.

Die mit einzelnen Routern respektive Access Points verbundenen Geräte liefert beispielsweise der Zweig ioNetToMediaEntry (1.3.6.1.2.1.4.22.1). Verfügbaren und genutzten Speicher fragen Sie über 1.3.6.1.2.1.25.2.3.1.5.101 und 1.3.6.1.2.1.25.2.3.1.6.101 ab, die durchschnittliche CPU-Last der letzten fünfzehn Minuten erfahren Sie mit der OID 1.3.6.1.4.1.2021.10.1.5.3. Die OID 1.3.6.1.2.1.2.2.1 schließlich sammelt alle zu den Netzwerkschnittstellen verfügbaren Informationen ein. Hier lohnt es sich unter Umständen, die Datenmenge ebenfalls ein wenig zu reduzieren: MTUs, Schnittstellenbezeichnungen und so weiter müssen Sie nicht jedes Mal mitloggen.

Haben Sie sich überzeugt, dass Snmpwalk oder Snmpget das Gewünschte liefern, verpacken Sie die einzelnen Abfragen in ein Skript, das später via Cronjob ausgeführt wird. Snmpwalk bietet noch einige Möglichkeiten, um die Ausgaben zu kürzen. Im Beispielskript monitor.sh (Listing 4) erfolgt die Abfrage mit -Oqs so, dass nur das letzte Element der OID und der zugehörige Wert ausgegeben werden.

Die einzelnen Abfragen verpackt das Skript in einer Funktion, sodass Sie sie nur an einer Stelle ändern müssen, falls sich neue Anforderungen ergeben. Die zu überwachenden Hosts hinterlegen Sie mit IP-Adresse und Beschreibung in einer Textdatei (Listing 5). Die Beschreibung enthält Geräteart und Standort, sodass bei einer Alarmierung auch Mitarbeiter, die nicht an der Installation beteiligt waren, wissen, wo sie suchen müssen. Zu guter Letzt wird monitor.sh regelmäßig in einem Cronjob aufgerufen.

#! /bin/bash
#: Title: monitor.sh
#: Date: 28.01.2015
#: Author: Falko Benthin
#: Version: 1.0
#: Desciption: Sendet SNMP-Abfragen an einzelne APs/Router und loggt Ausgabe mit Zeitstempel für spaetere Auswertungen
#: Options: none
# sendet snmp-Abfragen an einzelne Hosts
function checkMachines() {
  # ipNetToMediaPhysAddress
  snmpwalk -v1 -Oqs -c $ROCOMMUNITY $HOST .1.3.6.1.2.1.4.22.1.3
  # memory_used
  snmpwalk -v1 -Oqs -c $ROCOMMUNITY $HOST .1.3.6.1.2.1.25.2.3.1.6.101
  # CPU-load-1 snmpwalk -v1 -Oqs -c $ROCOMMUNITY $HOST 1.3.6.1.4.1.2021.10.1.5.1
  # CPU-load-5 snmpwalk -v1 -Oqs -c $ROCOMMUNITY $HOST 1.3.6.1.4.1.2021.10.1.5.2
  # CPU-load-15
  snmpwalk -v1 -Oqs -c $ROCOMMUNITY $HOST .1.3.6.1.4.1.2021.10.1.5.3
  # wlan_clients
  snmpwalk -v1 -Oqs -c $ROCOMMUNITY $HOST .1.3.6.1.4.1.2021.255.3.54.1.3.32.1.4
  # ifInOctets
  snmpwalk -v1 -Oqs -c $ROCOMMUNITY $HOST .1.3.6.1.2.1.2.2.1.10
  # ifInUcastPkts
  snmpwalk -v1 -Oqs -c $ROCOMMUNITY $HOST .1.3.6.1.2.1.2.2.1.11
  # ifInDiscards
  snmpwalk -v1 -Oqs -c $ROCOMMUNITY $HOST .1.3.6.1.2.1.2.2.1.13
  # ifInErrors
  snmpwalk -v1 -Oqs -c $ROCOMMUNITY $HOST .1.3.6.1.2.1.2.2.1.14
  # ifOutOctets
  snmpwalk -v1 -Oqs -c $ROCOMMUNITY $HOST .1.3.6.1.2.1.2.2.1.16
  # ifOutUcastPkts
  snmpwalk -v1 -Oqs -c $ROCOMMUNITY $HOST .1.3.6.1.2.1.2.2.1.17
  # ifOutDiscards
  snmpwalk -v1 -Oqs -c $ROCOMMUNITY $HOST .1.3.6.1.2.1.2.2.1.19
  # ifOutErrors
  snmpwalk -v1 -Oqs -c $ROCOMMUNITY $HOST .1.3.6.1.2.1.2.2.1.20
  }
# Verzeichnis fuer Logfiles
LOGDIR="/home/falko/monitorlog"
# community string
ROCOMMUNITY="community"
# date
YEAR=$( date +%Y )
MONTH=$( date +%m )
DAY=$( date +%d )
while read HOST DESC
do
  DATEDIR=$LOGDIR/$YEAR/$MONTH/$DAY
  # Verzeichnis fuer Datum
  if [ ! -d $DATEDIR ]; then
    mkdir -p $DATEDIR
  fi
  # pruefen, ob Host erreichbar ist
  if ! ping -c3 $HOST > /dev/null; then
    if [ ! -e $LOGDIR/$HOST.lastmail.log ] || [ ! $( date -d @$( cat $LOGDIR/$HOST.lastmail.log ) +%d ) = $DAY ]
    then
      printf "Der AP/Router %s, %s ist nicht erreichbar. Bitte pruefen." $HOST "$DESC" | mail -s "AP/Router pruefen" recp1@mustermail.org recp2@mustermail.org recp3@mustermail.org
      echo $( date +%s ) > $LOGDIR/$HOST.lastmail.log
    fi
  else
    # SMTP-Checks und Logging
    checkMachines | \
    while read OUTPUT
    do
      printf "%s %s\n" $( date +%T ) "$OUTPUT" >> $DATEDIR/$HOST.log
    done
  fi
done < machines.txt
exit 0

192.168.2.1   Modem im Buero
192.168.2.2   Picostation Dach
192.168.10.1  AP Seminargebaeude
192.168.10.4  AP Kueche Hochlland
192.168.13.1  Picostation Neubau
192.168.13.2  AP Neubau unten
192.168.13.3  AP Neubau Mitte
192.168.13.4  AP Neubau oben

Logfiles

Wenn sich jetzt Gäste beschweren, dass das Internet langsam war, hilft ein Blick in die Logfiles des betroffenen Tages, um eventuelle Probleme aufzudecken oder festzustellen, ob Sie zusätzliche Informationen benötigen.

Ferner können Sie prüfen, ob es WLAN-Clients gibt, die sich auffallend häufig mit den APs verbinden und vielleicht eine Sonderbehandlung erfordern. Denkbar wäre, vom betreffenden WLAN-AP weitere Informationen abzurufen und auf deren Basis eine Firewall-Regel für den Client hinzuzufügen.

Mit der Zeit fallen recht viele Logdateien an. Das einmal täglich als Cronjob ausgeführte Script compress_and_delete.sh (Listing 6) hilft, Speicherplatz zu sparen, indem es die Logdateien des Vortags mit Gzip komprimiert und Logs nach 30 Tagen löscht.

#! /bin/bash
#: Title: compress_and_delete.sh
#: Date: 28.01.2015
#: Author: Falko Benthin
#: Version: 1.0
#: Desciption: Komprimiert alte Logs und löscht ganz alte Logs
#: Options: none
# Verzeichnis fuer Logfiles
LOGDIR="/home/falko/monitorlog"
# gestern
YEAR=$( date -d "yesterday" +%Y )
MONTH=$( date -d "yesterday" +%m )
DAY=$( date -d "yesterday" +%d )
# Logs von gestern komprimieren
gzip $LOGDIR/$YEAR/$MONTH/$DAY/*log
# alte Logs loeschen
find $LOGDIR -mtime +30 | xargs rm
exit 0

Fazit

Mit SNMP sammeln Sie viele Informationen ein, die bei einer späteren Auswertung helfen, aufgetretene Probleme nachzuvollziehen. Das Protokoll und die Abfragen fallen recht ressourcenschonend aus, sodass Sie dem Raspberry Pi durchaus noch weitere Aufgaben aufhalsen können.

Die puren SNMP-Abfragen sind allerdings nichts für Admins, die sich ein Echtzeit-Monitoring mit grafischer Darstellung wünschen. Gehören Sie zu dieser Riege, sollten Sie lieber zu MRTG, Cacti oder den klassischen Netzwerküberwachungswerkzeugen Nagios/Icinga, Zabbix oder Munin greifen.