Leider erreichen uns regelmäßig Hilferufe von Kunden, die eine Netzwerk-Störung erleiden mussten.

In vielen Fällen sind einfache Missgeschicke von Anwendern die Ursache: Es wurde unwissentlich eine Schleife gesteckt oder ein externes Gerät angesteckt, welches falsche IP-Adressen verteilt. Die Folge: Eine massive Störung im Netzwerk. Im heutigen Blog-Beitrag möchte ich erläutern, wie Sie solche Missgeschicke mit einem Syslog-Monitoring schneller feststellen oder gar vermeiden können.

Allgemein

Wir nutzen gerne Observium für das Monitoring unserer Netzwerke. Mit verhältnismäßig wenig Arbeitsaufwand lässt sich mit Observium auch einfach und schnell ein umfangreiches Syslog-Monitoring Ihres Netzwerkes realisieren. Natürlich ist auch ein Syslog-Monitoring mittels ELK, check_logfiles oder vielen anderen Monitoring-Lösungen möglich.

Kernaussage dieses Blog-Beitrages soll sein: Nutzen Sie nicht nur SNMP- und Ping-Monitoring, sondern werten Sie auch die z.T. sehr umfangreichen Informationen aus dem Syslog aus – egal mit welchem Tool.

Bei welchen Fehlerbildern kann ein Syslog-Monitoring nützlich sein?

Beispiele

Hier eine kleine Auswahl:

• Virtual-Chassis Master Switch: Bei einem Ausfall des Master-Route-Engine innerhalb eines Virtual-Chassis, wird (bei richtiger Konfiguration 🙂 ) automatisch auf die Backup-Routing-Engine geschwenkt. Das ist natürlich gut, weil es unbemerkt verläuft – aber genau aus dem Grund kann es auch übersehen werden. Die Ursache möchten Sie aber in jedem Fall ermitteln.
  • CM_CHANGE: Member 0->0, Mode B->M, 0M 1B, GID 0, Master Changed, Members
  • CM_CHANGE: 0M 1B
  • CM_CHANGE: Mastership 0->1
• Storm-Control: Ein Loop! Der Albtraum eines jeden Netzwerk Admins. Egal ob durch Anwender, kaputte Geräte, fehlerhafte VM-Konfiguration etc.: Die Ursachen für Netzwerk-Loops sind vielfältig. JunOS bietet Ihnen die Möglichkeit betroffene Ports sofort mittels Storm Control zu blockieren – sozusagen als Schadensbegrenzung. Natürlich ist es auch für Sie als Admin wichtig herauszufinden, um welchen Port es sich genau handelt.
  • ESWD_ST_CTL_ERROR_IN_EFFECT: ge-0/0/10.0: storm control in effect on the port
• DHCP Protection: JunOS bietet die Möglichkeit DHCP-Offer Pakete auf gewissen Ports zu filtern. Wenn z.B. ein findiger Anwender seinen eigenen FritzBOX WLAN Access Point aufbauen möchte, soll natürlich verhindert werden, dass der DHCP-Server der FritzBox IP-Adressen in Ihrem Firmennetz verteilt. Als Admin möchten Sie natürlich sofort wissen, welcher Port betroffen ist.
  • ESWD_DHCP_UNTRUSTED: 1 untrusted DHCPOFFER received, interface ge-0/0/1.0[index 79], vlan CLIENT[index 2], server ip/mac 192.168.1.1/00:11:22:33:44:55[…]
• Doppelte IP-Adressen: JunOS wird Sie darauf aufmerksam machen, wenn jemand anders die IP-Adresse des Routers oder Switches nutzt. Dies ist etwas, was Sie in jedem Falle sofort unterbinden möchten, da hier theoretisch sogar ein Hacker-Angriff (Man in the Middle) dahinterstecken könnte.
  • Syslog Meldung: KERN_ARP_DUPLICATE_ADDR: duplicate IP address 10.1.1.1! sent from address: d8:b1:22:11:aa:00 (error count = 1234)

Syslog-Monitoring Einrichten

Die Observium Dokumentation beschreibt alle nötigen Schritte ausführlich.

Der Einfachheit halber beschränken wir uns auf „Regular Expression“. In der oben verlinkten Dokumentation habe ich die nötigen Strings für die RegEx bereits fett markiert. In folgendem Beispiel wird ein Syslog-Alert für doppelte IP-Adressen erzeugt.

Die genannten Beispiele beinhalten nur die häufigsten Fehlerquellen. Ferner kann es sein, dass sich die Syslog-Einträge je nach Release geringfügig unterscheiden.

Sie haben Fragen zum Syslog-Monitoring, Observium oder Sie möchten Ihr Netzwerk gegen die genannten Probleme absichern und somit die Verfügbarkeit Ihres Netzes erhöhen? Kontaktieren Sie uns!

Patrick Müller

Patrick Müller ist seit 2015 für die Proact Deutschland GmbH in Nürnberg tätig. Er beschäftigt sich hauptsächlich mit der Konzeption, Weiterentwicklung und dem Betrieb der Proact Cloud Services, ist aber auch als Consultant im Bereich Open Source und Netzwerk unterwegs. Vor seiner Zeit bei Proact war Patrick für ein Bankrechenzentrum tätig.